JSON-LD Working Group Telco — Minutes

Date: 2019-05-10

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Adam Soroka, Ruben Taelman, Rob Sanderson, Dave Longley, Benjamin Young, Ivan Herman, Manu Sporny, David I. Lehn, Simon Steyskal

Regrets: Pierre-Antoine Champin, Tim Cole, David Newbury, Harold Solbrig, Jeff Mixter

Guests:

Chair: Rob Sanderson

Scribe(s): Ruben Taelman

Content:

1. Approve the minutes of previous call

Proposed resolution: approve minutes of previous call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-03-json-ld (Rob Sanderson)

Rob Sanderson: +1

Adam Soroka: +1

Dave Longley: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Benjamin Young: +1

Ivan Herman: +1

Resolution #1: approve minutes of previous call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-03-json-ld

2. Announcements / Reminders

Rob Sanderson: Any announcements?

Gregg Kellogg: Thanks to Simon, we figured out publishing problems. So WDs are published as of today.

Rob Sanderson: Any others?

3. WD Publication / Echidna

Rob Sanderson: gkellogg, could you summarize what happened with the WDs?

Rob Sanderson: +1 to simonstey for expert debugging!

Gregg Kellogg: When publishing and it gives a failure, it gives a log, which is un-useful. It is specberus that is complaining that this is not a WD, which makes no sense. Simon figured out a change in the tool. Also, we were pulling from the wrong version branch. Now we are using the latest version, and it works now. Only problem: the errors are not really helpful. Thanks to Simon for helping.

Ivan Herman: I’m traveling, so I was not able to help; sorry…

Rob Sanderson: Could you give the new URLs for the minutes?

Gregg Kellogg: https://www.w3.org/TR/2018/WD-json-ld11-20181214/

Gregg Kellogg: https://www.w3.org/TR/2018/WD-json-ld11-api-20181214/

Gregg Kellogg: https://www.w3.org/TR/2018/WD-json-ld11-framing-20181214/

4. Errata

Gregg Kellogg: https://www.w3.org/2001/sw/wiki/JSON_LD_Errata

Gregg Kellogg: Errata publishing for JSON-LD 1.0. Bad expansion for native values was fixed. IRI expansion creates unintended IRIs required a change in 1.0 when creating IRIs.
… In 1.0, IRIs were used for that. We addressed that further in 1.1 using @prefix definition.
… We need to ratify that this is a change we want to allow and use for purpose of old 1.0 processing.
… Issue 7: This is a result of a decision of this WG to not allow term set to not allow expansion …... which was a security issue.

Ivan Herman: We must explicitly propose changes to 1.0. The other thing that we disagreed on was that we refer to behaviour to 1.0, we must refer to REC 1.0, and not REC 1.0-amended-by-errata.
… There was an intermediate version with errata in. As far as RECs are concerned, we must refer to official REC without the errata.
… It’s an editorial thing.

Gregg Kellogg: Spec text says that 1.1 processor can work in in 1.0 mode.

Ivan Herman: We have to specify if it works in 1.0-mode, or 1.0-with-errata. Current text is not clear.

Benjamin Young: We don’t have much text around a 1.0 processing mode. It’s just the default mode until 1.1 is signaled.

Gregg Kellogg: You get in 1.1 if you see 1.1 in the context. You can not set 1.0 in the version.

Benjamin Young: https://w3c.github.io/json-ld-syntax/#dfn-processing-mode

Gregg Kellogg: Do we want to formally describe mode of processor without version 1.1 being seen?

Rob Sanderson: Editorial note: We should not preclude future modes by defining 1.1 as everything that is not 1.0. Because there can be future versions.

Manu Sporny: +1 to azaroth – ensure we’re aware of future versions

Rob Sanderson: There must be a process for errata for this sort of situation where proc mode for some spec is changed by errata for security or other reasons. Is there something we can point to that could be used for justifying this?

Gregg Kellogg: Notes that a hypothetical 2.0 processor likely would depend on @version: 2.0, as we locked down values in 1.1 processing. It could work with @version: 1.1

Ivan Herman: This is fuzzy. Usually: if there is errata in one version, group issues new version, and new version incorporates errata.
… Here we have this extra round that says if we have data that was created years ago, that there should be a switch.
… we should document exact expectations. It is true in 99% of cases that until 1.1 version is triggered, any data processed will be not dependent on processor version.
… We can do any of the two options: non-1.1 would process in strict 1.0 Recommendation mode, or non-1.1 would process in 1.0 Rec mode amended with the errata. We have to decide which one do, but either way must be documented.

Manu Sporny: Any experience on backwards-compat changes?
… In general, I agree with what you said about future-compatibility. e.g. Not making too broad statements.
… I don’t think anyone wants to change 1.0 processing things.

Dave Longley: I think the errata is very narrow and there may only be very few cornercases that would be affected by it – and those probably should be affected by it (for those that are related to security)

Rob Sanderson: It seems like we should accept errata and issue them with expectation that processors act differently when updated taking into account errata for 1.0. There should be clear signaling that this is a change for security reasons without significant impact on current usage.

Manu Sporny: Agree w/ dlongley :)

Ivan Herman: I am fine with that. But this has to be made very clear in the doc.
… Say that the behavior is not exactly the same what 1.0 doc says.

Manu Sporny: … and it’s “ok” in this case, because we’re fixing a security concern.

Gregg Kellogg: We’ll need directions on editorial actions.

Ivan Herman: The other errata was security issue

Gregg Kellogg: Yes, erratum 7

Proposed resolution: Accept erratum 5 on the expansion of native values to IRIs (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0001.html ) (Rob Sanderson)

Rob Sanderson: +1

Dave Longley: +1

Gregg Kellogg: +1

Ivan Herman: +1

Simon Steyskal: +1

Ruben Taelman: +1

David I. Lehn: +1

Adam Soroka: +1

Gregg Kellogg: +1

Ruben Taelman: +1

Resolution #2: Accept erratum 5 on the expansion of native values to IRIs (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0001.html )

Proposed resolution: Accept erratum 7 on expansion of IRIs to terms that are IRIs other than the input (per https://lists.w3.org/Archives/Public/public-rdf-comments/2019Apr/0000.html) (Rob Sanderson)

Dave Longley: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Ruben Taelman: +1

Adam Soroka: +1

Simon Steyskal: +1

Ivan Herman: +1

David I. Lehn: +1

Resolution #3: Accept erratum 7 on expansion of IRIs to terms that are IRIs other than the input (per https://lists.w3.org/Archives/Public/public-rdf-comments/2019Apr/0000.html)

Proposed resolution: Be explicit about the processing change for the errata 5 and 7 on systems that implement current 1.0 specifications, to be written in 1.1 spec (Rob Sanderson)

Ivan Herman: +1

Rob Sanderson: +1

Dave Longley: +1

Ruben Taelman: +1

Simon Steyskal: +1

Gregg Kellogg: +1

David I. Lehn: +1

Adam Soroka: +1

Resolution #4: Be explicit about the processing change for the errata 5 and 7 on systems that implement current 1.0 specifications, to be written in 1.1 spec

Proposed resolution: Accept erratum 6, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0002.html) (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Dave Longley: +1

Gregg Kellogg: +1

Gregg Kellogg: Item 2 is also a difference in behaviour.

Ruben Taelman: +1

Simon Steyskal: +1

David I. Lehn: +1

Rob Sanderson: Because it changes the algorithm?

Gregg Kellogg: Yes

Resolution #5: Accept erratum 6, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0002.html)

Proposed resolution: Accept erratum 2, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2014Jul/0011.html) (Rob Sanderson)

Gregg Kellogg: If you have a list where a bnode exists in two different graphs, then it would be incorrect to express as a representation of lists. Because the fact that that bnode was used twice, was removed. The correction is to not allow such lists to be shared. You can only use @list for subset of tail of the list that has only bnodes that exist in a single graph.

Rob Sanderson: +1

Ruben Taelman: +1

Simon Steyskal: +1

Gregg Kellogg: +1

Dave Longley: +1

Adam Soroka: +1

Ivan Herman: +1

David I. Lehn: +1

Resolution #6: Accept erratum 2, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2014Jul/0011.html)

5. Contexts in HTML

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/172

Rob Sanderson: Summary: in the spec we say that (normatively) json-ld can be included in script el. There is now a requirement on <base>. It was noted that contexts are also jsonld. Hence, it is permissible to have contexts embedded in script tags inside html. This means that processors need to be able to process that.
… We all agree that this is an extension to normal proc mode. Either we need to say that contexts have a special role, contexts are not jsonld, or we need to accept that contexts can be embedded in html and processors should have to be able to say that they support processing them.

Manu Sporny: Some context wrt VC. Purely json-based processors find information using context. Someone said it would be nice to have human-readable context. Argument in favor of this feature.
… Person said, It would be nice to see jsonld in html. But I don’t want the burden of jsonld processor supporting html.
… We all agree that JSON-LD in HTML is a huge use case (e.g. schema.org)
… I think pulling in contexts from html is controversial
… 2 questions
… 1: does jsonld context in html greatly increase jsonld usage?
… I think the answer is no
… There are other ways to solve issues people would have to want html for contexts.
… 2: is this going to create interop issues?
… Is this going to cause ecosystem to change by other processors to start failing?
… I think this is going to create issues.
… Some people are going to start publishing contexts as html only.
… Even if we say you should not do this.
… The damage this feature could create is far greater than possible benefits.
… I have more reasons, but this is the biggest argument.
… We should wait until there is more demand for this feature. We could do it in the future if really needed.

Benjamin Young: “This means that processors need to be able to process that.”

Benjamin Young: +1 to everything Manu said.
… This is the part of what Rob said in start that jsonld in html normative somehow begets this notion that we have to …
… jsonld in html has always been normative thanks to the data block in script tag
… we just described it better
… comes from HTML5 spec.
… Using single URL to specify context and its documentation is interesting. (Conneg can be used)
… Overhead of making this possible is too big for processors.
… This is a nuclear weapon to kill a small bird.
… There are less damaging ways to solve the problems discussed.

Dave Longley: +1 to manu and bigbluehat

Manu Sporny: +1 to bigbluehat !

Benjamin Young: We need to be more careful than we have before, before introducing new things like these.

Rob Sanderson: ref - https://www.w3.org/TR/2018/WD-json-ld11-20181214/#embedding-json-ld-in-html-documents

Rob Sanderson: in 1.1, we made it our problem, so we have to solve it.
… I want to channel danbri. Search engines want to include info in their knowledge graph that they find on the web as jsonld.
… schema.org, or at least the engines, currently assume do not process contexts at all.
… If you have a template in your website, with multiple schema.org definitions, you could put into your CMS as a data script block to push this into every single page.
… search engines would be able to see these blocks
… by having google’s clusters waiting to process jsonld in page. Publishers would be required to not embed into page.
… why not have it as include contexts object?: when multiple people responsible for editing context. Also, if there are templare-driven CMSs being used, you want to stripe jsonld over different templates being used. This would cause data blocks being used multiple times.

Dave Longley: Many of these things can be solved by saying that serving should happen with application/ld+json
… I think there are many cases not being considered wrt complexity
… many use cases not covered on template-based html pages
… Such as dynamic pages when generated client-side with javascript
… We shouldn’t get into that space.
… We should say that context MUST be server with proper content type

Manu Sporny: I could not follow schema.org use case. Danbri should write this up. We should do a deep analysis on this use case, to see what could address his concern.
… There are a bunch of assumptions in that use case
… e.g. people could create their own non-schema.org contexts. This would add a huge amount of complexity.
… it would be good to have dan involved.

Rob Sanderson: +1 to dlongley and manu

Manu Sporny: Also, it feels like this is migrating away from BPs.
… We are learning a lot from security around publishing contexts.
… We had discussions on the type of attacks, if you could publish contexts as html.
… So there are security concerns around this feature
… Concern around complexity, interoperability, …
… A long list of reasons for saying that this is not spec-ready.
… So we have to get use-case right. And see if it can be solved with current feature-set. Only if needed, we should look further into this html issue.

Ivan Herman: Manu said many things what I wanted to say. We need danbri to raise his voice.
… We have to rely on documented requirements

Rob Sanderson: I agree

Benjamin Young: I think what you described, if it’s on danbri’s previous desire to have this in jsonld, then this is a request. Dan has expressed multiple times that search engines want to understand page contents. This is different to giving identifier that serves contexts in html.
… We are going to end up with RDF dataset that is compiled of multiple contexts.

Gregg Kellogg: no, doesn’t work that way

Benjamin Young: Generating a graph is not about coupling jsonld context identifier algorithm.

Gregg Kellogg: I don’t think it is practical for many CMSs to do content negotiation (like github pages)
… we have to re-characterize what jsonld in html is.
… I agree that these things start to increase complexity and raising barrier.
… We need to reconsider what processing jsonld in html means.

Manu Sporny: +1 to re-characterize how processors process JSON-LD in HTML.

Rob Sanderson: We are not going to solve this today.
… I will reach out to danbri to see if he wants to engage.

Gregg Kellogg: He may be at WebConf

Benjamin Young: +1 to re-characterize it in relationship to the existing usage patterns

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/issues/174

6. Resolutions