Re: 3. WoT Thing needs to have meta Band

Hello David,

Picking up on facets. A few jumped out at me:

iot-facet:toy - to me this rather than saying what a thing does this is 
telling what it expects me to do with it. For example: a quadcopter 
flies. I may use one for an aerial photography business in which case I 
wouldn't consider it a toy.

iot-facet:media.radio.internet - Is this facet mixing principles? I read 
the facet as media content being delivered over a radio interface over a 
particular radio technology e.g.fm, am, sw etc. "Internet" would be a 
radio technology. "Internet Radio" may be better as "media.streaming". 
However one could assert "radio" is content from a "radio station". I 
think it highlights that facets need to be defined clearly defining what 
is the semantic scope of the facet.

iot-facet:media.receiver - is a media receiver thing a superset of 
media.radio?

iot-facet:control.climate - this seems to stick out from the control.* 
facets. The other control.* facets to me relate to something physical 
(e.g. I can picture a mouse). I can't picture a "climate". I could use a 
"dial" or a "keyboard" to control the temperature and humidity. I know 
in your example below you mention the nest doing "AC control" but does 
it match with "human input control".

Regards, Christian G


BTW: There seems to be an error for iot-facet:media the example says 
"doors, windows". I assume these are fixtures not media.


On 27/01/2016 8:39 PM, David Janes wrote:
> ****
> Formatted version here:
> https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/3.%20WoT%20Thing%20needs%20to%20have%20meta%20Band.md
> ****
>
> 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:
>
>   * https://schema.org/Thing
>   * https://schema.org/Product
>
> 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
>

Received on Wednesday, 10 February 2016 08:45:07 UTC