JSON-LD Working Group Telco — Minutes

Date: 2019-01-18

See also the Agenda and the IRC Log

Attendees

Present: Benjamin Young, Gregg Kellogg, Ivan Herman, Rob Sanderson, Pierre-Antoine Champin, Dave Longley, David I. Lehn, Jeff Mixter, David Newbury

Regrets: Adam Soroka

Guests:

Chair: Rob Sanderson

Scribe(s): Gregg Kellogg, Rob Sanderson

Content:

1. scribe selection

Action #1: David I. Lehn to update the playground instead of scribing

2. Approve the minutes of the last call

Proposed resolution: Minutes of the last call are approved ( https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-11-json-ld ) (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Ivan Herman: +1

Benjamin Young: +1

David I. Lehn: +1

David Newbury: +1

Resolution #1: Minutes of the last call are approved ( https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-11-json-ld )

Gregg Kellogg: There’s a github user called @vocab who gets notified from minutes

Ivan Herman: Don’t think it’s from the minutes
… what triggers is if it’s … oh … the transcript

Gregg Kellogg: ivan: it’s triggered by something in the comments.

Benjamin Young: Doesn’t matter if it’s robot or typed
… If we can do that in the minutes, that would help.
… I’ll either do it by hand, or try to update the software.

Rob Sanderson: bigbluehat is keeper of the software stack, so he might note that.

3. Logistics

Rob Sanderson: I’ve reached out to Folger a couple of times to confirm that we can use the space, and they haven’t yet responded. I believe that everything’s fine, but I haven’t yet canceled the meeting space at Dupont circle.
… Eric, contact at Folger, needed to validate with their events people, but we havne’t gotten the final word, yet.

Ivan Herman: I see a mail from Sophie, who has confirmed it.

Rob Sanderson: So, we’ll definitely be there, and I’ll let Dupont know.

Action #2: Rob Sanderson to update the web page

Rob Sanderson: There are several places near the Folger we can go for dinner.

4. Issues - Sealed Contexts

Rob Sanderson: Github issue: https://github.com/w3c/json-ld-syntax/issues/20

Ivan Herman: Related issues: https://github.com/w3c/json-ld-syntax/issues/98 and https://github.com/w3c/json-ld-syntax/issues/108

Rob Sanderson: We want to have it such that contexts that are processed after sealed contexts are unable to change the definition of terms.
… So, if you see something like “foo” in the context, you can be confident of its meaning from the sealed context.
… There is also the desire to “unseal” sealed terms. dlongley is champion from Credentidals WG.

Dave Longley: The main reason for the feature is that there are a number of specifications that add prose to text about order of contexts, and that you can extend the context, but may not override terms. There’s no mechanism to enforce this.

Rob Sanderson: An example of such language: https://iiif.io/api/presentation/2.1/#linked-data-context-and-extensions

Dave Longley: People sometimes don’t use JSON-LD processors, and could interpret the data differently then those using JSON-lD procesors.

Rob Sanderson: And: https://iiif.io/api/presentation/3.0/#45-linked-data-context-and-extensions

Dave Longley: The other issue is related: we want a base context to define terms, and call-out an area where you can clear out the sealed contexts. You could use a scoped context to define a new scoped context for whatever is under that term.

Pierre-Antoine Champin: I’m not sure I understand the use case for allowing people to unseal the context. My understanding is that, in some vocabularies, a term is an extension point, so that below that term the sealed context shouldn’t apply.
… I’d understand the case where it’s always cleared, but not where it “could be”

Dave Longley: Yes, it would be a clean-slate by definition.

Benjamin Young: https://w3c.github.io/web-ledger/

Benjamin Young: https://github.com/digitalbazaar/jsonld-patch/tree/implementation

Dave Longley: The case for unsealing is used in web ledger, which allows you to store arbitrary data, and has know knowledge of being in a ledger.
… In the case of json-ld patch, you want to be able to update arbitrary values in a document, in particular, if you want to be able to digitally sign patches.
… You could use a scoped context for “value” to clear the context. It’s the case that you want a clean slate and allow users to override the context using embedded or scoped contexts.

Benjamin Young: Conceptually, this feels like “important!” in CSS, to not allow things to be overridden.
… I think dlongley’s point about how specs are written in the last couple of years is in play in so many places that a sealing mechanism is important.

David Newbury: We talked about JSON literals before, could that be a way to handle content that is not associated with the context?

Dave Longley: We looked at that, but it ends up being much more difficult, because of how signing works.
… You’d end up having to canonicalize the JSON, and it becomes a mess. It avoids pitfalls where we want to avoid causing everything to be marked as a JSON literal.

Rob Sanderson: In IIIF, we have the same wording, but it puts the contexts at the end, rather than the beginning, but we do want to have extension points.
… Similarly, we use language maps, annotations uses string, we want those to be used together.

Gregg Kellogg: Having something that prevents you from saying @context None would be inadvisable
… it does what people have asked for to create the clean slate
… it requires that values for terms to have their own context, so would need to be explicitly set
… is there expectation about changing the default content is up higher.
… If Annotations defines a term, data, and you want to unseal it. You add null as a scoped context
… If you want to have the data in schema.org in data, you could do it with a scoped context that’s an array with null as the first entry, but it’s sealed
… so the context needs to unseal itself

Ivan Herman: The usage of “sealed” seems to be straightforward. I wonder about unsealing only appears when we talk about embedded contexts, is that correct?
… If I have an array of contexts it’s different than if I have an embedded context.

Dave Longley: I think that the main use case where you set context to null, should then allow the scoped context, or via an embedded context. If you defined “data” in a sealed context, you’d then say "@context": null, the second context could then define the term and introspects into the sealed context to see that the term can be overridden because it has a scoped context of null.
… I think we should keep the cascading order we have.

Rob Sanderson: +1 to last in winning

Dave Longley: It can’t override terms, but can override scoping.

Rob Sanderson: I think we can’t change definition order either.

Dave Longley: +1 to sealing individual terms

Jeff Mixter: +1 to individual term sealing

Dave Longley: (we’ve worked out some of these details in #98)

Rob Sanderson: what about sealing specific terms in a context? Then, we wouldn’t need to worry about unsealing different things.
… What would current processors due if they had a …?

Dave Longley: "data": {"@id": "foo:data", "@container": "@graph", "@context": null, "@sealed": true} => enables a later @context to define: "data": {"@context": "..."}

Dave Longley:

"data": {
     "@id": "foo:data", 
     "@container": "@graph", 
     "@context": null, "@sealed": true
}

=> enables a later "@context to define: "data": {"@context": "..."}

Rob Sanderson:

"@context": [
    {
        "data": {
            "@id": "eg:data", 
            "@sealed": false
        }
    },
    {
        "data": {
            "@context": "http://example.org/data-context.jsonld"
        }
    }
]

David Newbury: The only place I can unseal something is within the context that seals it. I can’t add something that unseals something that had previously been sealed.

Rob Sanderson: -1 to restricting to graph containers

Benjamin Young: I about how we can express this so that the behavior is obvious.

Rob Sanderson: E.g. An LDP implementation for Annotations should not require a graph container to put an annotation in a page

Benjamin Young: Perhaps something the scopes the sealing to the term, the content, or something else.
… Perhaps the @sealed could have different values?

Benjamin Young: "@sealed": "@id"

Benjamin Young: "@sealed": "@context"

Jeff Mixter: maybe we can walk through the IIIF use case in DC next month

Dave Longley: I think we can safely add "@sealed": "`"` (in a backwards compatible way) if we find that `"@sealed": true` is insufficient for use cases

Rob Sanderson: My understanding is that if you seal a context (or a set of terms), you’re only sealing the terms it defines. You could have a term outside that context can do whatever it wants, including override terms that would have come from an inherited context.

Rob Sanderson: {"data2": {"@context": {"data": ... }}

Rob Sanderson: If “data2” is defined in a separate context, and within that you define “data”, that could conflict with a sealed “data” term.

Dave Longley: If you tried to use that I would expect that to be an error.

Pierre-Antoine Champin: I’m not a fan of sealing or unsealing individual terms, saying "@sealed": false would not be good.

Jeff Mixter: What if someone want’s to just point at a different context and seal it, but you want to also import additional contexts, wouldn’t that lead to different errors or collisions?

Pierre-Antoine Champin: -1 to sealing someone else’s context

Rob Sanderson: I don’t think you can seal someone else’s context.

Jeff Mixter: so sealing contexts is only within the context of the JSON-ld document?

Rob Sanderson: jeff_mixter: Yep.

Ivan Herman: Perhaps dlongley or someone else could come up with a strawman spec text that we can look at. We’re getting lost.

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/98#issuecomment-443182908 and the last example of https://github.com/w3c/json-ld-syntax/issues/98#issuecomment-443241467

Ivan Herman: These discussions in November we had (see #98/comment-443182908 and the last example of #98/comment-443241467 a table to talk about different ways to seal, and this seems to give a core spec; if it can be written down, we may have something.
… If it becomes spaghetti, we have a problem.
… We have the F2F in three weeks, so maybe we can have a goal to have a final resolution then.

Dave Longley: We’d also want test cases so we can experiment with test cases.
… We intend to implement one way or another.

Rob Sanderson: I’m happy to contribute examples.

Jeff Mixter: so this is not valid - { "@context": [{"@vocab": "http://schema.org/", "@sealed": true}]?

Ivan Herman: We can also use the wiki page.

Action #3: Rob Sanderson to document simple input and expected processing of them

Action #4: Dave Longley to review azaroth’s text and add further examples

Dave Longley: +1

Benjamin Young: +1

Dave Longley: jeff_mixter: I think as a first cut of this feature you’d have to seal all of the schema.org terms yourself (defining them yourself in your own @context)

Ivan Herman: That’s discussed in #108; there was a syntax that might allow for that.

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-447629312

Ivan Herman: I didn’t realize I was sealing it, but it could be done. I’m not sure we want to do that.

Dave Longley: thanks everyone for the discussion!

Rob Sanderson: It’s been a useful discussion.

Dave Longley: I can probably dial into the F2F.

5. Resolutions

6. Action Items