JSON-LD Working Group Telco — Minutes
Date: 2018-08-31
See also the Agenda and the IRC Log
Attendees
Present: Rob Sanderson, Adam Soroka, Ivan Herman, Simon Steyskal, David Newbury, Jeff Mixter, Gregg Kellogg, Tim Cole, David I. Lehn, Harold Solbrig
Regrets: Benjamin Young, Dave Longley
Guests:
Chair: Rob Sanderson
Scribe(s): Simon Steyskal
Content:
1. Approve minutes of last call
Proposed resolution: Approve minutes of last call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-24-json-ld (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Tim Cole: +1
David I. Lehn: +1
Ivan Herman: +1
Simon Steyskal: +1
Resolution #1: Approve minutes of last call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-24-json-ld
2. Announcements
David Newbury: +1
Rob Sanderson: project link: https://github.com/orgs/w3c/projects/4
Rob Sanderson: tpac coming up; we also have made a project for the issues we are working on
… helps tracking issues over all 3 repos we are working on
… decide on topics that are probably better discussed during the F2F meeting
… if there’s anything else we could configure on that regard, please speak up
… any other announcements or reminders?
Ivan Herman: a minor thing, if we have anything to discuss with other working groups we should do that
… e.g., publication working group meets on Monday/Tuesday
… you are more than welcome to join
Action #1: Rob to create a meta issue for cross-WG sessions at TPAC
3. FPWDs
Rob Sanderson: according to our charter, we should have published FPWDs
… our documents are way more mature than required for FPWD
Ivan Herman: publishing FPWD needs more administrative actions
… reason being that IPR starts with the FPWD
… publishing FPWD cannot be automated
… we need a formal vote for publishing each of the 3 documents
… this includes also deciding on their respective short names
Gregg Kellogg: json-ld11, json-ld11-api, json0-ld11-framing
Gregg Kellogg: snapshots https://rawgit.com/w3c/json-ld-syntax/fpwd/publication-snapshots/FPWD/Overview.html, https://rawgit.com/w3c/json-ld-api/fpwd/publication-snapshots/FPWD/Overview.html, https://rawgit.com/w3c/json-ld-framing/fpwd/publication-snapshots/FPWD/Overview.html
Ivan Herman: we’ll vote here, it’s not binding yet, but will become so in a week from now
… unless someone objects to it
… publications happen on Tuesdays/Thursdays
… on the 11th is the earliest date we could publish
Rob Sanderson: any questions?
Proposed resolution: Approve the current snapshots for publication as FPWD for September 11th (Rob Sanderson)
Gregg Kellogg: ivan has suggested some changes, so they would not be exactly the same shapshots
Proposed resolution: Approve for publication as FPWD for September 11th the documents as json-ld11, json-ld11-api and json-ld11-framing (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Gregg Kellogg: we strive for excellence!
Harold Solbrig: +1
Ivan Herman: +1
Simon Steyskal: +1
David I. Lehn: +1
Tim Cole: +1
Jeff Mixter: +1
David Newbury: +1
Adam Soroka: +1
Gregg Kellogg: having issues in the public documents, sometimes cause some issues
… broken links and such
Ivan Herman: when you incorporate github issues with respec, you can define your own text instead of taking the one from github
Resolution #2: Approve for publication as FPWD for September 11th the documents as json-ld11, json-ld11-api and json-ld11-framing
Ivan Herman: you ping me when the documents are frozen, gkellogg ?
… you’ll generate static HTML, right?
Ivan Herman: once you’ve pinged me, I’ll start the process
Gregg Kellogg: yes
4. Issues
4.1. Ordering of keys, https://github.com/w3c/json-ld-api/issues/8
Ivan Herman: link: https://github.com/w3c/json-ld-api/issues/8
Rob Sanderson: we discussed over the week, proposal is in the agenda
Gregg Kellogg: the reason for having the ordering, was for the tests being then easier to evaluate
Gregg Kellogg: we should put something in the test readme, describing this kind of result checking
Rob Sanderson: does this also apply to scoping by type?
Proposed resolution: Remove the “ordered lexicographically by key” from the serialization algorithm and allow implementations to handle this as they see fit (Rob Sanderson)
Rob Sanderson: +1
Adam Soroka: +1
Gregg Kellogg: +1
Ivan Herman: +1
Jeff Mixter: +1
Simon Steyskal: +1
Tim Cole: +1
David Newbury: +1
Harold Solbrig: +1
David I. Lehn: has anyone tried doing this change to see if anything breaks?
Gregg Kellogg: yeah, for compacting e.g., where you only have to sort the compacted output
… I haven’t implemented the more complex result checking though
Gregg Kellogg: current algorithms should be able to deal with that
… ordering was actually one of the things that makes processing expensive
David I. Lehn: +1
Resolution #3: Remove the “ordered lexicographically by key” from the serialization algorithm and allow implementations to handle this as they see fit
4.2. support JSON literal values - https://github.com/w3c/json-ld-syntax/issues/4
Ivan Herman: link: https://github.com/w3c/json-ld-syntax/issues/4
Ivan Herman: defining a datatype for RDF would make the whole thing complete
… we could do that I think
… but postponing it to a future RDF WG is maybe not a good thing (it doesn’t exist yet)
Rob Sanderson: in the social web WG, they created a new LDP property
… the annotation WG doesn’t want to get the same thing done to them (as they said in a disclaimer)
Ivan Herman: creating a new datatype isn’t the same thing as changing the ontology
… we are not required to put it in the RDF namespace
Rob Sanderson: the question is more “where should it live”
Rob Sanderson: comment - https://github.com/w3c/json-ld-syntax/issues/4#issuecomment-416757994
Gregg Kellogg: I certainly support adding a JSON datatype to RDF
… should be whitespace normalized
… having implemented this, in theory this should work
… there might be some problematic corner cases wrt. to framing
… storing an empty array as json object in a frame for example
ivan>Exampl: that can be reused: https://www.w3.org/TR/rdf11-concepts/#section-html
Ivan Herman: we can have a separate section in our own document where we define this
Ivan Herman: you can see from the HTML example, it’s a relative simple thing
Gregg Kellogg: I was referring to the actual namespace documents
Ivan Herman: which ones?
Gregg Kellogg: if we decide to put it in the RDF namespace
Ivan Herman: that’s something we could do, because they are not in TR
… the important thing is that it’s really a short thing, not a big deal
Proposed resolution: Define a @json keyword, initially mapped to jsonld:json, for use with @type to indicate the @value is a json literal value (Rob Sanderson)
Gregg Kellogg: this does have utility outside of GeoJSON
… it does put json literals on the same level as xml/html ones
Rob Sanderson: +1
Gregg Kellogg: +1
Harold Solbrig: +1
David I. Lehn: +1
Tim Cole: +1
Simon Steyskal: +1
Jeff Mixter: +1
Ivan Herman: +1
Adam Soroka: +1
David Newbury: +1
Resolution #4: Define a @json keyword, initially mapped to jsonld:json, for use with @type to indicate the @value is a json literal value
David I. Lehn: should it be caps jsonld:JSON to align with those rdf:HTML etc names?
4.3. compaction issues, #3 and #6
simonstey>link: https://github.com/w3c/json-ld-api/issues/3
simonstey>link: https://github.com/w3c/json-ld-api/issues/6
Rob Sanderson: closely related
… issue 6 is exactly the same but for @id
… use case is consistency
… some things require arrays having a consistent datatype
Rob Sanderson: gkellogg:
Simon Steyskal: [azaroth explaining the issues]
Gregg Kellogg: there was a concern, we may need an extra keyword
… to be able to handle this case
Rob Sanderson: Explanation: In order to allow consistent JSON output, compaction should allow for values and resources to be compacted to a JSON object with a single key of @id or @value
Ivan Herman: it would be very difficult to give an understandable story of what the keywords are
… as we are already overloading them quite a bit
Rob Sanderson: +1
Ivan Herman: they make sense on an incremental basis, but looking at them as a whole things may become a bit blurry
… here we are reusing keywords for transforming json-ld from one format to another
Jeff Mixter: +1 to ivan’s concern
Ivan Herman: as of now, I would like to leave this issue open
… maybe discussing it at TPAC in more detail the set of keywords and their usage
Rob Sanderson: Similar situation as the “data type coercion” issue
Gregg Kellogg: conceptually this (i.e., type none) would mean that the type of those values don’t really have a meaning
… I understand the concern about overloading
Ivan Herman: on a micro level those changes are fine, but I would like to leave it open nevertheless
David Newbury: understanding what keywords have an effect on JSON output is non-trivial
… mapping algorithms to how input maps to output is not really straightforward
Proposed resolution: Accept the use case for #3 and #6, and continue to discuss the solution (Rob Sanderson)
Ivan Herman: +1
Simon Steyskal: +1
David Newbury: +1
Jeff Mixter: +1
Harold Solbrig: +1
Rob Sanderson: +1
Gregg Kellogg: +1
David I. Lehn: +1
Resolution #5: Accept the use case for #3 and #6, and continue to discuss the solution
4.4. https://github.com/w3c/json-ld-syntax/issues/15
Ivan Herman: link: https://github.com/w3c/json-ld-syntax/issues/15
Rob Sanderson: list-like structures for other ontologies
Gregg Kellogg: something like this was contemplated in 1.0 too
… the only way of creating an ordered list of items in json-ld is basically to leverage rdf list
… adding additional means for creating ordered lists, e.g., by utilizing the ordered list ontology
… hoping that danbri starts to show up at some point
Rob Sanderson: It also led to: https://github.com/w3c/json-ld-syntax/issues/17
Ivan Herman: we have to see if this issue is still as high on the list for schema.org as it used to be
Rob Sanderson: it seems like a lot of work
Ivan Herman: https://github.com/json-ld/json-ld.org/issues/595#issuecomment-368258625
Ivan Herman: we should be extremely careful in opening this can of worms
… sounds more like 2.0 than 1.1
Rob Sanderson: +1!
Ivan Herman: +1 to adam
5. Resolutions
- Resolution #1: Approve minutes of last call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-24-json-ld
- Resolution #2: Approve for publication as FPWD for September 11th the documents as json-ld11, json-ld11-api and json-ld11-framing
- Resolution #3: Remove the “ordered lexicographically by key” from the serialization algorithm and allow implementations to handle this as they see fit
- Resolution #4: Define a @json keyword, initially mapped to jsonld:json, for use with @type to indicate the @value is a json literal value
- Resolution #5: Accept the use case for #3 and #6, and continue to discuss the solution
6. Action Items
- Action #1: Rob to create a meta issue for cross-WG sessions at TPAC