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?
- 2. Transition to PR
- 3. Base Context Discussion
- 4. Adjourn
- 5. Resolutions
- 6. Action Items
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
- Resolution #1: Close #343 invalid, as the final form will have anchors in the html
- Resolution #2: WG agrees that we should progress the three core specifications, syntax, api and framing, to Proposed Recommendation status
- Resolution #3: Request publication of the Streaming note with short name of json-ld11-streaming, and a redirect from json-ld-streaming
- Resolution #4: Setup echidna for future publications of the streaming note
- Resolution #5: Merge the NS PR after updating the links, and ivan will publish to /ns/ when the note is published
- Resolution #6: Close rc #3 won’t fix, as the
@prefix: true
is the default anyway - 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
- Resolution #8: Use the dc11 and dcterms prefixes as per the syntax doc’s prefixes
- Resolution #9: Use /ns/json-ld-base as the name for the base context