7.2 Transformation to JSON-LD & RDF seems unnecessary

[msporny]

The entirety of Section 7.2 Transformation to JSON-LD & RDF feels unnecessary for at least one of these reasons:

• Developers often go from JSON/JSON-LD to RDF, rarely in reverse. If they do go in reverse, they pick and choose the RDF and output some simple JSON/JSON-LD. Having an algorithm to go from RDF to JSON has never been needed in the other specs/deployments using JSON-LD AFAIK. So, the fact that you're in unchartered waters here is a sign that something is off.
• If you do the JSON-LD Mapping correctly, you often never have round-tripping problems, so if you need such a complex algorithm, it's probably a sign that your data model is funkier than it needs to be.
• You may want to take a look at JSON-LD Framing as it was designed to enforce layouts in ways that JSON developers like and some systems require when processing JSON-LD documents using simple JSON processors and hard coded Javascript object paths.

I suggest an immediate review by the JSON-LD WG for the spec as there are a number of areas in the specification that could benefit from their input, AFAICT.

[vcharpenay]

Thank you, @msporny, for your review and apologies for not attending today's call. Looking back at the section, it deserves further case. Yet, I don't think we should completely remove it from the spec.

Developers often go from JSON/JSON-LD to RDF, rarely in reverse.

The algorithm presented in Section 7.2 is a transformation from JSON to RDF, not the contrary. The main use case is the integration of TD documents with contextual info in a large RDF store. I can remove references to the "bidirectionality" of the transformation. We haven't tested it in fact.

If you do the JSON-LD Mapping correctly, you often never have round-tripping problems

Is there a way to keep @index keys when transforming to RDF? This is our main problem, in fact. We suggested to index by IRI instead, to keep index values in the RDF graph, but it comes with other issues like custom @base values.

[sebastiankb]

In tomorrow's TD web conference we should discuss the new option that @msporny was recommended to us:

1. going back and claim the usage of JSON-LD 1.1 style again as we had for the Lyon f2f meeting (https://www.w3.org/TR/wot-thing-description)
2. Section 6 will be described in non-normative section, however, comes with a note "This section will be normative once JSON-LD 1.1 spec becomes REC"
3. Replace the current 7.2 Section with this kind of section again https://www.w3.org/TR/wot-thing-description/#note-jsonld-processing + explain the expected features which will be implemented in JSON-LD 1.1 soon (e.g., id path systems)

Pro:

• we can remove the @context and @type in the TD model
• TD will be kind of aligned with JSON-LD 1.1, not an own TD format must be specified
• some assertions can be removed such as the colon : usage

Con:

• some efforts to change the TD spec back, however, should still be reasonable

Something else?

[vcharpenay]

To add to the Con list:

• To my knowledge, there is no way to keep @index values in RDF, which makes the whole transformation process to RDF not bidirectional.

The bidirectionality of the transformation is important for serving TD documents from the Thingweb Directory. Of course, I can live without and implement something non-standard to fit the Directory's needs but I do think it is a good practice to make every bit of a TD identifiable. I would thus suggest to keep this section, at least for the JSON Pointer part.

[vcharpenay]

A side note:

some assertions can be removed such as the colon : usage

This assertion may remain in the spec, I think its main purpose is to simplify the implementation work and avoid confusion with standard terms. It is not exactly a JSON-LD limitation.

[sebastiankb]

also see discussion within JSON-LD 1.1 repo w3c/json-ld-api#65

[takuki]

During 3/1 Thing Description TF teleconference, in order to hedge against potential risks, the TD TF noted we should probably keep this section.

At the same time, the followings were suggested.

• Make a note saying we have intention to have JSON-LD 1.1 conformance.
• Move the section to Appendix. (Currently it is in the main body of the TD draft specification)

[vcharpenay]

You'll find a transcript of our discussion with the JSON-LD group here.

In summary: the feature we were asking for will be added to the JSON-LD syntax spec in the coming weeks (first as a draft).

[sebastiankb]

TD spec was updated by @vcharpenay and introduced the usage of JSON-LD 1.1 as serialization option.

Please review.