The Web of Things (WoT) seeks to counter the fragmentation of the Internet of Things (IoT) by using and extending existing, standardized web technologies.
The W3C Web of Things (WoT) Thing Description 1.1 specification [[wot-thing-description11]] defines an information model and JSON-based representation format for describing the capabilities of connected devices and the interfaces with which to communicate with them. Thing Descriptions are designed to be protocol-agnostic and flexible enough to describe a wide range of existing IoT devices.
In order to provide this level of flexibility the Thing Description specification includes a number of extension points including protocol bindings, payload bindings, security mechanisms, link relations, and semantic contexts. As long as all of the capabilities of a device can be described using a Thing Description and a Consumer [[wot-architecture11]] implements all of the extensions used, the Consumer should be able to interoperate with that device. However, the result of this extensible architecture is that any given Consumer can only interoperate with a subset of possible Web Things.
"WoT Profiles" are a mechanism by which out-of-the-box interoperability between WoT Consumers and Things can be guaranteed, by constraining a Thing to a finite list of options for each extension point, and requiring that it conforms to certain defaults. As long as a Consumer implements all of the extensions and defaults prescribed by a Profile, it should be guaranteed to be able to use all of the capabilities of a Thing which conform to that Profile, without Thing-specific customisation.
Whilst the Web of Things provides the freedom to describe a wide range of existing IoT systems using Thing Descriptions, Profiles provide an optional additional layer of common constraints to which new implementations can conform in order to benefit from an increased level of interoperability.
Profiles are designed to constrain, not extend, the Web of Things. They should only be used to constrain the set of options for existing extension points, never to extend the Web of Things directly.
Conforming to a Profile does not prevent a Web Thing from describing additional capabilities or protocol bindings beyond those described in the Profile in their Thing Description, as long as they conform with all of the normative assertions of the Profile.
Profiles are designed to promote cross-vendor and cross-domain interoperability, so a Profile should not be restricted to a single application domain.
As a developer of DIY smart home hub software, I want to safely expose a standardized web-based API for monitoring and controlling a range of smart home devices using different underlying protocols, so that cloud services from multiple vendors can add value to a user's smart home without having to implement a vendor-specific API.
As a developer of a smart home mobile app, I want to offer my users out-of-the-box interoperability with a wide range of smart home devices so that I can maximise the audience for my app.
As a developer of a smart home device, I want my device to be controllable by any smart home hub software and/or any smart home mobile app that conforms to a common standard.
As a developer of a smart building hub, I want to consolidate multiple building management systems from different vendors into a standardized web-based API, which cloud services can consume to safely monitor and control commercial buildings over the web without needing to implement vendor-specific APIs.
As a developer of a smart building cloud service, I want to be able to provide data analytics for smart buildings using smart building hubs from different vendors whose APIs conform to a common standard, rather than having to implement multiple vendor-specific APIs.