Subject: Re: [T2TRG] 3. WoT Thing needs to have meta Band

From: Christian Groves <[email-masked]>
Date: Mon, 8 Feb 2016 15:53:19 +1100

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
>

---

From: David Janes <[email-masked]>
Date: Thu, 11 Feb 2016 07:39:50 -0500

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 <
[email-masked]> wrote:

> 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.
>
> 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.
>
> 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
>
>
>> Since we want to be Semantic, we should use URLs (/QNames) for concepts,
>> giving us the facets
>>
>> 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?
>>
>>
>> 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
>>
>> "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".
>>
>>
>> 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.
>>
>> |{ "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",
>> 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
>>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 11 Feb 2016 17:33:58 +0000

The type facet is useful for displaying a default icon for the device.  If it supports an icon facet, you can get a better icon URI (including data: if you like) from the device itself.

The most interesting bit to include is a list of protocols that the device supports.  For example:

tag:[email-masked],2016-02-11:on-off
urn:ietf:iot:dim01

(i.e. once those protocols are standardized by someone, they can mint better URIs, but RFC4151 defines my current-favorite scheme for minting unique strings)

Once you know that a device speaks urn:ietf:iot:dim01, you can send it commands using a protocol denoted by that string.  In this case, it might be a POST to https://[IP]/iot/dim with the JSON document:

{ "dim": 0.5 }

Or there might be a URI discovery step ahead of that, if you don't care about latency.

See XEP-115 (http://xmpp.org/extensions/xep-0115.html) for what we've learned in XMPP about this stuff.  If you can use 115's hash trick, you can fit a good amount of description in a DNS TXT record, which means MDNS is a great way to discover a device, it's type, and it's protocol capabilities.

-- 
Joe Hildebrand

On 2/11/16, 5:39 AM, "T2TRG on behalf of David Janes" <[email-masked] on behalf of [email-masked]> wrote:

>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 
><[email-masked]> wrote:
>
>Hello David,
>
>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 <http://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.
>
>
>For this example, we'll be considering the Nest Thermostat. The Nest Thermostat has (let's say):
>
>  * it controls the AC
>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".
>
>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", |
>
>|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?
>
>
>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.
>
>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".
>
>
>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.
>
>|{ "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
>
>
>
>
>
>
>
>
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Feb 2016 15:26:43 +1100

Hello David,

Thanks for the reply. Please see my replies below.

Regards, Christian

> Thanks for the feedback - I've been dying in bed for the last couple 
[CNG] That doesn't sound like much fun.
>
> 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.
[CNG] No problem, I'm just trying to work out the reasoning.
>
> 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).
[CNG] Maybe a dbpedia link will sort that out?
>   * 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
>
[CNG] I agree the metadata needs to be editable by the user.
> 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.
[CNG] Is asking the IETF or W3C such a bad thing if its an easy process? 
Things will have discovery mechanisms but how about for the users 
themselves to discover possible vocab?
You'd want to avoid the case where you define camera-aerial and I define 
aerial-camera. Ideally we'd use the same vocab.
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello David,
>
>     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
>     <http://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: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.
>
>
>         The "type" of a Thing cannot be a single value. Furthermore,
>         the word "type" is heavily overloaded so we propose the term
>         "facets".
>
>         |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?
>
>
>         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.
>
>         "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".
>
>
>         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.
>
>         "iot-facet:climate.cooling", ], "schema:name": "My Super Cool
>         Nest Thermostat", "schema:manufacturer": "https://nest.com",
>         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
>
>
>

---

From: David Janes <[email-masked]>
Date: Sat, 20 Feb 2016 14:50:05 -0500

Just a brief note on using terms v Linked Data, an organization can still
define "camera-aerial", it just would be as a URI rather than that exact
phrase that you'd have to look up in a document. e.g. it would be "
https://somestandard.org/camera-aerial". This has several advantages:

   - it's obvious where to find the definition: at "
   https://somestandard.org/camera-aerial". If you have "Content-Type:
   application/xml" it's not obvious where "Content-Type" or "application/xml"
   are defined, you have to go look them up somewhere. Obviously too late to
   change _that_ decision though!
   - it can be gracefully shortened using QNames, e.g.
   standard:camera-aerial
   - if I need to define something that's not envisioned by the standard, I
   don't have to do "x-my-thing"
   - if two different organizations define "camera-aerial", there's zero
   chance of a naming conflict
   - if two different organizations define "camera-aerial", it's fairly
   straight forward to define mappings between the usages
   - it really isn't that wordy!
   - Tim Berners-Lee likes it!

Regards,
D.

On Sun, Feb 14, 2016 at 11:26 PM, Christian Groves <
[email-masked]> wrote:

>> 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
>> 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 (
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     Hello David,
>>