JSON-LD: do we need 1.1?

[VladimirAlexiev]

Which features of JSON-LD 1.1 do we need?

• localized context to define shortened prop names ?
• @Sveino mentioned another reason, but I can't remember what it was?

If 1.1 is needed then the context (or instance data?) must declare "@version": 1.1

[VladimirAlexiev]

As a downside of 1.1, it's harder to parse than 1.0. Eg for java: jsonld-java works only with 1.0 and is about 2x faster than titanium that works with 1.1. However, that gap is closing due to current work in rdf4j and GraphDB. The next version of GraphDB will integrate titanium.

Note: I'm not aware of any published JSON-LD 1.2 spec.

[ericstephan]

From a standards perspective (because it takes so long to get communities to adopt new ideas), I'd prefer putting support behind the JSON-LD 1.1. JSON-LD 1.0 is soon to be 11 years old and we discussed the next generation of W3C RDF 1.2 standards will be focused on making enhancements through JSON-LD 1.1.

Having said that I don't think we need to boil the ocean using all of the enhancements of JSON-LD 1.1 because the spec itself offer extensions to JSON-LD 1.1 not breaking changes.

"This specification describes a superset of the features defined in JSON-LD 1.0 [JSON-LD10] and, except where noted, documents created using the 1.0 version of this specification remain compatible with JSON-LD 1.1."

[ericstephan]

Which features of JSON-LD 1.1 do we need?

• localized context to define shortened prop names ?
• @Sveino mentioned another reason, but I can't remember what it was?

If 1.1 is needed then the context (or instance data?) must declare "@version": 1.1

While thinking about this, as a time saver section 1.1 of the specification provides a way to highlight differences between 1.0 and 1.1. https://www.w3.org/TR/json-ld11/#how-to-read-this-document

[Sveino]

I agree with @ericstephan . We do not need to have elaborate use of JSON-LD 1.1, but need to open for the possibility to use features. To support both JSON-LD and GeoJSON DIGIN10-30-LV1_GL.geojson we needed to use v1.1. For schedule (time series) data we might consider supporting JSON and JSON-LD and can then use the same feature.

[Sveino]

We should in our specification state when declare "@version": 1.1 need to be used. In general we should be find with 1.0.

[VladimirAlexiev]

I also prefer 1.1 (let's move with the times!), I'm just saying we should collect requirements why we need it.