Why are Thing Types included in the WoT specification?

WebThings
#1

The computer on NCC-1701D interfaces with everything on board the ship and in its immediate vicinity (excluding, of course, subspace, which extends its “immediate vicinity” considerably). The types of things with which it can interface are countless. The computer does not always know what a thing is, but it can, nevertheless, detect, measure, and control in some fashion every thing that it encounters.

That is where the Web of Things is going, and we should begin describing those things in a specification in a way which can allow for things which have not yet been imagined.

The current unofficial draft specification describes some thing types:

  1. a “thing”, which is one or more of the other things mentioned below.
  2. onOffSwitch
  3. multiLevelSwitch
  4. binarySensor
  5. multiLevelSensor
  6. smartPlug
  7. onOffLight
  8. dimmableLight
  9. onOffColorLight
  10. dimmableColorLight

Those type definitions are unnecessary and, if every type of thing which will become part of the Web of Things is to be specified, maintaining the specification will become literally impossible. Those are not all of the types of things there are, and, if the specification is to accommodate all of the types of things which will eventually become part of the Web of Things, the specification alone will eventually require more storage space than can be made available in the known universe.

A system which implements the Web of Things specification does not need to know all of the types of things with which it may interface. The Mozilla IoT system demonstrates that plugins can be used to accommodate things. All that is required is that the inventor of a thing – or of an interface to a thing – tell the system where the implementation code is. A system, such as an IoT gateway, doesn’t have to know what a thing is; it merely needs to know where the application code is that describes the thing to the user and provides the user with the functional user interface.

Or am I missing something?

#3

This is a great point! Thanks for bringing it up.

The team has been talking about moving to a capabilities model over a type model in a future release. In the capabilities model a thing with the “on” property has the capability of being turned on and off and doesn’t specify whether it’s an “onOffLight” or an “onOffSwitch”. In turn, the UI can allow tapping the Thing to turn it on and off. Thing types would represent preexisting bundles of capabilities (can be turned on, can change color means it’s a color bulb and vice versa).

This capability model is already reflected to some extent in the rules engine where any Thing with an “on” property can be used as “if Thing is turned on” and “then turn Thing on”.

It’s very likely that we begin supporting capabilities in the near future but it isn’t our immediate focus. It’s definitely part of our five year mission to explore strange new devices.

1 Like
#4

Thanks for your thoughts on this, @hobinjk. I’m not sure that I understand, however, why even the capabilities of a thing would be important to a gateway or even to a platform that that is intended to provide user interface elements to a thing. While we certainly need a standard way to describe a thing that fulfills the needs of gateways and UI platforms, such details as the capabilities of a thing need be understood only by the implementation application. Such applications can be plugged in to those platforms, use the communication facilities of the gateway, and tell the UI platform what UI elements are needed, how they should be arranged, and what information to display.

For instance, the important functions that the Mozilla IoT gateway provides are registrations of gateways and users, and a dynamic DNS service so that users can find those gateways. It also duplicates a service that is provided by the gateways, i.e., a user interface to control things. But it’s the implementation code, provided by thing developers, that provides the data and initiates control signals. The Mozilla IoT software is merely a vehicle for transmitting and displaying data that is understood by the thing’s applications.

Neither the UI nor the gateway need to know the meaning of that data.

This reduces the requirements of the standard to describing a general thing registration protocol. As long as the gateway and UI platform don’t insist on knowing what a thing is, thing developers are free to imagine and create things that the gateways’and UI platforms’ developers haven’t even imagined.

HTML5 already provides a pretty good standard for displaying information, so any work in that direction may be nothing more than trying to re-invent the wheel. UI providers may simplify thing developers’ task of displaying data, and they may do it in a copyrighted or trademarked theme, but that’s about all UI providers can do that is useful. On the other hand, a directory of the locations of things and an API for plugging thing application code into gateways are definitely needed.

But the the only people who need to know what a thing is and what its capabilities are are a thing’s developers and its users.

#5

Interesting feedback. How would a JSON thing description look to you then? What JSON definitions would define a smart bulb, a smart plug, a smart toaster? One or multiple definitions per “product”? And are you thinking of a way to tie multiple capabilities together into a product such as a “smart toaster”?

I like to think broadly about how I would use the data. If I’m going on vacation, I’d like to set all my things at home to “vacation mode” – most things off but some randomized lighting so it “appears” that someone is home. I might also want to redirect security alerts or other high-priority alerts to friends/family or neighbors who are local and who could investigate.

I tend to think that we want to maintain atomic data – smaller pieces that can be creatively tied together with logic that I define, or that UI or app or analytics developers define. But too many atomic bits of data goes against ease of use.

#6

To be clear, the intention has never been to provide Web Thing Types for every possible type of “thing” in the world inside the specification. That is, as you point out, impossible.

The Web Thing Types provided in the specification are intended as a few simple core types which are built into the implied default context of the Thing Description data format. The real power comes from a schema based system which allows anyone to define a Web Thing Type to share with others, see Extensibility with JSON-LD. This allows for public repositories of externally defined web thing types, like iotschema.org, including domain-specific repositories for all kinds of use cases.

As @hobinjk points out, we have also found that defining types only at the “thing” level does not provide enough flexibility, so we are looking at definining “capabilities” which are probably going to be standard kinds of properties, actions and events which can be mixed and matched between different thing types.

Although the original intention was to maintain a list of core types in the specification (like HTML has a standard set of tags which can be extended), I’m not sure this is going to scale well for a capabilities based system. We may want to remove the web thing types from the specification entirely once popular repositories emerge (or we create one ourselves).

One challenge is going to be how to generate a useful UI for externally defined types and capabilities. We are planning to re-factor the things UI into re-usable web components. One approach might be to allow for extension add-ons which install additional web components which correspond to capabilities and thing types from different repositories.

P.S. I appreciate the Star Trek metaphors! I absolutely see the gateway evolving into a “ship computer” for your home that you can talk to :grinning:

1 Like
#7

Thank you for your reply, Ben. I’m still confused about a couple of things.

First, you said that the Web Thing Types provided in the specification are “a few simple core types”, as if they’re to be relied upon as core definitions for defining more expansive types. Am I interpreting what you said correctly? If so, that would seem to make them analogous to user interface elements, which would be dependent on the platform that implements the specification. Is it Mozilla’s intent to define every possible user interface element type that can be displayed? I actually think that would make sense, although the actual Web Thing Type which uses a UI element still seems to be irrelevant.

Second, you say that you want to define the capabilities of Web Things. Again, I think that’s impossible and unnecessary. Thing developers need to know the capabilities of the Things they invent and how to present the information provided by those things to users. The gateway does not need to know anything. It does not even need to know how to display UI elements. The /ONLY/ things a gateway needs to know is where a thing is, whether or not a specific user is authorized to access it, and how to connect a user to a thing. A web interface designed by the developer and using UI elements provided by the web server then allows the user to interact with the Thing, which presents information as required by the developer’s code. Again, the gateway doesn’t need to know anything about the thing except where it is and how to channel a data stream containing arbitrary data.

Standards such as WoT work best when they are general in nature. Defining capabilities limits what developers can invent. Such definitions should not be within the scope of the standard, since developers will invent capabilities that we can hardly imagine today.

#8

The schema currently doesn’t include visual element information. For example a boolean is by default represented as a checkbox, but may also want to be an on/off switch, a play/pause button etc. The product may want other visual aids, like icons that identify the thing type uniquely, and currently the schema doesn’t let the thing provide one.

Why wouldn’t you want to make the thing provide icons? What if one consumer has an UI that requires black icons and one an UI with white icons?

I don’t think just making the thing provide an UI is something that’s future proof, nor is it a good experience for the end-user. It means a lot of duplicate work for the thing developer, since the WoT API would still need to exist besides the web UI, even though the WoT API can control every aspect of the device (in a perfect world). Further, having multiple different UIs can be a challenge to users - a big power feature of IoT hubs is that they unify how you interact with your devices instead of having to deal with whatever the developer of a device has come up with.

#9

That was the intention, yes, but we’re now planning to move entirely to an extensible schema based system, with the intention to remove those basic web thing types from the specification altogether.

No, our intention is to create a repository of schemas which define capabilities a device can have, including the properties, actions and events which a device with those capabilities are likely to expose (as per the W3C Thing Description data model). We are implementing a set of web components to represent those capabilities in the web interface of our WoT gateway implementation such that a UI can be automatically generated for a Thing from its Thing Description, but anyone is free to implement their own UI to represent web things.

In the latest version of our gateway implementation, web thing developers can provide a link to a custom UI which represents a Thing. But if a gateway wants to provide its own user interface to monitor and control things via a graphical or voice user interface and a rules engine to automate them, then it absolutely needs to know about the properties, actions and events those things have and how to monitor and control them. This is the whole purpose of the Web Thing API and the work of the W3C Web of Things Working Group.

The web already provides a way to locate something and transfer data to it, it’s called HTTP. The Web of Things goes further by defining a machine-readable Thing Description format such that any web thing can be monitored and controlled by any web thing client. You’re right that we can’t possibly define every possible capability of a thing in a single specification. This is why the schema system is extensible, such that anyone can create a new schema and share it with others. We expect multiple schema repositories like iot.schema.org to emerge, many with domain specific schemas created by experts in those domains. Without this system for standardising types of things and their capabilities, it won’t be possible to achieve ad-hoc interoperability.

#10

I agree, and we’re creating the capabilities system to allow developers to be more expressive in their Thing Descriptions about the capabilities a Thing exposes such that we can automatically generate a meaningful and consistent UI across devices. Importantly, this Thing Description also allows other apps and services to interoperate with those things on an ad-hoc basis.

There are limits to the automatic generation of a user interface from a Thing Description however, which is why we also give developers the option to provide their own custom UI for a thing.

#11

It appears that I didn’t make myself clear. I did not intend that Things provide UI elements. Things provide arbitrary data that a client processes. In the current Mozilla model, developers write client code to process that data and present it using UI elements provided by a server, which can be a local machine or a Mozilla gateway. In either case, the gateway doesn’t have to know anything about the Thing except where it is and how to channel arbitrary data between the Thing and the Thing developer’s code. Mozilla’s gateway also provides a user interface for presenting data to users according to the Thing developer’s (and, presumably, the user’s) requirements.

For instance, I have developed a Farbisham, which measures the magnitude and frequency of guiments, efferigs, and related events, and provides real-time control of the sighashers which generate those events. The data provided by the Farbisham is sent to the client in blocks. The code that I’ve written for managing the Farbisham and what it does to the sighashers parses, sorts, and filters the data in those blocks, presenting it in a display consisting of graphs, gauges, lighted indicators (which may have two or three states), and text. My code can specify the data ranges for those UI elements that need them, as well as the text for the labels of other elements. The client code also analyzes the data from multiple blocks over time and suggests control actions to the user. From there, a user may select a value to activate and adjust the magnitude of one or more controls, and click a button to apply that value. In a future version, I want to allow the user to select the components of the display they wish to see and arrange them according to their whim, assuming, of course, that the gateway’s web server can provide that capability.

What does the gateway need to know about the Farbisham except how to channel data between it and the client? I suggest that the gateway needs to know absolutely nothing about the data or what a Farbisham is.

#12

You’re creating – or you should be creating – a gateway that:

  1. Authenticates users

  2. Facilitates the transfer of arbitrary data between Things and the developer’s code.

  3. Displays data to users in a format specified by the developer and the user.

The gateway needs:

  1. A database of users and means of secure authentication,

  2. An API for developers’ plugins,

  3. A channel for the transfer of arbitrary data between Things and developers’ plugins, and

  4. A versatile web server that can provide a wide variety of user interface elements as specified by the plugins.

If you want to provide a standard for plugins, we already know how to use APIs. A standard API is fine, but basing the development of the standard and the gateway on the types of things developers can create will restrict developers. Please see my example of the Farbisham I’ve developed, above. I’m pretty sure that you could not have imagined, in your wildest dreams, that anyone would ever develop such a Thing. Will your gateway be able to accommodate it?

#13

Without this system for standardising types of things and their capabilities, it won’t be possible to achieve ad-hoc interoperability.

How can you standardize Thing types when you can’t imagine what types of things developers will invent? No standard is necessary for the design or usage of Things as simple as spoons, but I can pretty much guarantee that someone with too much time on their hands will invent an “intelligent” spoon someday. I suggest that we don’t try to shove a standard down their throat. Just give them the tools to help people use it, whatever its capabilities may be. Who knows? Someone may decide they actually want an intelligent spoon – even if your gateway has no idea (and doesn’t have to know) what that spoon can do.

#14

Our Thing Description specification (and the latest W3C Editor’s Draft we’re converging towards) defines a general data model for describing the capabilities of devices in terms of “properties”, “actions” and “events”. Anyone can define whatever device they can imagine using that data model. It doesn’t have to conform to any predefined device type.

JSON-LD style semantic annotations using @context and @type can then optionally be used to add an extra layer of metadata for shared capability schemas (like the schemas at iotschema.org) to enable ad-hoc interoperability between devices which adopt those schemas. Anyone can define their own schema to share with others.

#15

WHY is it necessary for the gateway to know the capabilities of Things? For what reason does the gateway need to know anything about Things? The gateway, itself, doesn’t control or interact with Things in any way. It is nothing more than a channel for data between plugins and Things that it doesn’t have to understand. All interaction is done by plugins written by developers who, of necessity, know the capabilities of the Things for which they’re writing code.

A Thing gateway must be able to accommodate every kind of Thing there is or will ever be. Why should I have to describe the satellite I’ve just launched to measure the expansion of space to the gateway when the plugin I’ve written already knows everything about it? All I need is an authentication service, a relatively simple API for passing data back and forth to my Thing and for presenting data and controls to the user, i.e., a web interface that I don’t have to design myself.

#16

That is exactly what it does. It provides a web interface to monitor and control devices, and a rules engine to automate them. In order to do this, it needs to know the capabilities of the devices.

The gateway bridges existing smart home protocols like Zigbee, Z-Wave and HomeKit to a standard Web Thing API, and generates a user interface for the user to interact with those devices.

The plugins (adapter add-ons) simply bridge an existing protocol to the Web Thing API, they don’t provide their own UI. Anyone can create their own “native web thing” which directly exposes the Web Thing API and provides its own UI if they want to (which the gateway will link to). Native web things don’t require a custom add-on.

Developers can also can create a third party application or service which provides its own UI and calls the gateway’s Web Thing API.

Your questions suggest that you haven’t actually installed and used the gateway yet. I would suggest that doing so may help you understand how the gateway software works and answer many of your questions.

#17

Blockquote [The gateway] provides a web interface to monitor and control devices, and a rules engine to automate them. In order to do this, it needs to know the capabilities of the devices.

Plugins interact with Things. The gateway is just a gateway. The description given here is of an all-purpose controller that is intended, without plugins, to control every kind of Thing that is and that ever will be.

Plugins provide the control mechanisms, not the gateway. The “rule set” is embedded in those controls. Trying to implement a “rule set” for Things, other than for authentication, is redundant and /will/ break the intended functionality of Things. You /cannot/ develop rules for every kind of thing that will be plugged in to the gateway because you simply don’t know and /cannot/ know every kind of thing that will be plugged in to the gateway.

In contradiction to your assumption, I have installed and used the gateway, using both a local-only installation and Mozilla’s S3-based service. Your comments suggest that you need to avoid trying to directly answer my question.

You said it yourself: The gateway is a bridge. It is not a controller. The plugins are the controllers. They use the API provided by the gateway to interact with the Thing and with users. The gateway is nothing more than a channel between a plugin and a Thing.

We need secure authentication, a secure channel for arbitrary data, and a standard API for accessing those functions and for providing a user interface. Protocols already exist for everything else. We DON’T need your Thing “rule sets”.

Unless Mozilla can focus on the actual need for and purpose of a gateway and abandon the desire to “rule” every possible kind of Thing, this project will fail. You cannot imagine all of the kinds of Things we’ll develop.

I’m ending this discussion. You have failed to answer my repeated question: Why does the gateway need to know how to control Things when third-party plugins already know everything about the Things they’re intended to control? I’m convinced that you do not have an answer for that question. The correct answer is, “It doesn’t.”

Stop trying to define Things. You cannot predict what will be invented, and you don’t have to.