JSON-LD Working Group Telco — Minutes

Date: 2020-04-17

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Pierre-Antoine Champin, Ivan Herman, Ruben Taelman, Gregg Kellogg, David I. Lehn

Regrets: Benjamin Young

Guests:

Chair: Rob Sanderson

Scribe(s): Pierre-Antoine Champin

Content:

1. Announcements / Reminders?

Ruben Taelman: I don’t see the namespace PR mentioned on the agenda. I think we have to discuss that.

2. Transition to PR

2.1. Dispose remaining issues

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/255

Rob Sanderson: the example about the @included keyword was not very easy to understand;

Rob Sanderson: https://github.com/w3c/json-ld-syntax/pull/348

Rob Sanderson: last week, I finally pushed a PR to fix it
… It replaces the anonymous “things” with “categorisations” with
… “members” of an organization, with “roles”
… The PR has been approved by pchampin gkellogg ivan bigbluehat .
… Any objection from the others?

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/343

Gregg Kellogg: this was mostly a misunderstanding, about which document should be accessed
… the published document does not have the issue

Proposed resolution: Close #343 invalid, as the final form will have anchors in the html (Rob Sanderson)

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Ruben Taelman: +1

David I. Lehn: +1

Resolution #1: Close #343 invalid, as the final form will have anchors in the html

Rob Sanderson: if the previews were working efficiently we could point to them

2.2. Implementation Reports

Rob Sanderson: all open issues have been addressed

Gregg Kellogg: https://w3c.github.io/json-ld-api/reports/

Rob Sanderson: Where are we with the implementation reports?

Gregg Kellogg: we now have 10 tested implementations in various languages;
… a CSS trick adds a red cross next to tests that don’t have 2 passing implementations.
… With the latest implementations that were added, all tests now are good w.r.t. this criterion.

Rob Sanderson: it would be nice to get a Java implementation, but we can go

Ivan Herman: we are fine to submit to the director;
… the Java implementation may even come in the meantime.
… We must include proofs of wide review (pointers to github).

Gregg Kellogg: https://github.com/w3c/json-ld-api/issues?q=is:issue+is:closed+label:wr:spec-updated

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/issues?q=is:issue+is:closed+label:wr:spec-updated

Gregg Kellogg: https://github.com/w3c/json-ld-framing/issues?q=is:issue+is:closed+label:wr:spec-updated

Gregg Kellogg: that’s the ones I did put.

Ivan Herman: perfect

2.3. Transition Request

Rob Sanderson: the process is for ivan to submit an issue on the magic github.

Ivan Herman: I will do it, but I need a formal resolution.

Proposed resolution: WG agrees that we should progress the three core specifications, syntax, api and framing, to Proposed Recommendation status (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Resolution #2: WG agrees that we should progress the three core specifications, syntax, api and framing, to Proposed Recommendation status

Ivan Herman: to be really precise, this will only be effective in a week (to leave time for objections).
… But I can submit it right away, it will be a week before the director looks at it.
… I had a chat with Ralph, explaining why we have many FAILs on the HTML features.
… There are good chances that we get it without a telco.
… gkellogg, I assume all the docs pass all validators?

Gregg Kellogg: I’ll check today.
… the HTML tests are all marked with a specific feature;
… the spec states that processors are not required to implement this feature;
… some parsers have only FAIL (go, ruben’s), it does not mean that they attempt to do it and fail.
… This is an issue with earl statuses. They should rather not report anything.
… I also marked in gray the tests about non-normative features.
… We have implementations of the i18n datatype and compound literals.

Rob Sanderson: any other questions about transition?

Gregg Kellogg: is it premature to freeze versions with a given date?

Ivan Herman: yes, we will see to it later

2.4. Transition for Streaming Note

Rob Sanderson: hopefully, people had time to read the latest version of the Streaming note

Ivan Herman: the resolution should mention the short name we want to use

David I. Lehn: does it require the 11 in the name?

Rob Sanderson: I think it does, in case version 1.2 changes something in the note

Ruben Taelman: are we going to ask for a redirect without the 11?

Ivan Herman: yes we can

Proposed resolution: Request publication of the Streaming note with short name of json-ld11-streaming, and a redirect from json-ld-streaming (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Ivan Herman: +1

David I. Lehn: +1

Resolution #3: Request publication of the Streaming note with short name of json-ld11-streaming, and a redirect from json-ld-streaming

Ivan Herman: I would propose to sync the publication of this one with the PR.
… rubensworks we need to check that the document passes through all the pub-rules checker.

Gregg Kellogg: I can help Ruben with that

Ivan Herman: also, is it worth setting up Echidna for it?

Gregg Kellogg: there is only one implementation for the moment;
… I’m trying to build another one, but the note lacks some precisions, which is ok,

Proposed resolution: Setup echidna for future publications of the streaming note (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: but if others give it a try, issues may arise

Ivan Herman: gkellogg can you copy your echidna setting from the other specs?

Ivan Herman: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Resolution #4: Setup echidna for future publications of the streaming note

2.5. Namespace issue

Ruben Taelman: https://github.com/w3c/json-ld-wg/pull/140

Rob Sanderson: rubensworks would like to provide a profile IRI in the JSON-LD namespace,
… to mark content as complying with the Streaming note
… I think that we decided last week to wait until the note was approved,
… before changing the namespace.

Ivan Herman: we could sync that with the publication.
… The HTML files are not redirected, they are copied.
… What about the TTL file?

Gregg Kellogg: it is generated from the CSV file.

Ruben Taelman: The changed to the CSV file should be included in the pull request.

Ivan Herman: if we are confident that this is the final text, we can merge the PR.

Ruben Taelman: https://www.w3.org/TR/json-ld11-streaming/

Ruben Taelman: will that be the final URL or the note?

Ivan Herman: yes

Proposed resolution: Merge the NS PR after updating the links, and ivan will publish to /ns/ when the note is published (Rob Sanderson)

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

David I. Lehn: +1

Ivan Herman: +1

Ruben Taelman: +1

Action #1: republish the NS document when streaming note is published (Ivan Herman)

Resolution #5: Merge the NS PR after updating the links, and ivan will publish to /ns/ when the note is published

Ivan Herman: another administrative info

2.6. Other Admin Info

Ivan Herman: I will submit the JSON-LD maintenance charter at the same time as the PR,
… that can go through the same AC vote

3. Base Context Discussion

Rob Sanderson: https://github.com/w3c/json-ld-rc/issues/

Rob Sanderson: two weeks ago we discussed whether we should mark the prefixes with "@prefix": true

Rob Sanderson: https://github.com/w3c/json-ld-rc/issues/3

Rob Sanderson: this would be more explicit, but ivan and gkellogg noticed that it makes the document more complicated
… and is not strictly required (this is the default)

Proposed resolution: Close rc #3 won’t fix, as the @prefix: true is the default anyway (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #6: Close rc #3 won’t fix, as the @prefix: true is the default anyway

Rob Sanderson: https://github.com/w3c/json-ld-rc/issues/4

Rob Sanderson: this issue proposes to split the context into two different ones:

Gregg Kellogg: https://github.com/w3c/json-ld-rc/tree/split_contexts/contexts

Rob Sanderson: one defining only keyword aliases
… the other one defining common prefixes
… This came from a concern from bigbluehat and ivan that keyword aliases are not always relevant.

Ivan Herman: I think that’s over-complicating things.
… if the recommended context does not work for you, then don’t use it.

Gregg Kellogg: the idea of separating prefixes was to avoid the burden of maintaining them,
… when things get out of fashion for example.
… But we still have the burden if we publish them somewhere else.

Proposed resolution: Close #4 wontfix, as it adds complications for minimal value. context editors that know what they’re doing, know how to fix any conflicts with the base context, and those that don’t won’t know they have the problem (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Resolution #7: Close #4 wontfix, as it adds complications for minimal value. context editors that know what they’re doing, know how to fix any conflicts with the base context, and those that don’t won’t know they have the problem

Gregg Kellogg: +12

David I. Lehn: +1

Gregg Kellogg: -11

Rob Sanderson: https://github.com/w3c/json-ld-rc/issues/6

Ivan Herman: I feel that we must keep the prefixes to the strict minimal;
… the comparison with RDFa is wrong, because RDFa does not have a mechanism of @context
… JSON-LD users can use ad-hoc contexts for specific use;
… we only need to put in this context those that we think every body need.
… One question was raised about the mess with both Dublin Core namespaces,
… what prefixes should be put for them.

Gregg Kellogg: I think we should leave “dc” out;

Gregg Kellogg: Don’t publish “dc” as a prefix

Gregg Kellogg: in the RDFa, it is mapped to dcterms, although many people use it for dc11

Rob Sanderson: I would have gone the other way: “dc” for dc elements, and “dct” for dc terms

Rob Sanderson: dc11 and dcterms

Rob Sanderson: ?

Gregg Kellogg: this would introduce an incompatibility with RDFa

Rob Sanderson: https://www.w3.org/TR/json-ld11/#conformance

Rob Sanderson: has dc11 and dcterms

Gregg Kellogg: I think at some points even we were inconsistent in the spec, in our use of “dc:”

Rob Sanderson: in the conformance section, we used “dc11” and “dcterms”

Ivan Herman: that’s a killer argument :)

Proposed resolution: Use the dc11 and dcterms prefixes as per the syntax doc’s prefixes (Rob Sanderson)

Gregg Kellogg: +1

Ruben Taelman: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Resolution #8: Use the dc11 and dcterms prefixes as per the syntax doc’s prefixes

Ivan Herman: +1

Ivan Herman: the file is in the repository; do we want to use the github.io directly?
… or do we went to store it somewhere else?
… Do we want a W3C URL?

Rob Sanderson: I think we should have one.

Gregg Kellogg: it would be under w3.org/ns/json-ld/

Rob Sanderson: FWIW, annotation context: https://www.w3.org/ns/anno

Gregg Kellogg: e.g. w3.org/ns/json-ld/base-context

Ivan Herman: currently the json-ld files under ns are not in a directory,
… so I would prefer not to do that.

Rob Sanderson: ns/json-ld11-base-context ?

Gregg Kellogg: versioning namespace documents has proven to be a bad idea.

Rob Sanderson: yes but this is not really a namespace document
… My fear is that if we add a new keyword in 1.2, with an alias in the base context,
… that would blow up for 1.1 processors.

Ivan Herman: something like /ns/json-ld-base

Ivan Herman: we don’t have versions for the core files

Proposed resolution: Use /ns/json-ld-base as the name for the base context (Rob Sanderson)

Ivan Herman: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Gregg Kellogg: + 0.5

Resolution #9: Use /ns/json-ld-base as the name for the base context

Action #2: PR to the context for new version (Ivan Herman)

4. Adjourn

5. Resolutions

6. Action Items