Skip to content

Latest commit

 

History

History
122 lines (77 loc) · 3.4 KB

3. WoT Thing needs to have meta Band.md

File metadata and controls

122 lines (77 loc) · 3.4 KB
Raw

3. WoT Thing needs to have meta Band

Points to be made:

  • Facets: AC / Furnace / Thermostat combo
  • Schema.org properties, what if we want a Model Number?
  • Meta or Model?

Nest Thermostat

For this example, we'll be considering the Nest Thermostat. The Nest Thermostat has (let's say):

  • it controls the AC
  • it controls the Furnace
  • it monitors Temperature
  • it monitors Humidity

(3A) What's the "type" of this Thing?

Problem

As in:

    readonly attribute DOMString type;

Is it a:

  • Nest
  • AC Control
  • Heating Control
  • Climate Control (in General)

My answer would be "it's several of these" and in particular, the last three.

Solution: Facets

The "type" of a Thing cannot be a single value. Furthermore, the word "type" is heavily overloaded so we propose the term "facets".

So the Nest thermostat would have

We propose the following solution:

  • use a "meta" band to store this type of data
  • use "facets" (within the meta) to describe the "type" of a Thing

e.g. the Nest Thing would have (at least) the following facets:

  • "Climate Control"
  • "AC"
  • "Heating"

Since we want to be Semantic, we should use URLs (/QNames) for concepts, giving us the facets

"iot-facet:climate",
"iot-facet:climate.heating",
"iot-facet:climate.cooling",

Which can be looked up here:

https://iotdb.org/pub/iot-facet

(3B) Additional Data

The WoT Model defines the following meta-data like items.

readonly attribute DOMString id;
readonly attribute DOMString type;
readonly attribute DOMString name;

What if we want to have an image associated with the metadata. How about two images? What about the manufacture name, or URL, or the Model code? How about a description?

(3C) Schema.org Vocabulary

Schema.org provides a well supported semantic vocabulary. Of particular interest to the IoT community is:

There is no need to make new definitions for common concepts: the work has been done for us.

(3D) Meta v Model

Note that you might say "why are you using metadata to describe this rather than the model". In fact, you probably want it in both, e.g.

  • the model has the initial definitions
  • when a Thing is instantiated, it copies the initial definitions from the model to the meta.
  • the meta can be modified during use; the model is basically static

Considering the WeMo Switch again. Out of the box its facet is "iot-facet:switch". However, if we connect it to a lamp then we really want to consider this to be a lamp, e.g. its facet should become "iot-facet:lighting".

(3E) Putting it all together

Instead of variables on a Thing, we propose that there be a band (i.e. a JSON-like dictionary) that stores all the meta data.

This would look very much like this:

{
	"iot:thing-id": "<the thing id>",
	"iot:facet": [
        "iot-facet:climate",
        "iot-facet:climate.heating",
        "iot-facet:climate.cooling",
	],
	"schema:name": "My Super Cool Nest Thermostat",
	"schema:manufacturer": "https://nest.com",
	"schema:model": "Nest",
	"schema:mpn": "......",
	"schema:productID": "......",
}

You'll note that this looks very much like the istate and ostate bands, even though its purpose is very different. Code wise it's much the same

thing.meta.get("schema:name")	## "My Super Cool Nest Thermostat"
thing.meta.get("iot:facet")		## [ ... ]
thing.meta.set("schema:name", "David's Thermostat")

and so forth