Re: Representative sample of industry protocols

On 25 October 2016 at 16:02, Dave Raggett <dsr@w3.org> wrote:

> Things can have URLs (or more generally URIs) that act as their names and
> which can be used to access their descriptions.  This is independent of
> which protocol is used to access the platform hosting a thing.
>

In theory, yes. But how many of the protocols you listed actually use URIs?
CoAP has coap:// URLs (although it also arguably has a lot of overlap with
HTTP/2). How do you deal with all the protocols which don't provide URIs? I
assume they need to be bridged to HTTP via a gateway or cloud service in
order to be exposed to "the web"?

I see the Web of things as an abstraction layer above the IoT.  Things are
> named with URIs that can be used to access their descriptions. These
> descriptions may refer to other things, thereby forming a Web of things.
> The thing descriptions allow a platform to figure out how to access things
> hosted by another platform. Thing descriptions play an analogous role to
> HTML for the Web of pages in that they can be downloaded by software agents
> and spidered by search engines (subject to access control restrictions).
>
> For a gateway that hosts one or more things, the gateway itself could
> expose both the thing description and the REST API for accessing things as
> URLs for the HTTP server hosted by that gateway.
>

OK, I'm completely with you so far.


>
> Thing descriptions are more general than representations designed
> specifically for describing REST APIs. This allows us to integrate
>  protocols that are not based upon REST. This is made possible by
> separating the description of the object model exposed to applications
> (properties, actions, events) from the usage of the protocols.
>

I can understand why someone might want to re-use the Web Thing description
format for non-web protocols in the same way that HTML has been used to
create all kinds of packaged (non-web) apps. But I'm not sure why that use
case should be within the scope of the Web of Things Working Group's
charter?

Taking one of the examples you provided, how would you create a meaningful
binding of the WoT interface to ZigBee, which already has its own
established application protocol and data format with defined
domain-specific profiles, hundreds of existing certified products already
using those profiles and (AFAIK) doesn't use URIs? Or more importantly, why
would you try to do that in the first place?

Surely a much more meaningful thing to do would be for a WoT implementer to
create a layer of abstraction on top of ZigBee which gives ZigBee devices
HTTP URLs and exposes a REST/WebSockets API which web applications can talk
to using a web standard format across multiple protocols, but which uses
ZigBee on the back end so as to be compatible with all of those existing
products out of the box? Would that not be a more effective way to create
interoperability?

Ben