Re: 3. WoT Thing needs to have meta Band

Hi Christian,

Thanks for the feedback - I've been dying in bed for the last couple of
days lol.

Just one thing I want to make clear is I'm trying to say is "you should be
doing something like this", not "you should be be doing this specific
thing". Or more generally, you need a flexible metadata model for Things.
Doing something like the "WoT Thing" where there's a single "type" is not
sufficiently powerful for what people will need to be doing.

I'll take your feedback into revising my vocabulary - it has been evolving
as I've been working with real things. I no longer believe there needs to
be a "control.*" space, as you can figure this out by introspecting what a
Thing does. A "receiver" is in this context (
https://en.wikipedia.org/wiki/AV_receiver).

With regards to the quadcopter and "toy", this gets into why this type of
data should be editable.

   - you buy a quadcopter and it's _model_ says it's a toy
   - that gets immediately copied when first seen to the _metadata_: this
   means that when someone says "find me all the toys", this you would search
   the metadata, not the model for this information
   - but let's say you're not using it as a toy, you're using it to film
   houses aerially for real estate listings: you just edit the metadata and
   remove the "toy" designation and add whatever else you'd like ("aerial
   camera"?) for finding this type of Thing

And because we're using Linked Data, your vocabulary is potentially
infinite. You don't have to ask the IETF or W3C to put a magic word in a
public file, or do "x-aerial-camera" or whatever: just use an appropriate
URL and you're good to go.

D.



On Sun, Feb 7, 2016 at 11:53 PM, Christian Groves <
Christian.Groves@nteczone.com> wrote:

> 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
>>
>>
>