Re: Project Things by Mozilla and the Web Thing API

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

> There is current interest in work on both simple JSON and JSON-LD for
> serialising thing descriptions.
>

Is it not possible to have a core plain JSON vocabulary which can be
extended with semantic markup in JSON-LD? Rather than two separate
encodings.

For example, a simple JSON thing vocabulary could be used with an implied
default context and a canonical list of simple built-in types:

{
  "name": "My On/Off Switch",
  "type": "onOffSwitch",
  "properties": {
    "on": "boolean",
    "href": "/properties/on"
  }
}

Then anyone can specify their own Web Thing Type schemas and others can
reference them using a JSON-LD @context and @type:

{
  "@context": "http://iot.schema.org",
  "@type": "Toaster",
  "name": "My Toaster",
  "properties": {
    "on": {
      "type": "boolean",
      "href": "/properties/on"
    },
    "timeRemaining": {
      "type": "number",
      "unit": "seconds",
      "href": "/properties/timeRemaining"
    }
  }
}


This way, anyone can write a simple Thing Description using plain JSON and
the core vocabulary without having to know any JSON-LD, but the full power
of JSON-LD is available to extend that basic vocabulary with complex
examples using multiple layers of linked data.

I am also working with Darko on linking interaction models to semantic
> models as a basis for discovery, composition of services and adaptations to
> variations across devices from different vendors. As an example, consider
> the scenario where you plug smart lights into sockets around your home, and
> make use of a smart service to discover them and dynamically configure how
> they can be controlled from physical switches in the home and from your
> smart phone etc. This involves a means for services to discover the devices
> based upon the kinds of capabilities they expose, along with a means to
> model the context (the rooms in the home, and the devices in each room).
> We’re looking for the atomic building blocks to enable such smart services.
>

I get it, but I think you're going to quickly lose most web developers when
you start talking about semantic models and magic services which understand
them. This is why I recommend starting with very simple JSON markup and
using the semantic layer as a extension on top of that.


> Note that much of this can be implemented at the application layer as
> virtual things that offer smart services, e.g. as agents that run on a home
> hub to register things and provide access to a repository of information
> about the things in the home along with the context. By implementing some
> proof of concept demos, we can validate the requirements for the core
> underlying standards. Additional complementary standards could be added
> later as market experience dictates, just as has happened for CSS for web
> browsers.
>
>
> Also, the gateway concept looks sound. However, I'd be interested in how
>> far can we go with protocol bindings. Packaged SW update is less of an
>> issue for a gateway, but it's probably more difficult for an end device
>> that needs re-flashing and it's already deployed.
>>
>
> I'm not sure I understand what you mean. What's the link between protocol
> bindings and over the air updates that you're making?
>
>
> Good security practices call for secure means to apply updates as defects
> are discovered. Furthermore, to connect a new device to a gateway may
> involve installing a driver for a new protocol or communications
> technology. Each driver will be controlled via the corresponding metadata
> in the thing description.  My proposal is to include an identifier as a URI
> that can be dereferenced to obtain metadata for the required driver, for
> instance, implementations appropriate to different IoT platforms, along
> with the security credentials needed to verify the integrity of the driver
> as it is installed.
>

If I understood this correctly you're suggesting that a gateway could
automatically install a driver for a new protocol based on a Thing
Description? I can see a gateway using the Thing Description to add a known
device type for a protocol that the gateway already supports, but I'm very
sceptical that a gateway could automatically install software packages to
support a whole new protocol based on metadata in a universal Web Thing
Description format. Gateways are likely to use diverse operating systems,
programming languages and software packaging formats. We are a very long
way away from being able to standardise "driver" or "adapter" formats. That
would be like trying to get Mac, Windows and Linux to all use a common
software package a device driver format from day one.

I also don't think the Web Thing Description should even include any
information about the underlying implementation of a Thing like what
network layer protocol it is using. The WoT API should abstract away those
implementation details and provide a uniform interface for all Things.
Gateway adapters can be responsible for translating between the uniform web
layer and diverse underlying protocols - similar to how the Internet
Protocol exists on top of multiple underlying network protocols.

The key deliverable for the WoT IG is the work on thing descriptions.
>

Great, I think this is the area where we have the most alignment and
consensus on need.

The scripting APIs can be seen as good design patterns that will make it
> easier for developers to switch from one platform to another.
>
> The idea of a manager thing is that we can re-use the core standard for
> thing descriptions and APIs rather than having to invent something
> completely new. This includes the means to (un) install applications, to
> (un) register applications, to securely update them and so forth.
>

This is where you lose me I'm afraid. Installing and updating applications
is way outside the scope of what a WoT API should do. IMO keeping this as a
deliverable risks harming the credibility of the Web of Things effort as a
whole.

The fragmentation of the IoT is widely recognised as a problem.  However,
> the variation in requirements across use cases and application domains make
> it very unlikely that a single approach will win out.
>

Isn't that the point of creating a standard though? I would argue that a
usable standard needs to be more concrete than an encoding-agnostic data
model, a protocol-agnostic interface and a programming language-agnostic
scripting API. These things are too abstract to actually be useful.

Another way of approaching this diversity is to provide different
integration patterns for applying the same API in different use cases. Some
devices will expose the API directly while others will use one of many
specialised underlying protocols which are bridged to the standard API by a
gateway or cloud service.


>  We’re therefore trying to standardise a basis for describing things as a
> basis for decoupling apps from the underlying protocols and communication
> patterns. These descriptions form a Web of things, analogous to the
> existing Web of pages supported by Web browsers. Thing descriptions may
> include references to other things, e.g. where one thing depends on the
> services provided by other things.
>

> Web pages are executed by Web browsers. Applications for the Web of things
> are executed by application platforms that map the thing descriptions into
> objects that forms part of the application execution space. Application
> platforms may support multiple protocols, e.g. HTTP for Web pages and
> access to thing descriptions, and CoAP and Web Sockets for messaging. Web
> developers will be able to use familiar technologies such as JSON for
> descriptions, and JavaScript for programming, but we want to avoid the need
> for a developer to have to master the details of myriad different IoT
> standards, for which the effort can be delegated to IoT driver developers.
>

The reality is that the web of pages uses one universal markup language
(HTML), one universal application protocol (HTTP) and one universal
client-side scripting language (JavaScript) - but numerous underlying
network protocols, server side programming languages and software package
formats.

The web of pages simply wouldn't work if we had an abstract document data
model with everyone using different markup languages, a protocol agnostic
interface with everyone using different application protocols and a
language-agnostic scripting API with everyone using their own client-side
scripting language. The software that exists below that standard layer of
abstraction is where web implementations compete.

Ben