Repository navigation
Consider context by reference with metadata #108
Description
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:
- How to distinguish between a context by value JSON object and a context by reference with metadata JSON object?
- As the version is in the context, and this functionality is only version 1.1, how would we signal the processing requirement - some sort of transclusion within a context that has the version?
- Are metadata properties extensible or fixed in the specification? If they're extensible, we would need some sort of meta-context wherein the mapping is asserted. If they're fixed, we would need to be very careful to accommodate the various use cases otherwise the tendency will be to simply add in new keys regardless and hope for the best.
For example:
{
"@context": [
"https://example.com/context-by-reference",
{"id": "@id"},
{"@version": 1.1, "@context": "https://example.com/context-with-metadata", "@sri": "sha256-abcd"}
]
}
Activity
gkellogg commentedon Dec 15, 2018
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
https://example.com/context-with-metadatain the first place and only really allows you to say that the retrieved context should have the associated hash and fail otherwise.iherman commentedon Dec 16, 2018
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
<link>element:-).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.
iherman commentedon Jan 5, 2019
This issue was discussed in a meeting.
View the transcript
Ivan 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
azaroth42 commentedon Jan 17, 2019
(this issue stems from this resolution: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-12-14-json-ld#resolution3)
iherman commentedon Jan 18, 2019
I realize that the example given in #108 (comment), is different from the issue discussed in #98. Indeed, in #108 (comment) the
"@sealed":"@true"is set by the caller, i.e., by the one who uses the context, whereas in all examples of #98 sealing is done by the called, i.e., the author of the context. I am not sure whether there are use cases for both, in case we do such sealing.iherman commentedon Jan 18, 2019
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...
azaroth42 commentedon Jan 18, 2019
Question arose about sealing
@vocabdefinition or just term definitions, or sealing@contextreferences.gkellogg commentedon Jan 18, 2019
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.
ajs6f commentedon Jan 18, 2019
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?
pchampin commentedon Jan 22, 2019
@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.
iherman commentedon Feb 4, 2019
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 commentedon Feb 7, 2019
maybe by using ETags?
ajs6f commentedon Feb 7, 2019
@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.
iherman commentedon Feb 7, 2019
What about using the hash value, as described/defined by SRI?
simonstey commentedon Feb 7, 2019
@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.
17 remaining items
gkellogg commentedon Aug 7, 2019
To be consistent with other deferred issues, I've reopened this and marked with the defer-future-version label.
iherman commentedon Sep 21, 2019
This issue was discussed in a meeting.
View the transcript
Ivan 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
@importfor 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@importso 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?
gkellogg commentedon Feb 12, 2020
Given continued discussion on SRI, and with
@import, one design might be the following:{ "@context": { "@version": 1.1, "@import": "https://example.com/context-with-metadata", "@sri": "sha256-abcd", "@protected": true } }azaroth42 commentedon Feb 12, 2020
I think we need to stick to the feature freeze and focus on clearing up the algorithm and
@jsondatatype definition that caused the re-entry to CR to be necessary.We have put the framework in place for the above with
@import, and the details can be done in a future release.gkellogg commentedon Feb 12, 2020
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.
iherman commentedon Feb 14, 2020
This issue was discussed in a meeting.
RESOLVED: Continue to defer work on context metadata (syntax #108)View the transcript
3.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
@importmechanism 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)
danbri commentedon Aug 18, 2022
Re
Did this ever get to the TAG review stage?
TallTed commentedon Aug 18, 2022
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.)
gkellogg commentedon Aug 18, 2022
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
https://schema.orgwhich does redirect for JSON-LD context access, to use a 403 to a static versioned context, in which case the ongoing cost would be to satisfy that redirect. Enforcing rate-limited access to this would have the result of getting the purveyors of JSON-LD processing software to follow the Best Practice advice on aggressively caching such contexts, along with the recommendations on HTTP Cache-Control headers when serving the context.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.
SAEED2ALAHMARI commentedon Apr 29, 2023