Is there a scope context mechanism for clearing context definitions?

[dlongley]

Is there a way to use the scoped context mechanism to "embed" information in a JSON-LD document such that all term definitions are cleared? So, for example, suppose we had this:

{
  "@context": {
    "@version": 1.1,
    "someTermToClear": "ex:someTermToClear",
    "record": {"@id": "ex:record", "@container": "@graph", "@context": null}
  },
  "someTermToClear": "should be defined here",
  "record": {
    "@context": {
      "someOtherStuff": "ex:someOtherStuff"
    },
    "@id": "ex:someId",
    "someOtherStuff": "this should be defined here",
    "someTermToClear": "this should NOT be defined here"
  }
}

The goal here is to avoid requiring the author of record value (or a user of it) to have to know to clear any terms in an "outer container". This may allow "safer" composition/embedding of JSON-LD documents.

[dlongley]

By the way, the exact example given above does not work in the playground, the term someTermToClear is still defined in the embedded record.

[ajs6f]

I'm probably missing the point, but can you not unset someTermToClear in the inner context? The author of the data there needn't know about that, just the context author...

[dlongley]

@ajs6f,

The @context author doesn't know anything about the "enveloping" structure. The point is to be able to reuse contexts when embedding data -- without breaking abstractions (having to rewrite/change those contexts such that JSON-LD processing becomes required).

[ajs6f]

@dlongley Ok, makes sense. How would this play with "sealed" contexts?

[dlongley]

@ajs6f,

Yes, this is related to "sealed" contexts. I think one of the properties of sealed contexts should be to enable term overrides using embedded contexts. It may be that an embedded @context can simply override sealed terms (because it's explicitly in the data) but it may be better if this is only permitted if the sealed context explicitly uses a scoped term that clears term definitions in order to enable it. Does that make sense?

[ajs6f]

The first part does, IIUC: contexts in the instance would override contexts from elsewhere, even if they don't "want" to be overridden, because the instance author is the ultimate authority.
I'm not quite sure I follow the second point. "a scoped term that clears term definitions"-- that means a new keyword that would drop the definitions? That keyword would appear in the (outer) sealed context?

[dlongley]

For "sealed" contexts, suppose a context array like this:

[<sealed context 1>, <sealed context 2>, <maybe sealed context 3>]

In this case, a JSON-LD processor should ignore any "overriding" term definitions provided in context 2 and 3, always keeping the definition from context 1. This much is clear. But what happens in the case of an embedded context?

{
  "@context": "[<sealed context 1>, <sealed context 2>, <maybe sealed context 3>]",
  "record": {
    "@context": {
      "i_am_embedded": "ex:foo"
    }
  }
}

Here, I would expect us to need additional/different behavior. And it may turn out that it would be nice to have this different behavior whether a context is sealed or not. Essentially, being able to say "treat this document as an embedded one that knows nothing about its parent information" is valuable. It may be, that for sealed contexts, we will need to "enable" this to happen ... or it could happen automatically, but that seems more dangerous.

[dlongley]

@ajs6f,

I can imagine core W3C data model specs defining some kind of JSON tree that looks like this:

{
  "@context": "some_sealed_context",
  "service": {
    "id": "ex:fooService",
    "endpoint": "https://example.com"
  }
}

Now, if an instance author does this:

{
  "@context": "some_sealed_context",
  "service": {
    "@context": {
      "endpoint": "ex:haha_tricked_you",
      "realEndpoint": "ex:endpoint"
    },
    "id": "ex:fooService",
    "endpoint": "https://junk.example.com",
    "realEndpoint": "https://example.com"
  }
}

All the software that performs JSON-LD processing will use a different endpoint from the software that does not. I don't think we can assume that an embedded context can always override terms. I think we may want to be able to say "here's where you can override terms/here's where terms must be overridden". It's a more clean way of calling out where extensions are expected to be or where "embedded documents" can more freely override (anything).

[dlongley]

@ajs6f,

I'm not quite sure I follow the second point. "a scoped term that clears term definitions"-- that means a new keyword that would drop the definitions? That keyword would appear in the (outer) sealed context?

Yes, it would look something like this:

{
  "@context": {
    "extensionsGoHere": {"@id": "ex:extension", "@context": null}
  }
  "extensionsGoHere": {
    "@context": "whatever"
  }
}

[ajs6f]

It seems like we might be talking about a few things here:

1. the relationship between sealed and unsealed contexts,
2. the relationship between retrieved and instance-embedded contexts,
3. and the relationship between inner and outer contexts, whatever their source.

So there's a lot of ways those things could interact (I kind of want to write down a combinatorial table here, but I'm not sure what I would be computing!)

I'd like to try and simplify the discussion (just for a bit). Perhaps we can leave aside sealing (I realize that we can only do that for a little while) and think about unsealed contexts only and the latter two relationships. In a world without sealed contexts (just for now! :) ) what would this feature look like? Would it enable instance contexts to easily blank out the computed context and "start afresh"? I'm just trying to get my head around a small piece of this before we reintroduce sealing, because sealing is also hypothetical for the moment and I'd like to minimize the hypotheticals in my brain. It's not much larger than Pooh's. 😵

[dlongley]

@ajs6f,

I agree that we're talking about a number of different things and how they interact. :)

Perhaps we can leave aside sealing (I realize that we can only do that for a little while) and think about unsealed contexts only and the latter two relationships. In a world without sealed contexts (just for now! :) ) what would this feature look like? Would it enable instance contexts to easily blank out the computed context and "start afresh"?

Yes, it would enable instance contexts to blank out the computed context and "start afresh". In particular, it would do so for certain terms (i.e. any objects under the term "x" would have a "fresh start"). The use case for this would be to ensure that nothing "leaks in" from the original instance context into whatever is embedded within a certain term, without undefining the term itself. It enables encapsulation and, because of that, I would expect it to often be used in conjunction with "@container": "@graph".

[gkellogg]

Setting aside the sealed/frozen nature, setting either @context or a given term to null clears it out. What should happen for frozen contexts or terms defined in a frozen context?

Arguably, setting @context to null should clear out any frozen contexts, as it's not modifying them and is a rather specific directive.

How to clear a sealed/frozen term definition? This needs discussion, if we want to allow it at all.

[dlongley]

@gkellogg,

setting either @context or a given term to null clears it out.

The example given in the OP does not clear out all the terms on the playground. Are you suggesting that it should and it's a problem with the playground (and that this is already spec'd)?

[gkellogg]

@ajs6f said:

I think one of the properties of sealed contexts should be to enable term overrides using embedded contexts.

Sounds like adding a fair bit of complication. Is this a real-world concern?

[gkellogg]

Step 3.1 of the Context Processing Algorithm indicates that null starts everything afresh:

If context is null, set result to a newly-initialized active context and continue with the next context.