JSON-LD Working Group Telco — Minutes

Date: 2020-04-24

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Ruben Taelman, Gregg Kellogg, Ivan Herman, David I. Lehn, Benjamin Young

Regrets: Rob Sanderson

Guests:

Chair: Rob Sanderson

Scribe(s): Gregg Kellogg, Ruben Taelman

Content:

1. Announcements / Reminders?

2. Transitions

2.1. Streaming

Rob Sanderson: https://github.com/w3c/transitions/issues/240

Ivan Herman: the streaming note has been approved.

Action #1: check pubrules on streaming note (Gregg Kellogg)

Ivan Herman: We’re waiting to hear on transition of rec-track specs

Rob Sanderson: We can move the namespace doc forward, given that the streaming doc has been approved

Ivan Herman: I’ll wait to push the docs to /ns until after publication.

2.2. Core Spec Transitions

Rob Sanderson: https://github.com/w3c/transitions/issues/239

Rob Sanderson: Not yet approved by Ralph.

Ivan Herman: Ralph and Phillipe usually have approval sessions on Friday, so may happen today. Otherwise, I’ll start poking

3. New issues submitted after PR request

3.1. Process

Rob Sanderson: https://github.com/timothee-haudebourg/json-ld

Rob Sanderson: There are 6+ new issues for the API. (from Rust impl)

Ivan Herman: Things are frozen when the PR is published. We can do editorial changes between now and publication.
… Once PR is to AC, the documents are frozen once and for all.

Gregg Kellogg: They are some imprecise steps in the algorithm, with things missing.

Ivan Herman: Those things can still be done before PR.
… If changes are not styistic, then we should wait

Gregg Kellogg: What is the process for dealing with issues that are discovered after the document has been frozen?
… We could record these issues as errata.

Ivan Herman: I need to set up errata management. That will be for once the REC is out.
… For the time being, let’s keep things marked as issues.

3.2. Issues

Gregg Kellogg: One issue (#480) is a bit different: @id: null is not a valid jsonld document, which has to do with the fact that we ignore keyword-like entries. A step in the algorithm has issues with this. So this would be more complicated.

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

Gregg Kellogg: One of the differences with set versus array is with duplicates. If you compact, there are no duplicates. In expansion, there is nothing that eliminates duplicates. This issue shows something that we may want to look at.
… In a future version, this may require an incompatible change.
… The editorial change is that expansion does not remove duplicates.

Rob Sanderson: We can do this before the document is frozen.

Proposed resolution: Make editorial change to note that @set terms can have duplicate entries during expansion (only) (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Ruben Taelman: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #1: Make editorial change to note that @set terms can have duplicate entries during expansion (only)

David I. Lehn: +1

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

Rob Sanderson: This issue is a micro-tweak to the algorithms.

Gregg Kellogg: The API document does not explicitly handle @protected: false cases.
… I believe this change is editorial.

Rob Sanderson: The change to the text should be very small.
… This is a change to a normative section that we have previously decided is editorial, because the tests aren’t changed. So we should fix this if we are comfortable given the transition request.

Ivan Herman: Does it affect any implementation already out there? I assume not.

Rob Sanderson: If you implemented strictly, you would fail the test. So this change is required to make implementations pass the test.

Proposed resolution: Make editorial fix for @protected in Create Term Definition algorithm per api #475 (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Ruben Taelman: +1

David I. Lehn: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #2: Make editorial fix for @protected in Create Term Definition algorithm per api #475

Benjamin Young: +1

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

Gregg Kellogg: This is editorial. I suggested an improvement to the wording. This would not change the intention, only improve the wording.

Proposed resolution: Improve wording to clarify any/all and concatenate per api #477 (Rob Sanderson)

Ruben Taelman: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Benjamin Young: +1

Resolution #3: Improve wording to clarify any/all and concatenate per api #477

David I. Lehn: +1

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

Gregg Kellogg: We have a flag “from map” that was not used, but it is actually used, but got lost. It is required for inherited scoped context. If an implementation does not use this, it can not pass the tests. So this would require restoring the use of this flag to fix this.

Proposed resolution: Add back from_map to 13.8.3.6 to recursive call for scoped contexts per api #478 (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Ruben Taelman: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Resolution #4: Add back from_map to 13.8.3.6 to recursive call for scoped contexts per api #478

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

Gregg Kellogg: It passes active property, while it shouldn’t. A node object contains an incl block, and has a rel to another block, the prop relationship should only hold to …. Passing null should be fine here.

Pierre-Antoine Champin: Does passing this active property have some impact on scoped contexts?

Gregg Kellogg: yes, by passing the active property, it is used in an unexpanded sense to find relationships in unscoped contexts, and also for informing the relationship. In a streaming impl, it could be used for creating that triple. I discovered that in my streaming impl. If you strictly follow the algorithm, it doesn’t create the issue, as can be seen by the implementations that pass the tests. It is however more correct to not pass an a

Ruben Taelman: ctive property.

Pierre-Antoine Champin: I was afraid that this would cause an unintended ripple effect.

Gregg Kellogg: Those things should be unrelated.
… I tried it in my implementation, putting null did not break anything.
… But it was required in my streaming implementation.

Proposed resolution: Clarify that in 13.4.6.2 for @included an implementation should pass null to avoid creating a reference, per api #179 (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Ruben Taelman: +1

Benjamin Young: +1

Resolution #5: Clarify that in 13.4.6.2 for @included an implementation should pass null to avoid creating a reference, per api #479

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

Gregg Kellogg: This is an implication of ignoring keyword-like things.
… The intention is that if you see something that looks like a keyword to be ignired, it would not result in any properties that would be added to the expansion output.
… In this case, this reveals that there may be other cases requiring a more substantial change. So we may have to work with this, and tackle it in the future.
… It would only be a problem for docs using invalid keywords that are ignored in any case. Those cases may result in invalid documents. There is nothing inherrently wrong with this, but we may need a proper solution in the future.
… @json is only valid for @type values, so if someone would use it as a value for a node, there is no logic that would transform it into rdf:json. Since it is a valid keyword, it could result in a URI if you have an @vocab.
… In CBOR, that is not a keyword, the result would be null. Same thing if @type is used in a node object. Neither of those cases would produce anything invalid. It’s a special case. The problem may be entirely contained to @id.

Rob Sanderson: We should defer to future version. This is a an edge case that would result in more weirdness through the algorithm.

Proposed resolution: Defer api #480 until future version, as error case of assigning a non-URI as a URI leads to a further (worse) error case, and the solution would be far reaching (Rob Sanderson)

Gregg Kellogg: We could annotate the test related to this that this results in invalid jsonld.

Gregg Kellogg: +1

Ruben Taelman: +1

Rob Sanderson: +1

Ivan Herman: +

Pierre-Antoine Champin: +1

Benjamin Young: +1

Resolution #6: Defer api #480 until future version, as error case of assigning a non-URI as a URI leads to a further (worse) error case, and the solution would be far reaching

3.3. Errata management

Ivan Herman: The script we use only works with a single repository. We could set up an errata for each repo, or one just for the WG.
… (I’d rather not hack the script)
… THe cleanest thing is to put the errata close to the document.

Benjamin Young: We talked about doing errata with annotations.

Ivan Herman: We’d need to set up an annotation server on W3C.

Benjamin Young: We use slack now …
… Other groups use the WHATWG’s kit to do Github-based errata.

Ivan Herman: What I have does that. It was done for the CSVW group.
… The script gives you a report of the current errata with discussions, resolutions, etc.

Rob Sanderson: e.g. https://www.w3.org/annotation/errata/

Ivan Herman: In theory, we could have one errata for all the documents, but that would be more difficult.

Benjamin Young: I could set up a GitHub template repo to make this easier.

Ivan Herman: Not that simple.

Benjamin Young: It doesn’t show it within the document :(

Action #2: put labels into the four repos for errata management (Ivan Herman)

Ivan Herman: I’ll add the labels to the four repos to allow them to appear in the report.

4. Rechartering

Ivan Herman: I’m still waiting on some things for recharting, but will come in when the PR is done.

5. Base Context

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

Ivan Herman: See latest

Ivan Herman: I summarized the changes. I think we agree on prefixes.
… While bigbluehat and I grugingly accept to use aliases, but perhaps the ship has sailed.
… I added “direction” and “graph”.
… We have two types, “HTML” and “JSON”. Note “json” is also a term.
… No one will use these things anyway, so maybe we can skip them.

Rob Sanderson: +1 to removing JSON and HTML

Ivan Herman: I also lised some pre-defined terms (comment, label, …)

Rob Sanderson: I’m: +1, +1, +1, +0 (no opinion)

Ivan Herman: “isDefinedBy” and “seeAlso” seem natural.
… Also, “license” is mapped to schema:license, not XML2.

Benjamin Young: desribedby - https://www.iana.org/assignments/link-relations/link-relations.xhtml

Benjamin Young: You put isDefinedBy as an alternative to describedBy, (they mean different things)

Benjamin Young: from POWDER https://www.w3.org/TR/powder-dr/#assoc-linking

Benjamin Young: As describedBy might become obsolete, I’m reluctant to add it.

Rob Sanderson: https://iiif.io/api/presentation/3.0/#45-html-markup-in-property-values

Benjamin Young: Putting HTML in JSON is extremely common. Whether “rdf:HTML” is harder than “HTML”, I don’t know.

Benjamin Young: “@type”: “rdf:HTML” vs. “type”: “HTML” in a data document

Benjamin Young: (or “@type”: “HTML”…which I’d prefer)

Rob Sanderson: {“value”: “<p> …</p>”, “type”: “HTML”}

Ivan Herman: I’m less worried about the context author.

Benjamin Young: The risk is naming collision, and it’s harder to remove something than add it.

Pierre-Antoine Champin: and as ivan pointed out, ‘rdf:HTML’ can still be used

Benjamin Young: I’d remove HTML and JSON, along with all the keyword aliases.
… Others might think that keyword aliases would have different meanings in their contexts.

Ivan Herman: Two different things, are the datatype aliases in there, the other is are the keyword aliases in there.

Benjamin Young: People might have values for these types, and an expectation for existing JSON for a collision is fairly high.

6. Adjourn

7. Resolutions

8. Action Items