AW: Representative sample of industry protocols

On 25 October 2016 at 16:02, Dave Raggett <dsr@w3.org<mailto: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"?
When a protocol becomes important enough and fulfills some requirements, it is possible to define new URI schemes for those. For “minority protocols” a gateway approach is more viable. Depending on the scenario, however, people might translate to CoAP, for instance, rather than HTTP.
(Sure there is overlap with HTTP/2: REST. But since HTTP/2.0 focused only on the big Web during its design, there are also missing parts.)
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?
For the same reasons that HTML supported many other apps: the IoT is in a different evolutionary state than the Web as we know it today. Back then, nobody knew which bits would survive. The same natural selection needs to happen for IoT approaches. But for now, the best solution to counter fragmentation is to accept it and provide means to resolve it.
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?

You would do it by mapping the ZigBee protocol to the WoT interaction model (Properties, Actions, Events) and convert the semantic information from the ZCL to the semantic TD annotations for the respective interactions.

Now you already achieved one thing: You can write application code against the Scripting API that can interact with all the ZigBee devices around you.

What we primarily wanted to achieve is that those devices become available outside ZigBee. Since there is also a mapping of the WoT interaction model to HTTP or CoAP or foo it is now trivial to connect them. Writing a gateway is not that much engineering work anymore that you have to for ZigBee and with another team for Z-Wave again ;)

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?

Exactly, the abstraction to a simple common model and common format (TD) to express it is the challenge. Everyone can write a Web gateway for ZigBee. I did this 8 years ago and many others probably even earlier. The hard part is to implement a gateway that then does not become a universe of its own again and needs to be adapted to every other gateway. For this you cannot look at only one protocol at a time.

In addition, the odd looking step above to connect the WoT interaction model to ZigBee only is quite important for thing companies. In WoT we do not simply ignore how the embedded IoT are implemented by letting the Web begin after the gateway. For me it is the Web of Things because we adapt patterns from the Web and apply Web technology to the IoT space: we push the Web programming model down to the embedded devices. This way you can write IoT app for a specific purpose without the need to care about the platform where it will run (similar to the situation we have now among the modern Web browsers and the apps they run).

I believe that this in the long-term will lead to the nice and tidy landscape we now encounter in the Web: proven patterns survive and everything becomes more harmonized.

Kind regards
Matthias