Wot-thing-description: Problems translating TDs from JSON-LD 1.1 to RDF and back
In the discovery group we are facing the problem that if we have a TD expressed in JSON-LD 1.1, and we translate such TD into N-Quads (or any other RDF serialisation), then the only way express the N-Quads data as JSON-LD 1.1 with the same structure of the former is by using a frame. The problem is that, I was not able to find any frame in order to perform this operation in the spec, and thus: I can translate JSON-LD 1.1 to RDF, I can translate RDF back to a valid JSON-LD 1.1 serialisation but TDs do not look like the ones in the documentation (or formerly provided by an user).
For the sake of the explanation let's assume this TD, its N-Quad version would be:
<urn:dev:ops:32473-WoTLamp-1234> <http://purl.org/dc/terms/title> "MyLampThing" .
<urn:dev:ops:32473-WoTLamp-1234> <https://www.w3.org/2019/wot/td#hasActionAffordance> _:c14n0 .
<urn:dev:ops:32473-WoTLamp-1234> <https://www.w3.org/2019/wot/td#hasEventAffordance> _:c14n5 .
<urn:dev:ops:32473-WoTLamp-1234> <https://www.w3.org/2019/wot/td#hasPropertyAffordance> _:c14n1 .
<urn:dev:ops:32473-WoTLamp-1234> <https://www.w3.org/2019/wot/td#hasSecurityConfiguration> <https://json-ld.org/playground/basic_sc> .
<urn:dev:ops:32473-WoTLamp-1234> <https://www.w3.org/2019/wot/td#securityDefinitions> _:c14n3 .
_:c14n0 <https://www.w3.org/2019/wot/td#hasForm> _:c14n7 .
_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2019/wot/json-schema#StringSchema> .
_:c14n1 <https://www.w3.org/2019/wot/json-schema#propertyName> "status" .
_:c14n1 <https://www.w3.org/2019/wot/td#hasForm> _:c14n4 .
_:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2019/wot/json-schema#StringSchema> .
_:c14n3 <https://www.w3.org/2019/wot/td#in> "header" .
_:c14n3 <https://www.w3.org/2019/wot/td#scheme> "basic" .
_:c14n4 <https://www.w3.org/2019/wot/hypermedia#hasTarget> <https://mylamp.example.com/status> .
_:c14n5 <https://www.w3.org/2019/wot/td#hasForm> _:c14n6 .
_:c14n5 <https://www.w3.org/2019/wot/td#hasNotificationSchema> _:c14n2 .
_:c14n6 <https://www.w3.org/2019/wot/hypermedia#forSubProtocol> "longpoll" .
_:c14n6 <https://www.w3.org/2019/wot/hypermedia#hasTarget> <https://mylamp.example.com/oh> .
_:c14n7 <https://www.w3.org/2019/wot/hypermedia#hasTarget> <https://mylamp.example.com/toggle> .
Now, if we serialise these N-Quads as JSON-LD 1.1 (regardless the type of serialisation, i.e., compact, explicit, flattern) the JSON-LD 1.1 will not look like the former one.
In order to obtain the same document after the round trip translation, it is required a frame. Is there a frame in the spec?
AndreaCimminoArriaga
All 9 comments
I mentioned this in the TD call today but unfortunately @vcharpenay did not attend. I know we were discussing framing last year, but that was before the JSON-LD 1.1 spec was complete. I think it makes total sense, as part of the TD 1.1 spec, to include an official "framing" specification to allow round-tripping through RDF databases, which is indeed necessary for us to deal with SPARQL queries during Discovery. Perhaps as an appendix to the TD 1.1 spec?
mmccool
on 2 Dec 2020
BTW I should also mention that for canonicalization and signing, we are talking about simply storing the original string value for use when necessary. So the framing does not have to be "perfect", i.e. exactly recovering the input, but it should at least let us output something that can be validated as a TD. It would be ok though if it does things like fill in/suppress things with default values, or render arrays with single elements with/without brackets (regardless of how it looked in the input...), although it would be NICE to align these choices with whatever we decide for canonicalization.
mmccool
on 2 Dec 2020
Converting expanded URLs back into prefixes is tricky, but I assume we would ideally want to re-serialize using "compact" terms and suppressing prefixes for "built-in" TD vocabulary. However, it's probably also ok if the output prefixes are not the same as the ones originally used in the input but are autogenerated (a, b, c, etc), in alignment with the point mentioned above ("perfect" reproduction of the input not being a requirement if we deal with signing by some other means).
mmccool
on 2 Dec 2020
[...] However, it's probably also ok if the output prefixes are not the same as the ones originally used [...]
FYI: I think this might become an issue if anywhere canonicalization is in place since it would simply break any check...
The same applies to expanded vs. compact URLs.
danielpeintner
on 3 Dec 2020
In my opinion, the best way to have a canonical representation could be relying on other deterministic RDF representations, like TURTLE. Bear in mind that even if having a standard frame, such frame will not be applicable if the TD contains terms from other ontologies (like the examples with SAREF from the documentation of the TDs). In those cases a new frame should be defined.
In addition, the current "frame" of the TDs has an internal constraint that is the fact that in the document there can be only one URI as subject (the td:Thing) and the rest must be blank nodes. This is a hard constraint for RDF since two things may refer to the same subject, which in all likelihood would require such subject to be a URI and not a blank node. For instance, in the case of links.
It is important to be sure that we will be able to translate a TD from JSON-LD 1.1 framed as it is now to RDF, and back. Otherwise users may send a payload and received a different representation of the same as result of some operations.
AndreaCimminoArriaga
on 3 Dec 2020
@vcharpenay - Any updates on this?
wiresio
on 2 Mar 2021
I was working more on this issue and found serious problems. For instance, take the following fragment of TD. I simplified the TD for the sake of the example, it lacks of mandatory keys right now, but it servers for the goal of the example:
````
{
"@context": "https://www.w3.org/2019/wot/td/v1",
"id": "urn:dev:ops:32473-WoTLamp-1234",
"actions": {
"status" : {
"uriVariables": {
"p" : { "type": "integer", "minimum": 0, "maximum": 16, "@type": "eg:SomeKindOfAngle" }
}
}
}
}
`````
This TD is translated into RDF as follows:
<urn:dev:ops:32473-WoTLamp-1234> <https://www.w3.org/2019/wot/td#hasActionAffordance> _:b0 .
_:b0 <https://www.w3.org/2019/wot/td#hasUriTemplateSchema> _:b1 .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <eg:SomeKindOfAngle> .
_:b1 <https://www.w3.org/2019/wot/td#maximum> "16"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:b1 <https://www.w3.org/2019/wot/td#minimum> "0"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:b1 <https://www.w3.org/2019/wot/td#type> "integer" .
As you can notice the 'id' is translated into the subject of the TD, and then, this id has the property https://www.w3.org/2019/wot/td#hasActionAffordance that points to my action. However, notice that the name of the action does not appear. Therefore if someone would like to go back to the framed document it will end up in an impossible task, due to the fact that there is no way to know the action name status since it does not appear in the RDF. This very same issue occurs with the events, but it does not with the properties that have in RDF a property describing their names.
Furthermore, if we check the instance pointed out by the property https://www.w3.org/2019/wot/td#hasUriTemplateSchema, identified by _:b1, the same happens with the uri variable names; in the example "p".
This issue is not due to the fact of using JSON-LD 1.1, but due to the fact that TDs are a framed version of regular JSON-LD documents. I think we really need the framing rules, otherwise issues like these shown before will be never identified. In addition, the TDs will never benefit from the RDF and semantic advantages.
Finally, for the sake of validation, the JSON-LD framed document I show is syntactically incorrect (it lacks of title for instance). Nevertheless, in RDF the document is correct since no standard validation mechanism is provided (like SHACL shapes). The SHACL shapes can be computed from an ontology given, for instance using the Astrea service. I think providing the shapes should be considered as long as providing the framing rules.
AndreaCimminoArriaga
on 17 Mar 2021
if someone would like to go back to the framed document it will end up in an impossible task, due to the fact that there is no way to know the action name status since it does not appear in the RDF.
The TD ontology has a term to store affordances' names: td:name. If the transformation to N-Triples doesn't include triples with that property, it is a bug and I'll have to fix the default context.
This very same issue occurs with the events, but it does not with the properties that have in RDF a property describing their names.
It shouldn't be jsonschema:propertyName here but td:name, as for action and event names... Same bug.
the same happens with the uri variable names
Ah, this one is also a bug, and I didn't define any term in the ontology for these. I'll also fix that.
This issue is not due to the fact of using JSON-LD 1.1
It is, indirectly. The feature that allows round-tripping has been added to version 1.1 and there was no implementation of it at the time we released the TD recommendation.
vcharpenay
on 22 Mar 2021
Providing a JSON-LD frame is yet another thing to do. Again, framing was not a recommendation at the time TD became one. I'll have more latitude now to test framing and provide an "official" TD frame.
I'll work on it after fixing all bugs mentioned above.
vcharpenay
on 22 Mar 2021
Related issues
farshidtz
路
5Comments
jmcanterafonseca
路
8Comments
benfrancis
路
8Comments
egekorkan
路
4Comments
kolotu
路
7Comments
Most helpful comment
Providing a JSON-LD frame is yet another thing to do. Again, framing was not a recommendation at the time TD became one. I'll have more latitude now to test framing and provide an "official" TD frame.
I'll work on it after fixing all bugs mentioned above.