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