[TF-LD] minutes - 27 October 2017

available at:
  https://www.w3.org/2017/10/27-wot-minutes.html

also as text below.

Thanks a lot for taking these minutes, McCool!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                             WoT IG - TF-LD

27 Oct 2017

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/public-wot-ig/2017Oct/0033.html

   See also: [3]IRC log

      [3] http://www.w3.org/2017/10/27-wot-irc

Attendees

   Present
          Victor_Charpenay, Kaz_Ashimura, Maria_poveda,
          Michael_koster, Michael_McCool, Taki_Kamiya

   Regrets
   Chair
          Koster

   Scribe
          McCool

Contents

     * [4]Topics
         1. [5]Continue discussion of semantic annotation with
            examples
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

   <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> [8]example TD

      [8] https://github.com/mjkoster/wot-protocol-binding/blob/master/td-example-annotated.json

   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> [9]https://github.com/iot-schema-collab/iotschema

      [9] 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> [10]Generic Sensor API

     [10] https://www.w3.org/TR/generic-sensor/

   Kaz: might want to look at this

   McCool: also SSNO

   Koster: something in SSN may be useful, generic

   <kaz> [11]SSN ontology

     [11] https://www.w3.org/TR/vocab-ssn/

   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]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [12]scribe.perl version
    1.152 ([13]CVS log)
    $Date: 2017/10/31 23:16:37 $

     [12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [13] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 31 October 2017 23:20:09 UTC