<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
<scribe> scribenick: kaz
Joerg goes through the agenda
Sebastian is taking notes locally, and it will be merged here later.
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: 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
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:
https://www.w3.org/WoT/IG/wiki/AP_breakouts_Montreal_F2F_2016
... architecture model; contribution from Fujitsu
... abstract messages
... scripting APIs
... how to subscribe events?
... error conditions
... resource patterns
... those are the topics
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 ]
Slides of Fujitsu and Panasonic
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:
https://www.w3.org/WoT/IG/wiki/AP_breakouts_Montreal_F2F_2016
... 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
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 ]
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 ]
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.
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 ]