W3C home > Mailing lists > Public > public-wot-ig@w3.org > February 2016

Re: 3. WoT Thing needs to have meta Band

From: Christian Groves <Christian.Groves@nteczone.com>
Date: Mon, 15 Feb 2016 15:26:43 +1100
To: David Janes <davidjanes@davidjanes.com>
Cc: "t2trg@irtf.org" <t2TRG@irtf.org>, Public Web of Things IG <public-wot-ig@w3.org>
Message-ID: <56C15383.7050000@nteczone.com>
Hello David,

Thanks for the reply. Please see my replies below.

Regards, Christian

On 11/02/2016 11:39 PM, David Janes wrote:
> Hi Christian,
>
> Thanks for the feedback - I've been dying in bed for the last couple 
> of days lol.
[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?
>
> 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
>
[CNG] I agree the metadata needs to be editable by the user.
> 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.
[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.
>
> D.
>
>
>
> On Sun, Feb 7, 2016 at 11:53 PM, Christian Groves 
> <Christian.Groves@nteczone.com <mailto: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
>     <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.
>
>
>     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 Monday, 15 February 2016 04:27:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 15 February 2016 04:27:27 UTC