WoT Types with thanks to Ganesh

Ganesh Ramanathan posted some interesting points to github, see:

    https://github.com/w3c/wot/issues/119#issuecomment-219436032

I thought it would be worthwhile surfacing this on the main IG list to encourage a broader discussion.

Ganesh looked at potential problems in modelling the types used in protocol specifications like BACnet, KNX, and LonWorks. Some of the features he discusses are as follows:

The role of bit vectors, e.g. for flags
String values with a specific meaning and format, e.g. IP and email addresses
Enumerated values
Whether a collection is a set, sequence or bag
Actions that return files in a particular format that is not JSON
Type inheritance for complex types
Property values that refer to other resources
Stream types
We should separate how these can be modelled abstractly,  in RDF e.g. in OWL, and how they can be represented in a serialisation format like JSON-LD.

Here are some comments on the above. 

Bi vectors can be seen as a platform choice for internally representing a set of boolean properties. Bit vectors are also useful for efficient message encodings. This also makes me think about the potential for representing sparse vectors.

For string values with a specific meaning and format, it is tempting to consider regular expressions, but these are rather expensive for resource constrained devices. We can easily state that a given property is an email address (for instance), and introduce regular expressions as part of the domain model for evaluation on more powerful devices.

I think it is worth supporting enumerations as part of lightweight data models that can be applied by resource constrained devices.  Note that on such devices it is better to avoid having to dynamically store strings given the limited amount of RAM. This is where it is desirable to replace strings by symbols that take much less space to store and transmit.

I would like to look at the use cases where an IoT device needs to know the distinction between sets, sequences and bags. This is not a problem at the RDF level though.

For actions that return files, we should distinguish between what is exposed through the API to applications, as compared to what is used over the network. For the API, a file would look like a stream. For the network, IETF content types could be useful.

Type inheritance also relates to templates and domain models.  It further brings in the issue of overriding the inherited types, something can be at odds with the open world hypothesis for RDF.

Properties that refer to other resources include the role of things as first class types, as well as the potential for late binding of types.

This is hopefully the first of many studies of how we can include IoT platforms of different kinds within the Web of Things.  Whilst it is tempting to straight away dive into how to represent types and platform bindings in JSON, we should do our best to do the analysis at multiple levels: types and APIs for applications, the abstract messaging level, and the bindings to specific protocols and platforms.


—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>