Allow partial definition / redefinition of terms

[azaroth42]

From #20, there is the notion of partially defining or redefining terms in separate contexts.

For example, removing the sealing from the picture, ...

{
  "@context": [
    {"wild_west": {"@id": "eg:playground"}},
    {"wild_west": {"@context": "http://schema.org"}}
  ]
}

Should set the scoped context for wild_west to schema.org in the second context of the list, without resetting the predicate defined in the first.

[gkellogg]

That is completely different for how term definitions are handled now. The new "wild_west" completely replaces the old "wild_west", and unless there's a default vocabulary in range, would probably lead to an error.

But, it sounds like to make this work with @context: null in the sealed context, the new term definition would be special, in that it would update the previous term definition, and would be limited to setting @context. I don't see it working on anything other than a sealed term, unless we identify an important use case for it.

[iherman]

I find all this a bit confusing...

I wondered whether we should not use a kind of ternary logic for @sealed instead:

• "@sealed: "true" seals the full context and definition for that term
• "@sealed": "false" unseals a term in a sealed context, essentially making the effect of the upper level @sealed ineffective
• "@sealed": "partial" seals all definitions on the term that are explicitly present, but allows for expansions

(I guess, the third value is irrelevant for full contexts)

The role of "@context": null would mean to wipe out all inherited context term definitions. It would not affect any statements explicitly listed in the term definitions, but everything implicit.

---

{
  "@context": [
    {"wild_west": {"@id": "eg:playground"}},
    {"wild_west": {"@context": "http://schema.org"}}
  ]
}

Would fall back on the current interpretation, i.e., it is equivalent to JSON-LD 1.0. The second definition for "wild_west" wipes out the "@id" definition of the first.

---

{
  "@context": [
    {"wild_west": {"@id": "eg:playground", "@sealed" : "true"}},
    {"wild_west": {"@context": "http://schema.org"}}
  ]
}

would be an error, because "@sealed": "true" means that the first definition is cast in concrete and nobody can change anything.

---

{
  "@context": [
    {"wild_west": {"@id": "eg:playground", "@sealed" : "partial"}},
    {"wild_west": {"@context": "http://schema.org"}}
  ]
}

means the "@id": "eg:playground" would remain unchangeable, but expanding on the term definition by using schema.org is all right. If the creator of the first context decided to, e.g., specify the datatype of the value, this would also become sealed, too, etc.

---

{
  "@context": [{
        "data": {
            "@id": "eg:data",
            "@sealed" : "partial",
            "@context" : null
        }
    },{
        "data": {
            "@context" : { … }
        }
    }]
}

means (I think) the starting example of @dlongley: the second definition of "data" operates on a completely empty slate, ie, the content of "ex:data" can be anything the user wants except that the user cannot change the URL of the "data" term itself.

Does this make sense?

---

(I guess this is a bit related to #20 as well, adding a cross reference...)

[iherman]

This issue was discussed in a meeting.

• ACTION: Pierre-Antoine Champin to write spec text of his mental model

View the transcript

3. Sealed Context Issues
Benjamin Young: link: #116
Benjamin Young: Our first set of issues is the new ones that have been filed since we last spoke.
Benjamin Young: Rob, you filed if you want to summarize.
Rob Sanderson: Last week we discussed the notion of partially defining rather than redefining completely. If there were two contexts, one that defined that the @id was playground and another term just added a scoped @context and didn’t repeat @id — this came from the sealing discussion — then you’re only sealing the aspects that are defined by the original context rather than sealing all aspects.
Rob Sanderson: The issue provides an example where a scoped context is added without overriding the @id property.
Rob Sanderson: The question is would the sealing algorithm be able to duplicate all of the sealed term definition attributes and then add something else?
Gregg Kellogg: This just seems a completely different thing to sealed contexts to me, it’s term updating. Which I commented on — it’s fraught with all sorts of potential issues. You need enough knowledge about the original term definition to know that what you’re doing make sense … it would be much less ambiguous to just update the term definition. I don’t see enough of a positive (or really any) to make a change like that.
Gregg Kellogg: I would vote against such a feature.
Benjamin Young: I too have big concerns about changing how these term definitions interact from an overwrite to a merge … where this plays into sealing has to do with sealing a term but not its contents.
Benjamin Young: There were proposals that were very similar to ivan’s comment on this issue last week that had things like sealed term / etc. and there’s interplay with sealing specifically.
Benjamin Young: But as Gregg noted this would be a massive change and complicated to reason about.
Benjamin Young: The case in practice might be more complicated than our examples.
Benjamin Young: Have to be ready to deal with pain.
Ivan Herman: If we keep to the current version, which I’m not against, just exploring. It seems that many of the things we’ve discussed with sealing become irrelevant because they are impossible.
Rob Sanderson: +1 to Ivan
Ivan Herman: In a way — sealing becomes maybe pretty simple in a sense that if I put a seal on a given term in a context then nobody can ever do anything with that term in another context. If there’s something that could be done that would wipe out a definition, it can’t be done.
Ivan Herman: My mind has began to have problems with various combinations — it’s fine with me, the question is are we ok with that?
Dave Longley: I’m mostly in agreement with gkellogg here
… I don’t think we want to enable partial redefinitions
… except for explaining how sealed contexts work
… I’m in agreement that we should not start specifying partial updates to terms definitions
… but we should think in the context of sealing
… so things behave as developers expect
Gregg Kellogg: As Dave was saying, I think this has to do with where sealing applies. You could potentially use a term/redefine it under a property which was not sealed. The ability to do that might make a lot of the worries about the ability to get into sealed contexts be not as important.
Ivan Herman: Can you explain that?
Gregg Kellogg: The concept is that once you’re inside of a scope you’re outside of the domain of sealing.
Rob Sanderson: What parts of a term definition are sealed?
Gregg Kellogg: The entire definition is sealed. When you are going to create a term definition, there’s currently a step to handle this.
Rob Sanderson: So #20 (comment) /is/ an error?
Gregg Kellogg: Currently a new term definition will remove an old one — and that’s just blocked by sealing.
Gregg Kellogg: There is no mechanism and there never has been one to reach into a term definition and replace it.
Rob Sanderson: So then, if you have a scoped context that tries to redefine a sealed term…
Gregg Kellogg: I commented on that on a comment earlier this morning, my understanding from last week, it would be ignored — an attempt to change it would be ignored. Scoped contexts aren’t magic, they are just specified as part of a term and introduced in the expansion phase as if they are inline.
Benjamin Young: That last little bit was clearer, thanks.
… I’m thinking that to even explain this to an informed JSON-LD developer is going to take use cases an flow charts of some kind.
… To say this is how it works and once you add sealed this is how it changes, etc.
Benjamin Young: Any time someone feels like they are reaching an understanding for how this may work and has paper, etc. that would help.
Dave Longley: #20 (comment)
Dave Longley: now seems like a good enough time to bring up issue 20
… this is an attempt to explain how this is meant to work
… the focus is specifications which have JSON in them
… which have fixed semantics for fixed terms
… but that also have extension points
… folks who write JSON specs express these things in relation to the tree
… but there’s no consistent way to enforce these things
… and that’s where bringing in a JSON-LD processor could help
… the first example I give is a spec which has different semantics based on the nesting within the tree
… where the meaning of the term changes based on where it appears
… so, creating a term definition for that would be creating a sealed term with its own context
… the other example is about explaining where extensions go
… this term has this id/definition, but within that term you can put whatever you want in there
… the other pattern is, here are all our terms, they’re all sealed, but anything inside those terms can be whatever you want them to be
… we need to think about how this applies to type scoping as well
… I think we can handle all of these
… but I do think it would help to think about these features in terms of how people write JSON
… and how they want to extend JSON-based documents
… and how we can best express those extension points and semantics
Ivan Herman: Actually, two things, because one just came up what Dave was saying. Before that, forget about sealing for a moment. Let’s go back to the fundamental issue that Gregg raised about partial definitions. Let’s suppose that I have one context which defines something for a term.
… I have another one coming after that, for the same term, the only thing I do is add the scoped context. Based on what Gregg said, the second appearance in the second context would completely wipe out what was in the first one.
Gregg Kellogg: That’s the behavior today.
Ivan Herman: I have to figure out how that works with sealed, that bothers me.
… I wonder if we would be better off with trying to concentrate on that we need these extensions points and define them explicitly and have a way to say — in this term it’s a clean slate — instead of going to sealed with its semantics raises other issues.
Rob Sanderson: +1 to Ivan - that seems like the comprehensible compromise.
Ivan Herman: It came by when you were talking that we can simplify on some of the use cases and we seem to be down the road in generalizing that and it may be one of the problems we may have.
Pierre-Antoine Champin: One thing I wanted to mention because Dave mentioned it as well. For the moment I have a hard time wrapping around how typed-scoping interacts with sealed contexts. Apart from that I think I have a clear view of what Dave is trying to achieve with that.
… So I will try to help and share with my intuitions. Couldn’t we talk about the scope of the sealing — my idea is that whenever a sealed context becomes active, simple case is at the root of the JSON object, we will honor this seal by preventing redefinitions of the sealed terms whenever we traverse them.
… Whenever we traverse a term that isn’t part of the sealed then we do not honor any more.
Dave Longley: +1 that sounds pretty good so far (have to think about it more)
Gregg Kellogg: +1 that is what I was trying to describe
Pierre-Antoine Champin: The idea here would be that be that sealed contexts work like regular JSON and once you traverse terms that are “extensions” then fall into regular (old style/non-sealed) JSON-LD processing.
Gregg Kellogg: That’s basically what I was trying to relay. Sealing only applies for immediate values of the terms that are sealed. So if you have “sealed1” and its value is “object” then “sealed1” and all other sealed terms remain sealed and I would think that’s the case with a sealed type as well.
… If you introduce a new term that is not sealed and that represents an extension point and sealing does not apply. I think where Dave and I might have different understanding there…
… When you say that the scoped context is null you have to establish whatever context you want from that point. The other is that the context and all the terms remain in scope, they just are no longer sealed at that point.
… People tend to put all of their stuff at the top to use scoping and it helps with framing, etc.
Gregg Kellogg: I think that this will be closer to existing behavior.
Dave Longley: azaroth talks about an example I can’t scribe :)
Rob Sanderson: I also like pchampin’s suggestion
… I think type-based sealed contexts will run into issues regardless
… if you have in the first context agent as foaf:agent
… and in a second you have schema:producer which is not sealed
… but within schema:producer the agent term would no longer be sealed, correct?
… so it seems like type-based mechanisms, the sealing is irrelevant
Gregg Kellogg: well. I think it’s the same
… if you have an object for an unsealed property
… but that type is sealed
… then that type introduces sealing
… whether its a property or a scope, the behavior is whether it happens inline
… nonetheless after that point you would be in the scope of something being sealed
Ivan Herman: I think that this really needs a f2f meeting
Gregg Kellogg: this seems like an important feature, but it does come with complication…which will decrease adoption
David Newbury: I think I’m agreeing with the complication thing
Dave Longley: priority of constituencies applies here, IMO
David Newbury: and wondering if there are ways of reducing the comprehensiveness of this feature
… can we scope this to say that it does not apply in scoped contexts etc?
… just at the top as a master-list?
… does that meet our use cases?
… are there ways to meet the use cases around this, but by reducing the various ways we use contexts?
Dave Longley: a couple points to make. first, pchampin’s point is really important
… I think it would help both explain it and how we implement it
… processors will start at the top of the document and work their way down
… if it’s something they don’t understand, they’ll be ignored
… anytime there’s a new thing defined, you’re introducing a new processing model
… the point of the feature is to lock in the terms that were originally meant to be sealed
… if you get outside of that space, then you could go back to the old processing model
… the other point I wanted to make is a priority of constituents that we need to take into account
… this is an extremely important feature for JSON developers
… as it improves the ergonomics for end users
… my last point was that there seems to be a lot of miscommunication that we seem to have resolved on this call
… I’m more in agreement with gkellogg than we probably first thought
… working them out on github seems better than talking them out at this point
Pierre-Antoine Champin: with the goal of keeping things simple
… my mental model works well in two scenarios
… I’m concerned about sealed contexts containing terms which are not sealed
… and I think only one context should be sealed at any point in the tree
… and that introduces a lot of complexity
… and the corner cases don’t seem like driving reasons to support that
… last point, under those conditions, the typed scoping behaves quite well
Ivan Herman: we should write all this down in spec text
Pierre-Antoine Champin: that’s my plan
Dave Longley: i think we’re actually making good progress, despite how it may appear :)
Rob Sanderson: I agree we’re making progress. It’s complicated :)
Ivan Herman: test cases are good, but some explanation would also be helpful
Pierre-Antoine Champin: please put the action for me to do that
Rob Sanderson: we’re at the top of the hour, but I do think we’ve made great progress
Action #2: Pierre-Antoine Champin to write spec text of his mental model
Rob Sanderson: and I do think we’ll be helped by having a whiteboard
… we’ll talk again next week!

[iherman]

Thinking about this further, I am afraid that this would open a can of worm. Whether we like it or not, JSON-LD 1.0 made a clear choice with any re-definition of a term completely wiping out the old one. We should skip to this and not introduce some sort of a spaghetti spec to circumvent this...

[pchampin]

I agree with Ivan, and it seems to me that we can do without this "partial redefinition" feature. Let me develop.
Consider a seald context http://example.org/context_a.jsonld defined as below:

{
  "@context": {
    "@version": 1.1,
    "@sealed": true,
    "foo": "http://example.org/foo",
    "ext": {
      "@id": "http://example.org/ext",
      "@context": null
  }
}

ext is an "extension" property, reseting the context to allow possible redefinition of previously sealed terms.
Say I want to use another context http://example.org/context_b.jsonld under property ext.

The "partial redefinition" feature is meant to address this use case. I would use it that way:

{
  "@context": [
    "http://example.org/context_a.jsonld",
    { "ext": { "@context": "http://example.org/context_b.jsonld" } }
  ],
  "foo": "this is property foo as defined by context_a",
  "ext": {
    "foo": "this is property foo as defined by context_b"
  }
}

But I would argue that the following, which does not require the "partial redefinition" feature, is better:

{
  "@context": "http://example.org/context_a.jsonld",
  "foo": "this is property foo as defined by context_a",
  "ext": {
    "@context": "http://example.org/context_b.jsonld",
    "foo": "this is property foo as defined by context_b"
  }
}

It is better IMO, because it makes it understandable for a non-JSON-LD processor, that the subtree under ext complies with the format identified by http://example.org/context_b.jsonld. See for example how Web Annotation manages extensions.

[dlongley]

@pchampin,

But I would argue that the following, which does not require the "partial redefinition" feature, is better:

{
  "@context": "http://example.org/context_a.jsonld",
   "foo": "this is property foo as defined by context_a",
   "ext": {
     "@context": "http://example.org/context_b.jsonld",
     "foo": "this is property foo as defined by context_b"
   }
}

I certainly think this should be one of the options -- and it solves an important use case. So +1 to this approach.

However, I don't think it's enough on its own. For example, it does not handle the JSON-LD patch use case. The case above that achieves the same through a scoped context does handle that use case:

{
  "@context": {
    "recordPatch": {"@id": "ex:recordPatch", "@graph": "@container"}
  },
  "recordPatch": {
    "@context": [
      "https://w3id.org/json-ld-patch/v1",
      {
        "value": {
          // this *MUST NOT* be embedded below
          "@context": [
            "https://w3id.org/did/v0.11",
            "https://w3id.org/veres-one/v1"
          ]
        }
      }
    ],
    "target": "did:v1:test:nym:z279yin3yjTDWAVJquwiB8jC7eMmJ7a5xwwekukh4nxGiWPF",
    "sequence": 0,
    "patch": [
      {
        "op": "add",
        "path": "/service",
        "value": [
          {
            "id": "urn:foo",
            "serviceEndpoint": "https://agent.example.com/",
            "type": "AgentService"
          }
        ]
      }
    ]
  }
}

In the above case, the terms nested inside value need to be defined, however, a @context must not be present or the patch will produce an incorrect result when applied. Here, being able to add a scoped context is the only way to achieve the desired outcome if value is sealed.

Ideally, the ID of value would be sealed ... so only a scoped context could be added to it to apply definitions to what is nested underneath it. It is possible to require users of JSON-LD patch to define value entirely (and always make sure they use the proper definition), but this is more brittle.

[gkellogg]

This approach should work with the update I made to the API PR, as processing a scoped context for a property acts as if the property term is not sealed.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Adopt the following rules for sealing - 1: If @sealed:true is encountered on a term definition in the active context, then attempts to redefine the term will fail and result in a warning. 2 - If @sealed:true is encountered on a context, then all terms defined within the context should be treated as having @sealed:true in their definition. 3- If @sealed:false is encountered on a term definition in the active context, where the context has been sealed with @sealed:true, then the sealing for that term is removed. {: #resolution1 .resolution}
• RESOLVED: Close #87, as unnecessary given above rules. {: #resolution2 .resolution}
• RESOLVED: Close #98, as @context: null clears context definitions {: #resolution3 .resolution}
• RESOLVED: Close #98, as @context: null clears context definitions {: #resolution4 .resolution}
• RESOLVED: if @id is not present in a term definition, and there is no default vocabulary, but has an expansion to an absolute IRI in the active context, then the @id of the new definition is taken from the active context (otherwise this is still an error) {: #resolution5 .resolution}
• RESOLVED: Once previous is done, we can close #116 {: #resolution6 .resolution}
• RESOLVED: We agree with the processing order per #61: scoped definition from property, then from type, then embedded. PR to update docs to come. {: #resolution7 .resolution}

View the transcript

Sealed contexts
Ivan Herman: If we can’t get to a clear model and agreement on sealing today, I propose we defer it.
Adam Soroka: If we happen to do that, what do we say to verifiable claims, etc?
Rob Sanderson: (reads guiding principles)
Rob Sanderson: https://www.w3.org/2018/json-ld-wg/WorkMode/guiding_principles
Rob Sanderson: sealed contexts - goal is to solve by end of day
Ivan Herman: one thing from last week’s discussions - sealing seems to be a very dangerous thing to do…
… if Google decides to put a seal on schema.org, community will be unhappy …
Gregg Kellogg: we need to understand who we’re serving. Not there for schema.org, rather verifiable claims
… specs as verifiable claims have a shared vocabulary, with some domains wide open, but people can’t change semantics
… in spec, intentionally or otherwise
Benjamin Young: chief aim of proposal is that json and json-ld world co-exist. Term sealing is to guarantee that …
… json and json-ld authors work on exact same shape
… maybe take a step back from sealing and see what other options there may be
… notion of foundational shape surviving framing
Ivan Herman: what I understand from ver. claim. is that they have a wrapper w/ properties whose value is an object…
… want to give total freedom for another vocabulary to leave locally. How about a syntax that says this is an extension point…
… @context null + specific situation that is sealing + @context null
… concentrate on this use case and try not to generalize
Rob Sanderson: sealing doesn’t solve actual shapes - just relationship between key and class. Not producing necessary structure
… it is intersection of RDF semantic layer and JSON keys. Not shape thing as an API. Mapping not API
Pierre-Antoine Champin: goal of sealing is not to guarantee LD has same shape as plain JSON, but JSON LD that has the same shape…
… has the same semantics.
… agree with ivan – sealed is sealed from point to rest of subtree and not try to address unsealed point.
David Newbury: Use case for unsealing is to insert user specified documents into structure. Unstructured JSON into LD…
Ivan Herman: may try to pick up json literal again
Ivan Herman: some examples don’t want literal, but piece of RDF graph but based on another vocabulary on its own
David Newbury: do we need ability to interpret unsealed part in context of whole document?
Gregg Kellogg: yes
David Newbury: do we have use cases where sealed and unsealed need to be interpreted?
Rob Sanderson: I think so
Rob Sanderson: Note - if we can’t solve by the end of the day, revisit the fallback position of JSON literals
Gregg Kellogg: We’re making this too hard. A sealed context is a collection of sealed terms – maintains original interpretation
… an extension point is where you use a term that is not sealed…
… say there is a named term in VC that has a given meaning, but want to be able to add other properties that aren’t sealed…
… also need a “this is a place for you to put stuff” – creating a scoped context where properties can be re-interpreted.
… sealed terms have fixed meaning when you use them.
Pierre-Antoine Champin: a term may be sealed (i.e. its meaning, esp. its IRI, can not be overridden) and an extension point (allow sealed terms to be overridden in its subtree)
David I. Lehn: common use will be use an example, preserving semantics and adding on…
Adam Soroka: we have ways to control shapes of json and RDF, but now we’re talking about a third way… controlling semantics
Pierre-Antoine Champin: gregg says extension points are properties that aren’t sealed — sealed means one cannot override
Gregg Kellogg: one approach is sealed context that allows context underneath to be unsealed…
Pierre-Antoine Champin: thanks @gkellogg, that’s clearer :)
Ivan Herman: i would like to hear a description of the exact sealing proposal
Gregg Kellogg: that would be pchampin’s PR
Ivan Herman: if we cannot explain where we are, we have a problem
Pierre-Antoine Champin: I agree with first 2 parts of the PR, the 3rd one is related to extension points
… we don’t have the same model for unsealing
… especially when it happens automatically
… I think the sealed definitions in a context cannot be overwritten by anything in that context
Ivan Herman: if you seal a context, then the only way the terms can be overridden is in a scoped context within the sealed context?
Pierre-Antoine Champin: I think so
Gregg Kellogg: explicates example on whiteboard Test so03
David I. Lehn: there are problems with this example because the inner context has no effect
Ivan Herman: we often use such examples, which I find a little unnatural
Harold Solbrig: That confuses me
Ivan Herman: [discusses example]
Gregg Kellogg, Ivan Herman, Rob Sanderson: [edit and discuss example]
Ivan Herman: sealing seems to mean that the terms are cast in concrete
Ivan Herman: it is very difficult to explain exception
David I. Lehn: Not sure why it’s unnatural?
Ivan Herman: if the context says “Sealed” that would seem to me to mean that everything is cast in concrete
… but that doesn’t seem to be the case
… we can change things with scoped contexts etc
Gregg Kellogg: this comes out of discussion of multiple sealed contexts
Harold Solbrig: by changing this one term to add a typo, I can open up everything I thought I was sealing
David Newbury: I would have assumed that by sealing a term, it would remain sealed
Gregg Kellogg: so once sealed, always sealed
Gregg Kellogg: that didn’t work for Verifiable Claims because they don’t want to intro a constraint on the JSON-LD within the wrapper
jeff mixer: can I constrain the type of value used with a term this way?
all: no, JSON-LD has no way to constrain the types of values
Adam Soroka: Agree completely. The wrapper compresses the protocol into the document
… It pulls us toward sealing other things beyond just the mapping, but into complex chains
Harold Solbrig: preventing people from accidentally overwriting contexts seems within our scope, but not all the further ramifications
Pierre-Antoine Champin: re: when terms become unsealed
… it is genuinely hard to explain
… I would say that a sealed term is sealed anywhere, except when the sealed context opens it
… there are two situations in which one can redefine a sealed term
… plain JSON users don’t expect the semantics to be sealed any more
… we should leave the decision of when to unseal terms to the authors of the sealed context
Ivan Herman: an extension point means a combination of “context now” and “I cannot touch what is on the upper level”
Gregg Kellogg: {discusses Ivan’s example]
Ivan Herman: how about a keyword “extension” that means you cannot redefine anything you inherit?
Gregg Kellogg: not quite @context: null.
David Newbury: if we have a context that defines ‘name’ within a sealed context, [points to examples]
Gregg Kellogg: [discusses examples]
… it may be simpler in the end to say that sealed terms are always sealed except for @context:null
… but subtleties arise when two sealed contexts interact
Rob Sanderson: can we do that example?
Ivan Herman: the only place where @context:null would have a nuclear option would be in the context that is sealed
Adam Soroka: [discussion of various examples]
Gregg Kellogg: [refers to examples]
David Newbury: ditto
Pierre-Antoine Champin: [example of two contexts conflicting]
David Newbury: the confusion caused by accounting for the complex interactions outweighs the utility
Harold Solbrig: what if we turned the pattern inside out and let contexts signify that they don’t intend to override?
… if you want to enforce that, you do it on a vocabulary-specific basis
… with rules for that particular context
Gregg Kellogg: so if a context lacked that flag, it would be harder to reuse it
Harold Solbrig: depends on how much you care about this relationship between the contexts
Adam Soroka: [discussion of what is or is not in scope for the use case and interoperability concern]
Gregg Kellogg: not clear how to specify that
Ivan Herman: going back to David’s example
Ivan Herman: [discusses example]
Rob Sanderson: [discusses example]
Gregg Kellogg: @context: null has a specific meaning and we are altering it
Ivan Herman: if we go down the road of “sealing”, then @context:null is going to conflict in some way and we will have to resolve it
Harold Solbrig: that’s why I went for an extension-based approach
Gregg Kellogg: we have until noon!
Harold Solbrig: can we get the use case in a more concrete form?
David Newbury: I’m increasingly fond of Harold’s idea to put in an “extension” property that errors if something with it overrides a term
… this allows me to write extensions that will work, but it may not be what VC need
Pierre-Antoine Champin: I have to think about that idea (Harold’s idea). gkellogg convinced me to try to explain again how a context becomes ineffective.
… I’m in favor of saying that whenever I traverse a term that is not part of a sealed context, it’s not sealed anymore
… after which a term could have been redefined: no guarantees about the semantics!
… as for @context:null– maybe the “extension” idea is a better way to make extension points; it makes the unsealing specific
… to make @context:null work one goes through both extension properties
Gregg Kellogg: let’s for the moment let’s put off the table any terms from a non-sealed context
… the behavior I heard dlongley describe
… is that history is wiped out and we start from scratch
Ivan Herman: I’m good so far
Gregg Kellogg: but if you do want to allow a mixture of sealed and unsealed terms, we get into the case that pchampin discussed
… two ways to have an extension point: 1) an unsealed term, under which anything goes, 2) a sealed term that is defined as an extension point
… and 2) doesn’t satisfy the use case
Ivan Herman: let’s say I have a claim, and I put into the context a @context:null to make an extension point.
… the danger is that I will redefine a term from VC, accidentally or maliciously
… IIUC VC, it’s a bit like Annotation
… outsiders are expected to use their own vocabularies with these guys, without having to understand VC or Annotation
Gregg Kellogg: one case is that everything is wiped out, but the other is that you intermingle the use of properties
Ivan Herman: so I can add my own context
Gregg Kellogg: but not redefine terms
… we would end up with semantics that differ between JSON and JSON-LD
David I. Lehn: the way that Activity Streams does this is to say “You must not override or change contexts” as a normative piece (see https://www.w3.org/TR/activitystreams-core/#jsonld)
Rob Sanderson: people do this now by ordering the contexts
Rob Sanderson: [returns to examples]
Rob Sanderson: you can say that a sealed context can have an extension
… having sealed on the context is confusing and makes more sense at the term level
Ivan Herman: what is the difference between sealed and extension
… if extension was not true then there would be a warning
Ivan Herman: why not just say extension:true – it’s not setting a context?
Rob Sanderson: to distinguish from the case of this term being an extension
Gregg Kellogg: two different keywords that act on the context are unclear
Rob Sanderson: the change is that the default condition is “sealed”
Dave Longley: i’m on another call and can’t join, so i apologize… but was reading what’s here and thought i’d throw this in here… if there is a fear that schema.org (or contexts like it) might get sealed … we could allow {"@context": [{"@contextref": "http://schema.org", "@Sealed": false}, ...]} and the reason that would be ok for the sealed case we care about in VC community and so on, is because JSON processors would reject that … the context MUST be specified as a simple string, that’s what JSON-only processors would be looking for: {"@context": ["https://w3id.org/credentials/v1", ...]}
David Newbury: I thought we were talking about three use cases, one of which is ability to delete context, which is @context:null
… are we trying to prevent people from overriding accidentally or maliciously?
Gregg Kellogg: we can’t prevent malice
Ivan Herman: it’s a clean slate… but not
Harold Solbrig: @context:null is often too much
Adam Soroka: gkellogg and ivan: [thrash more examples]
Rob Sanderson: we fundamentally don’t want the semantics to slip between JSON and JSON-lD
Rob Sanderson: [more examples]
Rob Sanderson: gkellogg: “extension” unseals everything, which is not @context:null
Adam Soroka: [discusion of @context:null and whether it is a problem for the original use case]
Gregg Kellogg: if there’s another context with sealed terms and extension points
Rob Sanderson: regardless of which context has the sealing, extension overrides it.
Gregg Kellogg: that’s the simplest way
Benjamin Young: #20 (comment)
Benjamin Young: dlongley and I discuss term ordering and inheritance
… there is a problematic example there
… [discusses vocabulary]
Benjamin Young: #20 (comment)
Benjamin Young: this example shows how to avoid that by being verbose
… [discusses problems that concern @type usage and inheritance]
David Newbury: if I have two sealed contexts that define the same term, who wins?
Gregg Kellogg: last one in
Rob Sanderson: Reviewing the rules that we think we’re talking about.
Adam Soroka: the use case is to avoid semantic slippage around terms when interpreted as JSON.
Rob Sanderson: If @extension:true is encountered in scoped context definition, then attempts to redefine terms from the active context will succeed.
Ivan Herman: If this is the rule, in the embedded context, I can also change the ID of that term?
Rob Sanderson: yes. You can redefine anything.
Ivan Herman: so if I have @extension : {}, the extension of the original key remains.
Gregg Kellogg: the effect of extensions: true is to update the active context and remove the sealed status of all terms within that context
… allowing those terms to be renamed within the value of the extension property
Ivan Herman: so inside, something may be different than outside?
Gregg Kellogg: yes. It only makes sense within a scoped context, and only makes sense on a sealed term.
… if you extend an unsealed property…
Gregg Kellogg: within an extension property, we can only define additional properties within that context.
Rob Sanderson: this is an error: [{"extension": { @id: extension_property, @Sealed:true, @context: {@extension:true}}}}, { "extension":{@id: extension_propery}]
Rob Sanderson: extending unsealed terms is dumb, but not an error.
Pierre-Antoine Champin: I’m fine with this…in practice, this would mean that the plain JSON interpretation can only trust terms from the sealed context in the subtrees I defined.
… because when there is a term from another context, theydon’t know anything about that term.
… if we’re happy with this, we’re happy, but it seems like a lot of work to get to the same point.
Gregg Kellogg: I don’t think we’re at the same point.
… it’s only when we transition to a property when it’s extension: true that we transition
Pierre-Antoine Champin: the assumption that JSON-only is the same–it’s only trustworthy when looking at sealed terms.
Gregg Kellogg: that’s consistent with the spec.
Pierre-Antoine Champin: right. that’s why I’m OK with this.
Rob Sanderson: the thing we’re not able to deal with is nulling out terms and then redetermining them. So it works.
… so for VC, the context for the claim can start with null, which wipes out their context.
… so I don’t think that VC will use extension: true.
Gregg Kellogg: do we have a use case for this?
Ivan Herman: I thought that they want to avoid that anyone includes in the claim things that redefine things within verifiable claims
Gregg Kellogg: I think that applies to the envelope
… within the envelope, naive applications may not need to understand them.
… for example, annotation properties
… they come from another context
… so if you introduce another term in the envelope, those envelope extensions won’t override the VC
Rob Sanderson: don’t mess with our stuff
… vs:issuer should not be overridden, but if an extension defines ex:date, that’s fine. but the extension should not be able to override vs:issuer.
Gregg Kellogg: …explaining his example…
… since we have both a sealed context and schema, name remains it’s context. within the extension, something could set the scoped context to null.
… it could add a new context, and it could be anything.
… thus, VC does not need extension
Ivan Herman: why are we doing this?
… if this can be met with sealed and nullification, what is the use case for extension?
… this is the simplest thing that can work. That’s what we should do.
… do we need extension at any point?
Gregg Kellogg: I agree.
Adam Soroka: so there’s no need for nullification
… (i mean extension)
Gregg Kellogg: what we determined is that we’re not going to restrict @context: null. In that case, we don’t need the exceptions.
… you can always do @context: null
… thus, you can do it in a scoped context
… meeting VC’s use case
Benjamin Young: this VC is something that we haven’t discussed
… We don’t have anything that addresses it .
… since it’s type term usage, not property-term usage
… can we describe it as a use-case?
… term inheritance works…they don’t need sealing…
… but the scoped context around @type breaks things
… see the comment further down about getting around this by being verbose, but…this is how those things are extended.
… using a base type, and adding additional types…so type ordering matters.
… endorsed by handwaving, but would like a better mechanism
… but this is where things are breaking
Benjamin Young: example description is here #20 (comment)
Benjamin Young: verbosity “solution” is here #20 (comment)
Gregg Kellogg: this example: we would process the scoped context for specificCredential…issue is defined in an example.
… this is dlongley’s example, not mine
… he was saying that the context ordering gets nullified by scope contexts and type…core vocabulary at the end doesn’t work, since types can override that.
Gregg Kellogg: scoped context would not override this if issuer is a sealed term
Benjamin Young: we have two inheritance orders: CSS and FIFO
… so we would flip them, so if sealing isn’t done properly, then we have problems
… don’t know if there’s a solution here…other than a core vocabulary that comes first
Rob Sanderson: this seems to me to be application-logic-layer
… so VC would have a sealed context…
Benjamin Young: {"@context": {"@Sealed": "http://vc-data.example/", "@extensions": ["http://extension-1.exampe/", "http://other.example/extension"]}}
Rob Sanderson: …typing on the whiteboard…
Gregg Kellogg: so there’s a new extension keyword that imports without redefining?
Benjamin Young: this is something totally different
Rob Sanderson: this just inverts where the properties live
Benjamin Young: this means that the core is at the top, and the extensions below
Rob Sanderson: with would work with term definitions
Benjamin Young: currently, you put the core last.
… now you need to move it to the top, or potentially to both places
Gregg Kellogg: this means that the thing at the front and seal it, then it can’t be changed
Rob Sanderson: to me, sealing is the inversion of the property rules.
Benjamin Young: this means that the scope documents now need to be explicitly 1.1
Rob Sanderson: if you’re using 1.1, but interpreting as 1.0, it will be strange.
Gregg Kellogg: I think we can only talk about what 1.1 will do
… the reason that 1.1 is needed, so that if a 1.0 processor sees it, it will die
Benjamin Young: so in 1.1 we’re inverting the order?
Gregg Kellogg: I don’t see it as inverting, I see it as a new effect.
Benjamin Young: this sounds like !important in CSS
Gregg Kellogg: it continues to work
Benjamin Young: even if someone else seals it first?
Gregg Kellogg: I think we need to table multiple contexts that seal
… I don’t think it’s what we’re promoting
… as a best practice, there should be only one
… as a corner case, we should…
Ivan Herman: the usage of sealed in the grand scale of things will be minimal
… if it’s awkward, then that’s OK, because this is rarely used.
Adam Soroka: we don’t know this will be rare
Ivan Herman: our schema discussion showed us that we should not use sealed regularly.
… common, vague vocabularies should not used sealed.
… there are good use cases, but let’s be careful.
Gregg Kellogg: IMO, sealed should only be used by contexts defined in specifications where there is a dual JSON/JSON-LD processing mode, and then only rairly
Rob Sanderson: the other thing that’s important to put down is sealed is not a guarantee that it can’t be changed, but to prevent unintentional.
… you can always put in a version 1.0…
Gregg Kellogg: you can’t go back
Ivan Herman: the @context:null option is there, so we can not defend against all malicious use
Rob Sanderson: so we don’t need extension: true, because there’s no use case and we can cover it by nulling and re-i porting?
… so are we back to the simple rule?
… If @Sealed: true is encountered on a term definition, then attempts to redefine the term will fail and result in a warning.
Gregg Kellogg: with a note about using context:null
Adam Soroka: so there’s no way that a term picks up an unintentional meaning
Harold Solbrig: can I put a @Sealed on the external context?
Gregg Kellogg: you can’t do that
Ivan Herman: you can’t seal someone else’s context
Harold Solbrig: I would still like to be able to make sure that I don’t unintentionally reuse terms
Gregg Kellogg: can this be solved with SHEX?
Harold Solbrig: maybe…
Pierre-Antoine Champin: what happened to redefining a term within a sealed context?
Gregg Kellogg: we said that’s not possible.
… the only way to do this is to null the context
Pierre-Antoine Champin: so context:null could happen anywhere?
Rob Sanderson: correct
Pierre-Antoine Champin: so sealing prevents explicit redefining the sealed terms, but not guaranteeing their stability.
Gregg Kellogg: correct
Rob Sanderson: context: null is the way out of things, and you’d only do that in the VC case if you were trying to be malicious, and we’ve decided we can’t guard against that.
… the intent is to avoid unintentional redefining.
… to fix that, you need a preprocessor.
Adam Soroka: is sealing now to strong a name?
Gregg Kellogg: it is sealed in the active context.
Pierre-Antoine Champin: I disagree; freezing (and sealing, for that matter) in JS is a quite different thing
Ivan Herman: let’s make a resolution, and go to lunch
Proposed resolution: Adopt the following rules for sealing - 1: If @Sealed:true is encountered on a term definition in the active context, then attempts to redefine the term will fail and result in a warning. 2 - If @Sealed:true is encountered on a context, then all terms defined within the context should be treated as having @Sealed:true in their definition. 3- If @Sealed:false is encountered on a term definition in the active context, where the context has been sealed with @Sealed:true, then the sealing for that term is removed. (Rob Sanderson)
Harold Solbrig: if there’s a sealed: false for an unsealed term, what happens?
Rob Sanderson: +1
Ivan Herman: +1
Gregg Kellogg: nothing–that doesn’t mean anything
Adam Soroka: should we warn?
Gregg Kellogg: +1
Jeff Mixter: +1
David Newbury: +1
Simon Steyskal: +1
Harold Solbrig: +1
Pierre-Antoine Champin: +0.5
Gregg Kellogg: we SHOULD
Adam Soroka: +1
Benjamin Young: +0 (would like to see use case mappings for all these things)
David I. Lehn: +1
Resolution #1: Adopt the following rules for sealing - 1: If @Sealed:true is encountered on a term definition in the active context, then attempts to redefine the term will fail and result in a warning. 2 - If @Sealed:true is encountered on a context, then all terms defined within the context should be treated as having @Sealed:true in their definition. 3- If @Sealed:false is encountered on a term definition in the active context, where the context has been sealed with @Sealed:true, then the sealing for that term is removed. {: #resolution1 .resolution}
Dave Longley: “If @Sealed:false is encountered on a term definition in the active context, where the context has been sealed with @Sealed:true, then the sealing for that term is removed.” <– this sounds like a big problem as written …
Dave Longley: is this saying that with {"@context": [1, 2]} that 2 can unseal anything it wants?
Dave Longley: if so, that defeats the purpose of sealing … so i can only imagine that something else was meant by that text.
Dave Longley: it sounds like an attacker that defines 2 can get a VC to be successfully processed by a JSON-only processor in a different way from a JSON-LD processor under that condition
Dave Longley: i’ll check back here later to see if there’s a clarification
Dave Longley: if the ability to unseal a sealed context is a requirement (as opposed to just extending in an acceptable way) … it seems like we could do it without messing up JSON-only processors by using some other syntax that they would otherwise reject.
Dave Longley: JSON-only processors will be looking for {"@context": [, , ...ignored]}
Dave Longley: or could perhaps be further limited to: {"@context": [, , ...]}
Dave Longley: in other words, any deviation from some very rigid rules would cause a JSON-only processor to reject the input … which could be potentially used to our advantage if we need to cover other use cases where we are fearful of people sealing things that JSON-LD aware entities would like to unseal in a way that would not impact JSON-only processors.
Dave Longley: but what is key is that that any mechanism that is used to unseal would not impact JSON-only processors.
Dave Longley: if we can abide by that rule, i don’t see why i wouldn’t be supportive.
Rob Sanderson: dlongley: The @Sealed:false would only work for the original definition, no subsequent attempt to redefine it
Rob Sanderson: It overrides the @Sealed:true on the context
Rob Sanderson: But not @Sealed:true on a term
Dave Longley: azaroth: ok, if I understand you I think that’s fine
Adam Soroka: #87
2.1. closing related issues
Proposed resolution: Close #87, as unnecessary given above rules. (Rob Sanderson)
Rob Sanderson: +1
Ivan Herman: +1
Gregg Kellogg: +1
David Newbury: +1
Jeff Mixter: +1
Simon Steyskal: +1
David I. Lehn: +1
Resolution #2: Close #87, as unnecessary given above rules. {: #resolution2 .resolution}
Simon Steyskal: #98
Proposed resolution: close #98, as unnecessary given the rules above (Ivan Herman)
David Newbury: +1
Ivan Herman: +1
Proposed resolution: Close #98, as @context: null clears context definitions (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Harold Solbrig: +1
David I. Lehn: +1
Resolution #3: Close #98, as @context: null clears context definitions {: #resolution3 .resolution}
Resolution #4: Close #98, as @context: null clears context definitions {: #resolution4 .resolution}
David I. Lehn: #116
David I. Lehn: discussion of [https://github.com/w3c/json-ld-syntax/issues/116#issuecomment-460681505]
David I. Lehn: [missed scribing much back and forth, trying to catch up on the gist]
Gregg Kellogg: [pointing out current algorithm could be modified based on some rules to handle the partial redefinition]
Ivan Herman: [concerns about backwards compatibility]
Gregg Kellogg: based on algorithm, 1.0 would fall through to new 1.1 behavior
Ivan Herman: sounds like adding more hacks
Dave Longley: also want it to be easier for json authors
Gregg Kellogg: we go towards side of being easier for authors
David Newbury: hard to follow what is going on without knowing all the processing steps
Gregg Kellogg: not overriding term itself […?]
Rob Sanderson: more authors to explain to than people needing to understand this feature. on side of authors.
David Newbury: issue with how things are overridden. seeing next term definition would think it fully overrode first one.
Ivan Herman: [worries about more complications]
David Newbury: example seems like json in json-ld
David I. Lehn: it’s a mix in this case, using json tools to process json-ld. would want to know the context of the data.
Rob Sanderson: [discussing how some examples would be processed]
Ivan Herman: adding new features to already complex system. really worried about it.
Dave Longley: understand ivan. A goal is to make ergonomics of 1.1 easier for users and better than 1.0
Proposed resolution: if @id is not present in a term definition, and there is no default vocabulary, but has an expansion to an absolute IRI in the active context, then the @id of the new definition is taken from the active context (otherwise this is still an error) (Rob Sanderson)
Rob Sanderson: +1
Ivan Herman: +1
Simon Steyskal: +1
Gregg Kellogg: +1
Dave Longley: +1
David I. Lehn: +1
Jeff Mixter: +1
David Newbury: +0.5
Adam Soroka: +1
Resolution #5: if @id is not present in a term definition, and there is no default vocabulary, but has an expansion to an absolute IRI in the active context, then the @id of the new definition is taken from the active context (otherwise this is still an error) {: #resolution5 .resolution}
Proposed resolution: Once previous is done, we can close #116 (Rob Sanderson)
Harold Solbrig: +1
Ivan Herman: +1
Rob Sanderson: +1
David Newbury: +1
Simon Steyskal: +1
Jeff Mixter: +1
David Newbury: +1
Rob Sanderson: +1
Harold Solbrig: +1
Adam Soroka: +1
Ivan Herman: +1
Rob Sanderson: Really 116 :)
David I. Lehn: +1
Resolution #6: Once previous is done, we can close #116 {: #resolution6 .resolution}
Proposed resolution: We agree with the processing order per #61: scoped definition from property, then from type, then embedded. PR to update docs to come. (Rob Sanderson)
Ivan Herman: +1
Rob Sanderson: +1
Adam Soroka: +1
David I. Lehn: +1
Simon Steyskal: +1
David Newbury: +1
Jeff Mixter: +1
Harold Solbrig: +1
Gregg Kellogg: +1
Resolution #7: We agree with the processing order per #61: scoped definition from property, then from type, then embedded. PR to update docs to come. {: #resolution7 .resolution}
Harold Solbrig: scribnic hsolbrig
Gregg Kellogg: what if you said context null?
Rob Sanderson: it would wipe out all definitions
Gregg Kellogg: you could also seal activities

[azaroth42]

This is now #129. Closing.