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

Re: 3. WoT Thing needs to have meta Band

From: David Janes <davidjanes@davidjanes.com>
Date: Sat, 20 Feb 2016 14:50:05 -0500
Message-ID: <CACp1KyMYNcowxo30oghgc1PAkuh=XohubcnNiNq=+GFr96=vLw@mail.gmail.com>
To: Christian Groves <Christian.Groves@nteczone.com>
Cc: "t2trg@irtf.org" <t2TRG@irtf.org>, Public Web of Things IG <public-wot-ig@w3.org>
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 <
Christian.Groves@nteczone.com> wrote:

> 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 Saturday, 20 February 2016 19:50:55 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 20 February 2016 19:50:56 UTC