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