The Web Thing Model

A few month ago, the partners of the COMPOSE European projects also active in the WoT IG were asked to reflect on the experiences implementing large interoperable IoT ecosystems and to produce a technical recommendation for the WoT IG/WG showing the way towards standardization.

EVRYTHNG together with a number of partners and the support of W3C took on this mission and produced the Web Thing Model which became an accepted member submission last August. The goal of this post is to provide an overview of the Web Thing Model and explain its relation to the current work of the WoT IG/WG.

The Web Thing Model in a Nutshell

In a nutshell the Web Thing Model is a cookbook for integrating Things to the Web and in particular to HTTP, WebSocket, JSON and JSON-LD. It was built to give recommendations in 4 main areas: Protocols, Best Practices, Resources and Data Model and Semantic Extensions.

However, conscious that not all Things will offer native APIs using these tools (mainly because of resource constraints such as being battery powered), it starts by looking at integration patterns: Direct Connectivity, Gateway-Based Connectivity and Cloud-Based Connectivity.

With these integration options in mind, the Web Thing model looks at Best Practices (1) for implementing Web Things. This is where protocols such as HTTP and WebSocket are mentioned but it also covers how to apply REST principles to build the API of Things.

Then, it focuses on a simple but powerful Resource and Data Model (2) composed of the following resources:

• Things - A web Thing can be a gateway to other devices that don’t have an internet connection. This resource contains all the web Things that are proxied by this web Thing. This is mainly used by clouds or gateways because they can proxy other devices.
• Model - A web Thing always has a set of metadata that defines various aspects about it such as its name, description, or configurations.
• Properties - A property is a variable of a web Thing. Properties represent the internal state of a web Thing. Clients can subscribe to properties to receive a notification message when specific conditions are met; for example, the value of one or more properties changed.
• Actions - An action is a function offered by a web Thing. Clients can invoke a function on a web Thing by sending an action to the web Thing. Examples of actions are “open” or “close” for a garage door, “enable” or “disable” for a smoke alarm, and “scan” or “check in” for a bottle of soda or a place. The direction of an action is usually from the client to the web Thing. Actions represent the public interface of a web Thing and properties are the private parts. Much like in any programming languages, you can access the public interface, and whatever is private remains accessible only for privileged parties, like the instance itself or, in this case, the web Thing. But limiting access to actions - that is, the public interface - also allows you to implement various control mechanisms for external requests such as access control, data validation, updating a several properties atomically, and the like.

All these resources are semantically described by simple models serialized in JSON. Resource findability is based Web Linking standard and semantic extensions using JSON-LD are supported. This allows extending basic descriptions using a well-known semantic format such as the Schema.org Product schema or the GS1 Web Vocabulary. Using this approach, existing services like search engines can automatically get and understand what Things are and how to interact with them.

The Web Thing Model in the Real-World

The Web Thing Model has been adopted by a number of organisations and European projects as a basis for creating the application layer of Things in IoT scenarios. We also decided to start implementing it in the EVRYTHNG API and wrote an opensource Node.js reference implementation for the Raspberry Pi called webofthings.js.

The Web Thing Model and the W3C WoT IG Work

The Web Thing Model was only the beginning of the Web of Things work at W3C. Since then a number of members joined and are driving the exploration efforts forward in the W3C WoT Interest Group, soon to be starting as a Working Group.

The relationship between the Web Thing Model and the current WoT IG work is pretty straightforward to understand. The Integration Patterns of the Web Thing Model are similar to what the WoT IG Architecture Document references. Similarly, the model of Things and other the model of other resources is discussed in the Thing Description which takes a very similar approach and terminology to the Web Thing Model.

However, there are also differences: the Web Thing Model focuses solely on readily Internet (TCP/IP, UDP) and Web of browsers compatible protocols (WebSocket, HTTP, HTTP/2) and relies on translators for other protocols. The WoT IG Architecture Document extends this and proposes the notion of Protocols Bindings. A Protocol Binding is a way to map an existing IoT protocol (e.g., BacNet) to the Thing Description and its interaction patterns. Finally, unlike the Web Thing Model which focuses on describing a REST API and a pub/sub extension, the WoT IG Architecture Document also references a scripting API: it proposes an IDL (Interface Description Language) that offers programmatic access to Things and their services. Note that this presentation below gives you a closer look at the similarities and differences between the two approaches.

Reading Further...

If you are interested in adopting and evolving the Web Thing Model a good starting point is the “Building the Web of Things” a book by Dom Guinard and Vlad Trifa that takes a practical look at using the Web (and the Web Thing Model) to build connected products. Also, you might want to checkout or contribute to webofthings.js, a simple implementation of the Web Thing Model approach for the Raspberry Pi. Finally, this is only the beginning of standardization in the Web of Things so make sure you keep an eye on the upcoming work of the Web of Things Working Group!