AW: thing descriptions

Hi Dave, 

thank you for your mail and for your contributions. See my comments inline.


>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.

I'm agree on and that is also the view which we have in the TD task force.
 
>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 idea of the model is to have a more abstract understanding what we would see in the TD. Your concrete sample actually match so far perfect to the model that I have presented yesterday: You indicate both, the description for identification (sensor1, role / context, location) and data (type, unit, etc). However, some questions arises: How do you describe complex types (e.g., a set of 10 nested different values with different kind of types (int, float, date, etc.)). And how do you describe the parameters of a function of an actuator?


>The Web of Things framework models things in terms of events, properties and actions.  

Agree, in the next TD model version this will be taken into account. 

>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.

This may be true if you only consider Thing to Server / Cloud / Browser scenario. However, we should also consider the Thing2Thing interaction and resource constrained devices (e.g., microcontrollers). E.g., how would a plug & play scenario look like if we have one lamp in a room and you will install a new switch in that room. What is required at the semantic level to orchestrate both tings automatically?

>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.

I think we will have both, static and dynamic semantic properties. Static will be, e.g., the brand name and product id. Dynamic properties can be, e.g., location and date of last maintenance. 


>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.

See my comment above related to direct Thing2Thing interaction. 

>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.  

I'm looking forward to seeing more details about this.

>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.

Well, as you mention above we should at least agree on the 'horizontal' semantics in combination of an abstract TD model to give all the implementation a good common direction. 

Cu
Sebastian

Received on Thursday, 9 July 2015 10:41:53 UTC