<kaz_> scribenick: McCool

Continue discussion of semantic annotation with examples

Koster: didn't know what Darko had planned
... but we can continue discussion from earlier meeting
... to build annotations based on capabilities from
... iot.schema.org
... have some examples
... based around capabilities
... each capability is a set of interactions to do a particular thing
... set of semantic annotations
... whole light, vs. more modular
... Koster prefers more modular approach
... and it makes sense to compose them

<kaz> example TD

Koster: we may also want to do searches
... not a lot of semantic ambiguity for "dimming", you know it is a light
... but it was just on/off, you might want to distinguish lights from things like heaters, etc.
... Darko is also putting up a reachable endpoint

<kaz> mccool: how do you know the action would take place?

<kaz> ... wonder about the status property

McCool: I see, have separate "Status" properties, and also "Actions" which may affect state, but may do other things, too
... in the schema definition, there are triples relating the status and the actions
... what exactly do we have in the ontologies right now?

Victor: don't understand what boolean/true means here
... does that mean the output must be true?

Koster: likening it to brightness level

Victor: ...

Koster: ... well, maybe you are right, we don't need the value here

Victor: this is not in the proposal I made for LD

Koster: ok, this is an accidental copy of some other things I was doing
... there should not be some output data
... design pattern is it tells how the state changes

Victor: but this information could also be in the ontology
... could say the value is always false

kaz: some of the smart lights may remember dimming state
... older lights may not
... might want to have some profile of smartness of each device

turning off should be 0, not on will be different

McCool: I'm just looking for a simple example of how we can put different things under a common category

<inserted> kaz: actually, there is a similar situation with air conditioner. for example, we might configure an air conditioner to make the temperature 25 degree celsius, and would like the air conditioner to start with 25 degree selsius when we turn on it next time

Koster: in the degenerate case of a light, just have to choose
... model on/off, or dimmable
... maybe can't do anything more general in a binding
... in degenerate case might have to settle for reduced functionality

previous example showed capabilties at a different level of granularity

don't have to put the annotation in any particular

victor: I implemented the directory
... yes, this will be correctly parsed, and you will be able to send any sparql query, even if part of the URL... might be long, but that's ok
... can formulate query for both koster's and darko's style
... there was also a demo
... of how to use this
... victor won't be at plugfest, but darko will be there
... but to prepare the best examples, need to know what the ontologies will be

<mjkoster> https://github.com/iot-schema-collab/iotschema

victor: have only a small number of capabilities now, but easy to add more using these as a template
... they are modular, eg. the airconditioner lists the capabilities it uses
... have light, temperature, airconditioner, thermostat

Koster: I refactored the BinarySwitch to have both a state and an action

McCool: yes, this looks a lot my AVS stuff
... we also need to go the other way and map OCF to these capabilities

Koster: would be useful to have direct mappings for avs and ocf ontologies

and then in a separate step we would map to the generic iot ontologies

scribe: so an example of orthogonal properties would be power state and brightness for a lightbulb

if I turn a bulb off and read the brightness state, does it tell me the physical brightness of the bulb (0) or what the brightness would be if I turned it on (the "set state"). Right now it's not completely clear how to describe the two possibilities here

<kaz> kaz: wondering about how to handle additional capabilities in addition to the basic capabilities defined here?

<kaz> ... kajimoto-san proposed @include to extension but what would be the best solution?

Koster: also the issue of optional and mandatory properties

right now implicit is that all are optional

scribe: IF they are present, they are like this

McCool: it would be nice to have generic boolean and scalar sensors and actuators

McCool/Koster: rather than a class hierarchy, can just mark objects with multiple types

scribe: eg a temperature sensor can be both iot:Temperature and iot:ScalarSensor

Kaz: we are planning to have a joint session with Devices and Sensors

<kaz> Generic Sensor API

Kaz: might want to look at this

McCool: also SSNO

Koster: something in SSN may be useful, generic

<kaz> SSN ontology

Koster: those patterns already exist
... what we're talking about is the feature of interest

but... in SSN is pretty complex, we have to mention a lot of things about what is being sensed

SSN has a bunch of required definitions

Koster: possible to add SSN to instance, don't prohibit it
... but if it is a common pattern, we could add it to ontology
... airconditioner is not a capability...

McCool: is anyone going to do avs or ocf ontologies

Victor: will do some templates by plugfest

McCool: basically, I'll be working on AVS stuff over the next few days...
... got thing directory installed... see issue tracker for some build notes
... plan to get my ocf metadata translator resurrected and sending things to the thing directory

along with semantic annotation...

scribe: then will try some sparql queries
... sometime around Tuesday I should be finishing off the avs skill that talks to the TD to find devices

victor: will be adding documentation for the ontologies

Koster: at the very least there will be a referencable online ontology
... right now main thing is to get the protocol binding document drafted

<kaz> [adjourned]