JSON-LD Working Group Telco — Minutes

Date: 2019-07-12

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Ruben Taelman, Benjamin Young, Adam Soroka, Dave Longley, David I. Lehn, David Newbury, Pierre-Antoine Champin

Regrets: Ivan Herman

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Adam Soroka, Pierre-Antoine Champin

Content:

1. scribe selection

2. Approve minutes of previous call

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

Adam Soroka: +1

Rob Sanderson: +0 (not present)

Gregg Kellogg: +1

Benjamin Young: +1

David I. Lehn: +1

Dave Longley: +1

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-28-json-ld

Ruben Taelman: +1

3. Announcements / Reminders

3.1. Standing TPAC reminder

3.2. Other announcements

Benjamin Young: https://adaptivecards.io/

Benjamin Young: talking with team at MS building ^^^^

Benjamin Young: they are wondering if JSON-LD can map into their tempalting space
… they are excited about what that might do to avoid being dependent on particular key names
… I’m going to follow up with them in a month
… . JSON-LD evangelism is good!
… if there are people who need some contact I can help
… or let us know how your own efforts are going

4. Issues

4.1. @source and @propagates

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/108

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/174

Benjamin Young: there’s also a related API PR https://github.com/w3c/json-ld-api/pull/112

Gregg Kellogg: we should probably have created a new issue
… @propagate defines how scoped contexts are managed when traversing properties;
… by default type scoped contexts are droped when traversing; property scoped contexts are kept

Rob Sanderson: preview: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/200.html#context-propagation

Gregg Kellogg: there are caveats when contexts are in arrays.
… @azaroth and @pchampin proposed to change the default for type scoped contexts. This should be discussed in a different issue.
… Another discussion was about what could be used together with @source and @propagate.
… I argued that @version should be also used. @protected could be used also.

Benjamin Young: syntax PR https://github.com/w3c/json-ld-syntax/pull/200

Gregg Kellogg: And term definitions could be used to “edit” the sourced context.

Gregg Kellogg: https://github.com/w3c/json-ld-api/pull/112

Gregg Kellogg: This is reflected in two PRs (in syntax and api).
… One of the question is whether @source is the correct keyword,
… since this is not just a reference to a context (it can be customized).

Dave Longley: i’m currently in the @import camp for bikeshed colors

Rob Sanderson: You said it only works if the sourced context is an object, and not an array?

Gregg Kellogg: yes, the implementation of @propagate is complicated, especilally identifying what needs to be unwind.
… Arrays make it harder to figure it out.

Rob Sanderson: This limitations should be checked agains use cases.
… In XXX, we do have an array containing the Web Annotation context, then another redefining some terms.

Gregg Kellogg: this could be done by a context object sourcing the Web Annotation context, and customizing it in the same object.
… This would actually be more faithful to the intention.

Rob Sanderson: Thus: @context: { "@source": "http://www.w3.org/ns/anno.jsonld", "@propagate": true, "label": { ... } }

Dave Longley: There was no way in JSON-LD to inline edit a context when importing it.
… What @azaroth wants to do is exactly that.

Gregg Kellogg: The danger is that the remote context may change, then the edits may become inaccurate.
… SRI in this situation could be useful, to assert something about the context being referenced.

Dave Longley: +1, and the constraint of having a context object (as opposed to array) would also apply to SRI
… with arrays, this would be very brittle
… as arrays could reference other contexts

Pierre-Antoine Champin: this constraint (the referenced context only being an object) looked very complicated to me at first
… it’s started to make more sense
… but if we want to make this a thing, it should have a name
… a well-identified notion
… we might want to reuse it in other parts of the spec

Gregg Kellogg: I think we do
… we talk about it in the API algo
… but we may not have a term defined

Dave Longley: figuring out the language might have to do with talking about contexts as “composable” or not … at least via certain features

Gregg Kellogg: for that matter, we don’t have terms for a type-scoped context vs. a property-scoped context

Rob Sanderson: it would be useful to know about implementation status on this. Can we test it now in the distiller?

Gregg Kellogg: it is currently on a branch, but I can make it available in the distiller.
… I was waiting for us to discuss it, and settle the @source/@import question.

Rob Sanderson: what about the python and JS implementations?

Dave Longley: we don’t have a timeline for python at the moment

David I. Lehn: neither for JS

Rob Sanderson: as for @source vs. @import, let’s have a strawpoll

Benjamin Young: Those for @source please +1

Dave Longley: -1

Gregg Kellogg: +0

Rob Sanderson: -0

Benjamin Young: -1

Adam Soroka: +0

Pierre-Antoine Champin: +0

Ruben Taelman: -1

David Newbury: +0

Benjamin Young: Those for @import please +1

Rob Sanderson: +1

Dave Longley: +1

Gregg Kellogg: +1

Benjamin Young: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +0.5

Adam Soroka: +1

Resolution #2: change @source to @import

Rob Sanderson: :shipit:

Gregg Kellogg: there is some pressure to get a new working draft
… (discussion on whether we need to wait for feedback on the PRs)

Benjamin Young: merged https://github.com/w3c/json-ld-syntax/pull/202

4.2. Content addressable contexts

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/9

Rob Sanderson: +1 to closing, no normative change needed

Benjamin Young: this one has been closed and re-opened…

Dave Longley: +1 to closing, handled elsewhere

Gregg Kellogg: I’d like to close it as an issue for the normative documents. Create a new one for the BP

Proposed resolution: close #9 with no action needed; solved via DocumentLoader and possible content for the Best Practices (Benjamin Young)

Rob Sanderson: +1

Gregg Kellogg: +1

Dave Longley: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Adam Soroka: +1

Ruben Taelman: +1

David Newbury: +1

David I. Lehn: +1

Resolution #3: close #9 with no action needed; solved via DocumentLoader and possible content for the Best Practices

4.3. JSON-LD in HTML

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/172

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/103

Benjamin Young: #172 is Manu raising the problem of parsing text/html context documents.
… #103 is about changes in the document’s base URL for embeded JSON-LD.
… Let’s discuss them separately, starting with #103.
… The Web Publishing WG is rechartering. They are planning to focus on an audio-book format (using JSON-LD in a separate file).
… Their work on JSON-LD in HTML would be moved to the CG.
… So if the use case for #103 is too specific, we could decide to not address it.

Rob Sanderson: (asks a question about setting the base URL to null)

Rob Sanderson: +1 for consistency :)

Gregg Kellogg: if base is set to null, relative URIs are not resolved at all
… but in the case of JSON-LD is embedded, I think the URL of the embedding document is used
… There has been a concern about the fact that base can be dynamically modified.

Dave Longley: I remember use cases where people wanted relative URIs to survive compaction/expansion.
… We are well aligned with what others are doing.

Dave Longley: +1 for supporting package-scoped things

Benjamin Young: I think the behaviour of not resolving URIs when the base is set to null, should be made explicit (if it is not already)

Action #1: Benjamin Young to research the status @base: null and possibly suggest making things clearer

Benjamin Young: https://html.spec.whatwg.org/multipage/scripting.html#data-block

Gregg Kellogg: it is possible that it is explicit in the API doc, but not the syntax doc

Benjamin Young: from an HTML perspective, any attribute of the script tag should be ignored
… #103 should be taken care of by the action created above.
… Now discussing #172: context documents embeded in a text/html document.

Gregg Kellogg: Note that the spec currently mentions this use case.

Dave Longley: +1 to making it more palatable

Gregg Kellogg: There was concern about naming the HTML-enabled processors “full processors”,
… implying that otherprocessors are not “fully compliant”

Rob Sanderson: as soon as we decided to make JSON-LD in HTML, we open the door to this;
… so some JSON-LD will not be available to a non “full processor”

Benjamin Young: currently, contexts are all in JSON-LD documents.
… There does not seem to be a demand for embedding contexts in HTML documents.

Dave Longley: +1 to bigbluehat, “contexts” are all in JSON-LD documents, don’t change that … fine to talk about how to pull JSON-LD blocks out of HTML

Benjamin Young: Additionnally, we would need a different content-type for data-blocks, to distinguish contexts from data.
… For me, the fact that JSON-LD can be embedded in data-blocks was not normatively defined by JSON-LD; it was normatively defined by HTML.
… I never expected a JSON-LD processor to get itseld the embeded JSON-LD from the data-block.

Dave Longley: -1 to massive shifts that complicate all the things.

Gregg Kellogg: one demand is from schema.org:
… they would be happy to not have to perform content-negociation,
… and serve their context directly in the HTML homepage.
… Re. content-type, we don’t need a new one, merely a content-type parameter for distinguishing contexts.

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/172#issuecomment-493257482

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/172#issuecomment-501884159

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/172#issuecomment-502164325

Benjamin Young: danbri did mentioned that he didn’t want to put the actual (big) schema.org context in the HTML page;
… merely a small context referencing the original context

Dave Longley: -1 to using a hammer to solve a problem that may smash everything around it to bits

Benjamin Young: What happended before (content-negociation + redirection) was happening outside the JSON-LD processor.
… Now, we forced this in the JSON-LD processor, making it a much bigger animal.

Rob Sanderson: I see things differently.
… As we have JSON-LD data in HTML documents, we can not make contexts in HTML invalid.
… Would JSON-LD data with a context in it be invalid?

Dave Longley: -1000 to referencing an HTML document as a remote context

Rob Sanderson: This would make no sense.
… The question we could ask is: is it valid to reference an HTML-embeded context from another JSON-LD document?

Rob Sanderson: +1 to explicit justifications

Gregg Kellogg: topic for next week: we need a story to justify the perceived “bloat” in JSON-LD 1.1

5. Resolutions

6. Action Items