Thing Description for existing data sources

Hi all,



I have been recently trying to design a Thing Description for existing IoT data, within the frame of a European project called BIG IoT (http://big-iot.eu/). I wanted to share with you the conclusions I drew from that exercise. In general, it made me think the current version of the TD model is still rather limited, I expose here the features I missed.



The data consists of measurements collected in the region of Piedmont, Italy and exposed by an open-source cloud platform called Yucca. See e.g. https://userportal.smartdatanet.it/userportal/#/dashboard/stream/quadrante/2d5dbb35-9565-4eaa-cdfc-0fb9aa04e296/TrFl. The platform has a RESTful interface and uses the OData framework. Streams and datasets are modeled as resources, associated with standard query parameters and specific serialization formats.



1.     Modeling of data stream
The API is designed in such a way that streams are modeled as collections of single events (this had been debated on this mailing-list), each having an identifier (a URI). One can either access the events individually (the measurements) or access the stream as a whole (the collection). Obviously, the TD should contain an Event to describe a measurement. But in the same time, the collection that would normally act as the Event also returns data and can be seen as a Property. I guess this measurement pattern is pretty common. It is even captured in the SSN ontology (where measurement is called observation). How to deal with that?

2.     Query parameters
A proposal has just come up for dynamic query parameters in the group: https://github.com/w3c/wot/tree/master/proposals/resource-parameters. OData specifies some standard parameters like  "filter" or "orderby". It would be great to have these in the TD model. See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-protocol/odata-v4.0-errata02-os-part1-protocol-complete.html#_Toc406398291.

3.     Value type definition (I)
OData defines its own schema language (CSDL). Although I could translate the schemas the platform uses into JSON Schema, I doubt this is can be a long-term solution. Moreover, it would require for all data providers to re-engineer their data models. I would advocate instead that data type definitions should be outside of a Thing Description. Here, all schemas are hosted by the platform: WoT devices could actually do the same. Value types would then just need to contain the local URI of the type definition and its schema language. This way, no cloud connectivity is required for a client to retrieve. A JSON serialization of the type definition is also not mandatory anymore. One could use Relax-NG, XML Schema or even CSDL. This is the simplest solution I found to re-use existing value types declared by the platform.

4.     Value type definition (II)
This solution still need to be refined. For instance, CSDL is formalized in XML Schema, which means one could theoretically parse any SCDL document with the sole knowledge of XML Schema. Which schema language is it better to declare? CSDL (more efficient but too specialized) or XML Schema (more generic but resource-consuming)? Should the decision be left to the implementer of WoT software?



What are your comments on all that?



Regards,
Victor Charpenay

Siemens AG
Corporate Technology
Research and Technology Center
CT RTC NEC ITH-DE
Otto-Hahn-Ring 6
81739 München, Deutschland
mailto:victor.charpenay@siemens.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322