Re: Representative sample of industry protocols

Sidenote that people inside IETF are kicking around proposals for URIizing
BLE
https://www.ietf.org/id/draft-bormann-t2trg-ble-uri-00.txt

D.

On Tue, Oct 25, 2016 at 11:36 AM, Benjamin Francis <bfrancis@mozilla.com>
wrote:

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