Re: Capabilities & Schemas

This.

> On May 24, 2018, at 9:08 AM, Benjamin Francis <bfrancis@mozilla.com> wrote:
> 
> On 16 May 2018 at 04:26, Michael Koster <michael.koster@smartthings.com <mailto:michael.koster@smartthings.com>> wrote:
> 
> The idea is that for a complete semantic system, we need to account for both capabilities of devices (door lock) and the Feature of Interest they are bound to (front entrance door of my house). The idea of integrating FoI into iotschema is to create relation types that enable the capabilities of a device to be semantically bound to a real-world entity. 
> 
> Interesting. I can certainly see the use case for an IoT system to know that a door lock, a door sensor and a door opener are all devices which belong to an entity known as "front door". My question would be whether this metadata should be in the Thing Description or not? 
> 
Good question, and one which we will explore more in the coming weeks and at the plugfest. I think a Feature of Interest is also a Thing, but it may not have any of its own interactions.

My current thinking is that this information should be attached to a TD when it is registered in a directory or exposed for discovery. The basic pattern is to register the door as a thing and make links that point between the relevant interactions of the lock and the door, so instead of saying "lock action on the lock thing" we can say "lock action on the door thing", or something equivalent.

> One question is whether the door is one thing, or multiple things? This is a topic which has come up a few times on our team. For example, is a smart power strip with four power outlets a single thing, or a collection of four power outlet things? We've discussed the possibility of a Thing Description having a "things" member or things link relation which refers to a collection of sub-things. Another example is a Thing Description for a Web of Things gateway <https://github.com/mozilla-iot/wot/issues/91> which is itself a thing with properties, actions and events, but also has a collection of sub-things which it manages.

As above, the door is a thing and the lock on the door is a thing, and the door thing inherits some capabilities and interactions from its associated lock thing. This way any set of relationships can be synthesized and understood by a client application. There can be relations between Features of Interest that help explain the situation.
> 
> Another question is how much user-defined metadata should be contained in a Thing Description vs. stored alongside the Thing Description in the database of a things directory/gateway? Perhaps the user wants to provide their own name for a thing. What about a location of the thing? A room? A group? An inventory number? The owner's name? The date it was installed? The date of its next safety check? How much of this is in the scope of the Thing Description vs. additional metadata a particular thing directory or gateway may store and use?
> 
Some of these are probably good candidates for capabilities of a thing and some, like location, make more sense as a Feature of Interest binding. The concept of storing information alongside a thing in a database is what I mean by linking between items stored in a directory. I would like to come up with some concrete design ideas to do this for the next plugfest.

Best regards,

MIchael

> Ben
>