Introduce concept of "sealed” contexts #20
Comments
|
@gkellogg This seems reasonable and useful to me. Would sealing be a context-level-only feature? IOW, do you propose allowing some terms in a context to be sealed but not others? |
alternatively, one could also split the context into one sealed part and an unsealed one, and just import both right? |
|
I imagine so, although the interweaving might be difficult... I'd have to work through some examples. |
|
This issue was discussed in a meeting.
View the transcriptRob Sanderson: back to issue 20… sealed contexts … introduced in the CG by dave longley in June Gregg Kellogg: so the idea is that there is something in the context that says if a given context refers to something else that tries to override a known term … that there is a way to prevent the overriding (but w/o stopping processing) … one example, a context with a list of other contexts the others can’t overrride … how do we cause overriding to take place when you absolutely need to? context:null? … scoped contexts should do the same thing Ivan Herman: who would freeze the context? Gregg Kellogg: author Adam Soroka: perhaps to avoid caching problems? Gregg Kellogg: but that’s not what it means … but they do work together Ivan Herman: there is something in my forgotten past that is making me unhappy about this Adam Soroka: the use case that gkellogg mentioned is a good one Ivan Herman: once I have nulled things, I can do what I want anyway … for an example, when there is something missing in schema.org we either come up with a our own term or we use a context to override … but it’s not a very elegant solution, but it works and solves a need. Gregg Kellogg: but you could just as well solve it by creating a new term but then schema.org isn’t going to recognize it Benjamin Young: the sealed context goes against compaction Gregg Kellogg: no it does not. Benjamin Young: if you look on the playground this isn’t what I see…so maybe there is a difference between spec and implementation? Gregg Kellogg: the sealed context is relevant in expansion … by treating the input as always being expanded … also algos start from expanded form Rob Sanderson: I want to question the nuclear option … if that is allowed, then why would that be useful instead of just specifying new context? Gregg Kellogg: the reason to do it is that you don’t want to inherit things outside your scope Rob Sanderson: if have a context that wipes out all the previous ones, then everything form that point is known Gregg Kellogg: you can also set a single term to null … as a way to undefine a single term Adam Soroka: given ivan’s example, where I want to change the value type of a known term…that is quite different from completely overriding a term with completely different semantics. … we should be sure that all use cases are addressed with the same solution Gregg Kellogg: in the case of schema.org, we want to make it legitimate to avoid loading contexts Dan Brickley: and be sure to differentiate search from other cases Gregg Kellogg: verifiable claims wants sealed, but we’re not sure why Benjamin Young: VC relies on LD signatures, and sealing ensures that the output graph (which is what is signed) is always the same. Gregg Kellogg: but if they were defined in the scope of the client Ivan Herman: which is why nuclear works … they need a controlled environment and so they want to ensure that any previous state doesn’t impact the sig contexts Benjamin Young: but their user data goes lower and the sig is the higher tree … .they are the first context not the last Dan Brickley: w.r.t. signature over this, there are some old experiments around signing schemas (links near https://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC/FOAF_Use_Case#Signed_RDF somewhere) Adam Soroka: is this a real concern? Adam Soroka: actually this is real, just ? whether sealed contexts can fix it Gregg Kellogg: yes, if you could somehow (maliciously) change the context earlier on, then all breaks down Dan Brickley: this could introduce some serious problems with nuclear overriding needed things Dan Brickley: not feeling it. this doesn’t seem to align with the rest of the web and its use of JSON-LD Ivan Herman: this seems to be useful from the security/sig concerns Benjamin Young: but if you expanded everything then you wouldn’t have the problem Ivan Herman: but can I add signatures to a context? verifying authenticity of a context Action #3: Rob Sanderson to create context signature issue, related to #20 Gregg Kellogg: if we have a signature on a given context, has integrity, etc. - but that’s different from a new context Adam Soroka: both could be valid or one/both could be malicious Ivan Herman: the whole thing is a security thing that has to be built on top of JSON-LD Benjamin Young: since the people that wanted it aren;’t here, so let’s not touch it right now. If we get it wrong, it will make things worse … we need some use cases Leonard Rosenthol: If we’re worried about signing things, we should do it consistently. … there’s a mechanism in HTML to verify a linked resource - sub resource integrity - can we apply that there as well? Benjamin Young: https://www.w3.org/TR/SRI/ Benjamin Young: https://w3c-dvcg.github.io/http-signatures/ Dan Brickley: (there’s some relationship between the subresource integrity and webpackging . that I don’t totally understand) Leonard Rosenthol: also resource integrity might be useful here as well Dan Brickley: signing of HTML+JSON, HTML+Microdata, HTML+RDFa, HTML+SVG, CSS, Javascript, Typescript, WebAssembly, GLSL, blahblah … should all have a common! Benjamin Young: https://github.com/WICG/webpackage Dan Brickley: what happens when we come to a future TPAC and everyone has their own signatures :( … integrity and signatures isn’t the scope of this group Gregg Kellogg: this seems like something for HTML or Web Platform Benjamin Young: put some links in the chat for various other options … LD signatures might be part of DID but they are debating it there … so let’s kick the can over to them and see what happens. Ivan Herman: that being said, SRI is so simple that we might consider how we could use it for contexts. … it certainly doesn’t solve anything, but it would be useful Benjamin Young: the may be some issues about exactly what are you validating/checking. … there are some known issues, but we may be able to work around those with some specific info about JSON-LD Leonard Rosenthol: SRI is just hashing a “binary stream” Leonard Rosenthol: we need an action item to create an issue around use of SRI Gregg Kellogg: thinks we discussed this last TPAC Ivan Herman: how would the syntax work? Gregg Kellogg: yes, we’d have to work on that Proposed resolution: Defer #20 for TAG review for cross-specification issues of signing on the web ; confer with security regarding SRI and credentials regarding LDS vs byte hashing (Rob Sanderson) Leonard Rosenthol: +1 to proposal Ivan Herman: +1 Rob Sanderson: +1 Benjamin Young: +1 Adam Soroka: +1 Gregg Kellogg: +1 Benjamin Young: https://www.w3.org/TR/2014/WD-SRI-20140318/ Benjamin Young: wanted to point out that RFC as well which is much better than the current SHA expression as used in SRI … not our problem and lots of solutions Harold Solbrig: +1 Simon Steyskal: +1 Resolution #2: Defer #20 for TAG review for cross-specification issues of signing on the web ; confer with security regarding SRI and credentials regarding LDS vs byte hashing |
|
This issue was discussed in a meeting.
View the transcriptDave Longley: we wanted to talk about onboarding allies from the JSON world… a number of W3C specs have adopted JSON-LD, to get extensibility and interoperability … however, a number of non-RDF people are only going to use this data as plain JSON … not apply any JSON-LD algorithm … Most of those standards require that their context is the first one in the @context list; … and have the rule that terms from their context should not be overridden. … Result: plain JSON interpretation will differ from JSON-LD interpretation. Rob Sanderson: if the JSON-only processor does not use the context at all, where’s the risk? Dave Longley: E.g. Verifiable Credentials defines a ‘description’ field; … if someone uses an additional context redefining ‘definition’ to mean something else, … a pure-JSON tool will still interpret that as the VC description field. … The ‘sealed context’ feature is required to make JSON-LD-based formats robust, … reducing the gap btw JSON and JSON-LD. … JSON people understand how JSON-LD can help interoperability, … rather than having anyone defining their own schema, … but they don’t have an RDF background. Ivan Herman: the idea of a ‘sealed context’ is to prevent people from overriding terms in the first context. … Wouldn’t it break the expectation of someone publishing their own data with their own vocabulary? Dave Longley: this only applies in the case you are using a array of contexts Christopher Allen: In constructing VC examples or DID examples, … I ran in problem linked to the underlying graph model, that only Dave or Manu could explain. … In VC, I want to be able to put some metadata of my own, … something that’s not standardized or even ready for standardization, … how do we put it in a way that we are not messing up other things? Dave Longley: many people don’t get that curly braces in JSON-LD mean that you are talking about a node, … and attributes are about the links in this graph; … those people tend to produce data that make no sense for people who understand those principles. Benjamin Young: I came to JSON-LD from an RDF-aware background … I want to make things clearer, … but not at the price of hiding completely the graph model from Web developers. Adam Soroka: +1 to bigbluehat Benjamin Young: Anecdote: in some plain-JSON formats, the same attribute ‘name’ does not expect the same type at different levels of the tree. You don’t have that in JSON-LD. Christopher Allen: We are at a jey point where a lot of people are using JSON-LD. … We don’t want them to decide that they will just do JSON and forget about the LD. Gregg Kellogg: would the solution be a set of best practices? Ivan Herman: Question: who is expected to seal a context? The author of the context or the author of the data? Dave Longley: This is an open question. … The notion of sealed context is one way to hide the graph model . … Best practices, and anything that makes people aware that there is something beyond JSON, is a non-starter. Benjamin Young: for you, sealed context only apply for arrays of contexts? Dave Longley: yes, in all the use cases that I know of. … If someone publishes a new context which extends another one, Dave Longley: they can decide to override terms of the inherited context. … As this would be a totally differen thing from the POW of pure-JSON. Ivan Herman: Would it make sense to introduce a JSON datatype? … I could put a bunch of JSON in the JSON-LD, that would be interpreted as an RDF literal with the JSON datatype. Benjamin Young: but then you would have problems for signing, because you couldn’t determine the exact value of that literal (re. new lines, spaces…). Dave Longley: yes, that raises a number of other issues. Benjamin Young: One use case in VC is to be able to express an inner graph, with its own context, … without compromising the outer graph with the VC metadata. … In the old days, we would have used namespaces. … Why not use “vc:” in front of the terms you want to keep uncompromised? Dave Longley: The prefix wouldn’t survive some JSON-LD applications, … and would produce something different from the POV of plain-JSON. Rob Sanderson: Is it the expension that’s the issue? Or the compaction as well? … Is it only about the label or the rest of the definition (e.g. “@type”: “@list”)? Dave Longley: the full term definition has to be a constant. Ivan Herman: in the first round, let’s stick to sealing contexts, not individual term definitions … What we are trying to do is to add a “modifier” on the “@context” link. Adam Soroka: The notion of wrapping is important in this use case. … Is “sealing” not a special case of prioritization, … which might have more complex requirements? Dave Longley: ActivityPub also have requirements for priority. … Their answer is “if you nee priorities, use full-fledged JSON-LD” Dave Longley: re. WC, we could ask people to include their own @context, … but that could not work in all cases. Benjamin Young: pchampin suggested earlier to required that the sealed context be in the end, … so it will effectively not be overridden with the current rules. Gregg Kellogg: yes, but putting the extension before the extended context would be odd Rob Sanderson: if terms are marked sealed, and the extension redefines that term, … the overridden term will not be sealed, which can be detected by a validator … This could mitigate the problem. Ivan Herman: what if we have two sealed contexts in the list? Dave Longley: then we would also need order priority… Pierre-Antoine Champin: seems to me we’re discussing two different things with multiple contexts … extensions … which are aware of the sealed context … and it would therefore be carefully designed to not conflict … the other scenario is a “wrapping” one … where the contained statements are expected to not match the wrapper Benjamin Young: regarding the wrapping scenario, JSON-LD has graph containers. Dave Longley: VC is using that. Benjamin Young: could we solve the problem by adding some mechanism at the graph containers level. Dave Longley: that would only work in named graph. That might solve my problem, but may be not others’ (activity streams). Benjamin Young: following pchampin’s idea that there are two different categories, may be two different solutions are the way to go. Benjamin Young: #87 Ivan Herman: to wrap up, the options that we considered are … 1/ modify the semantics of graph containers … 2/ having a “sealed”: true attribute in the context … 3/ having a “sealed”: true within term definitions … 4/ having the equivalent of a “rel=” attribute on the “@context” link Gregg Kellogg: when you seal, are you sealing the local context or the active context? Gregg Kellogg: seal and integrity should be treated separately Benjamin Young: why not just go for putting the sealed context in the end? Gregg Kellogg: because the following contexts will usually rely on the definitions in the first (sealed) context. … e.g. after importing the schema.org context, I know I can use the xsd prefix. Rob Sanderson: ref: https://iiif.io/api/presentation/3.0/#45-linked-data-context-and-extensions |
|
Hello! An idea was proposed at the meeting at TPAC that this issue could be addressed by simply ordering "extension" contexts first and "core" contexts last in an First, there's the aesthetics of it (people would prefer a "core" Here a I think it would probably be best to create a "sealed"/"frozen" |
|
@dlongley thanks for that example! Scoped contexts do introduce a whole new layer of complication/confusion/unexpectedness... That said, I'm not sure the current array ordering is that unintuitive/unexpected. Developers (especially general Web developers) are very familiar with "cascading" thanks to CSS. Things currently work this way with JSON-LD It's also the way JavaScript (ECMAScript)'s a = {'test': 'ing'};
b = {'test': 'er'};
console.log(Object.assign({}, a, b));
// Object { test: "er" }And, it's also the way ES6's Object Rest/Spread Properties work: a = {'test': 'ing'};
b = {'test': 'er'};
console.log({...a, ...b});Consequently, I'd find flipping the order more confusing and intuitive--and out of keeping with the surrounding code one would write to create the local context. So, I'd be 👎 on flipping that order--especially between JSON-LD minor point releases. Sorry. I'll leave the continued discussion around sealed contexts--especially as it relates to the scoped context example you gave for another time. 😃 |
To be clear, I wasn't suggesting we flip the order for term definitions, just that sealed contexts should apply left to right ("first sealed context wins"). I think it would be odd for them to apply right to left ("last sealed context wins"). |
|
Yep, I guess where we did make a mistake at TPAC is to think only the way context works in 1.0. I am a bit neutral about the problem of whether one type of ordering is more natural than the other; I can see the points of @BigBlueHat. However, as the example of @dlongley shows, the problem of scoped contexts shows the limits of this approach anyway, and makes the problem about right order possibly irrelevant... :-( I.e., we may be back to the drawing board on that one. |
|
@dlongley musing on this some more (as I work on Verifiable Claims Data Model tests), and I'm wondering how much of this is solely "scoped context" related. For example, I altered the example you posted earlier, and made the "VerifiableCredential": {
"@id": "base:VerifiableCredential",
"@context": {
"issuer": {
"@id": "base:issuer"
}
}
}That, consequently, "fixed" the problem (in this narrow scenario). 😉 So, what I'm wondering now is:
Thoughts? |
I suspect all of the requirements discussed in issue #98 likely can't be covered. Even so, I'm also a little apprehensive about creating contexts that may appear to have useless cruft in them -- instead using the clarity that a It seemed like we arrived at a pretty good/coherent path forward for the |
|
Some proposed content to be turned into specification text if it meets the use cases...
Thus, some examples... This context defines This is equivalent to the first example. Label is sealed, but value is not sealed. Equivalent to the previous, just in reverse Within An error, as sealed_data is still sealed. (?) You can't redefine Error state, as the null would remove a sealed term. Questions arising:
(Tag @dlongley to take a look) |
|
I agree with Rob's examples.
Yes.
I think "no" makes more sense here, but I'm open to an argument for "yes".
Also +1 to deferring. Another example for clarity on This is not an error and causes the scoped context for "wild_west" (anything nested under that term) to be "http://schema.org". |
|
Regarding this: An error, as sealed_data is still sealed. (?) I'm not convinced that should be an error given that it's in the same document. This seems like something someone may want to do. I would expect the sealing here to prevent other documents from changing the scoped context. |
|
I think we need a separate issue for the partial redefinition case for adding a context to |
|
This issue was discussed in a meeting.
View the transcriptRob Sanderson: Github issue: #20Ivan Herman: Related issues: #98 and #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: #98 (comment) and the last example of #98 (comment) 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: #108 (comment) 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. |
|
That's a good point; I agree that terminology is important. That being said, I like the metaphor of the seal, as I have used it extensively in explaining how the processing should be done. I can't find an equivalent with a "frozen" metaphor. [[failed attempt to make a pathetic pun about seals, see ice and freezing...]] |
|
Maybe allow 10 minutes for bikeshedding on the call tomorrow. I can go either way. |
|
This issue was discussed in a meeting.
View the transcriptReview Pierre-Antoine’s proposal for sealed context processingBenjamin Young: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0016.html Ivan Herman: #119 Gregg Kellogg: #20 Ivan Herman: -> the proposed text for the syntax draft: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/119.html#sealed-contexts Benjamin Young: API PR w3c/json-ld-api#60 Gregg Kellogg: I can represent pchampin’s issue, since he can’t call in due to internet connectivity problems … There’s an issue, and discussion in the PR … the principle issue in #20, and pchamin’s work is around syntax … basically, he suggests sealing contexts, not terms, though it’s not design limited that way … and sealing a context, the term definitions are tagged with an identifier associated with that context … an implementation, for each term def., you know which context it comes from (for sealed contexts) … so if you attempt to update that within a sealed node, you can only update it if the update is coming from the sealing context … this would happen for embedded context … so if I define a term foo, and that context wants to update a term in that context, you can see the terms that the updated terms came from the same context … that would allow terms defined in other sealed contexts to not interfere … so you cannot create a term that interferes with a different sealed contexts. … there is a list of active sealed contexts active during expansion… … that effectively unseals all the other contexts when processing … if you were to descend into another property not associated, that would have the effect of unsealing all contexts. … if you use a term from a context, even if it’s unsealed, you now enter a mode where the context is sealed. … what this means for sealing contexts or terms, since you’re tagging the context info per-term, it seems straightforward to do that per-term. There is no support for sealing part of a term, say the ID, but not the container … no use cases Rob Sanderson: does the seal ID need to be different than the context ID? is it specified explicitly? … does this mean that the top context might be sealed, but an embedded one might be unsealed? Ivan Herman: he also put a text into the syntax document which describes things and makes it clear and easy to understand … there was also an issue: what happens if you do something that is not kosher? one possibility is a warning and you ignore, the other is to throw an error … and some of the examples will change based on that answer. It’s a decision Benjamin Young: This felt a lot like one context being last … it would be super if we could have our use cases written up, both verifiable claims and web of things … have use cases Dave Longley: I am thinking about this and reviewing it, and looking at it, I’m not sure how it would impact caching of active contexts. … I haven’t thought through how it works…can we keep track of an ancestry tree? … whatever we put in the spec, whatever matches the output, it’s OK. Still thinking through it Ivan Herman: I am worried that what’s described is an implementation strategy, not a requirement for a spec Rob Sanderson: +1 to Ivan Ivan Herman: we should make sure that we don’t define the process, but instead what we need to have as normative Dave Longley: +1 to Ivan Ivan Herman: informatively, we can put in examples. What counts is the test cases Benjamin Young: we currently don’t track term overriding and who overwrote what in what order Dave Longley: +1 … that would be a helpful tool Benjamin Young: so if you have two contexts and one overrides it, there’s no awareness of that in the code. So in a context dev, and to keep sealing in, it would be helpful to know what happened and in which order. that could clear a lot of confusion Gregg Kellogg: My feeling tis that we’ve been overly prescriptive to ensure interoperability … embedded contexts cerate a new ID and inherit from the one embedded … so I think we need to try and describe that in a way that stays as close as possible to the behavior, and the mental model has to be described in the syntax doc to understand orders of operations … but adding more complexity threatens to degrade performance Rob Sanderson: in the proposal, does that include externally referenced, but scoped contexts? So if I had a doc that had sealing at the top level, and I scoped in schema.org within a term, would that then seal schema.org? Dave Longley: {"@context": {"sealed": true, "foo": {"@context": "http://schema.org"}}}? Rob Sanderson: does that seal by reference schema.org? if you had it as an externally reference, sealed context. … what dave said in the chat … what happens? Gregg Kellogg: my feeling is that scoped context is not explicitly sealed. So, no. schema.org would not be sealed in that example. … what you need to know is there is a reference, and we might restrict that to being things in a local/embedded context, have the ability to affect things that were defined in the outer context, but not implicitly sealed … does the sealing act valid for everything, or are there parts like vocab that are not sealed? Gregg Kellogg: three top-level directives: version, vocab, language, and base … context is not a member of a context, it’s a member of a term definition Dave Longley: i’ll just say — my view of “sealed contexts” is that someone made a specification for a bunch of terms (a “sealed context”) and JSON-only devs will read that spec and apply the rules therein — not running any JSON-LD processing after that… and we should consider how sealed contexts according to that line of reasoning. Gregg Kellogg: the body is an object that contains term definitions, default vocabs…a term definition can itself be sealed, and if that includes an embedded context, and if that’s sealed, then the context that it defined in not implicitly sealed … I can’t update the context with a new context…otherwise the use of context within a context is in the document, and…. … . too many uses of the word “context”. Dave Longley: so if we want to allow people to write specs that say: “everything under this term will use schema.org’s context” … that’s what JSON devs would expect, no changes Dave Longley: we could of course, require those spec writers to redefine all those terms manually if need be Benjamin Young: the top level directives…is it imagined that those would be sealed? Gregg Kellogg: we don’t seal base, vocab. if you want to seal, seal a term. if the default vocab is schema.org, and can’t override it… Dave Longley: the main use is a spec, like W3c, and they’re defining terms in the spec, and will provide the context, and will only apply the rules in the spec. Rob Sanderson: I agree with that too, but then to me it’s going to be clearer if the individual terms are sealed, rather than the terms defined in a context that’s sealed, but other features (e.g. base and vocab) are not sealed in that context Dave Longley: first, you’re using JSON-LD to enable extensibility and semantics. that means that you want other terms to be created. … so I think that losing .vocab won’t work. Sealed contexts should not be constrain things not defined. … we should think of how they should behave within that domain. … if we want to figure out how it should work, we should think about it in the context of a spec–if there’s a term not in the spec, you can ignore them. … none of these term definitions will change. If you’ followed the path in the spec, nothing will change. … that’s what the feature should guarantee … everything else is outside of what people who care bout JSON will care about. Benjamin Young: +1 Dave Longley: think about this domain through the lens of JSON-only developers Rob Sanderson: Also +1 Ivan Herman: what would happen if Schema.org sealed that context? Dave Longley: all that would happen is that the terms wouldn’t change. Ivan Herman: using schema.org, some of the terms are underspecified. So what we do is add our own context that defines, with the same URL, we add additional constraints to the term. … this would prevent this Dave Longley: if you’re redefining these terms, this would lock that possibility. Ivan Herman: even if I use the URL, but I specify the type.. Dave Longley: that’s a separate issue, but an important one Ivan Herman: this happens a lot with schema.org a lot. Often I want to make them more precise Benjamin Young: maybe, given large vocabs, sealing many terms, this maybe an API thing, but not a syntax thing? Can the processor seal/not-sealed to create a processor that says that this context is sealed … but the developer chooses … and then these terms are sacrosanct … these are the terms my processor must understand Gregg Kellogg: echoing ivan, schema.org author: Values are expected to be an org or person, but that’s defined without a type. JSON-LD processor will allow a string value there Dave Longley: i’ll just say that’s interesting (doing this via an API mode/flags) Benjamin … and worth considering further. Gregg Kellogg: not a URI. Dave Longley: interesting, but i don’t think will work :) Gregg Kellogg: that’s a case for updating it for author is explicitly a URI. Rob Sanderson: +1 to dlongley, agree it needs to be syntactic Dave Longley: a good idea, but there will be people who won’t know to read the spec and flip on the flags. it needs to be in the data. Benjamin Young: we’ll see you in a week or less. look through it, add your notes, etc. |
|
Following up on the question @iherman raised at the end of yesterday's discussion, the need for a json-ld author to redefine select schema.org terms is real - it will create more work (or confusion for simple json developers) if there is no easy way to override a decision by schema.org to seal their context - e.g., could lead authors to clone and maintain their own variants of schema.org context. Illustration -- As has come up in the WG previously, schema.org has many properties with a range that encompasses multiple data types, e.g., per current schema.org documentation both Text and URL are listed as values expected for the properties genre, artMedium, artworkSurface, artform, fileFormat. But the schema.org context specifies only URL (@id) when defining each of these terms, e.g. from the current schema.org context document:
So, in one or our applications here at Illinois we routinely reference schema.org context document and then redefine these 5 terms, e.g. (for fileFormat): For full example (we have about 4,500 of these), see: Current JSON-LD playgrounds (both) accept these redefinitions and understands our use of text strings as values for these properties. So the following line in our json-ld instance
is expanded by the playgrounds as we want: If we fail to redefine these schema.org terms -- or if in the future our attempt in local context to redefine these terms are ignored because schema.org someday chooses to seal their context, then the playgrounds turn our strings into relative URLs. A version of our file without the redefinitions is here: In this case (no redefinition) the same key-value in the instance as above:
is expanded by the playgrounds this way (NOT the way we want): Of course we can effectively work around the default term definitions on a case by case basis by using object values for the un-redefined properties and explicitly specifying @value and @type:s:Text ourselves (will this technique still work if term definition is sealed?). But this is not the ideal solution to prescribe (especially for simple json developers) and notably the Google SDTT does not accept this usage (one of a few issues with the tool which I don't think actually looks at context at all). So, personally I would appreciate a more flexible seal mechanism that allowed some kind of a seal override on any externally referenced context document that includes the @Sealed:true directive. |
|
The problem is real (as I said on the call, we do something similar for Web Publication Manifests). But I am not sure what that would mean...
|
We need to consider the primary use case for sealing terms/contexts, which is to allow naive JSON apps to be able to interpret values as defined in a spec; this includes how to treat string values, and if an object value should be treated as a list, a map, or whatever. Allowing these things (or anything, really) to be overridden on a term sort of by definition does not allow naive apps to be able to properly understand their values. The only possible exception would be to add
Yes, absolutely; we should caution that this feature should be used judiciously, if at all. |
|
I lean towards option 2. Sealing should only be used in specific use cases,
and schema.org does not fit in those, I think.
…On Sun 3 Feb 2019, 21:04 Gregg Kellogg ***@***.*** wrote:
1. We could revive the approach, briefly mentioned at some point but
not really retained, to be able to "seal" only specific terms or those
terms that are explicitly mentioned. In the schema.org example, it
would mean sealing the @id value (and possibly other values as given
in the schema.org in the current context file) but allow extending the
term definitions like what @tcole3 <https://github.com/tcole3> has
shown. The problem was that this goes against the approach in JSON-LD 1.0
(where redefinition is an all or nothing action). Specifying this properly
may lead to a spaghetti specification (and implementation...)
We need to consider the primary use case for sealing terms/contexts, which
is to allow naive JSON apps to be able to interpret values as defined in a
spec; this includes how to treat string values, and if an object value
should be treated as a list, a map, or whatever. Allowing these things (or
anything, really) to be overridden on a term sort of by definition does not
allow naive apps to be able to properly understand their values. The only
possible exception would be to add @container: @set to ensure that
compaction always uses array notation, but that's a compaction use case,
which does not relate to naive JSON apps. So, I don't see a reason for us
to do this.
1. Another, more pragmatic approach is to make it very clear that...
if *possible*, you should not seal a context. To be more specific,
make it very clear that sealing an under-specified context may lead major
issues, and publishers shouldn't do that. Sealing should be reserved for
very specific use cases, where the context is extremely well specified and
it would be an issue if they were redefined.
Yes, absolutely; we should caution that this feature should be used
judiciously, if at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASl5DXM2y0LdKUGCuFr0bJH9sUxZ8YXks5vJ0DagaJpZM4U-BsL>
.
|
|
Agreed. The risks associated with misinterpreting schema.org data seem very small in comparison with the risks of misinterpreting WoT or Verifiable Claims data. |
|
This issue was discussed in a meeting.
View the transcriptSealed contextsIvan 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 |
|
This issue was discussed in a meeting.
View the transcriptSealing … againPierre-Antoine Champin: not ok with the decision with context null being able to wipe everything. It is brittle and using a nested context that could have null. It is not necessary to seal terms … we are overwriting context null … solution is to separate the functions and create a new keyword that can be used to unseal all of the current sealed terms. @unseal no would unseal all terms for example … sealed terms would not be touched … a third benefit would make it easier to deal with the situation where you import a sealed context Ivan Herman: what this means is that a context null wipes out everything except what is sealed? Pierre-Antoine Champin: no opinion on how this would function but sealed terms would not be affected David Newbury: for the use case where you have an area in the document we would need to use unsealed and context null Rob Sanderson: you could unseal everything and adding null to blow everything away Gregg Kellogg: is you see the @seal today it would have problems Ivan Herman: this is very similar to the extension conversation we had yesterday Pierre-Antoine Champin: this is a separation of concerns to unseal terms and/or wipe the context Ivan Herman: yesterday we came to this a realized that we do not have a real use case for this Ivan Herman: if you look at the examples at the end we decided to seal individual terms so in the current proposal we should rather look being able to unseal individual terms Gregg Kellogg: there is the asymmetry of unseal and seal - unseal unseals everything. This need does not seem to exist in the wild. … not in favor of doing this Pierre-Antoine Champin: agrees that the syntax is a bit odd but regarding the use cases from yesterday we were looking for a way to unseal the entire context. the use case here is when you encounter random sealed contexts in the wild Gregg Kellogg: if we allow you to fix wild sealed contexts we lower the need/concern to get the use of seal correct … better option is to have the community decide what should be sealed David Newbury: if we provide a mechanism to unseal sealed context that defeats the original point of this issue Adam Soroka: thought is was more of a strong suggestion to not unseal not a restriction to unseal Pierre-Antoine Champin: my concern about context null we are defeating the reason for seal but in a more sneaky way. this proposal clearly defines what we are doing and can imply why we are doing it Gregg Kellogg: wanted to note that we can not expect sanctity around contexts sealed, unsealed, null, etc … more comfortable with context null Rob Sanderson: also prefer context null because it raises the stakes for the user as opposed to just unsealing the terms. with null, you need to start all over Adam Soroka: if you want to unseal the context terms, you need to know all of the terms to unseal but if you can unseal at the context level … it is not a huge problem Ivan Herman: we should put in a proposal and move on Rob Sanderson: sounds like we prefer the decision from yesterday Proposed resolution: After discussion, we agree on no change to sealed contexts from yesterday (Rob Sanderson) Rob Sanderson: +1 Gregg Kellogg: +1 Pierre-Antoine Champin: +1 Harold Solbrig: +1 Jeff Mixter: +1 Ivan Herman: +1 David I. Lehn: +1 Simon Steyskal: +1 Resolution #1: After discussion, we agree on no change to sealed contexts from yesterday {: #resolution1 .resolution} |
|
See #129. |
|
A couple of things:
It took me a long time to read through this and understand the conversation, but I think where it ended at is good. I think we shouldn't make things more complicated than the current change; we should be able to explain sealing/restricting shadowing as a single rule that potentially composes with another rule, and I think the current language does that nicely. We should be clear though that sealing or whatever doesn't help json-only applications be "secure" in that they know for sure that a term is going to be the term they think it is; someone could always be intentionally tricky through context nullification. |
|
Now to talk about implementation. Here's how I think it can be done:
|
I disagree. These rules are supposed to make it such that if you follow a specification you should be safe. If you go off into extension land with no spec that makes it clear what checks you have to run, then you aren't. We'll need to make sure that context nullification of sealed terms is only possible through the creation of a term with a nested scope (no type-based scope context nullification or embedded context nullification of existing sealed terms). |
|
JSON developers understand "isolated extensions" to mean "a new term I define that can be used to create a new branch in the JSON tree underwhich all of the term definitions are wiped clean". This is the only place where context nullification that clears all sealed terms should be permitted. This means embedded context nullification is not permitted and terms with scoped contexts that appear in the type position cannot nullify sealed terms. Only a new term definition (with a scoped null context) where that term appears in a non-type position can nullify sealed terms -- as this matches the expectations of the core constituency of this feature. |
|
@cwebber said:
Note the implementation is described in w3c/json-ld-api#60, which I've implemented myself. |
|
@dlongley said:
We discussed this at the F2F and felt that it was too onerous and complicated things. Authors are creating these documents and choosing to add the sealed contexts in the first place, which they could subvert in other ways. Trying to make this too bullet-proof is ultimately impossible, and the nuclear option of nulling out the context is sufficiently rarely used now that it's not worth overly protecting. I could see generating a warning, if this is done with sealed terms in scope. Jump onto the next call to get a deeper discussion, but we spent quite a bit of time discussing this last Friday. |
I respectfully disagree. Without the above limitation the feature doesn't fully solve the use case. With it, I believe it does. I also believe it matches expectations for how one extends JSON. If we're able to make it so, the feature should provide the guarantees that the main users of the feature expect.
I'm not sure what you mean by this. The target use case is not potentially random combinations of contexts attached to documents floating about the Web. I agree that there should be no expectation for what you can trust there. Use a JSON-LD processor to mitigate your risk. But we absolutely should be able to create W3C specifications that truthfully claim application developers can use JSON-LD without doing JSON-LD processing if they run a couple of simple checks. Anything short of that lends credence to the argument that you can't really use JSON-LD without running a JSON-LD processor.
Ok. |
|
I fully support the consensus that if the feature must be watertight, then it is impossible without breaking compatibility with 1.0. 1.0 specifies that a null context wipes out all definitions, or setting a term to null wipes out that definition. See Section 6.7. We can't change that. FWIW, this topic is not on the agenda for the call on 2019-02-15. If there is time to revisit this before CR, then we will. If not, then we can take the feature out completely or leave it as we have specified. But we are not, in the short term, going to go around the circle yet again and especially not without stakeholders being present and engaged with the work of the group. |
And the check is that no context uses |
I don't think this position makes any sense. We can change 1.0 behavior regarding how select terms can be overridden but we can't change 1.0 behavior regarding how all such terms can be overridden at once? That reasoning sounds like it relies upon an inconsistent understanding of backwards compatibility. Rather, no terms were These new terms should behave in the fashion that best supports their use case and best fulfills the expectations of their main users. I think this means we should make it such that they are only cleared as in the example that's in the spec today. Namely, that you must define a new term that explicitly clears them through a scoped Most importantly, it best helps deliver on a promise the community has been making since JSON-LD was created: You can easily use JSON-LD as regular JSON without having to process it.
This check still requires JSON-LD processing which harms the purpose of the feature. It adds complexity on the users of the feature that is not necessary if we limit clearing I haven't seen a good argument against this definition for clearing |
|
This issue was discussed in a meeting.
View the transcriptSealed Contexts’ timingRob Sanderson: a discussion started yesterday about the decisions made during F2F about sealed contexts … we need to see to which extent the current proposal works and does not work with existing use cases; … we have spent several week and close to half the F2F time to talk about it; … continuing is not in the interest of the group. Dave Longley: We plan on implementing next week and we’ll engage on Github … we are globally happy with the decision of the F2F, … but we need sealing to be a little more restrictive. … We will come up with an implementation of what we need. Rob Sanderson: this will help to assess how much additional complexity is required Gregg Kellogg: what we have been looking at was doable (I did implement it), … but we still decided that it added too much complexity. … That being said, I’m happy to discuss with you about it. Dave Longley: All we want to do is add constraints on when the context can be cleared with ‘null’. … We don’t think it adds that much complexity. |
|
Resolved :) |
A number of standards track specifications use JSON-LD for extensibility but intentionally place limitations on overriding the terms defined in a core context. For example:
https://www.w3.org/TR/activitystreams-core/#jsonld
https://w3c.github.io/vc-data-model/#extensibility
It seems like it would be a nice feature to allow enforcement of this desire by JSON-LD processors. Then authors could be assured that the interpretation of a context would be proper and properly implemented JSON-LD processors would throw errors if rules were violated.
In short, I propose we add a keyword with boolean value such as
"@sealed": true(that could appear in contexts) to JSON-LD 1.1 that enables processors to enforce a desire to prevent defined terms from being redefined in subsequent contexts, but allows for new terms (aka extensions) to be defined.Original issue: Introduce concept of "sealed" contexts #656
The text was updated successfully, but these errors were encountered: