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

Dear Ben and Dave,

Thanks a lot for your really constructive comments. I should have been
doing this a little earlier on but let me speak up on some good points that
Ben makes.

First: we were quite disappointed to see that the Web Thing Model
submission was pretty much ignored in drafting the charter and the best
practices.
As a reminder the Web Thing Model was not just produced by EVRYTHNG out of
the blue but also by the Barcelona Supercomputing Center and as a result of
the work of several members of the COMPOSE project (including W3C, IBM and
others). Producing this submission also meant a number of meetings, face to
face workshops and working sessions with several members of the WoT IG
Group (who did not want to be officially on the submission for internal
reasons). All in all: this was a quite long process (about a year) in which
many hours were spent on trying to produce something based on the
real-world experience of the different parties in the IoT.
I'm 100% conscious the Web Thing Model won't be THE standard, but it
provides a starting point, a more concrete basis to discuss the elements we
want to tackle. As a consequence, the very minimum should be to reference
it from the best practices and architecture documents as well a in the
charter. I'm happy to fix that and perhaps organise a small session to show
what it is about and which bits might well be reused.

With that being said, let me answer inline:

On Wed, Oct 19, 2016 at 7:32 AM Benjamin Francis <bfrancis@mozilla.com>
wrote:

> 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.
>
>
Avoiding fragmentation should be the goal. I think we are all aligned on
this. The essence of the Web of Things is exactly *not* to introduce
another competing platform but rather providing a unifying layer.

However, to provide a unifying layer you have to provide a common model
(unless I'm totally missing the point). This is walking a thin line as it
will introduce yet another competing model. The key is in making this
generic enough to cover many cases yet specific enough to offer a
significant common ground. Failing to do this will mean that the
model/standard will be of very little use.

In essence this is the work being done in the TD (Thing Description) task
force: defining the common constructs of what Things are made of in the
IoT. I'd however argue that in its current state the TD does not cover
enough and this where I would like us to introduce some additional elements
from the Web Thing Model.
This part for me will be the key for the WG: if we fail to specify a
compelling set of constructs chances of adoption will be very low.



> 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.
>
>
I agree with Ben here, for me HTTP and WebSocket will be a must somewhere
along the chain of "proxies", being at the device level or at the
Gateway/Cloud level. It's interesting to see that actually the world of
Home & Building Automation for instance is adopting HTTP/WS + JSON as a
de-facto standard. You can see that from Weave to HomeKit to Amazon Echo,
Nest, SmartThings or EVRYTHNG.

Having said that I see a lot of value in the protocols mapping and the work
being done on that in the task force. The protocols mapping concepts allow
for dealing with the reality of the very fragmented IoT. My take however is
that HTTP and WebSocket will be the de-facto reference protocols
implementations, at least a the Gateway and cloud level.

Perhaps the point would be to achieve both: having a protocol mapping
framework and a standardized HTTP/WS mapping: all of this centered around a
common Thing Description Model and a well defined Interaction Model
(Action, etc.).


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

With Ben on that, apps will expect to speak HTTP/WS to the devices.

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

Absolutely, for me this is what this group should aim at achieving: a
common data model, a number of integration patterns and a common
interaction model, ideally also including a standard HTTP/WS + JSON mapping
that apps can rely upon. To be honest, from what I could see at the TPAC
this is not very far off the current direction but we need to make sure we
keep the work simple and aligned.


>
> 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).
>
> This would indeed be really valuable. Additionally to getting close to
existing standard groups there is a lot of value in understanding the
implementations of companies like Mozilla, Google, Nest, SmartThings,
Siemens, Bosh or EVRYTHNG because they have been shipping many of connected
Things for a while now.

I'll send some proposed actions points as a follow up on the internal list
and perhaps we should discuss some of these points in the next call.

Dom


> Ben
>
> --
--
Dominique Guinard, Ph.D. ////
co-founder & chief technology officer
+44 79 5153 2987 // w evrythng.com
t @domguinard // w guinard.org
b webofthings.org

About EVRYTHNG: http://bit.ly/smarterIoT
Book: Building the Web of Things: http://bit.ly/wotbook
Bloomberg Innovation Leader 2016: http://bit.ly/1OHR7k7
RedHerring Top 100 2016: http://bit.ly/1WbIF4t
10-billion Products Born Digital: http://bit.ly/1SUHiSN