Should we stick to the JSON-LD specification ?

[maximelefrancois86]

This is a follow up of discussion in issue https://github.com/w3c/wot/issues/259

I see the following advantages in proposing just a pure JSON syntax for Thing Descriptions, along with simple rules to transform a thing description to RDF,

• it is very probable that the JSON thing description will lighter than if we stick to JSON-LD, and moreover more natural to web developers;
• it will be a relief for Semantic Web members of the group to not having to manage in parallel:
  • the specification of the WoT ontology;
  • the maintenance of a JSON-LD context; and
  • to ensure any JSON thing description is indeed properly interpreted as RDF conforming to the WoT ontology.
• one may go further and define a JSON Schema that Thing Descriptions should validate against, Although this might prevent the extensibility of thing descriptions, it would surely ease the support of Thing Descriptions in constrained devices;
• there exists several formalisms one may use to define the interpretation of a JSON document as RDF, among other RML, XSPARQL, SPARQL-Generate;
• there exists at least one formalism one may use to generate a JSON document from RDF, STTL, aka SPARQL-Template.

One of our current research topic is actually precisely to define such equivalences between an ad-hoc format (e.g., the Thing Description in JSON), and RDF. Our proposal is called RDF Presentation and RDF Presentation negotiation, you may want to check out: https://w3id.org/rdfp/

[vcharpenay]

• it will be a relief for Semantic Web members of the group to not having to manage in parallel:
  • the specification of the WoT ontology;
  • the maintenance of a JSON-LD context

We are using a tool to generate the JSON-LD context from the ontology: owl2jsonld. Besides, I'm not convinced it is much more difficult to maintain consistency between JSON-LD and RDF than to maintain an RML spec for some JSON document.

JSON-LD has a few advantages we should not forget:

• it is a well-adopted standard that specifies useful details such as URI resolution or type coercion
• there exists many implementations of JSON-LD processors, notably in Javascript, which allows manipulating a TD in the browser

• one may go further and define a JSON Schema that Thing Descriptions should validate against, Although this might prevent the extensibility of thing descriptions, it would surely ease the support of Thing Descriptions in constrained devices

Having a JSON schema for TD was also part of the plan. We are currently using one for TD validation in our Thingweb implementation. Parts of a TD the schema is not aware of (such as "semantic" annotations and extensions) are simply ignored.

A TD should always be interpretable as plain JSON. This is a clear WoT requirement. JSON-LD allows that and, in combination with a "standard" WoT context, it also offers an efficient way to move to the RDF representation of a TD when needed.

Anyway, as Antoine Zimmerman mentioned in the mailing-list, we might want to focus first on a model (in Turtle) and think on a JSON serialization only after this model is stable. That said, have you tried any of the tools you mention on Dave's example (#259)? Could we see the result?

[maximelefrancois86]

Please understand I don't want to really push forward the idea of dropping JSON-LD. I don't mind. But some people say we should. So as a group, we should discuss the pros, cons, alternatives, and take a well motivated decision.

I'm very well aware of the benefits of using JSON-LD also, but I know its limits with respect to the flexibility of the description.

Besides, I'm not convinced it is much more difficult to maintain consistency between JSON-LD and RDF than to maintain an RML spec for some JSON document.

An RML mapping or SPARQL-Generate rule can be written at any time, it enables to decouple totally the design of the TD RDF model and the design of the JSON TD format.

Anyway, as Antoine Zimmerman mentioned in the mailing-list, we might want to focus first on a model (in Turtle) and think on a JSON serialization only after this model is stable. That said, have you tried any of the tools you mention on Dave's example (#259)? Could we see the result?

We actually designed SPARQL-Generate and implemented it on top of Jena. Show me an input JSON and the requested output RDF and I'll write the query.