Consider context by reference with metadata #108
Labels
defer-future-version
Defer this issue until a future version of JSON-LD
privacy-tracker
Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response.
security-tracker
Group bringing to attention of security, or tracked by the security Group but not needing response.
Comments
|
I came to a similar conclusion about how to do this, but the question remains: what use case is this solving. I don't see how it allows, say, a WoT system to avoid loading |
|
I agree with @gkellogg that we will have to evaluate whether we wanted a structure of such an "annotated" context link. But let us try to put that aside for a moment to see whether we can agree in a syntax. What I had in mind is slightly different; my goal was not to overload again the same keyword with different possible semantics. What I had in mind was rather: It is a bit more verbose but, I believe, a bit clearer (and mimics a bit the The array of links is also to bring back the issue we had at TPAC, namely to see if some sort of a local cache reference can be used. So that array is based on the idea used in CSS for font access: the processor takes the first URL that works in returning a context file. It is not yet clear in my mind how exactly we would identify a local cache, the array would be used for something like that. I guess, returning to @azaroth42's question, I tend to say that we would have to define the possible attributes, instead of an open end. |
|
This issue was discussed in a meeting.
View the transcriptIvan Herman: it is interesting, no doubt… (puts admin hat on) … these are very early drafts … Manu made this proposal in December, very early days … we’re fine, though. … if the technique becomes a standard form for URIs, we can use it as such … I’m happy to have us say that we are interested … we should try to see whether this tech really can be used to annotate links while we also pursue other avenues Gregg Kellogg: really like the idea, could be very useful Gregg Kellogg: but not clear that it really affects our docs at all … what would we change? Ivan Herman: we shouldn’t close issues just because this new thing is a new thing Gregg Kellogg: unless we think that we can do that via a reference in the best practice docs Adam Soroka: if hashlink solves for problems we have, then we may not want to recreate alternative features that solve the same issues Benjamin Young: although this new hash URI tech isn’t standardized, it has been put into use |
|
(this issue stems from this resolution: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-12-14-json-ld#resolution3) |
|
I realize that the example given in #108 (comment), is different from the issue discussed in #98. Indeed, in #108 (comment) the |
|
Following up on #108 (comment): I can see one reason to allow for such "caller side" sealing. There may be (well, there are) a number of 1.0 version contexts that we may want to use, and we may not expect the authors to change those context files. That in spite of the fact that in some situations the sealing would be very useful. Doing it on the caller side means that new, 1.1 compatible contexts and data set can be properly used without expecting the original contexts to be changed... |
|
Question arose about sealing |
|
IMO, sealing a context for which you have no control can lead to problems, as it may change out from underneath you in the future and make data which used to be valid no longer valid. I would not support the ability to seal a context by reference. |
|
Sealing a context in hand is an act on that context in that scope. Sealing a context-by-reference-- is that an act on the referent? The link? If someone later down the chain imports the same context via a different URI, is it sealed? |
|
@gkellogg wrote:
This can be mitigated if you also use SRI... That being said, I'm also uncomfortable with caller-side sealing, even though @iherman 's use-case seems very valid. |
|
Just to push this aspect aside: I agree (and we discussed on the call) that sealing a referenced context is not a good idea, i.e., we should remove this. Just to have a clear reference, here is my original example without it: {
"@context" : [
"https://...",
{
"@version": 1.1,
"@contextref" : {
"@url" : ["schema", "https://cdn1.../schema.org", "https://schema.org"],
"@sri" : "sha256-abcd"
},
"id" : "@id"
}
]
}The original proposal still stands without it, including my remark, whereby:
|
|
|
@simonstey That might work in the HTTP setting, but wouldn't that be too restrictive for some IoT applications? There are some very different protocols in use there. |
|
What about using the hash value, as described/defined by SRI? |
@ajs6f true.. so why not just defer the task of identifying a local cache to implementations and add a note along the lines of the one provided by the WoT WG who also (afaik) don't define how identifying a local cache has to be done, but e.g. say that Vocabulary files should be cached whenever possible. |
|
This issue was discussed in a meeting.
View the transcriptadding metadata to contextsRob Sanderson: github: #108 Rob Sanderson: from the discussion around sealing … beyond being able to seal we want to check if a context has changed … you should be able to annotate the context to know its version or a checksum to test it … there is a spec that already does this SRI … a 1.1 processor could use this to see if a context has changed and if so do something Simon Steyskal: link to SRI https://www.w3.org/TR/SRI/ Ivan Herman: originally this type of feature was based on the desire to create a helping hand for implementations that want to use caching for contexts … this is also what SRI is used with in HTML Ivan Herman: -> #108 (comment) another syntax Ivan Herman: as an alternative we could have data that points to the nearest stored version of the context similar to how CSS works … extra metadata for the context could be added and might be useful David Newbury: how is this related to hash links? Ivan Herman: SRI is around and tested … for SRI it is an existing implementation feature in HTML so all we have to so is refer to the SRI documentation Benjamin Young: question the value of encoding this in the context … concerned about adding all of the metadata for contexts into the context Rob Sanderson: spec: https://tools.ietf.org/html/draft-sporny-hashlink-02 Benjamin Young: msporny’s write up of hashlink’s value to JSON-LD (and friends) https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0000.html Gregg Kellogg: this seems like we are in the HTML domain based on the use cases … like the idea of pathing but feel like we should not bake that into the standard Benjamin Young: +1 to gkellogg’s thoughts Harold Solbrig: this seems like a general problem not specific to JSON-LD Rob Sanderson: against hashlinks because it is not normative. This is not prohibited but we do not need to explicitly say so. Do not want to focus just an a HTML approach Adam Soroka: maybe we could offer best practices Rob Sanderson: +1 to best practice note Adam Soroka: should we kick this issue up for the broader community to discuss Ivan Herman: do not see the relation to HTML as relevant. For SRI all we need is a clear definition of what the hash value we are using is referring to Adam Soroka: do we need to specify what to do with the hash value Ivan Herman: no Adam Soroka: is this a protocol level question? David I. Lehn: the readability could be a concern Rob Sanderson: reliance on the http headers seems not feasible. Since a document can load in multiple contexts where should that information be stored and acted upon. Gregg Kellogg: if the integrity checking is not done on the processor than it will not work Harold Solbrig: this is another feature we are adding to JSON-ld … what do we gain for adding this into the spec? Ivan Herman: if you want to help folks that are on a bad network connection - this could solve that problem. Harold Solbrig: what about support for current integrity versioning approaches that work and are used? David Newbury: to implement this we will need to add a third way to reference contexts Ivan Herman: we could defer this because it opens a lot of questions that we would need to address Ivan Herman: what do say to the folks that have this problem now … we do not have anything in our spec to address this use case concern Gregg Kellogg: this is a resource caching issue and there is ways to solve this currently David Newbury: is we allow metadata in context - we could also rethink adding documentation in the context Adam Soroka: is integrity also part of the concern? Ivan Herman: there are a few reference implementations. They should try to implement the best possible caching control and see how it work and document how to do it Ivan Herman: all of these implementations should serve as examples on how to solve this problem Benjamin Young: current CG “best practice” for caching https://json-ld.org/spec/latest/json-ld-api-best-practices/#cache-context Rob Sanderson: the issue of integrity is related to versioning - want to ensure that the contexts that are being loaded are not mutable Harold Solbrig: this is sort of what http expire headers are used for Harold Solbrig: if we did SRI we would need to explain how it works and what to do with it Rob Sanderson: we should propose that this is an issue but we are not the folks to deal with it Ivan Herman: agreed but we might want to also say that we will be more rigorous about documenting how implementors do this Proposed resolution: Defer the integrity/context metadata related issues, and request early horizontal review from security, privacy and TAG. (Rob Sanderson) Ivan Herman: +1 Gregg Kellogg: +1 Jeff Mixter: +1 Rob Sanderson: +1 Simon Steyskal: +1 Benjamin Young: +1 David Newbury: +1 Pierre-Antoine Champin: +1 Resolution #2: Defer the integrity/context metadata related issues, and request early horizontal review from security, privacy and TAG. {: #resolution2 .resolution} |
azaroth42
added
defer-future-version
|
This issue was discussed in a meeting.
View the transcriptcontext by reference with metadataRob Sanderson: link: #108 Rob Sanderson: metadata specified in a document without context … this has been asked for and discussed (as it has some privacy/security implications) … we need to have a good answer for not doing it, if we do so Ivan Herman: the example given in the issue is now outdated … is there any other example that would require this? (other than the SRI one) Rob Sanderson: I don’t.. other than comment, description, etc. Gregg Kellogg: by providing metadata one might not to have to download a context … just verify that the remote context hasn’t changed David Newbury: the other thing we talked about was finding documentation about contexts Ivan Herman: back to the various URI schemes, if we use that argument then some people might raise some eyebrows … as most of those schemes are more or less experimental … but we can say that it would require fundamentally new syntax to be able to handle those metadata, hence deferring Rob Sanderson: +1 that this would be a bigger change than a .1 ; and to refer abstractly to other work Dave Longley: I think we can refer to other work that’s going on in that space … not necessarily say one has to use them Proposed resolution: Defer syntax #108 to future WG, too large a syntactic change for 1.1, refer in HR to other ongoing work (Rob Sanderson) Gregg Kellogg: +1 Ruben Taelman: +1 Rob Sanderson: +1 Tim Cole: +1 Benjamin Young: +1 Dave Longley: +1 Ivan Herman: +1 Simon Steyskal: +1 David I. Lehn: +1 Adam Soroka: +1 Resolution #4: Defer syntax #108 to future WG, too large a syntactic change for 1.1, refer in HR to other ongoing work |
|
This issue was discussed in a meeting.
View the transcript3.1. Type scoped context continued; property wildcardRob Sanderson: link - #174 Rob Sanderson: what is the difference between type scope contexts and property scoped contexts. Is it scoped to the properties of that class, and other thought of it as a replacement for an inline context, and would then expand beyond that class. … where we came to last week is that there are good use cases for both, but the only way to allow for both use cases is to have type scoped contexts be class-only, and to have a way to expand beyond them by setting a default context within. … is that sufficiently detailed to explain where we are right now? Gregg Kellogg: I didn’t quite understand until right now. I’m trying to think of the syntax Dave Longley: my understanding is that what we’re looking for is to take this other context and define it within this scoped context, and then use it for all properties within that scoped ontext … We want to be able to reuse existing contexts within a type-scoped context, so we don’t have to be verbose typing out all of those contexts again. … syntactically, we can currently do this by re-writing all contexts within each of those properties, but that’s verbose. Rob Sanderson: Example use case: https://preview.iiif.io/api/image-prezi-rc2/api/presentation/3/context.json type scopes in http://www.w3.org/ns/anno.jsonld for Annotation and AnnotationPage Ivan Herman: so, if I want to have all schema properties valid within that type-scoped property, and to inherit, and do it by including the schema context file, not each property inline. Rob Sanderson: an example: we’re using type scoping within annotations to pull in the annotation context, which is a 1.0 context, and since the decision is that the annotations referred to would no longer inherit, and so this would need to be modified with a new keyword to maintain this behavior instead of retyping each property for each context Ivan Herman: so we want hasBody to remain an annotation? Rob Sanderson: we want the resource that is pointed to by that property to be an annotation, even though that annotation context is only valid on that class Gregg Kellogg: I understood that this could be for specific properties, but I thought of wildcard as applying to all properties … for instance, if you’re traversing to FOAF, you might not want to continue to use schema.org properties … syntax and wildcard: we could use full wildcarding or or something like a URI prefix … but then what happens when they have contexts defined? I presume they’re honored as well … how deeply have we thought about the various cases … and would it be a property of the propriety term definition, or a propriety of the class that the class term definition that then defines those terms? Rob Sanderson: we had not talked about globbing or real wildcarding: we’d talked about a shorthand for not retyping all properties within that context. … you would then need to define all schema.org contexts for every class that below need to apply … the question is at what level does the wildcard apply? Is it at the ontology level, or is it at the context level? … we’d talked about it at the context level, which is consistent with how other things work Gregg Kellogg: expanding treats properties as terms, not expanded URIs, and compacting we select terms by matching, not via URI. Enumerating properties by terms, not URIs, is more consistent with how we do things currently Rob Sanderson: some solution that says, for all the terms within this context, treat them as property-scoped within this class … like what dlongley put in the chat: for all properties, treat them as property-scoped contexts. … which then wouldn’t need actual wildcarding, just matching … which seems easier David Newbury: I’m wondering if this doesn’t suggest that @type scoping itself could be clearer and provide the approach to inheritance that people are expecting here Rob Sanderson: could we just have two keywords, one for each behavior? Dave Longley: I don’t know if it’s exactly the same, because comparability differs here. … when we pull them in, we treat them all as if they’re property-scoped terms, which is different than the behavior before. Dave Longley: +1 to something along the lines of what gregg is saying Gregg Kellogg: I think that if we have a property that can appear in a type-scoped context that says that all terms within that context inherit that context, or perhaps enumerated terms inherit, and in the absence, no terms inherit, and then it could not appear only on type-scoped contexts Dave Longley: I think that we’re thinking that each one of these contexts would then consider the type scoping as if it were defined on all descending properties Gregg Kellogg: and it would be recursive–this would then travel down the property chain Dave Longley: yes Gregg Kellogg: unless that property redefines its own scope … that seems reasonable Rob Sanderson: can we see a straw person example? Gregg Kellogg: @inheritPropertyScopes: true Gregg Kellogg: @inheritTypeScopes: [‘a’, ‘b’] Gregg Kellogg: do those terms need to be defined within that scope, or do they just need to have been in scope at the time it’s interpreted? Rob Sanderson: that would not work for our use case, since the properties of the annotation are not known higher-up the chain Dave Longley: processing: do you see if it appears up higher to see….(lost the chain here) Gregg Kellogg: I think your use case would be solved by using true Rob Sanderson: correct. Dave Longley: when defining a term within a type-scoped context, look for @inheritPropertyScopes Dave Longley: and if that appears, add a property-scoped context to the term definition Dave Longley: (unless one already appears, as that one would take precedence) Gregg Kellogg: we should come up with a better name Rob Sanderson: in our case, at the high level, our use case is… Rob Sanderson: { 'Annotation': {"@id": "oa:Annotation", "@inheritPropertyScopes": true, "@context": "http:...anno.jsonld"} Pierre-Antoine Champin: @propagates ? David Newbury: `@descends` ? Rob Sanderson: we can then just update the 1.1 context Benjamin Young: This is pretty ugly, but I think we can make it prettier. Do we use that case anywhere, and you will really need to understand the plumbing to make this understandable. Gregg Kellogg: @propagates +1 Benjamin Young: we’re really going to need a primer. Dave Longley: @propagate: true|[terms] seems ok Benjamin Young: the more we can reduce that cognitive pain…we need something other than reading the spec to explain how this works. Rob Sanderson: there seems to be consensus around @propagate? Proposed resolution: Create a new keyword, @propagate, for type scoped contexts which takes either a boolean (false is default) or an array of terms, which when present means that all or the listed terms propagate the context listed as the value of the keyword (Rob Sanderson) Dave Longley: @propagate “propagates” the type-scoped context as a property-scoped context for all listed terms Gregg Kellogg: we could consider context as an array, and the first item would be @propagate true. This is getting hacky…we’re pulling on a thread and we can’t stop pulling … I’m less in favor of this than making it a property of the context itself. … if it can’t work except this way… … I think this changes the default… … and if you want the next one to be false… … how do you inherit the default again? … these questions are why I’m not happy with these. Rob Sanderson: This could be solved with metadata on the context, but we’ve deferred that conversation Gregg Kellogg: how problematic is it to just refer to it in the context? Rob Sanderson: it means that we can’t include 1.0 contexts, which is not great. Gregg Kellogg: you can still refer to them… Rob Sanderson: for type-scoped contexts, if you want to refer to a 1.0 context, if you want to type-scope them in, you’d need to rebuild those contexts when @Property is a property of the context, instead of the referring context Ivan Herman: Red flag: we were wondering about feature freeze, and we are discussing something here that is not thought through yet, and it’s a long discussion, and it’s practically June … I am worried here. Protected took two months, and we’re approaching the same place. Rob Sanderson: the issue is that Verifiable Credentials have assumed one way, and the spec works the other way, so there needs to be a decision one way or the other … hopefully a solution that works for both. … we can stick with the spec Gregg Kellogg: we can do type scope as committed, and without dealing with propagation, or we can remove the type-scoped property… Rob Sanderson: but that chooses one use case over the other … we need to deal with the competing use cases … or revert back to the previous spec Dave Longley: it doesn’t make the previous use case impossible, just verbose. … the other way around was literally impossible Rob Sanderson: consider schema.org, you’d need to enumerate all terms in schema on each property. It’s possible, but implausible. … a property on the 1.1 context with propagation, and define a 1.1 context, and @propagates : true David Newbury: does this mean that the writer of this context … decides whether it propagates up or down? … wouldn’t that mean the annotations group would need to define two different versions of that context? Rob Sanderson: yes. that is indeed the case … which also seems…not ideal Gregg Kellogg: I think the way to handle this is to set @propagate changes the default to subsequent properties … we could including contexts judicious… Rob Sanderson: the ugly version of a list where there are processing flags and contexts within the context definition … documentable, but not pretty … and order dependent David Newbury: do we have a sense of which of these inheritance models is more common? … at this point it feels like we’ve built in the ability to turn this on or off … or is that not correct? Rob Sanderson: I don’t think that we know … currently, all of the inheritance models are propagate. 1.0, everything does so. … that implies that propagation is more common, but people coming from object-oriented might think otherwise Pierre-Antoine Champin: I’m not convinced by this, but…I don’t think this has been considered. … another keyword for non-propagating contexts? … remove the flag, make it cleaner Rob Sanderson: that does seem cleaner Ruben Taelman: I like the idea, but that might make context even more complicated, but now have two ways to find a context … is feasible, but complicated Pierre-Antoine Champin: Just to be clear, I share that concern. … two keywords for contexts ugly Dave Longley: it could be a keyword on the type definition instead David Newbury: .. and I wanted to point out that considering rob’s example, having @context always propagate, and a separate keyword for dlongley’s proposal Gregg Kellogg: the other thing, considering contexts with metadata, where we had metadata, and that could solve this … then we could set some of these properties… Rob Sanderson: two routes: new keyword, context reference metadata Benjamin Young: 1.0 propagates now, so the default is propagate true. Then what we need is the way to prevent that, and to say that this is exclusive Rob Sanderson: I would be fine with that Ivan Herman: here is the issue where this was discussed: #108 with a syntax possibility at: #108 (comment) … there’s a syntax proposal there Benjamin Young: I see it differently, type-scoped contexts didn’t exist in 1.0 and are a new concept … and scoping “type-scoped contexts” to types makes perfect sense. Ivan Herman: nobody seemed happy at the time with metadata at the time…if this is the only one we define, it allows others…I would not propose integrity now Dave Longley: +1 to providing a future hook Proposed resolution: Un-defer #108 with propogation as the use case (Rob Sanderson) Rob Sanderson: +1 David Newbury: +1 Gregg Kellogg: +1 Tim Cole: +1 Dave Longley: +1 Ruben Taelman: +1 Harold Solbrig: +1 Ivan Herman: +1 Adam Soroka: +1 Pierre-Antoine Champin: +1 Benjamin Young: +1 (with concerns about scope creep) David I. Lehn: +1 Resolution #2: Un-defer #108 with propogation as the use case Rob Sanderson: we should then look at 108 over the week and come up with a proposal for contexts Gregg Kellogg: it might be good if this were done through more detailed proposals in advance Rob Sanderson: so, everyone who’s not on a trip, please contribute to the issue … and it is the top of the hour |
|
My preference would be
|
|
This issue was discussed in a meeting.
View the transcript3.1. Consider context by reference with metadata #108Benjamin Young: #108 Ivan Herman: also: #174 Benjamin Young: This is about a more advanced context object that includes referencing other contexts with meta data for a whole host of issues. Most recent use case is around setting propagation. … Rob you were the last to propose some things. Rob Sanderson: At this point I think we need this particular pattern. Of the proposed colors for the bikesheds, @src seems to convey the appropriate semantics. It’s not necessarily a link/href, @context and @id would make for a lot of overloading that would maybe cause confusion.… @import isn’t too bad but pchampin indicated why it may not be ideal.… It seems to me like a reasonable way forwards, assuming, it’s implementable and unambiguous. Gregg Kellogg: I guess my concern about @src is … one is that we don’t typically use abbreviated keywords in JSON-LD, @source might solve that. The other thing is that my familiarity is similar to href like in HTML where it doesn’t provide for an inline option, if we wanted to allow for those there which would sort of make sense. @import seems a little more unambigious.Pierre-Antoine Champin: Regarding what Gregg just said, I think you have a point, indeed. I wanted to ask about the use cases, I realized after making those proposals, we might not cover one of those. We reactivated this issue about the idea that parameters could be added to this context, to allow this context to propagate/not propagate. Rob Sanderson: Reference: The propagate case - #108 (comment) Pierre-Antoine Champin: For this use case we might want to do this with a URL reference or an embedded @context. Meta data is always about a referenced context not one that is directly embedded. Does that cover all our use cases.Benjamin Young: Good flag to raise. Ivan Herman: It’s very close to what I wanted to ask. I’m not completely sure what we’ll use it for apart from the fact that it looks nice. … There are things like sealed and SRI that came up but we’re not talking about that anymore. What are the use cases we want to use it for? … Btw, ‘src’ is in use for the image URL in HTML, very close to href. Rob Sanderson: I wanted to ask the same question, do we really want to/need embedded contexts here or external sufficient? I don’t know why you would use an embedded one. … If it’s only for reference, @src is ok, but what’s the use case for embedded.Gregg Kellogg: I think we might want to constrain ourselves to a keyword that references an external resource about which we might assert some meta data. Rather than keeping it open about importing several things – which of them are we asserting things about, as well as an embedded case. There’s no use case for that, only some notion of uniformity to allow that. … Now it starts looking overly generalized. If we need a way for a context to reference another one with the semantics that that context is imported into the referencing context that would also allow some room for asserting information about the referenced context, that is a narrow solution which addresses that use case. Rob Sanderson: +1 Benjamin Young: Roughly like what Rob just posted in chat. Gregg Kellogg: In which case @source is ok, want some consistency.Rob Sanderson: Suggested syntax example: {" @context": [{"@src": "http://.../context.json", "@propagate": false}, ...] }Ivan Herman: I must admit that I didn’t even consider having this embedded. Rob would you want to comment … a question I have is are we sure this is the only property? We don’t have any other meta data properties to define in 1.1 so far? Rob Sanderson: I don’t think so, this is the only one we have so far @propagate.Ivan Herman: I’d like to be sure this is the right solution. Pierre-Antoine Champin: Just to be clear, I was not trying to generalize or over generalize, I was just pointing out that as Ivan and Rob pointed out … @propagate is what we unearthed this issue. When I think about it, it makes sense to use it on an embedded context. It started with scoped contexts, most of the time those are embedded.… Is @source really a solution to the problem we were trying to solve?… My personal answer would be “no it’s not” and maybe we reopened the wrong issue to solve that problem. This mechanism as we envisioned it is more about referenced contexts, not embedded ones. Rob Sanderson: I think it is still the right thing to reopen. If it’s embedded we don’t really need this pattern at all. … You could restructure your context to do things differently. … When you want to reuse an external context, then you need to say whether or not the terms of that context propagate or not. … If it’s embedded you just set it and you’re done. … When you pull in another context, like a 1.0 from Annotations, it assumes something that isn’t intended and you need to change it. … I think the case is an external context and it should not have the default propagation value. Gregg Kellogg: If it’s within a type then type contexts don’t propagate. Rob Sanderson: Right and this is to change this behavior so it does. … Yes, it’s to fix the impedance mismatch between 1.0 and 1.1. Ivan Herman: I am a little bit lost. What I would propose is that somebody comes up with text, possibly a PR that defines this syntax so that it’s clear what it is. Defines its usage with propagate and what that means. I’m a little bit lost. Having something specific written down would help. Gregg Kellogg: So I think my confusion is that I recall the discussion about this … as wanting the ability to reference an external 1.0 context where we’d have to have @version specified within there. You can’t update the referenced context to do that.… If that is one of the use cases .. the other use case is to override the propagation behavior of type-scoped behavior. Not sure how it does that cleanly. Not sure how this relates to the type-scoped propagatability without something more explicit. Rob Sanderson: This is the issue that we discussed a couple of weeks ago now. Where, it’s the combination of the 1.0 and the type-scoped context where it really matters. Because 1.0 contexts are defined without the notion of type-scoped contexts or propagation then they’d never be written in such a way that it’s prevented because it’s not possible in 1.0. … When type-scoped contexts gets prevented in 1.1 we need a way to override that for 1.0 and potentially for 1.1. … That would be a useful side effect I think to be able to do that. … The referenced context might be defined without any notion of type scoping at all. … If you want to include it in a way that is compatible with the rest of your constructions which would be propagating or not – you’d want to make sure it was interpreted consistently. Gregg Kellogg: I think there’s a bunch of use cases that need to be considered about what the effect is. Does this include the use of a @propagate keyword or not? In one example – an embedded context that references another one and that includes @propagate: false, is that keyword in play and if not, what are the behaviors?… If you reference a 1.0 context does that change the behavior? … I think we need test cases for what the expected behavior is. Rob Sanderson: I’m happy to write up in the issue in 108 rather than in the propagating one … a proposed syntax and the proposed functionality. Gregg Kellogg: I think part of that functionality is … if I have a context that defines things and it references things as a source, what is the order of processing. Presumably the point is to process @version bits first but can it override term definitions and what’s the effect on language, base, and vocab.… The result sort of considered an atomic context such that if it did adhere to some type-scoping or partial type-scoping behavior, does part of it go away, some of it, those are the things I need to understand. Rob Sanderson: Dave … the propagation point was from VC … what was the expectation? Dave Longley: for external would behave in the same way as external ones would today … the context would only apply to the type … and it would follow property scope behavior … so their should be consistency with how things happen today Gregg Kellogg: Good. … If properties within a type-scoped context, they propagate only if used. Dave Longley: Yes. Action #1: write up proposed syntax and functionality for @src/@propagate (Rob Sanderson)Rob Sanderson: Unless the propagate flag is set to true. Gregg Kellogg: There seem to be two different concerns, one is embedded contexts and the other is propagation. Rob Sanderson: Yes, we’re complicating it. But I don’t think there’s another solution. … We need something like this… the other option is to always propagate but then that’s what wont work for the VC folks. Gregg Kellogg: The other option is to have a type-scoped context that sets propagate to true and then it’s not removed when we go out of the node object. If we have referenced contexts then it’s as if that context were inserted through some process into the referencing one. … Well, what is the effect of property scoped contexts on embedded contexts? … What is the effect of @propagate on property-scoped contexts or referenced contexts.Pierre-Antoine Champin: If I understand correctly, that’s the kind of thing Rob is planning to do. Rob Sanderson: Yes, exactly. Pierre-Antoine Champin: I want to use the original JSON-LD 1.0 annotation context as a type-scoped context, but since it assumes propagation, I want a way to override the type-scoped behavior which is not to propagate. Rob Sanderson: If there is some other way to do that, that’s perfect, totally fine to do that. … I don’t understand how they are completely orthogonal, then we don’t need @source.Gregg Kellogg: I think you need @source because you need to be able to pull in the definitions from an external context so that you can assert 1.1 types of things about it.… I follow that. … I can see that you might use @propagate true on one that doesn’t reference an external source and you use @source because might want to assert things about that context like SRI.… For your use case you need both of these bits but their behavior is … we could create test cases that explore the various different uses and test cases for external referencing, and we should have a test case that combines the two. Largely their impact is orthogonal. Rob Sanderson: I think we’re in violent agreement. Pierre-Antoine Champin: Here’s an idea. The problem seems to come from the fact that you’re trying to use the Web Annotation context in a place where it was not designed to be used. It’s a 1.0 context. There are not scoped contexts, only local ones, no scoped ones. … In a way it makes that it doesn’t quite fit in this position. Wouldn’t a solution be to have a dedicated version of the Web Annotation context that would be appropriate to be embedded as a type-scoped context? … Maybe the solution is not to change the spec but to change the context that you use in this use case? Rob Sanderson: But to go back to the definition of @propagate can we say on an @type, @propagate true?Gregg Kellogg: Yes. Rob Sanderson: If we anticipate that the major schemas that are in use via context referencing… annotations would be one, schema.org etc. … if they are going to go to 1.1 and they can set propagate or not that would be one other way to do it. … It could be defined locally somewhere until they do. But yeah. … It seems a bit of a stretch to say that if you want to use this 1.1 feature then because of this weird rule that type-scoped contexts don’t behave like property-scoped contexts that you can’t use any of the 1.0 contexts. … The flip side would be that @propagate true is the default and then 1.1 contexts that want to turn it off can set @propagate: false.Ivan Herman: How many contexts are we talking about that are really widely known and would have to be updated in this sense? … What are talking about? We are hearing about two or three possible contexts right now, which is just peanuts. Rob Sanderson: I’m not sure that we know, I would say schema.org, annotations, maybe ldp. Ivan Herman: schema.org might not be easy to change, but the others are peanuts. David Newbury: Is it everything that has included those that also have to be updated at this point? Rob Sanderson: Assuming that there’s a different 1.1 context I think that’s ok, you’d reference that. Gregg Kellogg: I think it’s dangerous road to assume that we know the impact of all the contexts that are out there and the solution is to just update those contexts. Particularly if it requires that they adhere to 1.1 and the toolchains don’t get updated immediately after we release the spec. … Maybe the safest thing is to change the semantics to allow the propagation semantics to default to true but allow for false. … It allows that propagate to be used in other contexts as well. I think there’s a use for referencing to be able to do things like that, but you might want to use a 1.0 context and not have it propagate. Then you’d use an envelope with @propagate but then no weird stuff.Benjamin Young: Rolling out your contexts and managing multiple versions is an ambient concern. I don’t mean to derail your conversation. Our smaller more tightly knit communities aren’t going to face this as badly. But any of the ones that are actually doing deployments of other people’s vocabularies are going to be up a creek. … I’m not sure we yet have any vehicle to help them survive. This is taking them to another level, incompatibility concerns. Rob Sanderson: This would be an argument in favor of having the default to be to propagate rather than to not propagate? Benjamin Young: It may not really even matter because of the way we’ve used versioning it doesn’t really matter. … As soon as that gets stuck into anything you will have to shift to supporting two different ecosystems. … We’ll have that for an unknowable amount of time. Rob Sanderson: In terms of the VC side of things, requiring the context to turn off @propagate a hardship?Dave Longley: so, VC spec goes into PR on Tuesday … everyone has written their tests against the context that does not use @propagate false… so that would be the main concern … it’s a major timing issue … if we miss PR, the VC spec would fail … the other features from 1.1 don’t compose … so…it’d be strange to have things not work and then have to go find the @propagate term to make things work… it seems to me that once you pull in a 1.0 context … that’s been interpreted in a 1.0 scenario … folks will have to be ready for the meaning changes … if they’re processed both as 1.0 and 1.1 … I understand the desire to make them play nice … but I’m not sure about what we’d give up to keep that happening Gregg Kellogg: I’d say maybe the way forward is to add a @propagate keyword which changes the behavior of the context it’s in to not survive the node object it’s used within, but we don’t the default behavior for type-scoped contexts. We can add @propagate: true to allow to survive or @propagate: false on a property-scoped or embedded context to allow it to be removed. It gives us the ability to not mess up the expectations of VCs.David Newbury: A lot of the @propagate: true/false default is whether you’re coming from a programming background or a JSON-LD background.Rob Sanderson: What about if 1.0 contexts were treated that all had an implicit @propagate: true on them.… When a 1.0 is imported, all of the classes in that context are treated as if they had @propagate: true defined on them because that was the expectation.Pierre-Antoine Champin: are we taking { " @context": { "Foo": {"@context": { "@propagate": true, ... } } } or { "@context": { "Foo": {"@context": { ... }, "@propagate": true } }Pierre-Antoine Champin: I’m not sure Rob’s suggestion. The difference is subtle – is the @propagate flag supposed to occur in the context or next to the term definition.Gregg Kellogg: Inside the context. Pierre-Antoine Champin: I don’t understand Rob’s position then. Rob Sanderson: The primary mismatch is that between contexts defined in 1.0 days, there wasn’t any scoping, once defined it’s always true. That remains true for property-scopes but not for type-scopes. In 1.1 we want to be able to override that default. We want to be able to have it be explicitly set so a particular class does propagate. … The issue then is … a 1.0 context where it’s not a valid keyword, how can we have propagation be true. Given that the expectation in 1.0 was that everything propagated, that when a 1.0 context is imported, we should assume that there was a flag that propagate was set to true for that context. We don’t have to put it into the referring context – if that was just the way that it always worked. If you want to have a 1.1 context that imports Dave Longley: other contexts with propagate false then that’s fine you don’t have to set anything. Rob Sanderson: It would matter if you want a 1.0 to come in and not have it propagate. … But that seems even more marginal than the inverse. … I don’t think we need @source at all if we do that. We can just define @propagate with the notion that a 1.0 context acts as if it is true.David Newbury: This would need a very big explanation note somewhere because I don’t think anyone pays attention to @version and having things operate differently seems very confusing.Benjamin Young: And the fact that the same context could change its version under the hood changing how it propagates. Ivan Herman: +1 workergnome Gregg Kellogg: I’m concerned about that too and it’s possible to use 1.1 features without saying @version in the context.… Trying to infer things after the fact that we do things differently I think is fraught. I think solution is to be explicit in the wrapper and to set propagation in the referencing context. Ivan Herman: I am acting now as administrator because the minutes will be confusing, I have the impression we’re discussing 174 but started with 108. I would add the comments on both of them, and I’m not sure where we are. … Administratively I think 174 is just being reopened now. Benjamin Young: I think where we are – this will be the topic that we discuss next week and I’ll send out the same agenda. |
|
This issue was discussed in a meeting.
View the transcriptConfirm state of@import usageBenjamin Young: -> #108 Issue 108 Benjamin Young: Request by Rob to state to ourselves to not quickly add more features to @import.Ivan Herman: +1 Benjamin Young: This import issue is closable, as it is in the spec Gregg Kellogg: +1 Gregg Kellogg: This also puts the nail in for SRI? Benjamin Young: Yes … We would defer and close the SRI issue Proposed resolution: close 108 with statement that potentially related SRI issues will be closed as differed (Benjamin Young) Ivan Herman: +1 Gregg Kellogg: Can we close the issue on trig graphs? Ruben Taelman: +1 Benjamin Young: +1 Tim Cole: +1 Gregg Kellogg: +1 Resolution #4: close 108 with statement that potentially related SRI issues will be closed as differed Proposed resolution: close 128 (Ivan Herman) Tim Cole: +1 Ruben Taelman: +1 Ivan Herman: +1 Benjamin Young: +1 Gregg Kellogg: +1 Resolution #5: close 128 |
Closed
gkellogg
added
the
defer-future-version
|
To be consistent with other deferred issues, I've reopened this and marked with the defer-future-version label. |
|
This issue was discussed in a meeting.
View the transcriptIvan Herman: See issue syntax#108Manu Sporny: this is an awareness opportunity Rob Sanderson: so from our side, we’ve pointed to DocumentLoader as the thing that makes the loading stuff work … whatever the format, type, etc of the IRI … this is deferred to a future version because we don’t know if more data will be needed at the JSON-LD document level to express this … What we said is that document loaders should do whatever they can … hashlink or ipfs or something else that enables content integrity. We added @import for future version, if there is interest in putting data into instance graphs/contexts… this particular thing needs a particular SRI value or other, we have a slot that we can provide stuff in @import so you can add something.… The use cases fulfilled by document loader process, if there is need to support this in the future, we want to have support and have support. Manu Sporny: the thing I don’t know is anyone circling a solution? … we’re strongly pushing the hashlink spec as an option for DID and VCWG stuff … for VC’s bad things happen if your context changes … and in our specs, we make the promise that this context will never change … so you download it and put it into your code … but that doesn’t address extensions … which need something like hashlink … all you can do with SRI is to find out you got something you didn’t want … and it requires infrastructure to be setup, etc. … there are two parts of this … in the future we’d like to settle on hashlink as the primary way–in our communities … [demoing hashlink] Dan Brickley: manu, is there a github repo for the conversation you mentioned with J Yasskin? |
|
Given continued discussion on SRI, and with {
"@context": {
"@version": 1.1,
"@import": "https://example.com/context-with-metadata",
"@sri": "sha256-abcd",
"@protected": true
}
} |
|
I think we need to stick to the feature freeze and focus on clearing up the algorithm and We have put the framework in place for the above with |
|
I was only documenting recent design discussions, not suggesting to add a feature for 1.1. It may be useful to have this outline for a hypothetical 1.2 release, or for the CG to munch on. |
|
This issue was discussed in a meeting.
View the transcript3.1. Integrity feature disposalRob Sanderson: #108 Rob Sanderson: from someone on the mailing list working on Ethereum … interested in SRI … gkellogg pointed out that we have deferred this, … but that the @import mechanism offers an extension point.Gregg Kellogg: did he raised a different issue, which I referenced in 108? Rob Sanderson: this was an email on the list. … does anyone feel differently, or should we keep it deferred? Ivan Herman: that’s the only thing that we can do now. Proposed resolution: Continue to defer work on context metadata (syntax #108) (Rob Sanderson) Rob Sanderson: +1 Gregg Kellogg: +1 Pierre-Antoine Champin: +1 Tim Cole: +1 Jeff Mixter: +1 Harold Solbrig: +1 Resolution #3: Continue to defer work on context metadata (syntax #108) |
|
Re
Did this ever get to the TAG review stage? |
|
I find it helpful to link to the prior comment when quoting such, especially when it's ~3.5 years in the past... (I don't know whether the resolution was acted upon.) |
I seem to recall @hadleybeeman involved in discussions about this, probably at an F2F, but I'm not able to find anything from the Fukuoka TPAC F2F, specifically. Generally, my recollection is that we felt that @msporny's hashlink proposal had promise for handling the issue of resource caching and availability more flexibly than something specific to JSON-LD contexts, but that the timing wasn't right for that. Given that the direction most groups have gone on is to create a versioned and unchanging context definition, one route for schema.org would be to freeze a subset of the current context so that it can be made entirely static. Any future changes would need to be done inline in the JSON-LD document itself. An alternative might be to have We have plenty of time reserved in the Upcoming TPAC F2F for the JSON-LD CG, and we should organize a group to discuss the future directions in more detail. |
This comment was marked as spam.
This comment was marked as spam.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On the call of 2018-12-14, we discussed (briefly) #20, #98, and #86. One realization that came out of the discussion was that we currently have two ways to refer to contexts - either by references as a single string (the URI of the context) or by value as a JSON object (the actual context). In order to have in-document metadata about the context, such as asserting fixity such as via the SRI specification, we would need to have a URI with additional metadata about it.
Questions that arise:
For example:
The text was updated successfully, but these errors were encountered: