AW: [TF-TD] Meeting minutes + TD Tutorial

Hi Dave,

thank you for your feedback. I hope, you had a great vacation. Please find my comments inline.

>I think it is helpful to separate metadata relating to a server from metadata relating to a thing, particularly as a server could >support multiple things, especially on larger servers.

>A data model for your example could look something like:

>{
>          “name” : “MyLED”,
>          “properties”: {
>                     on: {
>                                 “type” : “boolean”,
>                                 “writeable”: true
>                     },
>                     “colorTemp”: {
>                                 “type” : “uint16”,
>                                 “writeable” : true
>                     },
>                     “red”: “uint8”,
>                     “green”: “uint8”,
>                     “blue”: “uint8”
>          }
>}

[SK] For the moment, we should rely on the consensus of the Sunnyvale meeting that includes the metadata, data and the 3 interaction models (property, action, event) which can be described using JSON-LD. In addition, it was agreed on to rely on XSD data types. Doing some optimization is something what we can do after the time of experience with the current TD model with its minimal vocabulary set.
The LED lamp is just a simple example and a sample guideline of how you can transform the characteristics of the LED into the Thing Description. You are right, the “switching on” functionality may be also defined as a property. However, some people also see this as an action (I already had a long discussion about that ;-) ). I think, there will be always cases which both cases fits quite well, however, there will be also some more complex actions (e.g., dimming lights over time).


>Updates to properties are automatically notified and as such don’t require declaration of events.  A previous discussion concluded that notifications of property >updates should be sent after the change has been applied to the device in question. This is needed to allow a user interface to show the user that an update is >pending and later to indicate that the update has been applied. The time lag may be due to waiting for a battery operated device to wakeup and signal it is >ready to communicate.

[SK] I don’t understand the motivation of assuming that updates to properties are always automatically notified. Let me give you 4 examples, where this does not make sense:
1) Let’s assume there is a battery powered client that only wants to request a temperature property of a remote Thing when the client is awake for few seconds before it go sleep for the next 10min. Why should the remote Thing always send a notification to a sleeping client if the temperature is updated? Apart from that we would waste network bandwidth and other resources.
2) Assume you have a property that serves complex data type including 20 data elements and a client is only interested in 1 or 2 data elements in there. If there always a high frequently change of the other 18 data elements then a notification will be always send without any valuable interest of the client.
3) Typically, there will be also some static properties (value is never changed) provided by a Thing, however, which may be not transparent to the clients. It would be wasteful if the clients should always set up an update handler for these kind of properties.
4) If you have a fan-out situation where one client accessing many Things or one Thing is accessed by many clients always transferring the complete status is very inefficient.

So, I think the concrete application or scenario should decide if there is a interest of subscription of a property when there is an update. In addition, a Thing should also decide which kind of its properties should be observable or not (e.g., to avoid example 3).

What is missing now in the current model is a kind of an observable flag in the Property field. Another approach can be that the Event can be defined as a specialization of a Property. What do you prefer?

{
            “protocols” : {
                        “ws” : {
                                   "uri" : "ws://www.example.com:8080/webofthings”,
                                   “priority” : 1
                        },
                        “http” : {
                                   "uri" : "http://www.example.com:8888/webofthings”,

                                   “priority” : 2
                        }
            }
}

[SK] Yes, we should provide this kind of information and maybe additional metadata for protocols. I will update this in the tutorial. Just for my understanding: What is the use case of the prioritization?
For the AP web meeting tomorrow, Johannes and me we want to prepare a protocol binding approach for CoAP and HTTP that can be applied to the thing descriptions.

Best wishes
Sebastian

Von: Dave Raggett [mailto:dsr@w3.org]
Gesendet: Samstag, 22. August 2015 13:05
An: Kaebisch, Sebastian
Cc: public-wot-ig@w3.org
Betreff: Re: [TF-TD] Meeting minutes + TD Tutorial


On 21 Aug 2015, at 13:33, Kaebisch, Sebastian <sebastian.kaebisch@siemens.com<mailto:sebastian.kaebisch@siemens.com>> wrote:

As I mentioned in the last web meeting I set up a tutorial [3] based on the outcomes of the Sunnyvale meeting. There you will find an example how to define a TD for a LED Thing. Please feel free to comment on it and / or realize your own TD for your Things based on the tutorial.

[3] https://github.com/w3c/wot/blob/master/TF-TD/Tutorial.md



Hi Sebastian, I am back from my Summer holiday and catching up with email.

Some comments on [3]

A LED Lamp “MyLED” has following characteristics:
          • supports CoAP and HTTP as application protocol
          • supports only JSON as exchange data format
          • can be switched on / off (ledOnOff) using a boolean value (true=On, false=Off)
          • provides the color temperature (colorTemperature) in unsignedShort; color temperature
can be changed by a client
          • provides current rgb values (red, green, blue) each of them in unsignedByte
          • notifies when color temperate is changed (colorTemperatureChanged)

I think it is helpful to separate metadata relating to a server from metadata relating to a thing, particularly as a server could support multiple things, especially on larger servers.

A data model for your example could look something like:

{
          “name” : “MyLED”,
          “properties”: {
                      on: {
                                  “type” : “boolean”,
                                  “writeable”: true
                      },
                      “colorTemp”: {
                                  “type” : “uint16”,
                                  “writeable” : true
                      },
                      “red”: “uint8”,
                      “green”: “uint8”,
                      “blue”: “uint8”
          }
}

Updates to properties are automatically notified and as such don’t require declaration of events.  A previous discussion concluded that notifications of property updates should be sent after the change has been applied to the device in question. This is needed to allow a user interface to show the user that an update is pending and later to indicate that the update has been applied. The time lag may be due to waiting for a battery operated device to wakeup and signal it is ready to communicate.

The above example assumes that the default context defines short names for common types, binding these short names to the URIs for the types.  We could make use of the XML Schema datatypes where appropriate, see, e.g.

    XML Schema Datatypes in RDF and OWL,  http://www.w3.org/TR/swbp-xsch-datatypes/


I have used a writeable property rather than an action. The idea that some properties are writeable and others are not should be a familiar concept to script developers.  An attempt to set a value for a read-only property would result in a run-time exception.

The protocols supported by a server could be expressed in JSON, e.g. a list of protocols as in:

[ “coap”, “http"]

Another possible representation is as follows:

{
          “ws”  :  {
                      "uri" : "ws://www.example.com:8080/webofthings”,
                      "priority": 1
          },
          “http” :  {
                      "uri" : "http://www.example.com:8888/webofthings",
                      "priority": 2
          }
}

This provides URIs for the access point for each of the protocols along with a numeric priority indicating a preference ordering of the protocols.  In this example, the server supports Web Sockets and HTTP on different ports.  The server suggests using Web Sockets in preference to HTTP where feasible.  This kind of representation lends it self to richer metadata, e.g. what data encodings the server supports for each protocol.

The precise mechanism a server uses to expose metadata on the protocols it supports will vary according to the protocols. For CoAP, it would seem reasonable to use a .well-known location and reference the metadata via a link.

Further discussion is provided at:

   https://github.com/w3c/web-of-things-framework/issues/13


In general, we should aim for simple, short representations as this will enable direct support on constrained devices that have limited memory capacities. It should be straight forward to retrieve a server’s metadata after having discovered the server, e.g. via a thing data model with a property whose value is a thing on that server.

Best regards,

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