JSON-LD Working Group Telco -- 24 Apr 2020

<azaroth> scribenick: gkellogg

scribe+

Announcements / Reminders?

Transitions

<azaroth> SUBTOPIC: Streaming

<azaroth> https://github.com/w3c/transitions/issues/240

ivan: the streaming note has been approved.

<scribe> ACTION: gkellogg to check pubrules on streaming note

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

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

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

<azaroth> SUBTOPIC: Core Spec Transitions

<azaroth> https://github.com/w3c/transitions/issues/239

azaroth: Not yet approved by Ralph.

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

New issues submitted after PR request

<azaroth> SUBTOPIC: Process

<azaroth> https://github.com/timothee-haudebourg/json-ld

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

ivan: 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.

<rubensworks> scribe+

<rubensworks> gkellogg: They are some imprecise steps in the algorithm, with things missing.

<rubensworks> ivan: Those things can still be done before PR.

ivan: If changes are not styistic, then we should wait

<rubensworks> gkellogg: What is the process for dealing with issues that are discovered after the document has been frozen?

<rubensworks> ... We could record these issues as errata.

ivan: 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.

<azaroth> SUBTOPIC: Issues

<rubensworks> gkellogg: 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.

<azaroth> https://github.com/w3c/json-ld-api/issues/473

<rubensworks> gkellogg: 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.

<rubensworks> ... In a future version, this may require an incompatible change.

<rubensworks> ... The editorial change is that expansion does not remove duplicates.

<rubensworks> azaroth: We can do this before the document is frozen.

<azaroth> PROPOSAL: Make editorial change to note that `@set` terms can have duplicate entries during expansion (only)

<azaroth> +1

<rubensworks> +1

<bigbluehat> +1

<pchampin> +1

<ivan> +1

RESOLUTION: Make editorial change to note that `@set` terms can have duplicate entries during expansion (only)

<dlehn> +1

<azaroth> https://github.com/w3c/json-ld-api/issues/475

<rubensworks> azaroth: This issue is a micro-tweak to the algorithms.

<rubensworks> gkellogg: The API document does not explicitly handle @protected: false cases.

<rubensworks> ... I believe this change is editorial.

<rubensworks> azaroth: The change to the text should be very small.

<rubensworks> ... 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.

<rubensworks> ivan: Does it affect any implementation already out there? I assume not.

<rubensworks> azaroth: If you implemented strictly, you would fail the test. So this change is required to make implementations pass the test.

<azaroth> PROPOSAL: Make editorial fix for `@protected` in Create Term Definition algorithm per api #475

<azaroth> +1

<rubensworks> +1

<dlehn> +1

<pchampin> +1

<ivan> +1

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

<bigbluehat> +1

<azaroth> https://github.com/w3c/json-ld-api/issues/477

<rubensworks> gkellogg: This is editorial. I suggested an improvement to the wording. This would not change the intention, only improve the wording.

<azaroth> PROPOSAL: Improve wording to clarify any/all and concatenate per api #477

<rubensworks> +1

<azaroth> +1

<ivan> +1

<pchampin> +1

<bigbluehat> +1

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

<dlehn> +1

<azaroth> https://github.com/w3c/json-ld-api/issues/478

<rubensworks> gkellogg: 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.

<azaroth> PROPOSAL: Add back from_map to 13.8.3.6 to recursive call for scoped contexts per api #478

<azaroth> +1

<rubensworks> +1

<bigbluehat> +1

<pchampin> +1

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

<azaroth> https://github.com/w3c/json-ld-api/issues/479

<rubensworks> gkellogg: 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.

<rubensworks> pchampin: Does passing this active property have some impact on scoped contexts?

<rubensworks> gkellogg: 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

<rubensworks> ctive property.

<rubensworks> pchampin: I was afraid that this would cause an unintended ripple effect.

<rubensworks> gkellogg: Those things should be unrelated.

<rubensworks> ... I tried it in my implementation, putting null did not break anything.

<rubensworks> ... But it was required in my streaming implementation.

<azaroth> PROPOSAL: Clarify that in 13.4.6.2 for `@included` an implementation should pass null to avoid creating a reference, per api #179

<azaroth> +1

<pchampin> +1

<ivan> +1

<rubensworks> +1

<bigbluehat> +1

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

<azaroth> https://github.com/w3c/json-ld-api/issues/480

<rubensworks> gkellogg: This is an implication of ignoring keyword-like things.

<rubensworks> ... 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.

<rubensworks> ... 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.

<rubensworks> ... 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.

<rubensworks> gkellogg: @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.

<rubensworks> ... 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.

<rubensworks> azaroth: We should defer to future version. This is a an edge case that would result in more weirdness through the algorithm.

<azaroth> PROPOSAL: 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

<rubensworks> gkellogg: We could annotate the test related to this that this results in invalid jsonld.

<rubensworks> +1

<azaroth> +1

<ivan> +

<pchampin> +1

<bigbluehat> +1

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

<azaroth> SUBTOPIC: Errata management

ivan: 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.

bigbluehat: We talked about doing errata with annotations.

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

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

ivan: 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.

<azaroth> e.g. https://www.w3.org/annotation/errata/

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

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

ivan: Not that simple.

bigbluehat: It doesn’t show it within the document :(

<azaroth> ACTION: Ivan to put labels into the four repos for errata management

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

Rechartering

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

Base Context

<azaroth> https://github.com/w3c/json-ld-rc/pull/8

<ivan> latest

ivan: 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.

<azaroth> +1 to removing `JSON` and `HTML`

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

<azaroth> I'm: +1, +1, +1, +0 (no opinion)

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

<bigbluehat> desribedby - https://www.iana.org/assignments/link-relations/link-relations.xhtml

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

<bigbluehat> from POWDER https://www.w3.org/TR/powder-dr/#assoc-linking

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

<azaroth> https://iiif.io/api/presentation/3.0/#45-html-markup-in-property-values

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

<bigbluehat> "@type": "rdf:HTML" vs. "type": "HTML" in a data document

<bigbluehat> (or "@type": "HTML"...which I'd prefer)

<azaroth> {"value": "<p> ...</p>", "type": "HTML"}

ivan: I’m less worried about the context author.

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

<pchampin> and as ivan pointed out, 'rdf:HTML' can still be used

bigbluehat: 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: Two different things, are the datatype aliases in there, the other is are the keyword aliases in there.

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

- DRAFT -

JSON-LD Working Group Telco

24 Apr 2020

Attendees

Contents

Announcements / Reminders?

Transitions

New issues submitted after PR request

Rechartering

Base Context

Adjourn

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output