- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 13 Apr 2016 21:21:28 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>
- Message-ID: <CAJ8iq9Ur=K5p7OCNeYdAWZ+QY9pHF+MG8zXMj6HAuO5qOxDdHA@mail.gmail.com>
available at:
https://www.w3.org/2016/04/12-wot-minutes.html
also as text below.
Thanks for your help, Sebastian!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-IG f2f Day 1
12 Apr 2016
Attendees
Present
Joerg_Heuer(Siemens), Sebastian_Kaebisch(Siemens),
Johaness_Hund(Siemens),
Louay_Bassbouss(Fraunhofer_FOKUS),
Michael_Koster(Samsung,_SmartThings),
Matthias_Kovatsch(Siemens), Claes_Nilsson(Sony),
Ian_Skerrett(Eclipse_Foundation),
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),
Frank_Reusch(RWE/Lemonbeat),
Regrets
Yingying_Chen(W3C)
Chair
Joerg
Scribe
Sebastian_, kaz
Contents
* [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
ecosystem
Dave: it's hard to bring everything in 'one' slide for the
management
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
ecosystem
<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
scribing)
<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
there
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
[12]
https://www.w3.org/WoT/IG/wiki/F2F_meeting_2016,_April,_11th_-_13th,_Montreal,_Canada#Tuesday.2C_12th_of_April.2C_WoT_IG_Meeting
Joerg goes through the agenda
Sebastian is taking notes locally, and it will be merged here
later.
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
fields
... 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
POST
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:
[13]http://w3c.github.io/wot/landscape.html
... 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
description
... 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
table
... 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:
[14]https://www.w3.org/WoT/IG/wiki/AP_breakouts_Montreal_F2F_20
16
... 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
proposals)
... 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
viewpoint
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
server
... 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
Servient
... 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:
[15]https://www.w3.org/WoT/IG/wiki/AP_breakouts_Montreal_F2F_20
16
... 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
shape
... 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
scratch
louay: accessing home appliances from remote would be a use
case
... 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
locally
... if you want all possible variations, you can think about
them
... if you 're not at home, you'll be connected with some
server
... 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
"(A)"
... 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
runtime
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) ?
(OK)
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
plugfest
... 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
JSON-LD
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
protocols
... 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
preparation
... would go for communication and plugfest today
... and WG charter tomorrow
(OK)
[ 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 -
Logistics
... Categories for each plugfest aspect:
... - developer howto (slide set for virtual meetup; CPD; test
cases)
... - 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
June
... - 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