how to set "@version" for a list of contexts?

[bertvannuffelen]

I would like to specify for a list of contexts

{ "@context": ["http://domain1.org/context1.jsonld", "http://domain2.org/context2.jsonld"]}
...

the version of the processor.

It seems that "@Version" is only defined in case an expanded context is used. And that the above reuse case is not supported.

kr,

Bert

[bertvannuffelen]

After reading the spec again I found a note that suggested the following

{ "@context": [{"@version": 1.1}, "http://domain.org/context1.jsonld", ... ] , ... }

however the playground-dev does not like it. It complains with

jsonld.ProcessingModeConflict: @version: 1.1 not compatible with json-ld-1.0

Is this an issue in the spec or the deployed tools on the playground?

[BigBlueHat]

@bertvannuffelen make sure you're using the 1.1/dev playground: https://json-ld.org/playground-dev/

The link to that is probably too subtle...

This example works fine there, fwiw:

{ "@context": [{"@version": 1.1}, "http://schema.org/" ] , "name": "me" }

However, that same code works fine in the 1.0 playground also.

Do you have a complete example you could post?

[gkellogg]

@bertvannuffelen In the past, such an error was generated, and you would only see this error on playground-dev. The playground should be updated, and at this point, I think the default playground should be for the 1.1 work, to avoid confusion.

cc/ @davidlehn

[bertvannuffelen]

Hi,

here is an example which generates the error:

{ "@context": [
              "http://schema.org",
                               
              { "@version": 1.1,
                 "creatie":{
			         "@id":"http://www.w3.org/ns/prov#qualifiedGeneration",
			         "@type":"http://www.w3.org/ns/prov#Generation"
                                  
                }}],
                
                
   "@id": "http://exampledomain.com/123",
   "creatie": {
    "tijdstip": "2002-01-11T15:25:22Z"
    
              }
}

I run it on the dev playground.

The example also illustrates a possible unwanted side effect when reusing external context files which are not in your control.

Suppose the client is running an engine capable of version 1.1, but defaulting to version 1.0 intepretation.
The first external context in the list has not specified a version, therefore the engine will interprete this under 1.0.

Based on that interpretation, the client draws some conclusions.

Then the external context file is updated with the annotation version 1.1 (no other change).
The client as it is capable to handle version 1.1, it will perform 1.1 interpretation now.
And it might lead to another conclusion.

Although nothing has changed in the code, and all input has been accepted by the client, such change might pass unnoticed for a while.

kr,

Bert

[gkellogg]

As I said, the dev playground is out of date. Try it on my distiller where it works properly.

Although nothing has changed in the code, and all input has been accepted by the client, such change might pass unnoticed for a while.

Yes, we considered this; originally, 1.1 needed to be set in the first context encountered, but that proved problematic. The main things that would be interpreted differently is if a term can be used as a prefix, which has very subtly different rules. Otherwise, it should do no harm. Was there some specific misinterpretation you had in mind?

[davidlehn]

I'm not sure the latest jsonld.js will fix this. My latest development code still fails on the expansion tp001 and tp002 tests. I think I looked into it and had difficulty figuring out the fix. I'll take a look again soon.

[gkellogg]

For this issue, it should just be relaxing the version check. Now, you can move from 1.0 to 1.1, where before it was an error.

[azaroth42]

Thanks Bert! I think the description around multiple versions could be added under https://www.w3.org/TR/json-ld11/#json-ld-1-1-processing-mode for greater clarity and visibility, thus an editorial issue.

[bertvannuffelen]

@ all, thanks for picking this up.