Re: [WoT IG] to converge on WoT architecture

Excellent mail Dave, couldn't agree more with all of that!

Indeed, the first part is where do the extensions you mention go: the common "thing" description object, and we need to make sure there's a hot chair for each element that matters (security, etc.).

The model we've been working on (bit.ly/wot-label <http://bit.ly/wot-label>, which we'll share mid-next week in more "clean & organised" format) is designed to natively support many such extensions and I believe provides a consolidated placeholder for those of you working on exactly the things Dave mentions. 

Cheers


> On 22 May 2015, at 14:50, Dave Raggett <dsr@w3.org> wrote:
> 
> 
>> On 22 May 2015, at 12:34, Lynn, James (Fortify on Demand) <james.lynn@hp.com <mailto:james.lynn@hp.com>> wrote:
>> 
>> Vlad/Johannes
>>  
>> Initially I had thought a Web Thing is anything that has a URI and is either a client or server on the web (HTTP or otherwise) , in other words it either sends or receives date, it participates on the web in some fashion. But I don’t know that all devices have a URI – my FitBit does not have a URI as far as I know. What do we want to say about these devices? Perhaps this is what differentiates IoT from WoT?
> 
> It could be given a URI if you want to expose it on the Web for other services to use its data.  In particular, we need the URI for the thing’s description.  We can distinguish between your particular FitBit, and the descriptions of FitBits in general.  I don’t know the details of FitBit, but presume it supports a standard Bluetooth Smart profile plus some extensions.  It would be paired with your phone, tablet or your home hub, and that in turn would host a “thing” as a proxy for your FitBit. There could be further proxies in a chain, e.g. in the cloud.
> 
> We’re informally chatting with people in the Bluetooth SIG about the relationship between the Web of Things and the profiles defined by the Bluetooth SIG. We need a way to define Thing descriptions for such devices, and this in turn involves coming up with URIs that correspond to the identifiers defined by the Bluetooth SIG, e.g. for heart rate.  The WoT is essentially at a layer above that of the IoT.  You could have devices that natively support the WoT, e.g. via CoAP and 6LoWPAN, but it is fine to have devices that require some kind of driver, e.g. on your home hub. 
> 
> A “thing” in the Web of Things needs to have a URI for accessing its description, and for enabling a server (or browser) to create a local proxy for that “thing”.  The description involves several broad categories of metadata, see slide 20 in:
> 
>      http://www.w3.org/2015/05/wot-framework.pdf <http://www.w3.org/2015/05/wot-framework.pdf>
> 
> For instance, how does a server identity the protocol and port to access a thing on?  In my experiments, HTTP URIs are used for the thing descriptions, and Web Sockets for the data protocol.  I am looking at extending this to allow for a choice of protocols, e.g. HTTP, Web Sockets, CoAP, MQTT and XMPP.  If we’re using HTTP, then a server that wants to proxy a thing on another server will need to provide a URI to that other server to pass notifications to for events, property updates and return values for actions.  We also have plenty to work to do on the security metadata, e.g. for access control, and terms and conditions.
> 
> For me, understanding the different categories of metadata is on the critical path to clarifying the architecture, and it would be great to have people contributing on that, e.g. via reporting on work they have done or plan to do. Note that thing descriptions could be hosted on a different device than the thing they describe. This addresses the chicken and egg problem of needing to know communications metadata to talk to devices that spend most of their time asleep, making it impractical to simply ask them.
> 
> Best regards,
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
> 
> 
>