AW: [WoT WG] Release of WoT WG Charter Draft extendend until next week

Dear Ben

Thanks for reaching out to us and giving additional context to the AC Review comment. We are currently discussing internally to formulate a group response. There is also a meeting with the W3M “Strategy Lead” only next week, which shall be used to discuss the reviews. Until then, please note that all comments are individual member (or staff) statements.

Anyhow, I hope this bilateral discussion continues, since it also helps to better understand the viewpoints within the group. The past two years in the WoT IG had a big share of learning from others to get Web companies and thing companies on the same page. In this regard, it is quite surprising to me and others that you call the Current Practices “nebulous”. Several members have implementations of that, tested them at multiple of our PlugFests, and presented the Current Practices in a live demo at the recent TPAC. There, I unfortunately did not meet anyone from Mozilla to learn more about open issues.

I agree that the Web Thing Model Member Submission is a nice and easy starting point. When integrating actual things and taking a stab against fragmentation, however, the simple MUSTs (in particular HTTP/1.1) and global conventions (enforcing a specific resource structure on all servers) directly become a contradiction. For this reason, the IG expanded on that model to overcome the limitations (see https://lists.w3.org/Archives/Member/member-wot-ig/2016Jun/0012.html). The hardest task is to find the right presentation of the content, so that everyone in the wide spectrum of stake-holders can relate to something they already know and see how IoT/embedded technology comes together with Web technology.

Best wishes
Matthias


Von: Benjamin Francis [mailto:bfrancis@mozilla.com]
Gesendet: Mittwoch, 19. Oktober 2016 13:29
An: Dave Raggett
Cc: Heuer, Joerg (CT RDA NEC EMB-DE); public-wot-ig
Betreff: Re: [WoT WG] Release of WoT WG Charter Draft extendend until next week

Hi Dave,

On 18 October 2016 at 15:04, Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> wrote:
We want to avoid increasing fragmentation by introducing yet another competing platform. Instead, we want to provide an abstraction layer that can be used with both existing and new platforms.

I fully agree. Through Connected Devices projects at Mozilla we are working to create a web abstraction on top of existing IoT protocols, using the web as a unifying application layer by giving Things URLs on the web and providing REST/WebSockets APIs to interact with them. We're following a similar approach to the one described in EVRYTHNG's member submission<http://model.webofthings.io/> (and book<http://webofthings.org/book/>) including the "integration patterns" described in that model.

For example in one experimental project we're using a gateway integration pattern to provide a web abstraction for a set of sensors and actuators in the home using non-web IoT protocols like ZigBee/Bluetooth/Thread by exposing them through a REST/WebSockets API on the gateway. In another project we're using a cloud integration pattern to provide a REST API to a large number of environmental sensors across a wide geographic area which happen to POST data to a cloud service using HTTP but could just as easily use another protocol like MQTT or CoAP on the back end. In other projects we may use a direct integration pattern where a device exposes a REST API directly (e.g. like a WiFi camera).

This means being agnostic with respect to the protocols, the data encodings and so forth. Different platforms may use the same protocols in slightly different ways, so we need to find ways to describe what’s needed for the specific platform hosting a given thing.

Here I'm not sure I fully agree. HTTP is the protocol of the web and with the addition of WebSockets it has a great deal of flexibility. We can provide a REST/WebSockets API as an abstraction on top of any existing IoT network or application protocol. I can see the need for multiple encodings of the data model (e.g. a highly compressed/binary encoding for resource constrained devices), but I'd argue it would be valuable to specify a default encoding with JSON being an obvious choice. Perhaps the parallel work at Schema.org could also be useful for defining extended domain specific schemas for Things.
A further consideration is simplifying app development by decoupling the protocol details via delegation to platform developers.  This is where the object model comes in, with things exposed to apps independently of the protocols.

This is exactly the reason for using HTTP/WebSockets as a unifying application layer protocol and a adopting a standardised API pattern and data model, using content negotiation to support multiple encodings of that data model if necessary.


What do you think about the work on APIs?  Google proposed that this requires further incubation.

I think Google might be right here. I see a potential opportunity to standardise on a common pattern for a REST/WebSockets API and a common data model which Google Weave, EVRYTHNG, Mozilla, Amazon AWS IoT, Microsoft Azure IoT and many others here could use.
The "WoT Architecture" and "WoT Current Practices" documents produced by the Interest Group still seem quite nebulous at the moment and the charter in its current form isn't particularly compelling (although the underlying goals are). I'd argue we could arrive at something much more concrete to form the basis of a specification.
I'd be interested to hear more input from Google, I imagine they have a learned a lot through their implementation of Google Weave (the details of which are still under NDA as I understand it).

Ben