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

6. Action Items