Consider context by reference with metadata

[azaroth42]

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"}
  ]
}

[gkellogg]

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-metadata in the first place and only really allows you to say that the retrieved context should have the associated hash and fail otherwise.

[iherman]

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:

{
    "@context" : [
        "https://...",
        {
            "@version": 1.1,
            "@contextref" : {
                "@url" : ["schema", "https://cdn1.../schema.org", "https://schema.org"],
                "@sri" : "sha256-abcd",
                "@sealed" : true
            },
            "id" : "@id"
        }
    ]
}

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]

This issue was discussed in a meeting.

• No actions or resolutions

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]

(this issue stems from this resolution: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-12-14-json-ld#resolution3)

[iherman]

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]

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]

Question arose about sealing @vocab definition or just term definitions, or sealing @context references.

[gkellogg]

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]

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]

@gkellogg wrote:

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

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]

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:

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.

[simonstey]

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.

maybe by using ETags?