| Thing Description | |
| Iconcaption: | The logo of the latest version, Thing Description |
| Extension: | .jsontd, .td.json, .td.jsonld |
| Mime: | application/td+json |
| Developer: | W3C |
| Type: | JSON-LD |
| Released: | April 9, 2020 |
| Url: | https://www.w3.org/TR/wot-thing-description/ |
| Standard: | W3C Web of Things |
| Open: | Yes |
| Genre: | Device Description |
The Thing Description (TD) (or W3C WoT Thing Description (TD)) is a royalty-free, open information model with a JSON based representation format for the Internet of Things (IoT). A TD provides a unified way to describe the capabilities of an IoT device or service with its offered data model and functions, protocol usage, and further metadata. Using Thing Descriptions help reduce the complexity of integrating IoT devices and their capabilities into IoT applications.[1]
The TD originated from the Web of Things (WoT) initiative of the international standards organization of the W3C which has the intention to increase the interoperability in the IoT.[2] Since April 2020, the Thing Description[3] is a W3C recommendation (W3C WoT Thing Description 1.0).
In December 2023, the W3C published 1.1 version of the Thing Description recommendation.[4]
The major principle of the Thing Description is to provide a human-readable and machine-interpretable interface description of an IoT device/Thing. In that context, the WoT Thing Description is to the IoT what index.html is to a website: it can be considered as the entry point of a physical or virtual Thing/device.[5] Thing Description are not limited to a specific communication protocol, rather it provides a framework called a WoT Binding Template.[6] Such a Protocol Binding defines the mapping from an Interaction Affordance to concrete messages of a specific IoT protocol such as MQTT, HTTP, CoAP, Modbus or OPC UA.
The WoT Thing Description defines 3 kinds of Interaction Affordances, named Property, Action and Event:
An Interaction Affordance that exposes state of an IoT device. This state can then be retrieved (read) and optionally updated (write). Devices can also choose to make Properties observable by pushing the new state after a change.
An Interaction Affordance that allows to invoke a function of an IoT device, which manipulates state (e.g., toggling a lamp on or off) or triggers a process on the device (e.g., dim a lamp over time).
An Interaction Affordance that describes an event source, which asynchronously pushes event data to the subscribers of the event (e.g., overheating alerts).
In general, the Thing Description is designed to reuse and rely on established Internet and Web standards, this includes:
Below is an example TD serialized in JSON-LD format, which has one property, one action and one event. The IoT device represented by this TD uses the HTTP protocol but a TD can represent any protocol with a URI scheme, as shown in the example below.
From this TD example, a client knows that there exists one Property affordance with the title status (lines 10-16). In addition, information is provided in lines 13-14 that this Property is readable with an HTTP GET request to the URI <nowiki>https://mylamp.example.com/status</nowiki>, and will return a string-based status value. In a similar manner, an Action affordance is specified to toggle the switch status using the POST method on the <nowiki>https://mylamp.example.com/toggle</nowiki> resource. The Event affordance enables a mechanism for asynchronous messages to be sent by a Thing. Here, a subscription to be notified upon a possible overheating event of the lamp can be obtained by using HTTP with its long polling subprotocol on <nowiki>https://mylamp.example.com/oh</nowiki>. The use of the GET or POST method is stated explicitly but can be omitted using the default assumptions stated in the TD specification. It can be seen that the HTTP methods are defined using the "htv:methodName" vocabulary terms. This vocabulary terms for HTTP are included in the TD vocabulary that is found in the "@context" value.
This example also specifies the basic security scheme, requiring a username and password for access. A security scheme is first given a name and its corresponding scheme in the securityDefinitions and then activated by specifying that name in a security section. In combination with the use of the HTTP this example demonstrates the use of Basic access authentication.
Below is the same connected lamp but using MQTT protocol and no security.
Differently from the last TD, here the forms include MQTT protocol as specified by the WoT Binding Templates. More specifically, lines 17, 25 and 34 describe what message types should be used to use the affordances. For example, instead of HTTP GET and longpoll subprotocol to observe the overheating event, a client can subscribe to this event using the MQTT protocol. Furthermore, a WoT device with MQTT protocol can be both a publisher and a subscriber. For the property and event affordances, it would publish the values, whereas for action affordances it would subscribe to the action topics that other MQTT publishers can trigger by publishing to these topics.
Thing Description editing and validation tools
Implementations using Thing Description