IRC log of csvw on 2014-11-12

Timestamps are in UTC.

14:58:26 [RRSAgent]: RRSAgent has joined #csvw
14:58:26 [RRSAgent]: logging to http://www.w3.org/2014/11/12-csvw-irc
14:58:40 [danbri]: zakim, start meeting
14:58:40 [Zakim]: I don't understand 'start meeting', danbri
14:58:44 [danbri]: trackbot, start meeting
14:58:46 [trackbot]: RRSAgent, make logs public
14:58:48 [trackbot]: Zakim, this will be CSVW
14:58:48 [Zakim]: ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 2 minutes
14:58:49 [trackbot]: Meeting: CSV on the Web Working Group Teleconference
14:58:49 [trackbot]: Date: 12 November 2014
14:59:14 [danbri]: scribenick: danbri
14:59:16 [danbri]: for now
14:59:21 [danbri]: chair: danbri
14:59:26 [danbri]: agenda: https://www.w3.org/2013/csvw/wiki/Meeting_Agenda_2014-11-12
14:59:34 [danbri]: can anyone scribe until jeni gets here?
15:00:31 [danbri]: see also http://lists.w3.org/Archives/Public/public-csv-wg/2014Nov/0029.html (link added to agenda wiki)
15:00:37 [Zakim]: DATA_CSVWG()10:00AM has now started
15:00:44 [Zakim]: +??P24
15:00:49 [gkellogg]: zakim, I am ??P24
15:00:49 [Zakim]: +gkellogg; got it
15:01:03 [gkellogg]: scribenick: gkellogg
15:01:12 [danbri]: thx gregg
15:01:26 [Zakim]: +bill-ingram
15:01:28 [Zakim]: +danbri
15:02:12 [danbri]: zakim, who is on the phone?
15:02:12 [Zakim]: On the phone I see gkellogg, bill-ingram, danbri
15:03:09 [jtandy]: jtandy has joined #csvw
15:04:17 [danbri]: http://irc.w3.org/ might help
15:04:29 [bandri]: bandri has joined #csvw
15:04:52 [danbri]: zakim, who is on the phone?
15:04:52 [Zakim]: On the phone I see gkellogg, bill-ingram, danbri
15:04:57 [danbri]: jtandy, will you join us?
15:05:09 [jtandy]: hi - am struggling to get a zakim line
15:05:21 [jtandy]: will keep trying
15:05:37 [danbri]: http://lists.w3.org/Archives/Public/public-csv-wg/2014Nov/0029.html
15:05:41 [danbri]: <- issue list
15:05:48 [Zakim]: +??P49
15:06:04 [danbri]: zakim, ??P49 is jtandy
15:06:04 [Zakim]: +jtandy; got it
15:06:05 [jtandy]: zakim, ??P49 is me
15:06:06 [Zakim]: I already had ??P49 as jtandy, jtandy
15:06:22 [gkellogg]: danbri: trying to be more driven by GitHub issues.
15:06:37 [danbri]: regrets: ivan, + others
15:06:38 [gkellogg]: … We’ll postpone message issues until JeniT comes on.
15:06:42 [danbri]: i'll look up the others later
15:06:51 [danbri]: topic: Discussion Issues from Mappings
15:07:10 [gkellogg]: jtandy: ivan is on route to Australia.
15:07:45 [gkellogg]: … We can talk on teleconf when no progress made on GitHub.
15:07:57 [danbri]: https://github.com/w3c/csvw/issues/62 Should the RDF/JSON
15:07:57 [danbri]: transformation check the values?
15:07:57 [danbri]: - CSV to JSON mapping, CSV to RDF mapping
15:08:11 [bill-ingram]: bill-ingram has joined #csvw
15:08:20 [gkellogg]: … first: issue #62
15:08:33 [gkellogg]: … we thought the mapping issues could assume all parsing has already been done.
15:08:52 [danbri]: (see github for detailed text, we are not reminuting it all)
15:08:53 [bill-ingram]: Zakim: caller is me
15:09:21 [gkellogg]: … question is, if we can’t perform a transformation, do we proceed or die?
15:09:37 [danbri]: q?
15:09:41 [gkellogg]: … My thought is that we can assume parsing has already thrown out bad data.
15:09:54 [danbri]: q+
15:10:20 [gkellogg]: danbri: I think this touches on what is being defined: conformance criteria or behavior.
15:10:44 [danbri]: ack me
15:10:49 [gkellogg]: … If it’s a clas of software, we should just do the easiest thing. Advanced implementaions might do better without being non-conformant.
15:11:19 [gkellogg]: … A perfectly conformant processor could just pass everything through.
15:11:34 [danbri]: eg. we might say "comformant processors are not required to …" so we only require pass through
15:11:54 [danbri]: gregg: it adds complexity/branching to testing
15:12:14 [gkellogg]: jtandy: summarizing gkellogg, in order to give us a spec which is testable, we’ll go with the pass-through.
15:12:24 [danbri]: dan proposing simple pass through
15:12:54 [danbri]: gregg: advanced processing needs to be under control of a flag, so all processors can be guaranteed to give same output from same input
15:13:12 [danbri]: zakim, who is on the phone?
15:13:13 [Zakim]: On the phone I see gkellogg, bill-ingram, danbri, jtandy
15:13:32 [gkellogg]: jtanday: I’ll take an action to update GitHub.
15:13:51 [danbri]: I suggest a "Resolution (of those present): " since we have low turnout
15:14:05 [gkellogg]: resolution of those present: different processor flags to control parsed or raw output.
15:14:48 [gkellogg]: … pass through literal values in conformant mode, and allow advanced processors to do some contextual parsing/fixing
15:14:49 [danbri]: conformant mode passes through literal values, advanced processors may offer additional contextual checking/fixing (via flags)
15:15:25 [danbri]: gregg: additionally, processors may support an advanced processing flag, which will allow us to test that advanced processors produce consistent output (if that's not over-constraining them)
15:15:33 [danbri]: jtandy to capture this into github issue
15:15:40 [danbri]: rrsagent, pointer?
15:15:40 [RRSAgent]: See http://www.w3.org/2014/11/12-csvw-irc#T15-15-40
15:15:50 [gkellogg]: jtanday: I’ll pass that through, and when we come to actual implementations, we’ll check back.
15:16:10 [gkellogg]: topic: issue 61:
15:16:23 [gkellogg]: what should the mapping of an empty cell be for RDF and JSON
15:16:33 [gkellogg]: danbri: 61 not flagged for discussion
15:16:50 [danbri]: https://github.com/w3c/csvw/issues/59 How should ``language`` be
15:16:51 [danbri]: used in RDF mapping?
15:16:51 [danbri]: - CSV to RDF mapping
15:16:59 [gkellogg]: topic: issue 60: how should langauge be used in JSON mapping?
15:17:15 [danbri]: Ivan wrote "•If the content of the cell is not datatyped, and is not a URI, and the language tag's value is not "en", then the generated object should be a language literal with the global language tag set."
15:17:21 [gkellogg]: jtandy: I’ll come back on that one.
15:18:00 [gkellogg]: … “How should the localle setting be used in the default mapping?”
15:18:27 [danbri]: rrsagent, pointer?
15:18:27 [RRSAgent]: See http://www.w3.org/2014/11/12-csvw-irc#T15-18-27
15:18:32 [gkellogg]: … unless the data itself is saying the language of a cell is different, the language of the metadata should be applied to every literal.
15:19:00 [danbri]: gregg: lets say default lang was english from default mapping, does the json now tag all its values with English, or is that assumed and untagged?
15:19:17 [danbri]: (non-jsonld, normal colloquial non-rdfy json)
15:19:39 [danbri]: jtandy: "plain old json"
15:19:57 [danbri]: jtandy: suggesting … we transform verbatim and don't add locale info
15:20:01 [gkellogg]: … I proposed that Plain Old JSON (“POJ”) we don’t put in the default mapping into the output.
15:20:42 [Zakim]: +[IPcaller]
15:20:45 [danbri]: q+ to ask if column contains codes e.g. enumerated values
15:20:49 [gkellogg]: … So, the information in the metadata says it’s German, but that is not reflected in the output.
15:21:15 [gkellogg]: topic: issue 59
15:22:08 [gkellogg]: … we assume people can determine this from the complementary language mapping.
15:22:29 [gkellogg]: s/topic: issue 60/topic: issue 59/
15:22:48 [jtandy]: PROPOSAL: for RDF mapping, apply locale / language tag from metadata to all literal values in output
15:23:21 [gkellogg]: jenit: I think it’s all string values, because the number 2 is a literal value without language.
15:23:24 [jtandy]: s/literal/literal string/
15:23:30 [danbri]: +1
15:23:31 [bill-ingram]: +1
15:23:32 [JeniT]: +1
15:23:33 [jtandy]: +1
15:23:34 [gkellogg]: +1
15:23:55 [danbri]: revisiting https://github.com/w3c/csvw/labels/Requires%20telcon%20discussion/decision
15:23:57 [gkellogg]: RESOLVED: for RDF mapping, apply locale / language tag from metadata to all literal string values in output
15:24:57 [jtandy]: PROPOSAL: for (plain old) JSON mapping, no locale information is added to the JSON output - we assume that people will look at the complimentary metadata for locale information
15:25:27 [danbri]: gregg: in our discussion we talked about locale coming from mapping info, as opposied to locale info that might come from the data itself
15:25:42 [danbri]: e.g. use of a particular col or diff lang. Are you proposing that we drop such from the JSON output also?
15:25:54 [danbri]: jtandy: not sure how i'd write locale info in plain json
15:26:05 [danbri]: gregg: you could use JSON-LD ...
15:26:22 [danbri]: …but simple needs to be simple; people can use json-ld etc if they're more ambitious
15:26:24 [danbri]: jtandy: agree
15:26:35 [gkellogg]: jtandy: if they care about localle, they should use RDF mapping with JSON-LD serialization.
15:26:39 [danbri]: jenit: I think the metadata will say what the lang cols are in,
15:27:13 [gkellogg]: jenit: the could always trace it back from the original data. I think in the JSON mapping, the’ll use a property name to indicate that, or it would otherwise be implicit.
15:27:56 [jtandy]: (if you want to say a particular locale for plain old json, you might say "property_en" or "property_fr")
15:28:37 [JeniT]: +1
15:28:42 [jtandy]: (e.g. the property has a human readable hint)
15:28:44 [jtandy]: +1
15:28:45 [gkellogg]: +1
15:28:52 [danbri]: +1
15:29:06 [bill-ingram]: +1
15:29:07 [jtandy]: RESOLVED: for (plain old) JSON mapping, no locale information is added to the JSON output - we assume that people will look at the complimentary metadata for locale information
15:29:13 [danbri]: topic: https://github.com/w3c/csvw/issues/39 What should be generated for a value with datatype in the case of JSON
15:29:39 [danbri]: rrsagent, pointer?
15:29:39 [RRSAgent]: See http://www.w3.org/2014/11/12-csvw-irc#T15-29-39
15:29:44 [gkellogg]: subtopic: issue 39: What should be generated for a value with datatype in the case of JSON
15:30:05 [danbri]: (where JSON is plain old JSON)
15:30:18 [gkellogg]: jenit: similar to language: how much structure to put in the output.
15:30:35 [gkellogg]: … I suggested recognizing boolean, numebers and null, and otherwise just map to a string.
15:30:40 [danbri]: jenit: (in github), "Given that we're aiming for a simple JSON mapping for simple JSON users, I think the first option above is the right one: map to a simple string, number, boolean (or null) as appropriate for the datatype."
15:31:26 [danbri]: proposal: re #39 for simple JSON we map to a simple string, number, boolean (or null) as appropriate for the datatype.
15:31:29 [danbri]: +1
15:31:29 [jtandy]: +1
15:31:32 [JeniT]: +1
15:31:33 [gkellogg]: +1
15:31:35 [bill-ingram]: +1
15:31:41 [danbri]: resolved: re irc://irc.w3.org:6667/#39 for simple JSON we map to a simple string, number, boolean (or null) as appropriate for the datatype.
15:32:48 [danbri]: topic: https://github.com/w3c/csvw/issues/30 How to interpret fixed string type values ("Table", "Row",...)
15:32:54 [danbri]: rrsagent, pointer?
15:32:54 [RRSAgent]: See http://www.w3.org/2014/11/12-csvw-irc#T15-32-54
15:33:00 [gkellogg]: subtopic: issue 30: How to interpret fixed string type values ("Table", "Row",...)
15:33:28 [gkellogg]: jtanday: I assume they’ll figure this out based on context.
15:33:58 [gkellogg]: danbri: propose we just endorse the editorial decision.
15:34:21 [gkellogg]: jtanday: we’re trying to make JSON as “brutally simple” as possible.
15:34:30 [danbri]: proposal: #30 aiming for json mapping to be super simple, we endorse the 2nd option as currently implemented by editors
15:34:33 [gkellogg]: +1
15:34:35 [bill-ingram]: +1
15:34:36 [danbri]: +1
15:35:19 [gkellogg]: jenit: I’d suggest the authors consider if anything can be considered tables columns. I’m not sure where the typed table mapping applies.
15:35:19 [JeniT]: +1
15:35:21 [jtandy]: +1 ... noting that further thought is required about whether things should be declared @type
15:35:34 [danbri]: yup
15:36:08 [danbri]: https://github.com/w3c/csvw/issues/20 Is row by row processing sufficient?
15:36:10 [gkellogg]: subtopic: issue #20: Is row by row processing sufficient?
15:36:17 [danbri]: topic: https://github.com/w3c/csvw/issues/20 Is row by row processing sufficient?
15:36:34 [jtandy]: resolved: #30 aiming for json mapping to be super simple, we endorse the 2nd option as currently implemented by editors
15:37:07 [gkellogg]: danbri: I propose that we know many CSV mappings have interdependent rows, for now we’re going to go with row-by-row mapping.
15:37:24 [danbri]: ie. we push work onto preprocessors etc
15:37:33 [danbri]: … and advanced mappings
15:37:43 [gkellogg]: jtandy: I think we discussed different alternatives, but agreed that the simple mapping is definitely row-by-row, but perhaps the templated mapping might want to consider holdover values from previous rows.
15:38:31 [gkellogg]: jenit: perhaps a flag in the metadata saying take it from the previous row seems relatively simple, but I’m happy to keep it super-simple for now.
15:38:59 [gkellogg]: jtandy: I’d suggest people just pre-process the CSV to populate those blanks.
15:39:27 [jtandy]: proposal: keep things simple - row by row processing only
15:39:31 [gkellogg]: +1
15:39:31 [bill-ingram]: +1
15:39:32 [jtandy]: +1
15:39:33 [danbri]: +1
15:39:41 [jtandy]: resolved: keep things simple - row by row processing only
15:40:10 [JeniT]: +1
15:40:15 [danbri]: revisiting https://github.com/w3c/csvw/labels/Requires%20telcon%20discussion/decision
15:40:16 [gkellogg]: jenit: can we take issues in reverse order?
15:40:17 [JeniT]: topic: https://github.com/w3c/csvw/issues/23
15:40:27 [danbri]: https://github.com/w3c/csvw/issues/23 CSV Dialect Description
15:40:33 [gkellogg]: subtopic: issue 23:
15:41:05 [gkellogg]: jenit: acting on the F2F about trying to map over the flags we describe in the syntax doc into the dialect description within metadata.
15:41:32 [gkellogg]: … but, also trying to get consistency from the datapackage, such as header
15:41:43 [JeniT]: http://w3c.github.io/csvw/metadata/#dialect-descriptions
15:42:14 [danbri]: rrsagent, pointer?
15:42:14 [RRSAgent]: See http://www.w3.org/2014/11/12-csvw-irc#T15-42-14
15:42:50 [JeniT]: PROPOSAL: we can close https://github.com/w3c/csvw/issues/23 as it’s sufficiently addressed by current draft
15:42:51 [danbri]: +1
15:42:52 [bill-ingram]: +1
15:42:53 [gkellogg]: +1
15:42:53 [jtandy]: +1
15:42:55 [JeniT]: +1
15:43:05 [JeniT]: RESOLVED: we can close https://github.com/w3c/csvw/issues/23 as it’s sufficiently addressed by current draft
15:43:39 [JeniT]: topic: https://github.com/w3c/csvw/issues/54
15:43:46 [danbri]: Using JSON-LD for the metadata document
15:43:56 [danbri]: oh sorry
15:44:08 [danbri]: "Pattern string formats for parsing dates/numbers/durations", rather.
15:44:12 [gkellogg]: jenit: we discussed using pattern strings for parsing dates, numbers, durations, … in CSV files based on some kind of localle.
15:44:18 [JeniT]: http://www.unicode.org/reports/tr35/
15:44:19 [danbri]: see http://www.unicode.org/reports/tr35/
15:44:39 [gkellogg]: … The i18n guys pinted us at tr35, which describes the kind of format for pattern strings and relation to different localles.
15:45:19 [jtandy]: s/pinted/pointed/
15:45:22 [gkellogg]: … having looked at it, it’s quite complicated, and I think we could cleanly drop that as a 1.0 requirement, and layer it on as something extra that implementations can play around with during the 1.0 period to be considered for 2.0
15:45:44 [jtandy]: q+
15:45:49 [danbri]: q-
15:45:56 [gkellogg]: … We had previously agreed to try to do this; there are strong requirements for parsing different dates and numbers, so I’m a bit uncomfortable dropping it
15:46:38 [gkellogg]: jtandy: I’ve not looked at the ISO datetime standard, but I understand that it includes a number of structures for how dates and times are recognized. Perhaps that would be a place to start.
15:47:20 [danbri]: q+ to suggest "The CSVW Working Group considered requiring an implementation of http://www.unicode.org/reports/tr35/ pattern string formats. Given the complexity of that specification, the WG decided against making a normative reference at this stage. Implementors are encouraged to share their experience with TR35 and related specifications as input to possible future versions of this specification."
15:47:24 [danbri]: ack jtandy
15:47:24 [gkellogg]: jtandy: I think the ISO standard allows things to be changed a bit compared to XSD, but simpler than TR35.
15:47:40 [Zakim]: -bill-ingram
15:47:42 [danbri]: there was also http://www.w3.org/TR/NOTE-datetime pre-xml-schema
15:47:44 [gkellogg]: jenit: I don’t think it does, but it could. It may be that there’s some flexibility.
15:48:15 [Zakim]: +bill-ingram
15:48:19 [jtandy]: ACTION: jtandy to review ISO 8601 to determine if it supports 'locale' type strings for date-times
15:48:19 [gkellogg]: jenit: the other one is number format, such as using “,” instead of “.” as decimal point.
15:48:19 [trackbot]: Created ACTION-57 - Review iso 8601 to determine if it supports 'locale' type strings for date-times [on Jeremy Tandy - due 2014-11-19].
15:48:33 [gkellogg]: danbri: is that covered by the dialect spec?
15:48:34 [danbri]: zakim, who is on the phone?
15:48:34 [Zakim]: On the phone I see gkellogg, danbri, jtandy, JeniT, bill-ingram
15:48:46 [gkellogg]: jenit: no, it’s not parsing the CSV into values, but parsing the values themselves.
15:48:51 [danbri]: q?
15:49:05 [danbri]: "1000,00"
15:49:13 [gkellogg]: jtanday: this is about picking up a string, which might have something like “nnn nnn,nn”, where it might be a decimal, vs a typo.
15:49:37 [gkellogg]: danbri: we ran into this with schema.org, and settled on the western method.
15:49:40 [danbri]: see http://schema.org/price
15:49:55 [gkellogg]: jtandy: problem is, people don’t publish their data that way.
15:50:03 [jtandy]: q+
15:50:11 [danbri]: ack jtandy
15:50:39 [gkellogg]: … we have a number of parsing directives, and having one to indicate decimal separator might be helpful.
15:50:41 [JeniT]: q+ jenit
15:50:48 [danbri]: ack danbri
15:50:48 [Zakim]: danbri, you wanted to suggest "The CSVW Working Group considered requiring an implementation of http://www.unicode.org/reports/tr35/ pattern string formats. Given the complexity of
15:50:51 [Zakim]: ... that specification, the WG decided against making a normative reference at this stage. Implementors are encouraged to share their experience with TR35 and related
15:50:51 [Zakim]: ... specifications as input to possible future versions of this specification."
15:51:06 [danbri]: ack jenit
15:51:42 [gkellogg]: jenit: I was trying to think of a way forward which would enable us to make a more informed decision. I think Jtandy looking at ISO8601 would be very useful.
15:52:03 [gkellogg]: … I’ll look at what it takes to do the number parsing, and see if that’s something we want to go forward with.
15:52:32 [JeniT]: ACTION: jenit to investigate what number parsing would look like if done right
15:52:32 [trackbot]: Created ACTION-58 - Investigate what number parsing would look like if done right [on Jeni Tennison - due 2014-11-19].
15:53:10 [danbri]: topic: https://github.com/w3c/csvw/issues/48
15:53:21 [danbri]: "Using JSON-LD for the metadata document "
15:53:51 [gkellogg]: jenit: this is just a copy-over of the issue as it was in the document. I think it’s completely resolvable as saying “yes, we are using JSON-LD”.
15:54:09 [gkellogg]: … The only question is if we should rename some of the JSON-LD keywords, subh as @id and @type, so they don’t stick out.
15:54:12 [gkellogg]: q+
15:54:20 [danbri]: q+
15:54:24 [jtandy]: q+
15:54:40 [danbri]: gkellogg: some of discussions have been to serve doc as json, provide context via a header
15:54:47 [danbri]: … aiming to look like JSON rather than JSON-LD
15:55:05 [danbri]: … makes some sense, aliasing those keywords
15:55:11 [danbri]: q?
15:55:15 [danbri]: ack gkellogg
15:55:17 [danbri]: q-
15:55:21 [JeniT]: ack jtandy
15:55:36 [danbri]: jtandy: to clarify, … it is possible to have a json-ld that replaces @id with something else and it will all work
15:55:41 [gkellogg]: jtandy: I want to clarify that it’s possible to have JSON-LD that replaces @id with something else and it will work.
15:55:42 [danbri]: jenit: that's aliasing and it is fine
15:55:47 [gkellogg]: jenit: yes, that’s aliasing.
15:55:57 [gkellogg]: jtandy: we’ll always have a context?
15:56:35 [gkellogg]: jenit: we’ll publish one, and people point to a context.
15:56:53 [danbri]: drafting a proposal: "close 48: we agree our metadata files are JSON-LD, and we are taking various measures to minimise associated syntax burdens"
15:56:57 [danbri]: q?
15:57:22 [danbri]: [I have a hard finish in 2 mins due to another meeting.]
15:58:44 [gkellogg]: jenit: I propose we split the issue into two: how json-ld processors can recognize this, and the other is aliasing of keywords.
15:58:47 [danbri]: +1
15:58:51 [gkellogg]: +1
15:58:53 [bill-ingram]: +1
15:58:54 [jtandy]: +1
15:59:13 [Zakim]: -gkellogg
15:59:15 [Zakim]: -jtandy
15:59:15 [danbri]: Adjourned.
15:59:19 [Zakim]: -bill-ingram
15:59:21 [danbri]: rrsagent, please draft minutes
15:59:21 [RRSAgent]: I have made the request to generate http://www.w3.org/2014/11/12-csvw-minutes.html danbri
15:59:21 [Zakim]: -danbri
15:59:21 [Zakim]: -JeniT
15:59:21 [Zakim]: DATA_CSVWG()10:00AM has ended
15:59:21 [Zakim]: Attendees were gkellogg, bill-ingram, danbri, jtandy, JeniT
15:59:28 [gkellogg]: probably some messup with topic vs subtopic to be fixed in minutes.
15:59:47 [danbri]: yeah, not sure how to edit those files but at least most of the right words are in the irc log
15:59:53 [danbri]: thanks gregg for scribing!
16:00:02 [JeniT]: ACTION: jenit to close https://github.com/w3c/csvw/issues/48 and to open new issues on (a) JSON-LD processors recognising metadata documents as JSON-LD and (b) aliasing of JSON-LD keywords
16:00:02 [trackbot]: Created ACTION-59 - Close https://github.com/w3c/csvw/issues/48 and to open new issues on (a) json-ld processors recognising metadata documents as json-ld and (b) aliasing of json-ld keywords [on Jeni Tennison - due 2014-11-19].
16:00:15 [JeniT]: rrsagent, please draft minutes
16:00:15 [RRSAgent]: I have made the request to generate http://www.w3.org/2014/11/12-csvw-minutes.html JeniT
16:00:57 [danbri]: trackbot, meeting is closed
16:00:57 [trackbot]: Sorry, danbri, I don't understand 'trackbot, meeting is closed'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
16:01:10 [danbri]: trackbot, end meeting
16:01:10 [trackbot]: Zakim, list attendees
16:01:10 [Zakim]: sorry, trackbot, I don't know what conference this is
16:01:18 [trackbot]: RRSAgent, please draft minutes
16:01:18 [RRSAgent]: I have made the request to generate http://www.w3.org/2014/11/12-csvw-minutes.html trackbot
16:01:19 [trackbot]: RRSAgent, bye
16:01:19 [RRSAgent]: I see 3 open action items saved in http://www.w3.org/2014/11/12-csvw-actions.rdf :
16:01:19 [RRSAgent]: ACTION: jtandy to review ISO 8601 to determine if it supports 'locale' type strings for date-times [1]
16:01:19 [RRSAgent]: recorded in http://www.w3.org/2014/11/12-csvw-irc#T15-48-19
16:01:19 [RRSAgent]: ACTION: jenit to investigate what number parsing would look like if done right [2]
16:01:19 [RRSAgent]: recorded in http://www.w3.org/2014/11/12-csvw-irc#T15-52-32
16:01:19 [RRSAgent]: ACTION: jenit to close https://github.com/w3c/csvw/issues/48 and to open new issues on (a) JSON-LD processors recognising metadata documents as JSON-LD and (b) aliasing of JSON-LD keywords [3]
16:01:19 [RRSAgent]: recorded in http://www.w3.org/2014/11/12-csvw-irc#T16-00-02