thing descriptions

Hi Sebastian,

Perhaps it is worth clarifying what I think W3C can contribute when it comes to thing descriptions.

I distinguish between horizontal and vertical metadata.  Horizontal metadata covers the semantics that is common across a wide range of application domains. Vertical metadata is specific to particular domains, e.g. smart homes, smart cities, smart grids, smart manufacturing and so forth. Vertical metadata should be defined by industry specific groups.  W3C can usefully standardise horizontal metadata that is essential to the web of things framework. I also find it helpful to talk about grouping metadata into semantics relating to things, security and communication.  All three are needed if you want to provide interoperable access across servers.  For example, you need to know which protocols and message encodings a given server supports.

In today’s call you introduced a simple temperature sensor with a location (room 10), units (celsius) and a representation (float).  This can be modelled as a thing property.  A potential description in JSON-LD could be:

{
 “@properties” : {
  “sensor1” : {
   “@context” : “http://example.org/semantics”,
   “role” : “temperature-sensor”,
   “location” : “room 10”,
   “units” : “celsius”,
   “type” : “float”
  }
 }
}

where the context is a URI for a resource that binds the names to URIs in specific Linked Data vocabularies.

W3C could define a default context that is bound to a MIME content type for thing descriptions in JSON-LD. This would have the advantage of reducing the overhead for communicating thing descriptions. This default context would define “@properties”, “role”, “location”, “units”, “type” and “float", whereas “temperature-sensor” and “celsius” would be defined by the example.org context in the above example. Note that example.org is a hypothetical example for discussion purposes.

The Web of Things framework models things in terms of events, properties and actions.  This core semantics enables servers to create local instances of virtual objects in the execution space of application scripts running on that server.  The server hides the details of the protocols, messages and encodings used to communicate with other web of things servers.  An app developer just needs to know the URI for the thing description and once the object has been instantiated, the script written by the developer can listen for events, read the thing’s properties and invoke the methods for the actions it supports.

If there are many sensors, then we would like to avoid repeating the same information over and over again, for instance, the role, units and type declarations in the above example.  We therefore need a standard way to express this that servers can recognise and act upon. 

By default, properties are read-only.  The model can declare that a given property is writable if the thing acts as an actuator, for instance, to set the target temperature for a thermostat.  Note that as the web of things is a distributed system, updating a property may take some time to have an effect, and the application user interfaces may need to reflect that.

The data model for a thing may define simple properties such as a temperature sensor reading, or complex properties such as other things, or data streams. When setting up a thing or a proxy for a thing, the server can identify that it has a dependency on other things, and proceed to set them up accordingly.  In principle, you can have circular dependencies between things, and my NodeJS based server is designed to support that.

A stream property describes a sequence of values. These may be composite, e.g. latitude, longitude and altitude for a GPS sensor. Values may have individual time stamps, or the time for each value could be implicit, e.g. when readings are taken at fixed interval.  Servers can buffer streams to provide applications with access to past data.

Things can have continuously changing properties, e.g. an analog sensor stream for an electrocardiogram.  The same is true for actuation.  Consider a robot on a manufacturing line. The robot has several joints. Each joint is driven by a servo with its own controller. The thing models describe how the servo positions change over time.  Local clock synchronisation is needed to ensure that the servos for all of the joints operate in tight synchronisation. I want us to address use cases for such sensor and actuator streams, and would be happy to provide details when we are face to face in Sunnyvale.  Note that as an Interest Group we aren’t tasked with defining the core metadata for the Web of Things, but rather to build a shared vision through use cases, requirements analysis, and an exchange of ideas based upon implementation experience.

Best regards,

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