Re: Project Things by Mozilla and the Web Thing API

On 9 July 2017 at 12:45, Dave Raggett <dsr@w3.org> wrote:

> Thanks for sharing this. It shows the value of using simple transparent
> JSON, and looks very close to my proposal for using JSON rather than
> JSOPNB-LD, which I implemented last year as a NodeJS server with HTTP for
> retrieving the JSON models, and WebSockets for messaging. See:
>
>       https://github.com/w3c/wot/blob/master/proposals/dsr-td/
> td-draft-spec-dsr.md
>

I think you meant to link to
https://github.com/w3c/wot/blob/master/proposals/dsr-td/json-to-ld-dsr.md

But yes, I had actually noticed this particular work of yours on GitHub and
I thought the same thing. We seem to be converging on a very similar simple
JSON-based format.

I wonder whether there might be an opportunity to try moving the WoT Thing
Description <https://w3c.github.io/wot-thing-description/> spec in this
direction.

Specifically:

   - Top level "properties", "actions" and "events" members of the Thing
   Description rather than a general purpose "interactions" member with a
   complex "@type" property for each interaction.
   - A canonical list of built-in primitive types (along the lines of the data
   types
   <https://github.com/w3c/wot/blob/master/proposals/dsr-td/td-draft-spec-dsr.md>
   you have listed, possibly just borrowing from JSON Schema primitive types
   <http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2>).
   These types can be used for defining features like property types, action
   arguments and event payloads.

Another thing which I think could potentially make the spec much more
approachable and concrete is:

   - A default implicit "context" with a pre-defined list of common Web
   Thing Types like "on/off switch", "binary sensor" etc. in the Web Thing
   Description specification itself
   - @context and @type being optional semantic extensions to provide
   lightweight extensibility to an otherwise plain JSON description format,
   using features of JSON-LD.

This would allow people to create simple Web Thing Descriptions using
nothing but the core Web Thing Description format, but also allows anyone
to define their own Web Thing Types and share them with others via
repositories like schema.org. This would arguably be similar to how on the
web HTML5 has an implicit default namespace with a pre-defined set of tags,
but can be extended (declaratively with other XML-based formats like SVG,
or procedurally using Web Components). More direct analogies in IoT are
Bluetooth profiles, Z-Wave command classes and ZigBee command clusters
which are built directly into their respective specifications, but can be
extended with custom types.

> Moreover the approach can be used with a wide range of protocols and is
> not restricted to REST.  I am about to start working on adding IoT
> standards drivers for OCF and oneM2M over CoAP, Bluetooth and so forth.
>

I see there being two distinct types of "standards" in that list:

   1. Underlying non-web or non-Internet protocols like ZigBee, Z-Wave and
   Bluetooth which may be domain specific or optimised for certain operating
   environments (e.g. on low power wireless networks or power line
   communication). These protocols can be bridged to the Internet and the Web
   of Things with the use of a gateway and there's no need for them to use a
   consistent Thing Description syntax or API internally. In fact that would
   likely be impossible.
   2. Web-like protocols and data formats like CoAP (which implements REST
   and has web URLs) and OCF resource representations (which use JSON). These
   protocols are arguably different takes on the Web of Things itself. As well
   as standardization efforts from the IETF
   <https://www.ietf.org/id/draft-keranen-t2trg-rest-iot-04.txt>, W3C, OCF
   <https://openconnectivity.org/developer/specifications> and OGC
   <https://github.com/opengeospatial/sensorthings> there are many similar
   proprietary examples like Amazon's AWS IoT API, Microsoft's Azure IoT API,
   Nest's Nest API and even Apple HomeKit and Google Weave. My hope is that
   these APIs can over time converge on a common format and protocol for the
   Web of Things, or at least converge on an underlying shared taxonomy like
   that being discussed at iot.schema.org.

Our gateway implementation <https://github.com/mozilla-iot/gateway>
includes the concept of software adapters
<https://github.com/mozilla-iot/gateway/tree/master/adapters> which map
devices using existing non-web protocols like ZigBee and Z-Wave into Web
Things. Adapters can also be used to map other web-based protocols to a
standard Web Thing API (e.g. a Philips Hue adapter
<https://github.com/mozilla-iot/gateway/pull/99> which maps HTTP requests
onto different HTTP requests so you have a hub talking to a hub), but
hopefully as the concept of a standardized Web of Things becomes more
established this would become less and less necessary.

Adapters are responsible for generating a Web Thing Description for a
device and translating the Web Thing (REST/WebSocket) API calls into
commands in the underlying communications protocols (which may or may be
Internet based protocols). We're starting to work on an adapter add-on
system to allow people to package their own adapters written in the
language of their choice, which communicate with the gateway over an IPC
mechanism. In our case this is not a specification writing exercise, but
rather a gateway implementation specific mechanism for developers to create
adapters which bridge existing connected devices to the web. This IPC
mechanism is actually likely to use the same JSON message format as the
higher level WebSocket API (over unix sockets and using internal IDs rather
than URLs), but this is considered implementation specific and need not be
the case.

We're also starting work on software libraries in various programming
languages which help developers support the Web Thing API directly in their
IoT devices. For example, a Java library
<https://github.com/mozilla-iot/webthing-java> to help turn Android Things
into Web Things by exposing a Web Thing API. Again not a specification
writing exercise to define a standard scripting API, but an implementation
specific programming interface to a standard web API where multiple
implementations can compete.

I suspect there are some a few takeaway points here that we can more easily
agree on (e.g. a simplified JSON-based format for Web Thing Descriptions),
and some issues which may take more time to work through (e.g. the level at
which standardization happens in defining a standard API for the Web of
Things).

Ben