[TF-TD] mapping to RDF #283
Description
I've implemented an online testbed for translating thing descriptions to RDF triples. Note that this demo uses the JSON based format I have been exploring in my NodeJS project and differs from the one given in the current practices.
The idea is to describe the object model exposed to applications in a way that should be easily understandable for web developers, and which also provides a straightforward mapping to RDF. It is emphatically not a goal to be able to express all the richness of RDF. This simplifies the format compared to JSON-LD. You can link to rich semantic models expressed in other formats, but this isn't something that constrained devices need to retrieve and interpret.
Context declarations using "@context" map short names to absolute URIs and can be given as a link to a file or inlined directly. "@context" declarations can be given at multiple level, and the inner scope overrides definitions in outer scopes. You can define a term as null if you want it to be translated as a string literal and need to block inheritance from outer scopes. Re-usable type declarations can be defined with "types", see the "ECG+Accelerometer" example.
One open question is whether the names of properties, actions and events can be mapped to URIs via @context or whether it is safer to leave the binding to semantic terms to separate declarations, for instance, by metadata asserting that this model conforms to some semantic model.
I think that it is reasonable to assume that properties are writeable by default. You can indicate that a property is readonly using "writeable:false". The "latency" metadata term defines the expected interval between updates, and can be used together with the "source" metadata that gives the URI for the source of a stream of updates, see the "ECG" demo. The "sink" metadata term is used where the application streams updates to a thing or to a property of a thing. We also need a term for a URI that acts as both source and sink, any suggestions? The "protocol" can be used to provide additional information, e.g. for how to use web sockets or server sent events.
The "Color choices" example in the demo illustrates how to support arrays and choices. A set of choices is defined as a list of values. Likewise, for unions as a list of types, something which could be useful for late bound types. Note that choices are unordered unlike enumerations which strictly speaking are usually defined as an ordered set of choices. See "Shopping basket" for the example illustrating unions.
Google's Protocol Buffers provide a text based schema format for messages. Each field (and enumerated value) is associated with a unique integer. This allows servers to support different versions of messages through the use of different integers to identify different interpretations. Do we need to allow these numbers to be explicitly provided as part of thing descriptions? In principle, thing descriptions could be mapped to protocol buffer message schemas for events, property updates, action requests and responses. The field numbers could be generated automatically. A comparison of thing descriptions could allow a processor to work out when the protocol buffer field numbers can be re-used or when new values are needed because the meaning is different. This suggests the need for modelling a sequence of versions of a thing or set of things.
More generally when there is a need to define thing descriptions for existing services, it may be appropriate for the thing description to link to a schema for the given service, using a platform specific schema language. This may entail the need for compound identifiers such as paths, e.g. when mapping a thing property to a resource path on a REST based server.
Some programming languages allow multiple versions of the same function name with different signatures (number and types of arguments), but other languages like JavaScript do not, so such declarations would cause problems in generating the corresponding object. The JSON representation for actions uses an object rather than an array to avoid this problem.
The current translation doesn't represent the ordering of arguments for action requests and responses. Given that arguments are named this isn't critical. However, arguments may be assigned a a unique integer number using the metadata term "number". This would allow for passing arguments based upon their position. Arguments can also be marked as required or optional (e.g. "required":true). Should the default be required or optional? Default values can be declared if needed for optional arguments. Arguments can also be marked as ordered or unordered collections.
Types can be declared and referenced multiple times, however, I am not quite sure how to model this accurately in RDF. For now I state that the given type is a subclass of type.
In principle, the representation could adopt further features from JSON-LD, but perhaps not in the first version.
- @base URIs for resolving relative URIs
- compact URIs, e.g. x:foo, where x is defined in a context as a URI
- @vocab within @context declarations
The demo is available at: https://www.w3.org/WoT/demos/td2ttl/
p.s. the demo currently generates RDF as either N-triples or JSON-LD. Future work is planned on support for Turtle. Note that I have deliberately used example.org and example.com for the context declarations as a way to indicate that these are for example purposes only. They would need to be replaced by whatever standard URIs the Working Group agrees to.