See also: IRC log
<kaz_> scribenick: McCool
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]