should JSON-LD 1.2 support RDF 1.2 basic ?

[pchampin]

The current charter says that JSON-LD 1.2 will focus on errata, and that JSON-LD 1.3 will align with RDF 1.2.
The rationale was that RDF 1.2 adds complexity for the syntax, because of triple terms.

A middle way could be to align JSON-LD 1.2 with RDF 1.2 basic, i.e. RDF 1.2 without triple terms. The only other major change between RDF 1.1 and RDF 1.2 are directional language strings, which JSON-LD already supports, so this would be almost free, and at least new JSON-LD would not rely on a subsumed version of RDF.

Concretely, what would need to change is a new possible value for rdfDirection, rdf-1.2, which would be the default value, and would lead value objects with @direction to generate directional language strings.

[pchampin]

@BigBlueHat @iherman WDYT?

[iherman]

I am sorry I missed this. Quite obviously, a big +1 for me.

[rubensworks]

The only other major change between RDF 1.1 and RDF 1.2 are directional language strings, which JSON-LD already supports, so this would be almost free, and at least new JSON-LD would not rely on a subsumed version of RDF.

I can confirm. In my implementation, this change was trivial: rubensworks/jsonld-streaming-parser.js@bd5094f#diff-689b3670b8c0042800b260a18e2b6e73f09d6283172931028f38e17ecd996597

[akuckartz]

Maybe this is the wrong issue, but it is irritating when JSON-LD X.Y is not aligned with RDF X.Y as JSON-LD is a serialisation of RDF.

[anatoly-scherbakov]

@akuckartz it was a matter of discussion at some point, and the matched versioning was considered. Trouble is, that would make the release schedule more difficult to manage. You can't release a new version of JSON-LD unless the corresponding version of RDF hasn't been released.

Or, we'd have to do JSON-LD 1.1.1, for instance, which can be done but is a bit more cumbersome.

[davidlehn]

Maybe this is the wrong issue, but it is irritating when JSON-LD X.Y is not aligned with RDF X.Y as JSON-LD is a serialisation of RDF.

How is it irritating? What can we do to help with that? Maybe improved compatibility docs?

It's impractical to lock versions since specs related to RDF need to evolve on their own.

[akuckartz]

How is it irritating? What can we do to help with that? Maybe improved compatibility docs?

People who are not well aware about the content of the specifications might wrongly assume that JSON-LD 1.2 is a serialisation of RDF 1.2 (similar to N-Quads, N-Triples, TriG, Turtle, XML - and previous versions of JSON-LD).

Maybe "JSON-LD 1.2 basic" would mitigate that (but probably have other problems).

[iherman]

How is it irritating? What can we do to help with that? Maybe improved compatibility docs?

People who are not well aware about the content of the specifications might wrongly assume that JSON-LD 1.2 is a serialisation of RDF 1.2 (similar to N-Quads, N-Triples, TriG, Turtle, XML - and previous versions of JSON-LD).

Maybe "JSON-LD 1.2 basic" would mitigate that (but probably have other problems).

... and is a short term solution only. The review cycle of RDF is different (for good reasons) than JSON-LD. Even if we get things right in this round, we can be sure that it will go wrong in a few years again...

[azaroth42]

+1 to implementing RDF 1.2 in JSON-LD 1.2

[TallTed]

Part of the challenge here is that the JSON-LD 1.2 specification is being produced by the specifically-focused JSON-LD Working Group (WG) (as were the previous JSON-LD specifications), and not by the distinct RDF & SPARQL WG that is producing most if not all other RDF 1.2 serialization specifications.

While JSON-LD is meant and was designed as a serialization of RDF, it has evolved distinctly since its beginning, and even JSON-LD 1.0 was a serialization of RDF 1.1, just as JSON-LD 1.1 was, and just as JSON-LD 1.2 has been built to be.

Pulling the JSON-LD 1.2 (or 1.3) specification into the RDF & SPARQL WG would at minimum require a rechartering, and I believe it would extend the already protracted work, of the latter WG.

While I sympathize with those who do not read the specifications with care and belatedly discover during testing or deployment that the JSON-LD version numbers are not synchronized with the the RDF version numbers, I do not think that this synchronization is possible with the currently in-process specifications.

[azaroth42]

@TallTed I don't think anyone is proposing pulling this group and work into the RDF/SPARQL WG?

The version numbers are a red herring IMO. The importance is to ensure that there is a usable JSON based representation of RDF 1.2 without waiting for another 5 years, and similarly I would anticipate that implementers will look at JSON-LD 1.2, realize it doesn't have what they need for RDF 1.2, assume that it will be coming, and not implement JSON-LD 1.2. Worse, that might lead to a decreased implementation of RDF 1.2 for organizations that rely on the JSON-ness of the format.

[TallTed]

@azaroth42 — I raised "pulling this [JSON-LD working] group and work into the RDF/SPARQL WG" as a path that might allow for full alignment of JSON-LD 1.2 with RDF/SPARQL 1.2, with simultaneous release of all these, albeit at a cost of extending the time until completion of any of these specifications, and a rechartering of one if not both WGs.

It might be that we (the RDF/SPARQL WG) could add some note(s) flagging that JSON-LD 1.2 does not (yet) correspond to RDF 1.2, and that we anticipate the in-process JSON-LD 1.2 or the as-yet-unchartered JSON-LD 1.3 to bring that full correspondence with RDF 1.2.

I believe that is the best we can offer at this point, without disrupting the work of both the current JSON-LD and RDF/SPARQL WGs.

If you have any new suggestion which has not already been made and decided against above (or elsewhere), that would be great. Regrettably, I don't see any benefit from continuing to rehash the same points.