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
- 3. New issues submitted after PR request
- 4. Rechartering
- 5. Base Context
- 6. Adjourn
- 7. Resolutions
- 8. Action Items
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
andHTML
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
- Resolution #1: Make editorial change to note that
@set
terms can have duplicate entries during expansion (only) - Resolution #2: Make editorial fix for
@protected
in Create Term Definition algorithm per api #475 - Resolution #3: Improve wording to clarify any/all and concatenate per api #477
- Resolution #4: Add back from_map to 13.8.3.6 to recursive call for scoped contexts per api #478
- Resolution #5: Clarify that in 13.4.6.2 for
@included
an implementation should pass null to avoid creating a reference, per api #479 - 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