14:02:40 <RRSAgent> RRSAgent has joined #wot
14:02:40 <RRSAgent> logging to http://www.w3.org/2017/10/27-wot-irc
14:03:06 <kaz_> scribenick: Kaz_Ashimura, Maria_poveda, Michael_koster, Michael_McCool, Taki_Kamiya
14:04:05 <Ali> Ali has joined #wot
14:09:46 <kaz_> present+ Victor_Charpenay
14:10:31 <victor> victor has joined #wot
14:10:58 <mjkoster> mjkoster has joined #wot
14:11:48 <McCool> McCool has joined #wot
14:11:50 <kaz_> scribenick: McCool
14:12:09 <McCool> Koster: didn't know what Darko had planned
14:12:22 <McCool> ... but we can continue discussion from earlier meeting
14:12:34 <kaz> Meeting: WoT IG - TF-LD
14:12:37 <kaz> Chair: Koster
14:12:43 <McCool> ... to build annotations based on capabilities from
14:12:49 <McCool> ... iot.schema.org
14:12:52 <McCool> ... have some examples
14:12:58 <kaz> Agenda: https://lists.w3.org/Archives/Public/public-wot-ig/2017Oct/0033.html
14:13:08 <McCool> ... based around capabilities
14:13:21 <McCool> ... each capability is a set of interactions to do a particular thing
14:13:52 <McCool> ... set of semantic annotations
14:14:16 <McCool> ... whole light, vs. more modular
14:14:21 <kaz> i|didn't know what|topic: Continue discussion of semantic annotation with examples|
14:14:29 <McCool> ... Koster prefers more modular approach
14:14:39 <McCool> ... and it makes sense to compose them
14:14:40 <kaz> -> https://github.com/mjkoster/wot-protocol-binding/blob/master/td-example-annotated.json example TD
14:14:49 <McCool> ... we may also want to do searches
14:15:25 <kaz> q?
14:15:29 <McCool> ... not a lot of semantic ambiguity for "dimming", you know it is a light
14:15:49 <McCool> ... but it was just on/off, you might want to distinguish lights from things like heaters, etc.
14:16:22 <McCool> ... Darko is also putting up a reachable endpoint
14:17:32 <victor> q+
14:18:10 <kaz> mm: how do you know the action would take place?
14:19:30 <kaz> ... wonder about the status property
14:20:09 <McCool> McCool: I see, have separate "Status" properties, and also "Actions" which may affect state, but may do other things, too
14:21:00 <McCool> ... in the schema definition, there are triples relating the status and the actions
14:21:42 <kaz> q?
14:21:49 <kaz> ack v
14:21:56 <McCool> ... what exactly do we have in the ontologies right now?
14:22:12 <McCool> Victor: don't understand what boolean/true means here
14:22:21 <McCool> ... does that mean the output must be true?
14:22:55 <McCool> Koster: likening it to brightness level
14:23:05 <McCool> Victor: ...
14:23:20 <McCool> Koster: ... well, maybe you are right, we don't need the value here
14:23:39 <McCool> Victor: this is not in the proposal I made for LD
14:24:07 <McCool> Koster: ok, this is an accidental copy of some other things I was doing
14:24:15 <McCool> ... there should not be some output data
14:25:08 <McCool> ... design pattern is it tells how the state changes
14:25:22 <McCool> Victor: but this information could also be in the ontology
14:25:39 <McCool> q+
14:25:57 <McCool> Victor: could say the value is always false
14:26:08 <kaz> q+
14:26:13 <kaz> ack m
14:31:32 <McCool> q?
14:32:26 <McCool> ... lights do all have remember dimming state
14:32:34 <McCool> ... older lights may not
14:32:51 <McCool> ... might want to have some profile of smartness of each device
14:33:18 <McCool> turning off should be 0, not on will be different
14:34:07 <McCool> McCool: I'm just looking for a simple example of how we can put different things under a common category
14:34:52 <McCool> Koster: in the degenerate case of a light, just have to choose
14:35:03 <McCool> ... model on/off, or dimmable
14:35:13 <McCool> ... maybe can't do anything more general in a binding
14:35:34 <kaz> ack k
14:35:38 <McCool> ... in degenerate case might have to settle for reduced functionality
14:36:17 <McCool> q+
14:36:42 <kaz> s/... lights do all have/kaz: some of the smart lights may/
14:39:35 <victor> q+
14:39:41 <kaz> i/Koster:/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/
14:39:53 <kaz> q?
14:39:58 <McCool> previous example showed capabilties at a different level of granularity
14:40:34 <McCool> don't have to put the annotation in any particular
14:40:51 <McCool> victor: I implemented the directory
14:41:21 <McCool> ... 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
14:41:44 <McCool> ... can formulate query for both koster's and darko's style
14:41:49 <McCool> ... there was also a demo
14:41:55 <McCool> ... of how to use this
14:42:27 <McCool> ... victor won't be at plugfest, but darko will be there
14:42:45 <McCool> ... but to prepare the best examples, need to know what the schemas will be
14:42:49 <victor> ack v
14:43:07 <McCool> ack m
14:43:17 <McCool> s/schemas/ontologies/
14:43:57 <mjkoster> https://github.com/iot-schema-collab/iotschema
14:44:42 <McCool> ... have only a small number of capabilities now, but easy to add more using these as a template
14:45:02 <McCool> ... they are modular, eg. the airconditioner lists the capabilities it uses
14:45:44 <McCool> ... have light, temperature, airconditioner, thermostat
14:46:21 <McCool> Koster: I refactored the BinarySwitch to have both a state and an action
14:47:06 <kaz> q?
14:47:11 <kaz> q+
14:48:43 <McCool> McCool: yes, this looks a lot my AVS stuff
14:49:00 <McCool> ... we also need to go the other way and map OCF to these capabilities
14:49:51 <McCool> Koster: would be useful to have direct mappings for avs and ocf ontologies
14:50:05 <McCool> and then in a separate step we would map to the generic iot ontologies
14:53:07 <kaz> q?
14:53:18 <McCool> ... so an example of orthogonal properties would be power state and brightness for a lightbulb
14:54:38 <McCool> 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
14:55:05 <McCool> q?
14:55:06 <kaz> kaz: wondering about how to handle additional capabilities in addition to the basic capabilities defined here?
14:55:28 <kaz> ... kajimoto-san proposed @include to extension but what would be the best solution?
14:55:31 <kaz> ack k
14:55:53 <McCool> Koster: also the issue of optional and mandatory properties
14:56:09 <McCool> right now implicit is that all are optional
14:56:16 <dsr> dsr has joined #wot
14:56:20 <McCool> ... IF they are present, they are like this
14:56:53 <McCool> q+
14:57:48 <kaz> ack m
14:58:51 <McCool> McCool: it would be nice to have generic boolean and scalar sensors and actuators
14:58:59 <kaz> q+
15:00:41 <McCool> q?
15:02:58 <naomi> naomi has joined #wot
15:03:05 <McCool> McCool/Koster: rather than a class hierarchy, can just mark objects with multiple types
15:03:30 <McCool> ... eg a temperature sensor can be both iot:Temperature and iot:ScalarSensor
15:03:54 <McCool> Kaz: we are planning to have a joint session with Devices and Sensors
15:03:56 <kaz> -> https://www.w3.org/TR/generic-sensor/ Generic Sensor API
15:04:13 <McCool> ... might want to look at this
15:04:31 <McCool> McCool: also SSNO
15:05:04 <McCool> Koster: something in SSN may be useful, generic
15:05:06 <kaz> -> https://www.w3.org/TR/vocab-ssn/ SSN ontology
15:05:12 <McCool> ... those patterns already eist
15:05:20 <McCool> s/eist/exist/
15:05:34 <McCool> ... what we're talking about is the feature of interest
15:06:00 <kaz> q?
15:06:06 <kaz> ack k
15:06:09 <McCool> but... in SSN is pretty complex, we have to mention a lot of things about what is being sensed
15:06:17 <McCool> SSN has a bunch of required definitions
15:07:16 <McCool> Koster: possible to add SSN to instance, don't prohibit it
15:07:32 <McCool> ... but if it is a common pattern, we could add it to ontology
15:08:00 <McCool> Koster: airconditioner is not a capability...
15:09:37 <McCool> McCool: is anyone going to do avs or ocf ontologies
15:09:55 <McCool> Victor: will do some templates by plugfest
15:12:24 <McCool> McCool: basically, I'll be working on AVS stuff over the next few days...
15:14:24 <McCool> ... got thing directory installed... see issue tracker for some build notes
15:14:38 <kaz> q?
15:14:46 <McCool> ... plan to get my ocf metadata translator resurrected and sending things to the thing directory
15:14:52 <McCool> along with semantic annotation...
15:15:08 <McCool> ... then will try some sparql queries
15:15:35 <McCool> ... sometime around Tuesday I should be finishing off the avs skill that talks to the TD to find devices
15:15:49 <McCool> victor: will be adding documentation for the ontologies
15:16:11 <McCool> Koster: at the very least there will be a referencable online ontology
15:17:09 <McCool> ... right now main thing is to get the protocol binding document drafted
15:17:26 <kaz> [adjourned]
15:17:31 <kaz> rrsagent, make log public
15:17:35 <kaz> rrsagent, draft minutes
15:17:35 <RRSAgent> I have made the request to generate http://www.w3.org/2017/10/27-wot-minutes.html kaz
16:17:02 <dsr_> dsr_ has joined #wot
16:38:10 <zkis> zkis has joined #wot
17:20:02 <Karen> Karen has joined #wot
17:55:48 <naomi> naomi has joined #wot
18:29:34 <Zakim> Zakim has left #wot
18:41:15 <Karen> Karen has joined #wot
19:01:27 <zkis> zkis has joined #wot
19:30:54 <zkis> zkis has joined #wot
19:43:55 <dsr> dsr has joined #wot
20:29:35 <Karen> Karen has joined #wot
21:26:49 <naomi> naomi has joined #wot
22:02:36 <Karen> Karen has joined #wot
23:21:43 <naomi> naomi has joined #wot