[TF-LD] minutes - 13 October 2017

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

also as text below.

Thanks a lot for taking these minutes, Maxime!

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                             WoT IG - TF-LD

13 Oct 2017

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/IG_Linked_Data_and_Semantic_Processing_WebConf#Agenda

   See also: [3]IRC log

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

Attendees

   Present
          Kaz_Ashimura, Danh_Le_Phuoc, Taki_Kamiya,
          Michael_Koster, Aparna_Thuluva, Darco_Anicic,
          Victor_Charpenay, Uday_Davuluru, Maxime_Lefrançois

   Regrets
          Dave

   Chair
          Darko

   Scribe
          mlefranc

Contents

     * [4]Topics
         1. [5]Proposals for PlugFest - preparation
         2. [6]Namespaces for the TD vocabulary (WoT ontology)
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <inserted> scribenick: mlefranc

Proposals for PlugFest - preparation

   [9]Darko's slides

      [9] https://www.w3.org/WoT/IG/wiki/images/1/15/2017-10-13-TD-LD-IoT_schema.pdf

   [10]JSON-LD examples

     [10] https://github.com/iot-schema-collab/iotschema

   DarkoAnicic: <showing list of thing drescription for plugfest
   2017-dusseldorf>

   <kaz> [11]TD repo

     [11] https://github.com/w3c/wot-thing-description/tree/master/test-bed/data/plugfest/2017-duesseldorf

   DarkoAnicic: <shows slide on IoT Schema Layer>
   ... datatypes -> interation patterns -> capabilities
   ... datatypes specified in iot.schema.org could be reused in
   different interaction patterns
   ... which could be in turn be reused by different capabilities
   ... as an example, datatype could be temperature data that has
   unit = degree celsius
   ... interaction pattern could be one of an observable
   temperature
   ... capability could be a thermostat
   ... <now showing the TemperatureSensing.jsonld document>
   ... for now temperature interaction patterns are written again
   and again in all documents

   DarkoAnicic: one need a website to navigate in the list of
   interaction patterns
   ... in the json-ld document one sees that temperature is a
   property and provide an output data that is a temperature data
   ... in this case temperature data is a subclass of
   schema:PropertyValue with datatype float and some temperature
   unit
   ... also, currently all datatypes are repeated again and again
   in thing descriptions
   ... the iot:TemperatureUnit datatype is a class, that has for
   instance iot:Unit and iot:Kelvin
   ... this is defined in Unit.jsonld
   ... and aligned to QUDT
   ... there is iot:reference that links to some ISO standard
   code, that many in the IoT domain actually use

   mjkoster: possible multiple definitions like book catalogs,
   e.g., ISBN and other codes

   DarkoAnicic: even Siemens doesn't always rely on real standards
   for units
   ... there are definitions for capabilities in different
   ontologies, we are currently investigating this
   ... e.g., Temperature, TargetTemperature, ThermostatTemperature
   ... iot:TargetTemperature has input data a iot:TemperatureData
   and output data a iot:TemperatureData
   ... <this is in interaction-patterns.jsonld>
   ... then iot:TemperatureData has schema:uniCode,
   schema:minValue and schema:maxValue that describe what the
   thermostat accepts
   ... currently the namespace iot is
   [12]http://iot.schema.org/core#
   ... that contains some datatype definition, interaction
   patterns, and capabilities
   ... which namespace will be chosen at the end of the day is
   something we need to discuss further
   ... <looking at Airconditioner.jsonld>
   ... we defined iot:Home and a few interaction patterns for
   iot:AirConditioner:
   ... iot:SleepMode, iot:CountDown etc.
   ... <these are defined in interaction-patterns.jsonld>
   ... there will probably be many different time data depending
   on (e.g., if they are defined in hours, minutes,...)

     [12] http://iot.schema.org/core

   kaz: This is one possible example of Thing Description, how can
   we make sure that Panasonic etc woudn't want their own ?

   DarkoAnicic: Indeed, it's an ongoing effort to create the app
   level semantics, that we really need for the sem
   interoperability at the end of the day
   ... need to see with plugfest users if they manage to conform
   to these proposal.
   ... concern about whether plugfest users will manage to
   implement these capabilities as described here
   ... I hope yes, now I understand there will be many different
   interaction patterns

   mjkoster: different layers of things happening here:
   ... first choose property naming
   ... second how to implement interaction patterns,
   ... we are targeting 99% of device that implemetn interaction
   patterns the same way
   ... at least for properties
   ... actions will be harder
   ... then a last level of composing capabilities together to
   create a "super-capability"
   ... a set of common features that certain kind of products
   share
   ... all of these levels are usefull and we might not want to be
   too prescriptive there
   ... else users might just use something else

   DarkoAnicic: yes, <taking example of thing description
   b36d96.jsonld> --> this td example is very difficult to reuse

   <kaz> [13]Matsukura-san's draft document

     [13] https://github.com/w3c/wot/blob/master/plugfest/2017-burlingame/preparation.md

   mjkoster: yes, not enough semantic annotations in the td
   sometimes, which makes them hard to be understood

   <kaz> kaz: agree

   kaz: where do you think these generic TD descriptions should be
   hosted with respect to Matsukura-san's types of servients ?

   <kaz>
   [14]https://github.com/w3c/wot/raw/master/plugfest/2017-burling
   ame/images/4layered_model.png

     [14] https://github.com/w3c/wot/raw/master/plugfest/2017-burlingame/images/4layered_model.png

   DarkoAnicic: where the TD should be hosted ? good question

   <kaz> s/Matsukura-san's types of servients/4 types of servients
   proposed by Koster and Matsukura/

   mjkoster: what would be great at the next level: should take
   one property and one action to do something
   ... a device that discovers a td could then recognize that
   property interaction pattern because it knows the URI for
   instance

   DarkoAnicic: in the discovery process, one could implement some
   capability search functionality

   kaz: so generic thing description could be hosted in a central
   TD repo as a template ?

   mjkoster: iot.schema.org could host templates for raw complex
   templates such as "a generic thermostat"
   ... without specifying the exact capabilities it has
   ... the purpose is to encourage reusability

   DarkoAnicic: another point: how to use these specifications for
   the plugfest
   ... if one creates something useful for the plugfest user, then
   how to explain it well and promote it ?

   mjkoster: ideally, these would be templates that would help
   someone to create a td for a specific kind of device
   ... a bit like schema.org works
   ... if I search for a thermostat, then I would see that it
   should have a bunch of capabilities,
   ... then I can search for those capabilities, if I'm lucky and
   I find them, then I can incorporate them in my TD
   ... and would just need to add the links to the actual href
   where these interactions can be triggered
   ... the point is to help users to browse the capabilities,
   event, action, properties, and how they go together
   ... help the user combine such templates to ultimately create a
   TD and upload it in their device

   DarkoAnicic: good question whether something like that can be
   done before the plufest
   ... we may ask during the main call to encourage users to reuse
   / create those capabilities

   mjkoster: like the idea of reusable interactions !

   DarkoAnicic: capabilities have coarse granularity, interesting
   to provide finer granularity

   mjkoster: ok for Properties, might be more difficult for
   Actions
   ... next step would be to make some TDs and annotate them
   ... someone else that we could engage in TD development ?
   ... iot.schema.org doesn't require a capability to have an
   instance

   DarkoAnicic: so far we proposed a model for capabilities that
   is compliant with our model,
   ... we haven't really thought in dept about
   reusability/modularity yet

   mlefranc: would like to work on actual examples where
   capabilities are shared by different thing descriptions

Namespaces for the TD vocabulary (WoT ontology)

   DarkoAnicic: for now we have td, rdf, rdfs, xsd,
   ... do we need another namespace ?
   ... this requires looking at TD ontology right now

   victor: xsd namespace is needed because it appears in the
   datatype schema definition (minExclusive, etc.)

   DarkoAnicic: if someone thinks that something is needed or
   missing w.r.t. namespaces, please discuss the issue on github

   mjkoster: one might want to look at the protocol binding to
   include namespace such as the http namespace
   [15]http://www.w3.org/2011/http#

     [15] http://www.w3.org/2011/http

   DarkoAnicic: we will work on the schema.org capabilities for
   the next plugfest

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [16]scribe.perl version
    1.152 ([17]CVS log)
    $Date: 2017/10/20 04:27:56 $

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

Received on Friday, 20 October 2017 04:30:28 UTC