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