14:42:13 <RRSAgent> RRSAgent has joined #csvw
14:42:13 <RRSAgent> logging to http://www.w3.org/2015/01/28-csvw-irc
14:42:15 <trackbot> RRSAgent, make logs public
14:42:15 <Zakim> Zakim has joined #csvw
14:42:17 <trackbot> Zakim, this will be CSVW
14:42:17 <Zakim> ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 18 minutes
14:42:18 <trackbot> Meeting: CSV on the Web Working Group Teleconference
14:42:18 <trackbot> Date: 28 January 2015
14:42:24 <ivan> Chair: Jeni
14:49:48 <JeniT> JeniT has joined #csvw
14:54:57 <gkellogg> gkellogg has joined #csvw
14:57:33 <danbri> @scribenick danbri
14:57:53 <trackbot> RRSAgent, make logs public
14:57:55 <trackbot> Zakim, this will be CSVW
14:57:55 <Zakim> ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 3 minutes
14:57:56 <trackbot> Meeting: CSV on the Web Working Group Teleconference
14:57:56 <trackbot> Date: 28 January 2015
14:58:35 <Zakim> DATA_CSVWG()10:00AM has now started
14:58:42 <Zakim> +[IPcaller]
14:58:53 <gkellogg> zakim, code?
14:58:53 <Zakim> the conference code is 2789 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), gkellogg
14:59:09 <ivan> zakim, dial ivan-voip
14:59:09 <Zakim> ok, ivan; the call is being made
14:59:11 <Zakim> +Ivan
14:59:22 <Zakim> +??P8
14:59:25 <gkellogg> zakim, I am ??P8
14:59:25 <Zakim> +gkellogg; got it
14:59:26 <ivan> zakim, drop me
14:59:27 <Zakim> Ivan is being disconnected
14:59:27 <Zakim> -Ivan
15:00:02 <ivan> zakim, dial ivan-voip
15:00:02 <Zakim> ok, ivan; the call is being made
15:00:04 <Zakim> +Ivan
15:00:13 <JeniT> ScribeNick: danbri
15:00:29 <Zakim> +danbri
15:00:32 <danbri> zakim, danbri is danbri
15:00:32 <Zakim> +danbri; got it
15:01:01 <danbri> zakim, who is on the call?
15:01:01 <Zakim> On the phone I see JeniT, Ivan, gkellogg, danbri.a
15:01:18 <danbri> regrets: phila
15:01:25 <danbri> regrets: bill
15:01:54 <jtandy> jtandy has joined #csvw
15:02:32 <danbri> noting https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0043.html from Wim to discuss later
15:02:49 <danbri> zakim, please remind ivan to remind jeni to discuss Wim's paper later
15:02:49 <Zakim> I don't understand you, danbri
15:03:03 <jtandy> just dialling in now ... waited for firealarm to complete
15:03:39 <Zakim> +??P15
15:03:51 <jtandy> zakim, ??P15 is me
15:03:51 <Zakim> +jtandy; got it
15:03:57 <danbri> jenit: let's go through the list of issues that gregg highlighted, ie. https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0050.html
15:04:15 <jtandy> (apologies - very limited work from me this week)
15:04:41 <danbri> jenit: I went through this earlier, can we start w/ #80 ?
15:05:03 <danbri> … unless otherwise let's assume closed #43, 76, 77, 78
15:05:09 <ivan> https://github.com/w3c/csvw/issues/80
15:05:13 <danbri> jenit: #80 is re json-ld context's contents.
15:05:23 <danbri> suggests resolution is an array of strings followed by an object
15:05:50 <danbri> jenit: seems fine but suggest could just be string not required to haev an empty object
15:05:57 <Zakim> -gkellogg
15:05:59 <danbri> <- jenit can you double check i got that right?
15:06:22 <Zakim> +??P8
15:06:23 <ivan> s/haev/have/
15:06:34 <gkellogg> zakim, I am ??P8
15:06:34 <Zakim> +gkellogg; got it
15:06:46 <gkellogg> Looking at audio settings
15:06:59 <danbri> gkellogg.volume(7)
15:07:50 <danbri> gkellogg: there are 3 possibilities, … there is string, a specific ref to our ns. 2nd: an array of string followed by an object. 3rd: just an object, ns is implied.
15:08:02 <danbri> in 3rd case I'm weakly opposed to that as requires special knowledge
15:08:06 <danbri> * /me nods, agrees
15:08:33 <danbri> jenit: I suggested either 1st or 2nd, i.e. you could put either one of those into a metadata doc and it would be ok
15:08:52 <danbri> gkellogg: lastly if an object is there it can only have language and base, i.e. not adding new term definitions
15:09:03 <danbri> jenit: that makes it v restricted compared to full json-ld
15:09:24 <danbri> gkellogg: if it were up to me, … it would be full json-ld. But I got msg from ivan et al to be more minimalistic.
15:09:32 <jtandy> q+ to ask whether people _can_ do full JSON-LD in their implementations if they want to
15:09:33 <danbri> … after experience and feedback we might move towards fuller form
15:09:38 <JeniT> ack jtandy
15:09:38 <Zakim> jtandy, you wanted to ask whether people _can_ do full JSON-LD in their implementations if they want to
15:10:04 <danbri> jtandy: presumably they could honour the json-ld stuff …?
15:10:36 <danbri> jenit: not entirely true, because if it is a restricted subset a full processor would be too permissive and let things through that ought not to be accepted
15:10:42 <danbri> jtandy: ok
15:11:07 <danbri> I missed audio earlier in that sentence, can you type it?
15:12:02 <JeniT> .RESOLUTION: #80 JSON-LD must contain EITHER a string “http:/www.w3.org/ns/csvw” OR an array of the string “http://www.w3.org/ns/csvw” followed by an object which MAY contain @language and @base and no other values
15:12:07 <jtandy> +1
15:12:12 <danbri> +1
15:12:15 <JeniT> +1
15:12:17 <ivan> +1
15:12:26 <gkellogg> +1
15:12:32 <JeniT> RESOLUTION: #80 JSON-LD must contain EITHER a string “http:/www.w3.org/ns/csvw” OR an array of the string “http://www.w3.org/ns/csvw” followed by an object which MAY contain @language and @base and no other values
15:13:18 <danbri> rrsagent, pointer?
15:13:18 <RRSAgent> See http://www.w3.org/2015/01/28-csvw-irc#T15-13-18
15:13:45 <rgrp> rgrp has joined #csvw
15:13:48 <rgrp> hi all
15:13:51 <rgrp> sorry for late arrival!
15:13:55 <danbri> gkellogg: did we resolve to close 43-78 as outlined?
15:14:00 <danbri> jenit: yes
15:14:14 <rgrp> hoping to in a minute or so
15:14:38 <danbri> rgrp, we're working through https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0050.html … just passed #80
15:14:42 <JeniT> RESOLUTION: We will resolve #43, #76, #77, #78 as suggested in https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0050.html
15:15:04 <JeniT> https://github.com/w3c/csvw/issues/81
15:15:08 <danbri> #81 is about aliasing of the json-ld keywords
15:15:14 <danbri> #81 "Should JSON-LD keywords be aliased" – "Resolve not to alias keywords"
15:15:26 <danbri> (that's gregg's proposal)
15:15:44 <danbri> jenit: there are subissues. One was about dropping @type. I think we should drop having @type anywhere.
15:16:06 <danbri> … only place it is remotely useful is for actual json-ld. If it is always optional they'll have to do something extra anyway.
15:16:19 <danbri> ivan: am fine w/ that, but do we want to drop the corresponding typing from the json-ld conversion
15:16:28 <danbri> jenit: suggest keeping it there, but not in metadata
15:16:48 <danbri> jtandy: the metadata doc spec says "one of these has to be of that type", i.e. it is superfluous
15:17:04 <rgrp> danbri: i am happy to drop @type if we replace with @datatype (if we want json-ld type support for columns - i'm happy without)
15:17:11 <JeniT> .RESOLUTION: We remove @type properties in the metadata document
15:17:27 <JeniT> rgrp: what you want is being handled by the ‘datatype’ property currently
15:17:41 <danbri> rgrp, don't tell me, I'm only scribing :)
15:17:50 <danbri> zakim, who is on the call?
15:17:50 <Zakim> On the phone I see JeniT, Ivan, danbri.a, jtandy, gkellogg
15:18:26 <danbri> [discussion of @type, which says different things to datatyping ]
15:18:52 <Zakim> +[IPcaller]
15:19:46 <danbri> q+ to check IPcaller is Rufus
15:19:59 <danbri> jenit: it is still useful to have those terms defined in the vocab
15:20:00 <danbri> q-
15:20:21 <rgrp> JeniT: re datatype see https://github.com/w3c/csvw/issues/26
15:20:49 <danbri> what was the verdict on #81 then? resolving @type first?
15:21:32 <danbri> danbri: I Wouldn't want my file declared invalid just because i leave them in
15:21:42 <danbri> jenit: then we'd have to expect them
15:21:50 <danbri> … as we've said it would be an error if there is anything in there
15:22:11 <danbri> gkellogg: json-ld is generally more permissive/flexible
15:22:22 <danbri> jenit: @type is being used in places that common properties aren't
15:22:27 <danbri> gkellogg; basically template and dialect
15:22:44 <danbri> …otherwise anywhere a common property can exist, we can also consider @type a common property
15:23:03 <danbri> jenit: if you're arguing that should allow peopel to do that, then we should have a rule that it must be this value
15:23:10 <danbri> otherwise you get a WRONG metadata doc
15:23:28 <danbri> we have to either say you can't put in @type or if optional it must be consistent with the vocabulary defined
15:23:37 <danbri> gkellogg: in which case I'd rather leave it as-is.
15:23:43 <danbri> ivan: I'm not convinced it is useful for anything.
15:24:02 <danbri> … people will probably forget it, doesn't add info for anyone except those who care about rdf
15:24:23 <danbri> jtandy: I thought that if we leave the spec as-is, …  if people put it in or leave it in, that's fine; if they use wrong type, that's an error.
15:24:26 <danbri> jenit: yup
15:24:35 <danbri> jtandy: which seems fine. most people won't bother.
15:24:43 <danbri> (I'm fine with the status quo)
15:24:55 <danbri> jenit: seems sufficient support for status quo
15:25:00 <rgrp> I like @id to url :-)
15:25:02 <danbri> only other thing in #81 was changing @id to url
15:25:12 <rgrp> or removing @id and url property
15:25:17 <danbri> … or preferably removing @id or making it optional like @type and adding a url property
15:25:19 <rgrp> +1 to JeniT here
15:25:25 <jtandy> q+
15:25:45 <danbri> I'm agnostic. We're skirting around http-range-14 blablah with url.
15:25:56 <JeniT> ack jtandy
15:25:59 <danbri> jenit: semantic slipperyness, table vs thing table describes
15:26:13 <danbri> gkellogg: a url property could be used just on table
15:26:26 <danbri> jenit: yes only useful for pointing to the csv file that underlies the table.
15:26:36 <danbri> jtandy: url property points to the csv file in which the table is described.
15:26:48 <danbri> … allowing us to be a little bit ambiguous re identifying the table itself.
15:26:56 <ivan> q+
15:27:03 <danbri> if someone did use @id they'd likely be talking about the table as opposed to the csv file
15:27:11 <JeniT> ack ivan
15:27:31 <danbri> ivan: strictly speaking, and this is why having url is a good idea, … if the metadata file is json-ld, then the @id actually identifies the metadata
15:27:41 <danbri> if i regard it as a json-ld content, that's what it means in json-ld
15:28:05 <danbri> ivan: what really counts is the URL for the data itself
15:28:25 <danbri> … if someone wants that id for the abstraction that's @id
15:28:32 <danbri> (+1 for optional and url)
15:28:34 <rgrp> +1 JeniT proposal
15:28:46 <danbri> jenit: proposing making @id optional and proposing an url property.
15:28:58 <danbri> gkellogg: url property woudl also then be used on template
15:29:03 <JeniT> .RESOLUTION: make @id optional, add url property to point to CSV / template files etc
15:29:09 <danbri> jtandy: would also need to ref table group?
15:29:09 <JeniT> +1
15:29:11 <danbri> +1
15:29:19 <gkellogg> +1
15:29:22 <jtandy> +1
15:29:26 <ivan> +1
15:29:36 <JeniT> RESOLUTION: make @id optional, add url property to point to CSV / template files etc
15:30:10 <JeniT> RESOLUTION: otherwise close #81 with no other aliasing
15:30:21 <danbri> next: 86
15:30:33 <JeniT> https://github.com/w3c/csvw/issues/86
15:30:37 <danbri> https://github.com/w3c/csvw/issues/86 schema term ambigious
15:31:04 <danbri> jenit: this one makes me roll my eyes… Because the rdfa context defines prefix 'schema:' to mean schema.org, then we can't use the property 'schema' to use something else in our document.
15:31:26 <danbri> gkellogg: if we follow that chain, … that's how it is used as a property
15:32:06 <danbri> jenit: i think it would be perfectly reasonable to have "schema:" as a prefix to mean http://schema.org/ … is there a way they can be disambiguated?
15:32:21 <danbri> … pushing on this because schema is the term used in the table description format
15:32:54 <danbri> jtandy: […] table groups / tables schemas .. .might be multiple
15:33:14 <danbri> rgrp: the table group thing, … can i ask, is that grouping of tables within a group of csvs?
15:33:21 <danbri> jenit: no, it is more like a group of csv files
15:33:33 <danbri> rgrp: it's like having a [missed]
15:33:43 <danbri> (rgrb, missed your comment can you retype?)
15:34:03 <danbri> jenit: so in that case, as i'm the only one annoyed by this, … go with gregg's resolution
15:34:20 <JeniT> RESOLUTION: #86 change ‘schema’ to ‘tableSchema’ to avoid conflict with schema: prefix
15:34:25 <rgrp> danbri: my point was that i'd raised multiple tables early on as in (tabular) data package - in fact default - you have a entry called resources and tables come under that ...
15:34:33 <danbri> (on behalf of schema.org, we didn't mean to impose on anyone else's use of 'schema' in property names!)
15:34:42 <rgrp> so default is multiple files / tables - and i think that is a great idea - if it could be aligned with tabular data package that would be really good!
15:34:46 <JeniT> https://github.com/w3c/csvw/issues/93
15:34:46 <danbri> jenit: next is #93 https://github.com/w3c/csvw/issues/93
15:34:47 <ivan> s/danbri:/rgrp:/
15:34:54 <danbri> … I just didn't understand the proposed resolution.
15:35:20 <danbri> rgrp, [clarifies that he likes simplicity in standards]
15:35:43 <danbri> #93: gregg, what's the suggestion here?
15:36:00 <danbri> gkellogg: 2 things. We just got rid of @id, so no confusion between metadata and actual data
15:36:08 <danbri> … also use of fragment ID
15:36:22 <danbri> id in output, … subject of the output for the table, would be the csv location with the table fragment identifier
15:36:34 <danbri> … that is basically taking some of jtandy's description in the csv2json doc
15:36:45 <danbri> … i'd certainyl be willing to separate that out as a separate issue
15:36:52 <danbri> … i think we've addressed the primary concern here
15:36:56 <danbri> rrsagent, pointer?
15:36:56 <RRSAgent> See http://www.w3.org/2015/01/28-csvw-irc#T15-36-56
15:37:26 <danbri> jtandy: there's a bit in here about whether to use the dcat terminology around terminology, versus the dataset, which i used in the rdf output
15:37:41 <rgrp> +q
15:37:44 <danbri> to try to make sure that i'm clear about the diff between the csv files vs the abstract dataset that the csv file describes
15:38:23 <danbri> rgrp, can anyone explain to me a user story, where a user will care, … not transforming to some other dataset, … who would care about the distinction
15:38:27 <ivan> ack rgrp
15:38:38 <danbri> … who would it need to matter to?
15:38:55 <danbri> jenit: only relevant to the rdf mapping
15:38:59 <danbri> q+
15:38:59 <gkellogg> q+
15:39:22 <JeniT> ack danbri
15:40:30 <JeniT> I really don’t want to have an HR14 discussion here
15:41:07 <rgrp> +1 JeniT
15:41:09 <danbri> I'm fine not persuing this.
15:41:15 <gkellogg> q-
15:41:33 <danbri> The distinction I mentioned was indeed different (but relates to the URis that the rdf mapping emits). I've interest in http-range-14 today!
15:41:40 <danbri> q?
15:41:42 <jtandy> (accepts)
15:41:46 <rgrp> +1 JeniT - but does that mean #93 is wontfix - i.e. no change
15:42:20 <JeniT> https://github.com/w3c/csvw/issues/96
15:42:21 <danbri> action gregg to open a separate issue from #93 and close #93.
15:42:21 <trackbot> Created ACTION-61 - Open a separate issue from #93 and close #93. [on Gregg Kellogg - due 2015-02-04].
15:42:53 <danbri> #96 about separate properties
15:43:03 <ivan> q+
15:43:09 <danbri> "Should the cell-value URI Template be treated as a datatype? "
15:43:20 <gkellogg> PROPOSAL: I propose to follow @iherman's suggestion (essentially), and have three Column properties subjectUrl, predicateUrl, and objectUrl, all of which are URI Template properties. Furthermore, subjectUrl' replacesurlTemplate` as a Schema property (or becomes an inherited property).
15:44:06 <JeniT> https://github.com/w3c/csvw/issues/96#issuecomment-71834886
15:44:29 <rgrp> ack - i'm deferring as outside my expertise here :-)
15:44:31 <danbri> jenit: … rather rdf'y terms, but otherwise fine. It would be good to have a Pull Request on github w/ the proposal in it.
15:44:35 <rgrp> JeniT: has my proxy :-)
15:44:38 <danbri> ivan: can we separate two things?
15:45:13 <danbri> … having these 3 properties with the names you propose. That is clean and we can all agree. But then discussion on which structures exactly these properties can be placed.
15:45:36 <danbri> if we put e.g. property URIs as a possibility for the schema as a whole, … we may need additional variables for the templating mechanism
15:45:38 <danbri> ...
15:46:19 <danbri> ivan: I sent one comment 5 mins before call, … whether we allow a different subject per column.
15:46:25 <danbri> that has consequences for the json and rdf output.
15:46:29 <danbri> (Is that issue tracked?)
15:46:58 <danbri> gkellogg: this also relates to whether the row values are in a list or not
15:47:04 <danbri> ivan: i don't think so
15:47:16 <danbri> … somehow we put that aside in one of our meetings, to just use a row id
15:47:30 <danbri> jenit: why don't we resolve right now, to adopt 3 sep properties, …
15:47:35 <danbri> … about property and value
15:47:50 <danbri> (jeni's typing the proposal?)
15:47:51 <JeniT> .RESOLUTION: adopt three separate Url properties (about/property/value), editor to suggest exactly how that works within a PR
15:47:54 <gkellogg> +1
15:47:55 <danbri> +1
15:47:58 <JeniT> +1
15:48:00 <ivan> +1
15:48:07 <jtandy> +1
15:48:47 <danbri> jtandy: … and the 'about' url is the one with potential impl for the json or rdf conversions?
15:49:01 <danbri> ivan: if we allow them to add in a column [did i get that right? --dan]
15:49:08 <danbri> … there is a potential conflict if we go down that route
15:49:24 <JeniT> RESOLUTION: adopt three separate Url properties (about/property/value), editor to suggest exactly how that works within a PR
15:49:25 <danbri> gkellogg: if we do not allow them in the column, that's an inconsistency
15:49:30 <danbri> ivan: that would be easy to clear up.
15:49:40 <danbri> rrsagent, pointer?
15:49:40 <RRSAgent> See http://www.w3.org/2015/01/28-csvw-irc#T15-49-40
15:50:04 <danbri> jenit: #98, #101 ok as proposed?
15:50:16 <JeniT> https://github.com/w3c/csvw/issues/98
15:50:24 <JeniT> https://github.com/w3c/csvw/issues/101
15:50:26 <danbri> [fine]
15:50:35 <JeniT> (101 is same as 96 really)
15:51:03 <JeniT> RESOLUTION: resolve #98 and #101 as Gregg suggests
15:52:08 <danbri> editors to take on these resolutions
15:52:27 <JeniT> https://github.com/w3c/csvw/issues/128
15:52:46 <danbri> jtandy: gregg, you suggested removing alis for xsd language, … i think it will still be useful
15:52:55 <danbri> … and do what ivan suggested, changing where we have language to lang
15:53:01 <danbri> gkellogg: i'm fine with that
15:53:08 <danbri> jenit: you just wanted it one way or the other?
15:53:14 <danbri> gkellogg: yes.
15:53:29 <danbri> rgrp: some of the issues in tracker are quite ambigiously described
15:54:01 <danbri> rrsagent, pointer?
15:54:01 <RRSAgent> See http://www.w3.org/2015/01/28-csvw-irc#T15-54-01
15:54:29 <danbri> jenit: conversation in the issues can tend to meander, please try to be more strict
15:54:31 <rgrp> danbri: more than just having resolution here (which is sometimes just "accept #xx" we need to summmarize precisely what was agreed on that issue
15:54:58 <JeniT> .RESOLUTION: change ‘language’ to ‘lang’ so we can keep ‘language’ as meaning ‘xsd:language’
15:55:04 <gkellogg> +1
15:55:08 <ivan> +1
15:55:11 <JeniT> +1
15:55:16 <jtandy> +1
15:55:29 <JeniT> RESOLUTION: #128 change ‘language’ to ‘lang’ so we can keep ‘language’ as meaning ‘xsd:language’
15:56:30 <danbri> danbri: i looked for things to argue with and fail, am supportive of closing the undiscussed issues as proposed
15:56:38 <rgrp> i'm really struggling also when reading the summary / issue to really understand proposal / resolution - if owners of issues could clarify with comment of current status proposal that would be really useful
15:56:53 <jtandy> q+ to ask about coming calls
15:56:53 <rgrp> thanks to gkellogg !
15:56:58 <ivan> q-
15:57:15 <danbri> gkellogg: two PRs pending in git
15:57:29 <danbri> 169 and 171, if we can pull those it'll put us in a better state
15:57:32 <danbri> jenit: any objections?
15:57:38 <danbri> ivan: it would be good to do that
15:57:42 <danbri> danbri: let's.
15:57:46 <danbri> jenit: go ahead then
15:57:54 <JeniT> ack jtandy
15:57:54 <Zakim> jtandy, you wanted to ask about coming calls
15:58:03 <danbri> jtandy: regrets for next week's call
15:58:09 <danbri> week after … is day before f2f
15:58:14 <danbri> will there be a call?
15:58:16 <danbri> jenit: no
15:58:43 <danbri> jtandy: see you at f2f. I'll go through all the issues that I have opened and cross-reference them.
15:58:53 <danbri> i'm massively busy abroad so actual editing time is limited.
15:59:06 <danbri> ivan: if you have these issues properly listed etc i can take a look next week.
15:59:15 <danbri> jtandy: i'll try to collate them on the wednesday.
15:59:35 <jtandy> ( a week on wednesday; 11th Feb)
15:59:41 <danbri> Rufus/rgrp, will you be at https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02#Attendee_List ?
15:59:44 <JeniT> https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0043.html
15:59:51 <danbri> (if so can you record it in the wiki page)
16:00:08 <danbri> jenit: we got a msg from Wim on the list about an alternative appraoch on the schema language
16:00:12 <rgrp> folks i have to drop!
16:00:25 <danbri> … in interest of getting people involved, i'd encourage him to join the group and attent the f2f
16:00:33 <danbri> zakim, who is on the phone?
16:00:34 <Zakim> On the phone I see JeniT, Ivan, danbri.a, jtandy, gkellogg, rgrp
16:00:35 <Zakim> -rgrp
16:00:54 <danbri> jenit, we could have a small slot to discuss possible last minute contributions.
16:01:03 <danbri> ivan, it is rather late in the day...
16:01:22 <rgrp> rgrp has left #csvw
16:04:27 <Zakim> -danbri.a
16:04:29 <Zakim> -gkellogg
16:04:29 <Zakim> -jtandy
16:04:31 <Zakim> -Ivan
16:04:33 <Zakim> -JeniT
16:04:34 <Zakim> DATA_CSVWG()10:00AM has ended
16:04:34 <Zakim> Attendees were JeniT, Ivan, gkellogg, danbri, jtandy, rgrp
16:04:41 <ivan> rrsagent, draft minutes
16:04:41 <RRSAgent> I have made the request to generate http://www.w3.org/2015/01/28-csvw-minutes.html ivan
16:04:48 <danbri> fwiw draft community group charter was at https://lists.w3.org/Archives/Public/public-csv-wg/2014Nov/0028.html
16:05:00 <ivan> trackbot, end telcon
16:05:00 <trackbot> Zakim, list attendees
16:05:00 <Zakim> sorry, trackbot, I don't know what conference this is
16:05:03 <danbri> "This community group explores advanced techniques for mapping between tabular data (based on http://w3c.github.io/csvw/syntax/) and otherdata representations." etc
16:05:08 <trackbot> RRSAgent, please draft minutes
16:05:08 <RRSAgent> I have made the request to generate http://www.w3.org/2015/01/28-csvw-minutes.html trackbot
16:05:09 <gkellogg> JeniT: I’ll handle PRs and try to get through most of the ED issues.
16:05:09 <trackbot> RRSAgent, bye
16:05:09 <RRSAgent> I see no action items