W3C home > Mailing lists > Public > public-wot-ig@w3.org > April 2016

[wot-f2f] minutes from Day 1 - 12 April 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 13 Apr 2016 21:21:28 +0900
Message-ID: <CAJ8iq9Ur=K5p7OCNeYdAWZ+QY9pHF+MG8zXMj6HAuO5qOxDdHA@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>
available at:

also as text below.

Thanks for your help, Sebastian!



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

                               - DRAFT -

                            WoT-IG f2f Day 1

12 Apr 2016


          Joerg_Heuer(Siemens), Sebastian_Kaebisch(Siemens),
          Matthias_Kovatsch(Siemens), Claes_Nilsson(Sony),
          Ryuichi_Matsukura(Fujitsu), Katsuyoshi_Naka(Panasonic),
          Yoshiaki_Ohsumi(Panasonic), Kazuo_Kajimoto(Panasonic),
          Kazuaki_Nimura(Fujitsu), Daniel_Peinter(Siemens),
          Taki_Kamiya(Fujitsu), Soumya_Kanti_Datta(Eurecom),
          Toru_Kawaguchi(Panasonic), Kaz_Ashimura(W3C),
          Dave_Raggett(W3C), Victor_Charpenay(Siemens),



          Sebastian_, kaz


     * [2]Topics
         1. [3]W3C WoT IG Objective & Goals of the meeting
         2. [4]Checking the agenda for today
         3. [5]TF Reports & Setup of Breakouts
         4. [6]AP&DI Breakout@3205
         5. [7]Web of Things Architecture update - Ryuichi
            Matsukura (Fujitsu)
         6. [8]TD/AP joint session@PK-3205
         7. [9]Practical Exploration and Plugfest
         8. [10]WoT mission statement
     * [11]Summary of Action Items

W3C WoT IG Objective & Goals of the meeting

   <inserted> scribenick: Sebastian_

   Joerg gives a short overview about the WoT IG

   IG started one year ago

   discussion about the visibility and communiction of the WoT IG

   <inserted> - Current Practice and Architecture

   <inserted> - Formulate Work Items for WG

   <inserted> - External Communication & Collab

   Dave: we need some milestone how to integrate 'your' systems
   into WoT

   Joerg: gives ideas what are the hocks to integrate WoT

   <kaz> Kaz: not really sure what is expected here... stronger
   collaboration between W3C and OCF? or document review by other
   SDOs including OCF?

   Matthias: we are good in technical explanation, however,
   missing short good statements for management level

   michael: message should be that we do not want a new IoT

   Dave: it's hard to bring everything in 'one' slide for the

   Joerg: we have to address 3 stakeholders: developers, our
   company's management, SDOs
   ... each stakeholders should understand the 3 major statements
   of WoT
   ... one of them should be the message that WoT is not a n+1 IoT

   <kaz> Kaz: we should clarify our expectation for their
   participation as well, e.g., joining plugfest, open day, IG, WG

   <kaz> (Kaz has been disconnected; Sebastian takes over

   <scribe> scribenick: Sebastian_

   Joerg: Question to the group: Does it makes sense to go back to
   use case & requirements discussion again?

   Dave: The use case document can be a living document.
   ... General we did not publish the document.
   ... people here prefer to do more the practical work.
   ... people from external is quite hard to understand what we
   are currently doing.
   ... work should be more accessible

   Kaz: The charter includes the use case document.
   ... it can be simple published and we can continue the work

   Matthias: We should focus on the deployment scenarios such as
   where can be the servient located or the lifecycle.

   Kaz: Companies can gives some needs e.g. for smart home and
   smart factory scenarios.

   Kajimoto-san: Gap between building block and use case.
   ... each of us should share the âimageâ what we understand by
   the bulding block.
   ... e.g., for the TD each has its own image

   Joerg: We should more focus on the plugfest.
   ... we need also to provide hocks for the plugfest
   ... should be discussed in the TFs

   Kaz: other groups uses wiki or templates to describes use
   cases. We can have a look on that.

   Joerg: Before we should look into our current use cases and the
   atomic use cases.

   Joerg continues with the agenda

   Joerg: we have 2 rooms available for the breakouts

Checking the agenda for today

   <scribe> scribenick: kaz

   [12]Day 1 agenda


   Joerg goes through the agenda

   Sebastian is taking notes locally, and it will be merged here

TF Reports & Setup of Breakouts

   sebastian: TF-TD
   ... shows TD slides.
   ... Thing Description consits of: Semantic Metadata, Thing's
   Interaction Resources, Communication, Security
   ... Simplified TD Structure: remove metadata + ineractions
   ... new example
   ... JSON Schema for validation
   ... Agenda & Topics for Breakout
   ... discussion about new TD structure: involve new contect
   ... data type and restrictions: structure of the payload data
   ... TD templates/tree and derivations: multi instances of one
   device type
   ... Implicit vs. explicit knowledg in TD: Action results into a

   louay: binding to protocols is also important
   ... non-IP protocols, e.g., BLE
   ... also MQTT

   sebastian: let's discuss that too

   johannes: make sense to have joint session between TD and AP

   dsr: why do you care about type of payload?
   ... AP binding should handle that

   johannes: that's why a joint session would make sense

   joerg: joint on the 2nd bullet (data type and restrictions) or
   4th bullet (implict vs explicit)

   sebastian: will put this slide on the wiki
   ... adds 5th bullet: How about non-REST protocols such as BLE
   ... and 6th bullet: Plugfest: What can be the topic? How to
   describe the scenarios

   soumya: TF-DI
   ... shows slide on DI
   ... Accomplished so far:
   ... tech landscape into github:
   ... categorization of resource discovery
   ... interaction patterns of discovery mechanisms
   ... evaluation of discovery tech
   ... identifacation of discovery technologies used by IoT
   standards and consortia
   ... discusion of security and privacy aspects
   ... Current Practices Document:
   ... contribute on github: discovery, discovery-api
   ... WoT WG - Work items:
   ... so far: API definitions, binding to common protocols, thing
   ... need more discussion to finalie the discovery items
   ... Provisioning:
   ... including: initial setting up of IoT devices/services
   ... Provisioning - So far:
   ... commenced discussion
   ... presentation on OMA LwM2M
   ... wiki setup
   ... seeking presentations
   ... points from Dave
   ... Propsed items for breakout sessions:
   ... within TF-DI: review tech landscape doc and evaluation
   ... identifying security and privacy
   ... DI topics for WG
   ... AP/DI joint: API and protocol aspects; mapping of DI items
   with WG items
   ... TD/DI joint: setup guidelines for how to discover/filter
   TD; how to handle lifecycle
   ... SP/DI joint: SPT issues

     [13] http://w3c.github.io/wot/landscape.html

   kaz: wanted to mention that MMI discovery draft was published
   the other day
   ... can make brief explanation during the breakout
   ... and the details could be discussed during the telconf later

   johannes: TF-AP
   ... shows AP breakouts wiki at:
   ... architecture model; contribution from Fujitsu
   ... abstract messages
   ... scripting APIs
   ... how to subscribe events?
   ... error conditions
   ... resource patterns
   ... those are the topics

     [14] https://www.w3.org/WoT/IG/wiki/AP_breakouts_Montreal_F2F_2016

   joerg: how to split the TFs?
   ... TD as the 1st group and DI/AP as the 2nd group

   michael: abstract messaging might be related to TD

   dsr: would see communication patterns

   joerg: in that case, joint meeting between TD/AP?
   ... should talk about Plugfest proposals
   ... 11:00-13:00
   ... room 3205: AP&DI (API, Plugfest proposals)
   ... room 3605: TD (wrap-up TD structure, TD template, Plugest
   ... 13:45-15:00
   ... room 3205: TD&AP (Protocol mapping)

   [ morning break ]

[ AP&DI Breakout@3205 ]

Web of Things Architecture update - Ryuichi Matsukura (Fujitsu)

   -> slides tbd

   matsukura: Purpose of the architecture document:
   ... want to clarify 2 things
   ... WoT common functions also structure of common functions
   ... and requirements to other documents from architecture

   nimura: Use Cases:
   ... non-IG stakeholders have difficulties with understanding
   the WoT Servient architecture
   ... so would like to clarify concrete use cases to help people
   understand the WoT Servient architecture
   ... (A) WoT servient on device (WoT device)
   ... electronic appliance like air conditioner including a WoT
   ... controlled by a smartphone as a remote control
   ... (B) WoT servient on smartphone
   ... WoT client on smartphone can control air conditioner within
   home locally or remotely
   ... (C) WoT servient on smart home hub
   ... WoT Servient on a smartphone can contol the air conditioner
   at home via the home hub
   ... (D) WoT Servient on Cloud Server
   ... D-1: WoT Servient on a smartphone can contol the air
   conditioner at home via some cloud server which includes a WoT
   ... D-2: WoT Servient on a smartphone can contol the air
   conditioner at home via both the cloud server and the home hub
   ... D-3: WoT Servient on a PC can contol the machines at a
   smart factory via a cloud server
   ... D-4: Connected Car: WoT client on cloud collects data from
   WoT Servient on a gateway connected to car devices
   ... (E) T2T (WoT to WoT) control
   ... air conditioner including a WoT Servient can be controlled
   by a Contol Agent including temp. sensor and WoT Servient

   johannes: puts comments on the AP agenda wiki at:
   ... Deployment scenarios:
   ... (A) single-Thing WoT Server on device directly controlled
   by WoT client in local network
   ... (B) in addition to (A), also discovery and control from
   remote (through internet)
   ... (C) home hub is a servietn that is a local proxy of
   electronic devices and is accessed like A/B. Discovery between
   hub and devices is local.
   ... (D-1) shadow is a servient acting as a remote proxy (e.g.,
   on the cloud), discovery of shadow is remote
   ... (D-2) both shadow and hub to enable local discovery for the
   hub and remote access and discovery via the shadow
   ... (D-3) industry case: local servients abstract industrial
   protocols, accessed or proxied by local clients
   ... (D-4) car gateway providing WoT server interface to
   car-specific interfaces, accessed remotely
   ... (E) servient-to-servient interaction, client/server roles
   for interaction determined by application. Discovery is local

     [15] https://www.w3.org/WoT/IG/wiki/AP_breakouts_Montreal_F2F_2016

   claes: issues like firewall/NAT?
   ... have you considered that?

   kaz: there are basically two use cases, (1) local UA accesses
   air conditioner within a smart home and (2) remote UA accesses
   air conditioner within a smart home from outside
   ... and the other use cases are rather implementation
   variations depending on network condition and security
   requirements (direct connection, via hub, via cloud, via both
   cloud and hub)

   johannes: how to create the shadow on the cloud side
   ... two atomic cases
   ... will update the wiki with them
   ... Findings/Questions:
   ... need a building block: how to create and synchronize
   virtual instances/shadows of a thing
   ... Interactions for discovery:
   ... local: be discoverable, discover
   ... remote: be discoverable, discover
   ... API privitives:
   ... Factory functions for thing object

   joerg: need more precise description
   ... would be excelent contribution
   ... how can we deal with that
   ... right now the use case document is not really in a good
   ... maybe a link to the architecture document?
   ... and describe this new finding

   nimura: originally planning to update the architecture document
   with this use case description

   joerg: don't care where to put
   ... we can go either way
   ... could be a separate document from the architecture document
   ... either way you feel confortable is fine
   ... then others can comment

   johannes: you can express the two findings

   kawaguchi: so what would be the task to do?

   johannes: we should describe the structure which covers this
   kind of use cases

   kaz: maybe we could start with the two basic use cases with 4
   possible implementaton variations

   johannes: would be hard to generate a use case document from

   louay: accessing home appliances from remote would be a use
   ... and there are several possible patterns

   joerg: we need to capture the upper part and explain there are
   several patterns/variations
   ... and we're looking for commonarities
   ... different scenarios
   ... maybe there could be still missing parts
   ... could start with categorizing the scenarios

   johannes: would suggest we describe concrete findings based on
   this contribution
   ... how to ensure the 2nd part, i.e., need to investigate how
   these servients find each other

   kaz: so the JP theam could start with putting this contribution
   (=these slides) into an HTML to describe the questions

   johannes: provisioning on how to handle TD registry,
   broadcasting, etc.
   ... need to clarify interactions for discovery
   ... and wondering about API primitives

   louay: same for API as discovery
   ... send a query on what you want
   ... and get TD as answer
   ... may need mapping for multiple protocols

   johannes: on the abstraction layer, local and remote look same?

   louay: would be same from API viewpoint
   ... if local, the IP address is local
   ... if remote, the address is remote
   ... depending on if the repository is accessible
   ... the mechanism should be available if you're not located
   ... if you want all possible variations, you can think about
   ... if you 're not at home, you'll be connected with some
   ... but from API viewpoint, there is no difference

   johannes: synchronizing shadow or twins
   ... virtual instance on the cloud
   ... for the Scripting APIs
   ... consuming Things and exposing Things

   louay: there 2 parts, advertising and discovery
   ... for accessing via cloud you need some proxy

   johannes: we can define primitives for that purpose
   ... need to provide information
   ... coming back to the findings
   ... how does the virtual instances host lifecycle?
   ... will add some more findings to "API primitives" and "Factry
   functions for Thing object" as well
   ... Louay and Soumya, could you think about how the possible
   APIs would be?

   Louay/Soumya: ok

   joerg: would be relevant to see Plugfest experience too?

   johannes: more protocol mapping issue

   louay: if we look at the use cases, the point is the first one
   ... physical API in my case is BLE

   joerg: something we could do to clarify the physical API and
   the client API?

   johannes: same script API could work on your runtime and my

   louay: in case of you're using protocols like BLE or something
   ... generate TD on the client side
   ... one important thing to be discussed AP/TD jointly

   matsukura: WoT servient structure overview
   ... WoT Servient has 3 interfaces
   ... Functional model of...
   ... WoT servient behavior (1)
   ... what the resource management does
   ... TD consists of Metadata and Instance
   ... IP address will be assigned to the instance device
   ... CRUD (Create, Retrieve, Update, Delete), Notify, Register
   ... WoT servient behavior (2)
   ... what protocol mapping does
   ... WoT servient behavior (3)
   ... what App script provider does
   ... WoT servient behavior (4)
   ... what the Communication protocol does

   johannes: legacy device I/F goes to resource management?

   matsukura: thinking about Echonet and KNX
   ... Summary:
   ... Thing Description, Resource management

   johannes: exactly what's done in our implementations

   joerg: would update the scenario based on this contribution
   from Fujitsu
   ... and expected contribution from Louay
   ... scenario, common findings

   johannes: updates the wiki with follow-up actions
   ... structure for scenarios out of the contribution of Fujitsu
   and DI
   ... API privitives for the "registering/advertising" part of
   the discovery
   ... define lifecycle for proxies/virtual shadows
   ... possible plugfest proposal: have an example script useing
   client/physical API, check interoperability

   [ TD breakout minutes TBD ]

   [ lunch ]

[ TD/AP joint session@PK-3205 ]

   sebastian: shows his slides
   ... Agenda&Topics for breakout

   johannes: what are the patterns
   ... what are the collection of 100 things

   sebastian: talked about collection of things during the TD/DI
   session in the morning
   ... 2 different topics
   ... how to organize collection of things

   michael: 3 different things
   ... different data
   ... same data
   ... spacial difference

   matthias: and different kind of lights

   johannes: how to proceed?
   ... some scenario identified
   ... maybe we should identify different scenarios
   ... action items to structure different scenarios
   ... local home appliances, remote control via proxy, etc.
   ... any comments from the group about prioritization?

   michael: something we wanted to discuss here
   ... Web protocol binding

   johannes: OK to do 3 (data type and restrictions) and 4
   (implicit vs. explicit knowledge in TD) ?


   sebastian: shows the Current Practice document
   ... request for the temperature property?
   ... "valueType": "xsd:float"
   ... let's talk about "encodings"

   matthias: valueType is very much in detail
   ... have to know the other side if we use RPC style
   ... but would not have interface with which we don't have to
   know about the detail
   ... what we need to have is the Max. value and the Min. value

   (discussion on data type and precision)

   johannes: could we handle the basic primitive part and
   annotation part for precision?

   taki: had same problem with EXI for JSON

   victor: schema.org as well
   ... shows schema.org site
   ... visits Enumeration
   ... and then Number which includes various types
   ... PropertyValueSpecification
   ... StepValue specifies granurarity
   ... Integer

   matthias: we should dig into the schema.org for our data type

   sebastian: framework for data type
   ... also hierarchy of data

   johannes: how to express JSON or XML using TD, e.g., array
   ... abstract way to express data

   michael: what about multiple field?
   ... may need a structure to express events

   johannes: would ask EXI guys for opnions

   sebastian: maybe Taki and Daniel can look into XML Schema

   daniel: somehting very tricky

   victor: 2 ways to communicate

   johannes: the most important at the moment is how to do this

   sebastian: generic discussion vs. what to do for the next
   ... Daniel/Taki can look into structure thing
   ... this should be done before the next plugfest in Beijing

   matthias: other schema solution like JSON hyper schema
   ... anyone have any experience?
   ... schema.org is not the only solution

   michael: different types can be used
   ... all kinds of namespaces are available

   kaz: I forwarded the UPnP data model definition the other day
   ... we might want to survey related data models

   victor: good point of schema.org is that it's for JSON-LD

   kaz: UPnP model is XML Schema-based
   ... we could start with schema.org given we're interested in

   sebastian: next
   ... REST-based message execution
   ... shows Example 1 from the Current Practice document again
   ... the advantage here is mapping resources easily

   michael: let's say consuming resources using media-type
   ... my client may or may not know how to consume the resource

   johannes: how to express "how to get the value"?
   ... can specify [["value": "something"]] using JSON structure

   michael: media-type is my preferred starting point
   ... e.g., coap type
   ... maybe we could use something like WoT media-type

   johannes: OCF also provides basic model and mapping to other
   ... we should have basic model and protocol mapping

   dsr: communication metadata should be described somewhere

   johaness: but not here within TD

   dsr: one part of TD is data model
   ... and another part is communication
   ... where the communication metadata should go?
   ... there is lot of additional metadata
   ... what should be the priority?
   ... what is the goal?

   louay: if we want to address new protocol, e.g., BLE, I'd like
   to put that here

   johannes: we could have several bindings to HTTP
   ... maybe sufficient to have we can do this and that
   ... not sure if all of that is machine readable, though

   matthias: question about create vs. post
   ... might need to clarify the behavior in each case

   johannes: applications don't need to know the details
   ... but developers need to know

   michael: like we are discussing the need for additional type
   ... maybe we need additional methods
   ... abstract metadata communication language
   ... zigbee, etc., have completely different model

   johannes: can we have additional content to show the need?
   ... we have some name for binding
   ... and then related context for binding

   michael: you could use the context file for binding
   ... even actuation may be complicated

   johannes: we need to identify OCF binding and TD binding

   matthias: don't care of the structure of the data
   ... but would know semantics

   sebastian: but you need to know the name of the key

   johannes: this is something machine can understand

   matthias: we can have different range for each protocol
   ... read vs. get

   johannes: methods to read/write could be easily binded

   sebastian: so what's the outcome of this discussion?

   dsr: look into binding with existing protocols?

   johannes: 2 tracks
   ... what can be generalized?

   sebastian: should we try HTTP, CoAP, MQTT?

   matthias: should have as many as possible

   louay: volunteer for BLE
   ... events can be mapped with MQTT

   matthias: who is interested in MQTT ecosystem?

   michael: HTTP vs MQTT is interesting

   sebastian: in Nice somebody implemented MQTT?

   matthias: first say we have this and that protocols
   ... and generalize the protocols
   ... MQTT, Back net instance

   michael: strawman integration for TD
   ... abstract messages could be mapped to anything?

   joerg: some notion on HTTP
   ... and some tonion on CoAP
   ... abstraction for those two protocols

   matthias: not an extension
   ... can try to generalize the messages

   michael: the server decides what to expose

   joerg: MQTT, CoAP and BLE

   matthias: CoAP by Daniel and Nimura-san
   ... HTTP by Louay, Michael and Sebastian
   ... BLE by Louay

   joerg: there are three more topics to discuss
   ... communication/collaboration, WG charter and plugfest
   ... would go for communication and plugfest today
   ... and WG charter tomorrow


   [ afternoon break for 15mins ]

Practical Exploration and Plugfest

   joerg: p13 of his slides:
   ... Input for upcoming plugfests:
   ... based on the current practice document
   ... discussed add-on from Montreal
   ... - API/DI: client interface for discovery (local/physical)
   (Louay, Soumya) [Louay, Johannes]
   ... - TD: datatype in TD, complex type, restriction (Daniel,
   Taki, Victor) [all]
   ... - TD/PM: (experimental) formal specification of the
   protocol binding, on the plugfest looking at TLE, CoAP, HTTP
   ... Objective/Test cases (Matthias)
   ... TD Repository:
   ... - Registratoin in TD repository
   ... - Discovery of Things in the TD Repository

   michael: mentions the idea of complex/composed devices which
   have multiple functions

   matthias: can volunteer for test cases based on ETSI tests
   ... mandatory tests and optional ones
   ... currently we don't have that separation

   michael: wonders what interoperability means
   ... could be orchestration of multiple clients via a server

   kaz: same protocols or including different protocols as well?

   matthias: both

   joerg: p14 of his slides: Practical Exploration and Plugfest -
   ... Categories for each plugfest aspect:
   ... - developer howto (slide set for virtual meetup; CPD; test
   ... - participation information in f2f wiki
   ... - call/initial table of participants (Siemens, Panasonic,
   RWE, Fujitsu, Fraunhofer, Samsung, ...)
   ... Network setup and prior testing:
   ... - network requirements (needs pretests of local persons in
   the hotel, share router configuration file for local pre
   testing, is a local registry possible?)
   ... - router setup config file
   ... - VPN? local pretest at the hotel
   ... - power supply, table setup (normal, bistro?), room setup
   ... Timeline
   ... - CPD: first draft: 6 May; review: end of May; freeze: 10
   ... - clarify network setup in May (to be checked with
   Yingying, ethernet cable, setup a router run it two days)
   ... - Things online: end of May

   matthias: can we have two people as the local organizers?

   michael: good to have a cookbook for router setup, etc.

WoT mission statement

   joerg: p2: C-level corporate decision makers
   ... what challenge is addressed?
   ... why is it important? (role of WoT)
   ... how it is to be solved? (WoT in nutshell)
   ... what action are we seeking? (hooks)

   kaz: note that there might be difference between Member
   companies and non-Member companies
   ... also depending on level of participation

   michael: Member companies also need more information

   joerg: Engineers and Developers:
   ... What is the problem to be addressed?
   ... Why is it important?
   ... How it is to be solved? (WoT)
   ... What action are we seeking? (Hook)

   (Joerg updates the Powerpoint slides based on the discussion)

   -> updated slides TBD

   [ Day 1 adjourned ]

Summary of Action Items

   [End of minutes]

    Minutes formatted by David Booth's [16]scribe.perl version
    1.128 ([17]CVS log)
    $Date: 2016/04/13 12:15:37 $

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

Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504
Received on Wednesday, 13 April 2016 12:22:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:58 UTC