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