RE: [W3C WoT IG, TF-TD]: Comments on proposals for Thing Descriptions

Thanks for your replies Sebastian and Dave.

See inline below.

Claes



From: Dave Raggett [mailto:dsr@w3.org]
Sent: den 6 november 2015 13:17
To: Nilsson, Claes1
Cc: public-wot-ig@w3.org
Subject: Re: [W3C WoT IG, TF-TD]: Comments on proposals for Thing Descriptions


On 6 Nov 2015, at 08:27, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>> wrote:

Hi all,

On the flight back home from Sapporo I made an exercise to apply a Thing Description, API primitives and CoAP protocol mapping similar to inputs to this IG to the “Remote Health Monitoring” architecture and use case described in https://lists.w3.org/Archives/Public/public-wot-ig/2015May/att-0021/UC_Remote_health_monitoring_system_-_mapping_to_APIs_and_protocols.pdf.


That exercise led to two comments/questions related to TD proposals that have been submitted to this IG. Please excuse me if these issues already have been discussed in TF-TD.

•        If an IoT device initiates communication with a cloud server the device gets a dynamic IP-address and port that the cloud server application can use to send messages to the device. It must be possible to express this in the TD for the device.

Why?  The IoT device needs to know the URI for the cloud server, but this could be embedded in the application logic for things hosted by the IoT device. The code would use a registration API (to be defined) to set up a proxy on the cloud server for the thing hosted by the IoT device. The URI would imply the protocol to be used. The registration process would result in the cloud server discovering the IP address and port exposed by the NAT box for the IoT device.

[Claes] Yes, this is exactly how it works in the prototyping we have done. So in this case the metadata URI fields for the IoT device thing would not be used. Set to “”?


•        For inputData and outputData I have only seen the data type expressed. How should value range be expressed? For actions the name of the inputData/outputData also have to be stated so that it is stated what the data is used for.

This is a matter of fleshing out the vocabulary for thing data models. Note we don’t have a single approach for thing descriptions as yet, so the precise details will depend on who you talk to. In my case,   it is easy to use a JSON object for additional metadata, e.g.

{
                      “@context” : “a uri for binding names to an ontology”,
                      “properties” : {
                                            “temperature”: {
                                                                 “type” : “float”,
                                                                 “min” : 0.0,
                                                                 “max” : 100.0,
                                                                 “units” : “celcius"
                                            }
                      }
}

For a property named “temperature” that is a floating point value in the range 0 to 100 and measured in Celcius. In principle, the unit of measure could be left out here, assuming that it is instead attached to metadata for the semantics of the property. This makes sense if the IoT device doesn’t need to dereference the context links. Hubs and cloud based servers could deference the context links and perform the corresponding interoperability checks, e.g. when composing services.

My preference is to avoid requiring the communications metadata as part of the thing thing description, given that servers will support protocols across the things they host, so that it is preferable to state the server metadata once rather than duplicating it in all of the thing descriptions.

[Claes] Ok, thanks for this example Dave. I understand that these are details that will be fleshed out when the work continues in this IG and the upcoming WG.

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