Re: Project Things by Mozilla and the Web Thing API

> On 14 Jul 2017, at 18:41, Benjamin Francis <bfrancis@mozilla.com> wrote:
> 
> On 14 July 2017 at 17:12, Dave Raggett <dsr@w3.org <mailto: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.

JSON-LD isn’t essential for mapping JSON to Linked Data. A simple algorithm borrows the context mechanism from JSON-LD, and maps the names in the JSON name/value pairs either to predicates or to labels for blank nodes according to whether the depth of nested JSON objects is odd or even. The default context provides the mapping of common names to Linked Data URIs. An explicit @context should be used for uncommon names.  The default context could be referenced as part of a media type definition for thing descriptions.

I’ve implemented this algorithm in JavaScript and described it in detail at:

    https://github.com/w3c/wot/blob/master/proposals/dsr-td/json-to-ld-dsr.md <https://github.com/w3c/wot/blob/master/proposals/dsr-td/json-to-ld-dsr.md>

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

Rather than formally mixing JSON and JSON-LD, it would be better to use a regular algorithm that maps the example in its entirety to Linked Data. 

The idea of Web Thing Type schemas is something we’re discussing. Darko has some work on recipes and ingredients, where an ingredient describes a given capability that you can combine with others as a recipe. The question we need to answer is what is the minimum requirements for enabling that.  My guess is that the @type (rdf:type) link to a semantic model is sufficient, as this allows for validation that the thing’s properties etc. are consistent with the recipe.  It may however be desirable to support some kind of @import statement for referencing external definitions when standardising a suite of devices using shared definitions for properties etc.  OCF and oneM2M both use this kind of modularity in their definitions of interfaces that make up particular classes of devices.

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

That is just what we’re proposing, so we are in strong agreement!  :-)

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

That is a misunderstanding.  It would be natural to have different implementations of drivers for different operating systems and IoT platforms. The metadata allows a given platform to find and install the correct driver for that platform. A regular web developer doesn’t see any of this, as it is the platform’s responsibility to manage the drivers. 

An example might help. A web developer designs an application that runs on a home hub and makes use of a thing provided by home appliance that conforms to the OCF definition and is accessed via CoAP. The thing description for that appliance includes an identifier for the OCF standards suite. The context maps this identifier to a URI that the home hub can dereference to get metadata describing the available drivers for different platforms. The home hub can then install the appropriate driver, taking care to check the security credentials to ensure that the driver is from a trusted source.

The metadata needed to describe the available drivers would be standardised later, as it is sufficient initially to just define a predicate that identifies the target protocol/standards suite.

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

I agree. We should avoid embedding the communications metadata directly in the thing description. For example, when a home appliance registers with a gateway, the registration process could record the communications metadata in association with the thing description. When an application wants to use the thing provided by the home appliance, the application platform uses the URI for the thing description as an index for the associated communications metadata.

As an example, if the device is accessed via HTTPS, the application platform would need the corresponding URL, and any associated security credentials needed for accessing that URL. The metadata describing this can be provided as part of the thing registration process. A given thing might be provided by a home appliance for use with applications on a home hub within the firewall, and for applications running in the cloud on the Internet. The registration process for the home hub and for the cloud hub will provide different communications metadata, but the thing description will be unchanged apart from having a different URI.

Note a complication is that the IP address obtained by DHCP may change from time to time. The lack of a stable IP address and the Domain Name System for local area networks is a challenge for embedding URIs for local devices as part of applications. Likewise for thing descriptions that reference other thing descriptions. This calls for further discussion of device identifiers. This is also related to privacy concerns where you want to avoid persistent identifiers that could be used to track people. How does a light switch identify a given light if the identifiers are not persistent?  What are the implications of the EU’s GDPR regulations?

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

To allow for a dynamic set of applications, there will be a need to install and uninstall applications, but the precise means to manage this may be platform dependent.  At this stage we just need to demonstrate that the core standard doesn’t conflict with implementing such management services.  We need to be careful to distinguish the experimental APIs we’re exploring in the plugfests from what we’re proposing as a standards track deliverable. 

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

The Internet is a good analogy. It provides an abstraction layer in terms of IP addresses and packets, and avoids developers from needing to know about the details of particular networking technologies and the networks that use them.  Over time the network technologies have continued to evolve and the same is true for IoT technologies. W3C needs to complement the choice of IoT technologies and not to mandate which ones to use.

We do need standards for the communication metadata used to identify protocol bindings. This needs to be done in collaboration with the corresponding standards development organisations, e.g. IETF, OCF, oneM2M, ...

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

I agree. I think it can be helpful to distinguish the protocols and technologies needed to access devices from the protocols commonly used on the Internet. The Web of Things abstracts away from this, allowing developers to use say HTTP to access a gateway, and for the gateway to use say Bluetooth to access an IoT device.  Developers can thus choose the integration pattern to match their requirements. 

For me a key principle is to decouple applications from the communication patterns. In some cases, there is a need for buffering of sensor readings and multiplexing of data from multiple sensors and so forth. Battery operated devices may spend most of the time asleep. Gateways and cloud hubs can host proxies that provide access to caches of sensor data.

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

It is likely that only a few protocols will be widely used on the Internet, but we can expect will continue to see greater variety for the device technologies. I agree that it would be nice if there were to be convergence, e.g. on scripting APIs and application scripting languages. JavaScript is certainly attractive given its support by Web browsers and the extensive community around NodeJS. However, this is perhaps analogous to image formats for web pages. HTML doesn’t specify which image formats browser must support, but in practice, there is strong convergence around GIF, PNG and JPEG.

Note that I am writing this on a personal basis and not on behalf of the WoT IG/WG or W3C.

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C champion for the Web of things