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

Hello Dave,

Just a comment below on defining priorities for protocol.

Regards
Louay
Von: Dave Raggett [mailto:dsr@w3.org]
Gesendet: Samstag, 22. August 2015 13:05
An: Kaebisch, Sebastian <sebastian.kaebisch@siemens.com>
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
            }
}

[Louay] I prefer to use array where first element has the highest priority like this:
[
                {
"protocol": “ws”,
                               "uri" : "ws://www.example.com:8080/webofthings”
                                               },
                {
"protocol": “http”,
                               "uri" : "http://www.example.com:8888/webofthings"
                }
]

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