Dealing with prefixed JSON-LD Files

[danielpeintner]

My assumption is that prefixed JSON-LD examples like the following should be valid.

{
  "@context": {
    "wot":"http://w3c.github.io/wot/w3c-wot-td-context.jsonld#",
    "td": "http://www.w3c.org/wot/td#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "sch": "http://schema.org"
  },
  "@type": "td:Thing",
  "wot:name":"echonet",
  "wot:interactions": [
       {
       "@type": "wot:Property",
       "wot:name": "operationStatus",
       "wot:valueType": { "@type": "xsd:boolean" },
       "wot:writable": true
      }
  ]
}

see https://github.com/w3c/wot/blob/master/proposals/td-lifecycle/Echonet_def0.jsonld

It seems the tool expects "wot:name":"echonet" to be "name":"echonet"

et cetera...

[vcharpenay]

First of all, this TD mixes up two things:

• the JSON-LD context (http://w3c.github.io/wot/w3c-wot-td-context.jsonld)
• the OWL ontology (http://w3c.github.io/wot/w3c-wot-td-ontology.owl)

A context is a JSON object that simply defines mapping between strings and URIs. In the reference TD context, strings are mapped to fragments of the OWL ontology, e.g. http://w3c.github.io/wot/w3c-wot-td-ontology.owl#Thing. (See also 3.2.2.1 TD Context - Current Practices.)

An OWL ontology contains logical statements (or axioms) to characterize Things and their Interactions. The TD ontology states for instance that the concept http://w3c.github.io/wot/w3c-wot-td-ontology.owl#Thing must have an associated Web resource (the TD itself) and some interactions available.

Here, wot:name resolves to http://w3c.github.io/wot/w3c-wot-td-context.jsonld#name, which does not exist. Instead, http://w3c.github.io/wot/w3c-wot-td-ontology.owl#name was meant. Besides, there is a small confusion with the namespace td. It points to some TD ontology (which is the right thing) but the URI is outdated.

Thus, this TD cannot be valid.

[vcharpenay]

But... Even if we corrected these mistakes, and submitted the following TD to the validation tool, it would be rejected:

var myTD = {
  "@context": {
    "wot":"http://w3c.github.io/wot/w3c-wot-td-ontology.owl",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "sch": "http://schema.org"
  },
  "@type": "wot:Thing",
  "wot:name":"echonet",
  "wot:isAssociatedTo": [
       {
       "@type": "wot:Property",
       "wot:name": "operationStatus",
       "wot:hasOutput": { "valueType": { "type": "boolean" }},
       "wot:isWritable": true
      }
  ]
}

Why is that?

The approved WG charter states that:

While enabling the use of powerful tooling, the Thing Description will be designed in such a way that even constrained devices can use it. In particular, for basic usages there will not be an explicit dependence on RDF and it will not be necessary for constrained systems to perform explicit semantic processing.

To me, validating this TD would require processing the local context and expanding CURIs, then comparing with the mappings provided in the standard TD context. This can already be thought of as "semantic" processing (or at least RDF processing), which means that some constrained clients could reject this TD if they did not support RDF. So the playground rejects it as well.

On the other hand, as this TD has the same semantics as what one would expect, it can easily be pre-processed. Using some library complying to the JSON-LD API specification, e,g, jsonld.js, one simply needs to run the following to get a valid TD:

jsonld.compact(myTD, "http://w3c.github.io/wot/w3c-wot-td-context.jsonld");

This transformation can also be done online, using the JSON-LD playground.

[danielpeintner]

What would be a good way forward?

• I think we need to differentiate between what are the capabilities of the tool and what belongs to the TD in general
• Should the specification of the TD (Current Practices Document?) make clear what is supported/expected and what not?
• Shall we discuss this and other restrictions in a WoT Call or list them somewhere (I think it is valuable that everyone is aware of restrictions)

[egekorkan]

Is this issue still relevant? @danielpeintner @vcharpenay

[danielpeintner]

I would say yes.

It should not matter whether a tagname uses the default prefix (which may be null) pointing to a context or any other prefix pointing to the same context.