Re: Capabilities & Schemas

Hi Ben,

OK, I see now that you weren't seeing the connections between capabilities and interactions, and between interactions and data, due to the broken links on the HTML site. I thought we were only discussing to what extent we need to constrain data types and ranges in iot.schema.org definitions...

Sorry about that. As Darko says, we will fix it at some point.

I see you also understand the data units issue, that we don't want iot.schema.org to mandate celsius, but rather to provide a consistent vocabulary for describing the units that a sensor exposes.

We still have questions about whether every instance of some interaction, e.g. light brightness, can be mandated to use the same scale and type. I would like to discuss exactly what client software adaptations we are expecting/not expecting and whether we are mandating that everyone either redesign their devices or use a gateway box or bridge. 

I don't think we are expecting to mandate e.g. every data representation from every temperature sensor, but I guess we should discuss that also.Surely temperature units can be adapted to by a reasonable client. 

For example, if I want to set a light at 50% brightness and the light has a 0-255 scale, I know what to do. Likewise, if another light has a 0.00-1.00 scale in floating point I also know what to do. We don't want to mandate a 0-255 brightness scale for all lights for ever. 

The question of reusing the property interaction for a data element is related to a discussion we are currently having in regards to the underlying TD model and our new simplified TD serialization. 

I guess it turns somewhat on the question of whether all representations for interactions are simple numbers, strings, etc. and can be re-used in composed payloads. Again partly a question of to what extent we are adapting to what's being built vs. mandating how things should be built.

Anyway, I agree with your conclusion. You only need to use the annotations that make sense for your use case, and both the semantic meaning and relational definitions (which interactions go with a capability)  are provided by the definitions in iot.schema.org.

What are your thoughts on the granularity of capabilities? Does it make sense to define "light bulb" as a capability itself, or to define "on/off", "brightness", color control", "energy measurement" as capabilities that can be composed int a light bulb? WHat is the tradeoff around reusability and compose-ability? 

Best regards,

Michael


> On May 24, 2018, at 9:23 AM, Benjamin Francis <bfrancis@mozilla.com> wrote:
> 
> On 18 May 2018 at 08:32, Anicic, Darko <darko.anicic@siemens.com <mailto:darko.anicic@siemens.com>> wrote:
> 
> 
> 
> 
> Actually we have already specifications for Capabilities, Interaction Patterns and Data schema (what you are referring to), but currently this content is not displayed on the iotschema <http://iotschema.org/>.org web pages. Until we fix the appearance on web pages, you can just access the content of iot.schema.org <http://iot.schema.org/> directly from github. For example, let us consider:
> 
> <snip>
> 
> This is really interesting, thank you. And unless I've misunderstood, seems to contradict what Michael Koster was saying above. These definitions do seem to specify which interaction patterns a device implementing a particular capability can have, and also the data types and (collection of) units an interaction and its data may use. Right down to primitive data types like "float".
> 
>  
> 
> Important to note is that iot.schema.org <http://iotschema.org/docs/full.html> is organized around patterns. If you don’t need the FoI pattern for your use case, then just use the Capability pattern alone.
> 
> 
> This is good to know, thanks. It seems we can start by just supporting a subset of the annotations and see whether we have a use for the other levels.
> 
> Ben