Day 1, 13 Jul 2016

Welcome and IG Objectives/Goals of the meeting

<kaz> scribenick: kaz

joerg: starts introduction on the IG work
... (WoT IG Roadmap (1/2))
... discussion on Use Cases; atomic use case to bridge application domains
... three building blocks: Script API/protocol mapping, Discovery, TD and Security/Privacy
... meetings in Sunnyvale, Sapporo, Nice and Montreal
... generating a document, "Current Practice"
... compilation of demo experience
... and in parallel working on the WoT Architecture document
... (WoT IG Roadmap (2/2))
... we're about to prepare for a Working Group
... identifying particular work items for the WG
... also generating a draft Charter for the WG
... we'll update the current practice document
... we have some more topics
... discussion on the concrete scenario
... that is a snapshot of the agenda for this meeting
... we're preparing the release of the IG deliverable documents
... also preparing for the WG expecting to start it by the end of the year
... identified how the IG will work for further exploration of new WoT building blocks
... comments or questions?

(none)

joerg: another slide
... (WoT IG Work in Iterations?)
... Use Cases/Requirements -> Identify WoT Building Blocks -> Tech Landscape -> Architecture and Current Practice -> External Communication & Collaboration
... particular discussion on the concrete scenarios
... iterating documents
... on the right side, we have more practical things
... demos -> PlugFest
... we'll have our next meeting in Lisbon during TPAC 2016

xueqin: resource on the documents?

joerg: on the group wiki

-> https://www.w3.org/WoT/IG/wiki/Main_Page WoT IG wiki

joerg: please see "Ongoing work documents" section

-> https://www.w3.org/WoT/IG/wiki/Main_Page#Ongoing_work_documents Ongoing work documents section

joerg: going through the agenda

-> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_July_2016,_China,_Beijing#Wednesday.2C_13th_of_July.2C_WoT_IG_Meeting Beijing f2f agenda wiki

joerg: 9:30 Breakout Introductions: Protocol Bindings, UC/Req, Type Systems, Resource Parameters, TD lifecycle, Scripting API
... after coffee break, we'll have 2nd breakouts
... then lunch
... after lunch breakouts again
... and afternoon break

<kajimoto> kaz-san, the lady who asks on the documents of WoT IG is Xueqin Jia from China Unicom

joerg: and breakouts
... goes through Thursday
... we'll have a lot of breakout sessions
... below the agenda, there is "Input/Comments on the agenda"
... how we deal with these proposals
... discussion on "call for implementation" results
... follow up on IoT Open System Architecture discussion
... Kepeng Li: Contribution to WoT Security & Privacy

(Kepeng is not here at the moment)

joerg: do we have further contributions?

xueqin: China Unicom: information exchange on common aspects related to TD

joerg: right now we have TD-related breakout sessions, type systems and lifecycle

dsr: how long do we need for each breakout?

sebastian: resource parameters wouldn't take long

matthias: we'll have quick pitches during the breakout introduction

xueqin: would provide brief description

joerg: everybody can provide quick pitch
... we also have follow-up discussion on the IoT Open Architecture

dsr: yesterday's panel session was a good starting point

<dsr> we could make further progress in a smaller group

dsr: and we could make further progress in a smaller group

kaz: maybe their work is related to TD lifecycle as well

matthias: detailed dialogues by a smaller group would be better

+1

joerg: coming back to the breakout introductions
... would like to have brief self introductions
... name, affiliation and background
... starting with myself

(everybody introduces him/her-self)

joerg: take a look at our documents
... joint meetings with the W3C Automotive group
... also IRTF T2T group
... welcome for security/privacy discussion
... second point is implementations by open source projects
... testing against our own implementations
... we'll discuss our "call for implementations" tomorrow
... now would like to start the breakout introductions

Breakout Introductions

matthias: Explicit Protocol Bindings
... working on this after the Montreal meeting

<inserted> https://github.com/w3c/wot/tree/master/proposals/explicit-bindings

<yingying_> https://github.com/w3c/wot/blob/master/proposals/explicit-bindings/binding-coap.md

matthias: explains the CoAP binding
... who is interested?
... 8 people raise their hands

<yingying_> https://github.com/w3c/wot/tree/master/proposals/subscriptions

johannes: proposal on resourceful handling of subscriptions for REST (for Michael Koster)
... take a look at this during the breakout
... which solution would fit which issue
... what problems would be addressed
... who is interested?
... 10 people raise their hands

<yingying_> https://github.com/w3c/wot/tree/master/proposals/type-system

taki: quick introduction
... (What is Type System?)
... (Type System in Human Communication)
... what kind of data you send to the counter part
... Date, Time, Number of people, Name, etc.
... (Type System in WoT)
... Semantics: Meaning, Intention, Purpose
... Type System: Abstract Type Definition
... Data Representation
... (Abstract Type Definition)
... Abstract Type Definition using JSON Schema
... representation binding with possible data formats: JSON, XML, EXI, etc.
... (Example 1 - Simple Data)
... Type definition -> JSON/XML binding
... (Example 2 - Structured Data - Object)
... ID and name
... (Example 3 - Structured Data - Array)
... (Type System Breakout Topics)
... comments on incorporating JSON Schema as a whole into the spec is too much
... but applications need to have type system anyway
... how to cooperate with deviation?
... semantic annotation by type system or external mechanism?

joerg: who is interested?
... 9 raised their hands

<yingying_> https://github.com/w3c/wot/tree/master/proposals/resource-parameters

sebastian: next topic addresses Thing Description
... (Resource Parameters)
... (Problem Statement)
... defining data model
... who is interested?

yongjing: not sure about the point

sebastian: resource description using query parameters
... or payload data
... query parameters are popularly used today

yongjing: could join the discussion

sebastian: who is interested?
... 7 raised their hands

<yingying_> https://github.com/w3c/wot/tree/master/proposals/td-lifecycle

matthias: TD Lifecycle
... (Thing Description Lifecycle)
... Thing Description will grow and change over the lifetime of the "Thing"
... how to keep the information updated?
... who is interested?
... 16 raised

joerg: the last one is scripting API

<yingying_> https://github.com/w3c/wot/tree/master/proposals/restructured-scripting-api

johannes: Breakout proposal: Scripting API
... (Scripting API)
... portable script which could be transfered from WoT Servient A to another WoT Servient B
... (ConsumedThing)
... (ExposedThing)
... (Script Example (Client API))
... (Plugfest Findings / Topics)
... how to do local discovery
... need some way to access TD
... extend the spec with optional parts/hints for runtime implementers
... event handling and decorator
... some more points during the breakout session
... who is interested?
... 13 raised

joerg: we should ask China Unicom as well for short introduction

xueqin: Sharing China Unicom's Views on things desciption in IoT
... (Background)
... would like to share our views on things description
... ITU-T SG20 work item Y.IoT-things-description-reqts
... initiated by China Unicom, CETC, China mobile, etc.
... (Overview of things description in IoT)
... (diagram)
... mapping between Physical Thing and object using the Things description
... (Relationship between things description, information model and description language)
... need to clarify the concept
... Things description is composed by the information model and the description language
... (Things description methodologies in IoT)
... Semantics-based things description
... uses semantic description language like RDF
... relatively heavy and not popular for light-weight devices
... Abstraction-based things description
... JSON and XML are popular
... simpler and lighter, so widely used
... but weakness on the aspects of interoperability
... Hybrid things description
... special type of abstraction-based approach
... interested in working here

sebastian: tx!
... we should organize a session to synchronize with each other
... maybe query parameter topic would not take long

dsr: tx to introduce this work
... would like to explore the heavy approach and the hybrid approach

darko: very interesting
... we're thinking about similar things
... schema org, domain specific information
... discoverability, etc.

<dsr> Dave: I have initiated a joint white paper across many organization on semantic interoperability, and see a great deal of interest in lightweight approaches and the need for agile processes for standardizing vocabularies and models

<dsr> Dave: I look forward to fruitful discussions to progress this further

sebastian: I'd like to propose we talk about query parameter because it would not take much time

kaz: many people are interested in many topics
... do we really want to have these sessions as breakouts?

joerg: good question
... need some more adjustment on the agenda
... shows the updated agenda on the screen

(some discussion on the agenda building)

(moving TD contribution by China Unicom after the TD Lifecycle session)

joerg: how to identify the breakout rooms?

kaz: we can call this room the Big Room and another room the Small Room (or "Not so Big Room")

joerg: adds the room assignment (with "Not so Big Room")

[ 15-min break ]

TD Lifecycle

<scribe> scribenick: kaz

matthias: shows example TD
... how the document should look like
... at the time of design, there are properties already
... name, uris, encodings
... interaction properties which are rather stable: name, valueType, writable, hrefs
... remember that Panasonic had a question on the time of manufacturing, product sold, etc.

kazuo: shows his slides
... (Things Description Template Concept)
... instances depending the owners and locations

<dsr> scribenick: dsr

Kazuo presents a slide for thing description template concept

Layers with CE category, subcategory and product catalog name

plus particular instances of these templates as actual devices

It is kind of like an inheritance mechanism

Each kind of product has its unique id, e.g. Panasonic SX226

When you install a device, you can assign a human meaningful name and the platform can assign a machine id

Matthias: this involves a means to copy and extend a thing description

Darko: we can define an ontology for such templates and how they relate to lifecycle

It is unclear to me how to deal with what you call the extended context

Matthias: this import of vocabularies underscore the lifecycle

Kazuo: we have many product types, and manufacturer should provide a template for each product

Matthias: I see a need for tooling, one way is to request a description from the device, another is to request it from outside

We need to do more work on domain models

<Zakim> kaz, you wanted to ask about produced year/month/date and serial number and to ask about "how to dispose" and to ask about "modification/repair"

Kaz: I wanted to ask about produced year/month/date and serial number and to ask about "how to dispose" and to ask about "modification/repair"

This info is often on the warranty sheet

we need to consider the end of life

Dave: In my work I have come across three approaches: a) device provides TD directly, b) device is queried by gateway enabling gateway to generate TD, and c) gateway uses device ID to get TD from cloud and combine with local communications metadata for the specific device.

Some discussion around scripts that when installed either extend a TD or generate a new one

Johannes: it is a good idea to support modular TDs with inheritance

inheritance can make things complicated …

Taki: we can use ontologies for this

and import at run-time

Darko explains his understanding

Dave: we need to support lightweight ontologies for semantic models and constraints, and to make these into easy to process descriptions for WoT devices. Note that the RDF open world model has implications, e.g. complicating overriding of defaults

Matthias does a recap

Sebastian: what can we standardise here?

Matthias: we need to drive this from the use cases

Darko: we can provide best practice based on different lifecycle use cases

one is adding a new script and changing a TD at run time

we should identify lifecyle phases and look at best practices

Matthias: we need to scale to handle industry requirements on a large scale

Dave: some interesting timing issues when starting a thing that depends on other things

I solved this in my NodeJS project last year

Matthias starts to collect some lifecycle phases: design time, run time, manufacturing, delivering, commissioning

Dave: at run time both the software and the hardware may change (e.g. when a new device is plugged in that extends an existing one)

Yongjing: unclear about binding vs run-time

Matthias: binding needs to be complete before things can interact

Yongjing: design time changes may only be internal to a company

Dave: software depending on a thing will need to be aware of versioning where the kinds of things they depend upon evolve over time

Yongjing: we can look at existing work on templating

Matthias: please send a point to the mailing list

Taki: vendors may offer two versions of TD, e.g. one for free use, and another with an extended set of features for paying customers

<Zakim> kaz, you wanted to mention there are several levels here, device/service level and application level

Kaz mentions there are several different levels of lifecycle here, e.g., device/service level and application/session level. so this list includes smaller loop (e.g., Thing2Thing binding and Operation/Runtime) in the bigger loop

Frank: we need updates as part of the lifecyle

Dave: we need to discuss how this relates to the APIs, e.g. events signalling changes

Joerg: we should look at changes such as change of owner and change of service provider

It would be helpful to collect some examples of use cases to guide discussion

Joerg: we should include a use case for simulation

and more generally a use case for each lifecycle topic

Darko: changes such as new firmware updates

and software updates

Kazuo volunteers to maintain a document on lifecyle

<Yongjing> Home Gateway Initiative Smart Device Template. Available at https://github.com/Homegateway/SmartDeviceTemplate/tree/7c890b69d9764e341ef1768c5a0e7d53a47cff5c.

<Yongjing> Some state of the art for your reference

Discussion around ITU-T’s work in this area and its relevance to the web of things for thing descriptions

We can make use of the liaison to avoid conflicts and misunderstandings

<Yongjing> HGI SDT3.0 defines modularized way to describe devices, it allows inheritance of device types and module classes as well.

ITU-T can focus on high level concepts and terms, while W3C focuses on more technical treatment

<Yongjing> oneM2M adopts HGI SDT3.0 for home appliance information modeling

This would encourage Chinese companies to join the W3C activities

Dave: we have had some liaison with ITU-T, but we need people to join the W3C groups to help drive the liaisons as the W3C staff are too few to do this all themselves

Kaz: we can collaborate on common use cases and vocabularies, how would you like to proceed? as Dave mentioned, there are several possible approaches, e.g., W3C Liaison, your direct participation in this WoT group or simply joint technical discussion.
... use cases and requirements would indeed be valuable to share

There is a need to track liaisons

Joerg: in the short term we can identify particular use case and see how the concepts map

It can be difficult for the W3C group to process documents from other external groups without the relevant context, so we need help

It is really important to have a person who is really active in the ITU-T to help us in that respect

Xueqin: we will try to join future meetings

Darko volunteers on behalf of WoT IG to act as liaison point for the ITU-T

<Yohsumi> quit

<kaz> [ lunch till 1:45 ]

Breakout: Type System (Bigger room) / Subscription (Smaller room)

<ying_ying> breakout session: Type System (at the Bigger room)

<kaz> the minutes from the breakout session on Subscription at the smaller room are also available

<ying_ying> scribenick: ying_ying

taki went through the proposal on github

<taki> https://htmlpreview.github.io/?https://github.com/w3c/wot/blob/master/current-practices/wot-practices.html

taki: this is currently we have in the current practice document.
... this is currently we have in Beijing meeting.
... first point is incorporating JSON schema as a whole spec is too much.
... second is related with the first one. What is the best way for apps.
... third is what's the best way for semantic annotation.
... last point flexibility.
... is there any other point you want to discussion.

dsr: is there any time to study some requirements that are independently with specific types?

taki: do you mean alternative of JSON schema?

dsr: I think we need something lightweight.
... there is similarity to JSON schema but not only it.

taki: do you have something to show to us?

dape: maybe we don't need all the things in JSON schema. We can just identify what's needed and missing and base on something to create our own type system.

dsr: I agree on Daniel on studying usecases. but W3C is not in good position to standardize JSON schema related.

dsr went through his slide.

dsr: we need to study late timing. We need to study contraints.
... compound type can be specified in a similiar way.
... in place of TD or provide the URI of the type. Store it externally is very valuable.

sebastian: I don't see much difference from JSON schema.
... I think we should ask the experience in PlugFest..
... I don't like one thing of JSON schema. We need to specify the types many times in TD.
... of course it provides a lot of things we need.

taki: do you see anything that JSON schema is missing.

dsr: not standardized so we could not reference them normally in our specs. We may ask other org to standardize it or we abstract what we need.
... from spec point of view, what do you want to reference?
... or you can specify it in our document.
... choice 1: if we use JSON schema, we need to ask other SDO to standardize it or we launch WG to standardize it.
... my recommend we include it in our WG charter.
... let's use the terms and define the terms.

<dsr> Dave: the current draft working group charter scope would allow us to define our own vocabulary definitions for data types

dape: in corporation with JSON schema, some spec just use JSON schema.

<dsr> and I believe that this would be the lowest risk and the least work

dsr: do we have any understanding on restriction for the first step of recommendation?
... enumeration can be not only string.
... could you use types in enumeration?

sebastian: then it becomes complicated.
... should we only have javascript in mind?
... whether we would like to make our own type system. We need to be as simple as possible. 500 pages of JSON schema types.
... look on existing approaches and make some mapping

dsr: schema language define complicated languages. We need something very simple.

taki: we can start from JSON schema. another point is there is already implementation.

dsr: define the type independently from the schema languages.

sebastian: I like to make something like optimized JSON schema.
... example: "valueType" : {"type" : "number"}

or "valueType" : numeric

scribe: in the background they should be the same.

dsr: my proposal we have the type name or you have an object when you want to include annotations.

ganesh talked about experience on property of TD and suggest value type other than RDF type.

taki: are you talking about implementation complexity issue?

ganesh: yes. Another question is when should we depend on RDF type.
... the client has to bridge the two types of semantic type and @1.

sebastian: should we have the default schema or should we be open to any type of definitions?

daniel: how powerful is the RDF types?

ganesh: xml complex type can be done by RDF types.
... I believe RDF types are much more rich than xml complex types.
... with JSON schema I am struggling.

dsr: with WoT we have to work with existing platforms. Simple approach will cover most of scope.
... keep simple until there is use case required.
... semantic level constraints are needed.
... relate the domain model to the types as ganesh suggested.
... we need to start modeling current existing devices and services.
... we should support existing use cases and devices.

sebastian: to ganesh, binding a class in RDF or other complex types?

ganesh: one use case is to create RDF class, reusable and linkable in domain.
... I can use regular search with regular SPARQL

dape talked about experimenting on some type definitions.

dape: I think maybe we need to go back to study what we need on type system.

dsr: I agree we should go back. We also need to study use cases.
... types of compound property should also be studied.

taki: ideas to proceed?
... any other points?

ganesh: view use cases from consumers' point of view.

taki: thx.

dsr: we should justify the type system we need from use cases.
... that's up to the companies which use cases are important and need to take into accounts for standardization work.

ganesh: why property value type is different from that of action and event?

<dsr> I second that, and believe we should have a common type system for properties, actions and events

sebastian: defined in Nice long time ago. property should have the same type as we read and write on it. that is the reason the value type is different from input type and output type.
... we can discuss it in more details on the upcoming breakout sessions.

explicit protocol bindings

matthias: get request with query parameter of a great range.
... what is the procotol we are currently using, similiar with OCF doing.
... subscribe to something and receive notification later.
... hope someone to look for MQTT

<ganesh> is it possible to bring the camera closer to the screen? difficult to read the screen..

matthias: to see the changes for the next PlugFest

-> https://github.com/w3c/wot/blob/master/proposals/explicit-bindings/binding-coap.md

Matthias went through the CoAP binding github document.

matthias: this shows the defaults of CoAP method.
... we don't create action.
... better name to catch the interaction.
... start to define the new basic interaction.

dsr: is it target the RESTful community?

matthias: these basic operations are what we are talking about.

dsr: don't carry explicitly but just two different URIs, one for turning on another for turning off.

matthias: you shouldn't put addresses in payload.

dsr: msg contains info on payload,uri with parameter.

matthias: we need to be able to talk about all these information.
... TD and all the information in it, as a factory to create the msg.

<dsr> Three choices: state in message payload, state as URI query parameters, or state as part of URI path, we need to be able to describe all of these

ganesh: can this knowledge be put to RDF type of property or action?

johannes: explicit binding would not be implicitly in the TD.
... since you have to reason if that way.

ganesh: advantange is to offer alternative way to subscribe and could be more efficient.

matthias: if you want to extract something quickly it should be in TD. type should be somehow stable because they are part of vocabulary.
... we need to keep the identifier of type very stable.
... we can specify any detailed information in the TD. we can explicitly have the in one document.

ganesh: there will be many TDs. it could become overhead to update and keep it up to date on the way of protocol binding.
... need not to be in type but some other choices.

matthias: TD will change frequently.
... any other comments on it?

dsr: we need to provide stable short name for common things for convenience of developers.
... reference to some external definition of types.

matthias: UI does not need to understand the semantics but can still retrieve the messages.
... "retrievable":["GET"]
... "writable":["PUT"]
... "writable":["PUT", "PropertyWrite"]
... parameterized the TD itself. if you list everything there, it becomes too much.
... not only RESTful need to be considered to support.

sebastian: many stuff now in the additional info that may be not necessary to be there?
... different combinations are available?
... not need to be explicit in that way.
... could you show example?

matthias: here is it:

{

"@id": "colorList",

"@type": "RGBColor",

"name": "myColorList",

"valueType": {"type":"array","items":{"type":"integer","minimum":0,"maximum":255},"minItems":3,"maxItems":3},

"writable": true,

"hrefs": ["list"]

}

scribe: if you want to complement other standards, you need to do it explicitly.

matthias: that is the default information for common simple case.

<yingying_> scribe: yingying_

matthias: if it comes to protocol binding, no need to go to semantic level and we can directly externalize it from TD

<kaz> kaz: so we're talking about how to handle protocol binding capability within the Thing Description, and I'm wondering about the opinions of Matsukura-san and Kajimoto-san because they were wondering about how to specify protocol binding during the Montreal meeting

<kaz> matthias: we'd like to have same image about this

[some discussions on who initiate the interaction]

<kaz> sebastian: how to specify "writable", e.g., PUT or GET, is a question

ganesh: property readable=>property readable by GET. clear in ontology. no need to specify in TD.

<dsr> Dave: I’ve seen cases where thing exposed by a cloud server is a proxy for a thing in a smart home, and HTTP is used to push property updates to the cloud from the home hub.

matthias: keep TD short.
... proposal from Michael.

<dsr> This shows that it is challenging to determine who is responsible for the thing description

matthias: who would like to work on the table?
... for instance MQTT?

-> https://github.com/w3c/wot/blob/master/proposals/explicit-bindings/abstract-transfer-layer.html

yongjing: I can post a reference done in oneM2M.

matthias: thx.

<dsr> For instance, how does the cloud server invoke an action on the thing, perhaps can am HTTP POST to the hub via an open port on the home’s firewalll/NAT gateway

sebastian: BT LE should also be there.

Matthias: there are already some works on BT LE and could be transferred to the table.

<kaz> WoT-AP Proposal for Interaction Model mapping to an Abstract Transfer Layer (Michael)

<ying_ying> scribenick: ying_ying

dsr raised his hand.

matthias: where are you on plugfest?

dsr: give me people

<dsr> answer: very busy on my day job for W3C

<Yongjing> MQTT binding reference: http://www.onem2m.org/images/files/deliverables/TS-0010-MQTT_Protocol_Binding-V1_5_1.pdf

matthias: I will copy the coap and http to the table.
... to show what protocols we are targeting on.
... sebastian will continue on parameters.

kajimoto: for thing server supporting coap or http, same app can work almost the same. protocol binding is very important

<yingying> scribenick: yingying

matthias: app needs to talk with scripting APIs. what do we need to modify in resource model then come to the protocol binding
... I would suggest to do experiments to see how far we will go to TD for legacy device

sebastian: e.g. two device supporting echonite can recognize each other and communication directly.

ohura: I will show you one slide.
... 2 kinds of protocol bindings: red one is for WoT protocol binding. the other blue one is the binding for legacy devices.
... we think red area is our scope of WoT IG.
... blue area: there are so many legacy devices we need to leave them to each industy.
... what do you think?

matthias: this part should be red in gateway for WoT interface.
... BT LE is very close to resource model.
... we started experimentation how far we could go there.
... ganesh is working on it on BACNet.
... I think it's hard to draw the line here. I would encourage people to do experiments. Evaluate the complexity and benchmarking.
... legacy box coupled with the specific legacy protocol in WoT Servient diagram.

<yingyingchen> scribenick: yingyingchen

[some discussion on BT LE]

kajimoto: the scope of protocol binding?
...we try to map http, coap, mqtt, etc.
...if it's related to Web API, it's better.

joerg: third party could be there. blue one is proprietary. but it could be a GW that has blue on left side and you have a chance on right side red one.
...it could be a generic one that can translate the models between WoT and Legacy parts.
...could minimize the efforts on GW.

kajimoto: GW and WoT are written by us and we understand.

matthias: my understanding of our consensus: we want to communicate in the red area. Legacy parts we are not clear. ideally we do not need GW.
...new device connect and agnostic to apps
... it's very demanding.
... we can push the TD the most to this blue area.
... we are working on BACnet ip. you can experiment others.
... considering the scope, we can extend TD to the legacy devices.

kaz: GW is also a WoT servient based GW.

matthias: from right side yes. from left side it's legacy based.

joerg: how to simply access the legacy device
... should be considered.

resource parameters

-> https://github.com/w3c/wot/tree/master/proposals/resource-parameters

sebastian: it should be have semantics in there.
... parameter should be part TD.
... you has to add parameters to payload when requested.

johannes: where would you see to fill in the value for parameter ?
... option field on API call is needed?

sebastian: no, can be generated on the API level.

matthias: parameters, payload separated in protocol binding level. should be more option on scripting API level?

sebastian: in that case yes we need another option field and hope it's not difficult.

<inserted> scribenick: yingying_

ganesh: 1. defaults: payload or parameters default values. there are some difficulties.

2. binding with parameter of URI and without URI.

sebastian: very interesting use cases. thx.
...href field assigned there for default value. can override the default values.

johannes: like the idea of default sets. some parameters are optional. API level can be optional.

sebastian: agree, just where to put it, in parameters or in href?
...any other questions?

<kaz> scribenick: ying_ying

joerg: we still have another agenda.
... next plugfest preparation.
... plan to take group photo. why not use several minutes to take a photo and go back to the next agenda and close the day.

Next PlugFest Prep

<kaz> scribenick: kaz

joerg: shows a slide
... (Documentation of Current/Preparation of Next PlugFest
... Compile current PlugFest setup
... slide pitches on the demo scenario
... ok to put them on the wiki?

-> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_July_2016,_China,_Beijing#PlugFest PlugFest section of the f2f wiki

joerg: would be useful to add links to the PlugFest participants table
... local setup and group work after that
... need to think about the network situation

sebastian: got demo scenario perfectly
... network had issues always
... regarding the demonstration, having multiple screens would be useful to show multiple locations/devices

kajimoto: almost same opinion
... PlugFest went very well to see Proof-of-Concept
... on the other hand, would see multiple locations at once, so would agree
... seeing simultaneous changes would be useful to understand the demo
... how to show-up our PlugFest at TPAC is important

matthias: improved pitches were useful for easier understanding
... but maybe we could have even nicer structure
... 1-2 slides on things
... another on background and protocols
... how it was implemented
... in the end the overview of the showcase
... still have problem to get addresses
... some ideas on how to improve

kaz: environmental setting was not perfect
... would like to work with my Team mates and improve the setting for TPAC in Lisbon

johannes: great experience to work together
... good if we could start the process earlier
... discuss what people can see in the early stage
... for the joint activity

joerg: further comments?

taki: in addition to the slides, we might want to have some English description should be provided

dsr: if we could put some message together, that would be a good tool for recruiting Members for WG

joerg: Matthias has some idea on scenario, etc.
... we could generate a few sentences based on what we did
... joint task by the group
... make sense?

matthias: interesting to have brief profiles by different participants

<yingying> +1

matthias: small profiles with pictures
... connection with ECHONET and BACnet
... overall scenario and one page profile

dsr: very compelling to have interoperable testing by many countries

joerg: what kind of implementations, e.g., client-side and server-side
... some text to clarify the mechanism
... do you come up with any ideas?
... the scenario is already some joint work

taki: ok

joerg: tomorrow afternoon we'll elevate this topic some more
... (shows slides again)
... test cases compiled by Matthias

matthias: people have filled it up

joerg: certain coverage for different implementations in the Current Practices document

sebastian: (shows the test cases sheet)

joerg: please fill out the table

sebastian: everybody should be able to do this
... I have a servient for consuming and exposing
... tried to fill each of the use case
... not be able to do scripting
... Matthias has already set up all the devices
... e.g., IoT 2000, Raspberry Pie, Panasonic, Fujitsu, ...

matthias: green or red
... green is successful
... red is having trouble
... if not implemented that is not an error, so just blank
... there are two columns
... on the one side, you need a client
... another side is a server
... TD repository is just exposing TD
... this is the first time
... would like everybody to know about this

sebastian: maybe we should add more description to avoid confusion

matthias: e.g., you implemented client and I implemented server, in that case your client can be green and my server can be green

nimura: depends on the Current Practices document
... so should clarify the version of the document

matthias: right
... so we call the current version "for Beijing"
... if needed you can introduce other colors, e.g., yellow for some specific version
... the first row is the name of the demo
... maybe would be better to have some specific procedure to get the name

joerg: is this practical?
... to provide this kind of overview?
... if there is any issues, we can use additional colors to express that
... so please make your contributions

frank: looking at TPAC page

joerg: two actions
... to describe the demo
... and to fill the test cases
... TPAC is a great opportunity to show our work to the other W3C Members
... becoming more demonstration mode rather than PlugFest mode
... with concrete scenario
... maybe could try again adding basic token-based security support
... communication with the other W3C Members outside the IG
... how to make the WoT scenarios easily understandable?
... also how to display system setup and communication?

<scribe> ACTION: PlugFest demonstrators to descibe their demos (once the PlugFest template is available) [ recorded in http://www.w3.org/2016/07/13-wot-minutes.html#action01]

<scribe> ACTION: PlugFest demonstrators to fill the test case excelsheet for their demos [ recorded in http://www.w3.org/2016/07/13-wot-minutes.html#action02]

kaz: this is not only the work for the Communications TF but the whole IG is encouraged to join

joerg: yes
... this work has technical side as well
... the Communications TF can help, though

matthias: what kind of media can we use?
... components of slides
... small pictures of devices
... prepare our scenario beforehand
... and nice to show ad-hoc mode of the WoT work
... smaller poster on new setup
... print it out beforehand, etc.

kaz: the Communications TF and the whole IG should work together for that purpose

joerg: wondering about the setting during TPAC in Lisbon
... e.g., can we get a breakout session in the afternoon on Wednesday?

kaz: will check that

<scribe> ACTION: kaz to check (1) if the WoT IG can get a breakout session including PlugFest demo on Wednesday durint TPAC in Lisbon, (2) if multiple displays/projectors are available for multiple locations for PlugFest and (3) if a small room for demo prepration is available [recorded in http://www.w3.org/2016/07/13-wot-minutes.html#action03]

johannes: one thing
... focus on working together
... so some more visualization so that people can easily understand the demo, e.g., nicer UI

joerg: updates the slides based on the discussion
... posters per thing which can be mashed up
... individual monitors/projectors to show the status of multiple locations
... PlugFest demo during breakout sessions on Wednesday
... and then shows tomorrow's agenda
... goes through the agenda

-> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_July_2016,_China,_Beijing#Thursday.2C_14th_of_July.2C_WoT_IG_Meeting Thursday agenda

joerg: would like to thank for Team Contacts who took notes :)

(our pleasure :)

[ Day 1 adjourned ]

---

Day 2, 14 Jul 2016

<scribe> scribenick: kaz

-> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_July_2016,_China,_Beijing#Thursday.2C_14th_of_July.2C_WoT_IG_Meeting agenda

Review of today's agenda

joerg: discussion on WG deliverables. we have a draft Charter document
... next breakouts: Scripting API and Home App Vocabulary

Home App Vocabulary

dsr: shows his slides
... (Web of Things - Web Scale Interoperability)
... semantic based interoperability
... (Scott Jenson's comments on 16 June 2016)
... work on smart homes
... (Francois' list)
... (Summary)

kajimoto: it's out of scope of this group, isn't it?
... there are so many industry areas
... and why do you pick up only home appliances?

dsr: we need practical example
... and home appliance is a good area
... a lot of interest in this area

kajimoto: there are many proposals already
... we have already done some survey
... as a case study, it's ok
... however, our WG scope is a horizontal framework

dsr: that is an open question

kajimoto: if it's just a case study or an example, it's ok
... but if some standard vocabulary is provided by the WoT WG, that would be out of scope

dsr: the IG's work include semantic work
... it's up to the Members

joerg: comment from my side
... I believe the WG charter draft has a clear statement
... we're not going for domain specific work
... we won't invent yet another domain specific framework
... may be some study case
... that should be clear

dsr: I was talking about this as an IG item

joerg: interesting in this
... we had discussions within the IG
... we won't go for domain specific things
... we're not experts on smart grid, automotive or smart house

(some more discussion)

-> https://lists.w3.org/Archives/Public/public-wot-ig/2016Jun/0067.html Scott's message

kaz: sounds like we're mixing topics for the IG and the BG

dsr: let's have the detailed discussion during the breakout session

joerg: will come back to the agenda review
... Matthias will talk about the WG Charter

WG Charter and Deliverables

matthias: explains the WG roadmap

-> https://www.w3.org/WoT/IG/wiki/Roadmap WG roadmap

matthias: AC reps think about the Charter review
... after Baijing end of July, planning to get group resolution for the WG Charter draft
... encourage you all to outreach for p2p review by Members

<scribe> ACTION: all the IG participants to outreach Member stakeholders and ask them to review the draft WoT WG Charter in http://www.w3.org/2016/07/13-wot-minutes.html#action04]

joerg: important to get feedback from outside of the IG as well
... would like to ask you to take some action to outreach AC reps
... if you see the AC review result of the IG Charter, you can see we got comments from the AC

matthias: we'll fix the draft WG Charter to get group resolution on July 27
... and get W3C Management approval for the AC review
... we'll start the AC review on Aug. 24 until Sep. 21
... this is a tight schedule
... if we get many comments from the AC, the WG launch might be delayed
... so if you have contacts from other Members, please contact them

dsr: it's kind of vacation season, so we should do that quickly

matthias: any questions?

(no questions)

matthias: so we should dive into the issues on GitHub
... got a response from Ericsson
... coordination with the HW security group
... charter draft of the HaSec WG

-> https://lists.w3.org/Archives/Member/w3c-ac-members/2016AprJun/0005.html

kaz: WG proposal had objections
... and the resolution was creating a CG instead

-> https://github.com/w3c/wot/issues WoT IG issues

matthias: next object security

-> https://github.com/w3c/wot/issues/210 object security issue

matthias: a pull request from Ari as well
... we have consensus to add this
... next coordination issue

-> https://github.com/w3c/wot/issues/207 coordination issue

matthias: IG has a long list of organizations
... the coordination for the WG is checking the specs
... initial proposed list here

kaz: we can start with this list and add some more later if needed

dsr: how about Web Crypt WG?

matthias: could you respond to the issue 207 and mention the resource?

dsr: sure

<dsr> The web crypto WG is at http://www.w3.org/2012/webcrypto/

matthias: next intro/concept illustration issue

-> https://github.com/w3c/wot/issues/206 intro/concept issue

matthias: editorial changes
... next still lots of issues on the obsolete repo
... raised by Sebastian and Michael but all of them have been transfered to the new repo

kaz: will close all of them

<scribe> ACTION: Kaz to close all the remaining issues on the obsolete GitHub repository for the Charters (=charter-drafts) in http://www.w3.org/2016/07/13-wot-minutes.html#action05]

matthias: last one
... issue on interoperability

-> https://github.com/w3c/wot/issues/174 consistency issue

matthias: still waiting for response from Jonathan, but we should be able to close this

(no objections)

matthias: so let's close this
... closes issue 174
... the other thing is wording

-> https://github.com/w3c/wot/pull/104 wording issue

matthias: time series instead of streams

dsr: use cases are business driver

matthias: high impact to implementations
... want to be safe

dsr: streaming is already on the Current Practice document

matthias: we can easily include existing scheme

dsr: quite common to use streaming for small devices
... depends on what kind of device you're using
... streaming is quite popular for IoT

joerg: we had discussion during the breakout yesterday
... we'll restart our Use Case work
... good to have explicit links on your proposal

matthias: on the other hand, we're talking about the WG Charter

dsr: the IG should do more than Use Cases

joerg: we had discussion during the breakout yesterday
... and the discussion was kind of controversial
... we need experts' references
... to better understand the use cases
... we need to make progress
... may need links to reference implementations
... provides very precise expression on his idea

matthias: we need to be very careful about the working for the WG Charter

dsr: several companies require streaming
... we should generate some concrete wording so that people outside this IG can understand it
... we have to clarify our intention

nimura: terminology on streaming and pub/sub is confusing

matthias: shows the draft WG Charter document
... we want editors and contributors

-> http://w3c.github.io/wot/charters/wot-wg-2016.html draft WG Charter

matthias: deliverables section

-> http://w3c.github.io/wot/charters/wot-wg-2016.html#deliverables deliverables

matthias: would like Kajimoto-san to take care of Architecture

kajimoto: ok

matthias: and TD by Sebastian

sebastian: ok

matthias: if you are also interested, raise your hand
... Scripting APIs by Johannes

johannes: ok

joerg: also we should identify who is active on which topic
... thought Fujitsu was interested in scripting api

matthias: the last item is Protocol Binding
... I myself
... also Michael should be interested
... something we need to work on is Test Cases
... for test suites

(no objections or questions)

matthias: ok we'll move forward to the next agenda item

nimura: interested to join the Scripting API work

-> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_July_2016,_China,_Beijing#Thursday.2C_14th_of_July.2C_WoT_IG_Meeting agenda

joerg: we've done the first agenda item
... we'll switch the topics and talk about the Home appliance Vocabulary topic first

Home Appliance Vocabulary

dsr: shows his slides again
... (Web of Things - Web Scale Interoperability)
... interoperability based upon metadata
... need to start work on semantic vocabulary
... home appliance is a good starting point
... (Scott Jenson's comments on 16 June 2016)
... (Who is working on Smart Homes)
... list of SDOs
... home gateway initiative, allseen, cenelec, ...

yongjing: please include oneM2M
... home appliance model
... quite similar to the Thing Description
... the concept is same

dsr: more extensive survey is needed

kajimoto: ECHONET has clarified vocabulary for smart home appliance
... also for the automotive area, Google and Apple promote their work
... the leader is Toyota in the auto world
... they also define some semantic information for automotive
... this is an area of industries
... the other is IIC

dsr: (Home Gateway Initiative)

joerg: we have several people on the queue

sebastian: generic approach on industry domains within EU project, OpenIoT

dsr: this is an initial list

kaz: Dave, are your suggesting we should try some more extensive survey about this for the Tech Landscape doc?

dsr: let's talk about that after the presentation

joerg: there are so many organizations working on semantic vocabulary
... we're interested in interconnection rather than each industry area
... afraid open survey is impossible
... also if we look at the original Scott's email, his original intention was different
... contributions on interexchange is our target
... wondering what would be the reasonable approach
... what would be your recommendation?

dsr: we don't have to create concrete vocabulary
... and we should investigate some specific area as an example

(some more discussion on the objective of the proposal)

joerg: need clarification on our target, interexchange or specific industry area

kajimoto: my understanding for Scott's message is quite similar to the one of Joerg
... there was not any strong intention for the WoT IG to handle specific industry vocabulary

dsr: right

kajimoto: we should not jump in a specific industry domain
... home appliance manufacturers themselves should work on the issue
... meaning the necessary semantic vocabulary for their own specific industry area
... Thing Description is a good candidate as the mechanism to describe that

dsr: agree
... but we need to demonstrate how to use the semantic model using Thing Description
... continues his presentation
... (Gateway)
... (Google Smart Home)
... bluetooth, wifi, ...
... (Apple Homekit)
... (Samsung SmartThings)
... (Francis Daoust's List)
... (Smart Home Appliances)
... very few people will want to be locked to a single platform provider
... (Francois says...)
... (Common Device Categories)
... (Common Characteristics)

<Yongjing> http://www.onem2m.org/component/rsfiles/download-file/files?path=Release_2_Draft_TS%255CTS-0023-Home_Appliances_Information_Model_and_Mapping-V0_10_2.doc&Itemid=238

dsr: brightness, ...
... (Summary)

<Yongjing> this is the latest oneM2M Home Appliances Information Model

dsr: semantic models of devices and characteristics
... further work is needed to study the details
... how to work with other industry alliances/SDOs
... PlugFest demos for services that work with devices

<Yongjing> oneM2M also did some survey on existing home appliance models: http://www.onem2m.org/component/rsfiles/download-file/files?path=Draft_TR%255CTR-0017-Home_Domain_Abstract_Information_Model-V1_0_1.doc&Itemid=238

dsr: should the WoT WG Charter scope enable standardization of such models?

matthias: several comments
... really confused
... Scott didn't raise this proposal itself

<Yongjing> how to get in the queue?

matthias: we have to be careful
... we should not build any industry specific vocabulary ourselves
... should rather use linked data mechanism for existing ontologies
... this is already available for smart home
... we're working on horizontal framework to interconnect with existing industry ontologies

(some discussion between Matthias and Dave on interexchange framework vs vocabulary)

matthias: this kind of work should be done by a BG or a CG
... and this work should not stop our technical work

yongjing: has just put links for oneM2M resources
... regarding the semantic interoperability, we could think about the mapping mechanism with existing ontologies
... Sara is RDF and could be easily integrated

dsr: proposed whitepaper is still in early stage

yongjing: oneM2M has survey document on existing SDOs as well

<Zakim> jhund, you wanted to emphasize the work on tooling and process rather than content

jhund: wanted to emphasize the work on tooling and process rather than content

dsr: we have the data model, i.e., Thing Description
... also have an idea of domain templates

jhund: what is your concrete use case?

dsr: demonstrate cross-domain interoperability
... for service composition

joerg: what would be the next step?

kajimoto: totally agree with the motivation and the goal
... however, each specific industry stakeholder, e.g., Panasonic, has already studied vocabulary for this purpose
... and this work should be done outside of the WoT IG
... we WoT is not an authority to handle the expected vocabulary
... why don't you create another group to handle this?
... the "Standard" we as the WoT IG should do is different from defining vocabulary

dsr: agree

kajimoto: each specific domain stakeholders themselves should create vocabulary for their own industry

dsr: this is demonstrating the expected semantic interoperability
... not defining the vocabulary itself

joerg: wondering what the best way to proceed...
... what can be the possibility?
... maybe you can look into the work of oneM2M
... we can look at the survey result during one of our teleconfs
... and Scott joined our meeting in Sunneyvale, we should try to talk with him again
... and see their intention
... why don't we invite him to our teleconfs?

(ok)

<scribe> ACTION: Yingying to invite Yongjing to the WoT IG call [recorded in http://www.w3.org/2016/07/14-wot-minutes.html#action06]

<scribe> ACTION: joerg to invite Scott Jenson to the WoT IG call [recorded in http://www.w3.org/2016/07/14-wot-minutes.html#action07]

sebastian: we should rely on existing ontologies
... nice to get more experience

<Yongjing> oneM2M base ontology: http://www.onem2m.org/component/rsfiles/download-file/files?path=Release_2_Draft_TS%255CTS-0012-oneM2M-Base-Ontology-V0_10_0.doc&Itemid=238

joerg: can we make the two points as the conclusion?

<DarkoAnicic> q+

(no objections)

joerg: 1. Yongjing to provide report on oneM2M and the whole IG will talk about semantic interoperability during the web conf
... 2. Joerg to invite Scott Jensen to our IG Web conf and the IG exchange opinions with him

yongjing: have already provided resources on oneM2M work
... and happy to explain them
... on the other hand, would like to invite W3C experts to the oneM2M call or f2f

Scripting API

jhund: how to do local discovery?
... need read access to the Thing Description, i.e., ConsumedThing.getTD();
... event handling and decorators
... extended sepc with optional parts/hints for runtime implementers
... optional arguments / default values (and overriding them)
... syntactic sugar: operator overloading, getter/setters
... synchronous wrappers
... directly access the results
... any questions? unclear points?

sebastian: query parameters

nimura: relationship between "exposedThing" and WoT API

kaz: support for behavior definition by event-driven state machines

jhund: Results

<Max> Dapeng Liu, my nick name is Max

jhund: local discovery
... need to discover all the voters for PlugFest
... can be misleading and complicated
... visits thingweb/plugfest-scripts
... shows the discover api
... "WoT.getLocalThing();"
... any objections?

dsr: better to have one API
... probably questionous to have asynchronous api

sebastian: not sure about local vs global
... good to have that as parameter
... WoT.discover('local', {'name' : 'voter'})

jhund: good point
... we need to define additional behavior

nimura: the purpose is to mash up

jhund: discover expose thing?

nimura: maybe part of Thing-to-Thing interaction

jhund: WoT.getExposedThing(); returning ExposedThing

(ok)

jhund: "returning Promise resolving to" instead of "returning"
... next, Getting TD from Object
... opinions?

dsr: returning actual objects

max: comment on the agenda
... can share some ideas using 1-2 slides

joerg: have discussion with Max

dape: would agree to simply return the JSON object

jhund: Dave's proposal was not to own interface but runtime's parsed JSON object

dape: ok

nimura: fine

jhund: any objections?

(no objections)

jhund: consensus to return runtime's parsed JSON objects
... ExposedThing and ConsumedThing should offer getTD(); to retrieve a parsed JSON object of the TD
... regarding event handling
... not sure if we have enough experts here
... visits wot repo

<inserted> https://github.com/w3c/wot/issues/173

jhund: discussion with Tobie from Generic Sensor (by DAS WG)
... maybe would put this topic on the agenda of our call
... Event handling postponed to a Web call
... next, Optional arguments / default values
... add function parameter for RequestParams as given in TD to invokeAction, get/setProperty, possibly events
... next, Relationship between ExposedThing and WoT API

-> https://github.com/thingweb/plugfest-scripts/blob/master/beijing072016/counter.js counter.js

(some discussion between Johannes and Nimura-san)

jhund: we should define event for TD change

nimura: ok

jhund: next, Support behavior definition by event-driven state machines

kaz: Apache Web server has a module as an implementation of SCXML processor

jhund: can you outreach some of the SCXML experts?

kaz: will do

jhund: Kaz to outreach for experts about state chart XML

<scribe> ACTION: kaz to outreach SCXML experts for scripting discussion [recorded in http://www.w3.org/2016/07/14-wot-minutes.html#action08]

Reports from breakouts

joerg: yesterday we had breakouts on Type System and Subscription
... and we talked about them this morning

[ 15-min break till 12:15 ]

IoT Device Identity Management

max: (Use Cases - Why we need a trust ID?)
... device-based charging
... remote control
... keys provision
... (Flow Example)
... IoT device - IoT service platform - ID management platform
... 1. IoT device sends ID and request random seed of sid to the ID management platform
... 2. ID management platform send the seed back to the IoT device
... 3. IoT device generates AuthCode
... 4. IoT device signs the AuthCode with device's private key
... (The IoT ID Management Ecosystem Example)
... many different roles here
... 3rd party service works as the "ID and Data Management platform"
... Max explains the data flow of the ecosystem diagram
... security requirements are relatively high in some use cases

liu: in your flow example, what kind of key was used?
... how to provide the key?

max: how to protect our private keys?

liu: right

max: private key will not be transferred

liu: what is your method?
... using UACC?

max: cryptography itself is out of scope of this diagram

jhund: using semantic encryption?

max: the platform needs to know the public key

jhund: the ID will allow me to generate the key?

max: this ID is just an index for the key

jhund: regarding the ecosystem example

<yongjing> request q

max: hardware vendor is responsible to the communication between the vendor itself and the others

sebastian: each device trustable?
... the real problem is how you could trust the data and devices
... we're considering the application layer not the hardware layer

max: each layer should have different level of security

mingyu: this is related to service security?
... seems like the point is certification rather than ID

max: this is just one example

mingyu: how can you prevent copying IDs

max: ID management platform handles that
... if public key is stolen, private key is safe

mingyu: your point is verification of ID rather than ID itself

max: how to manage the ID itself is out of scope

(detailed discussion to be made offline)

joerg: intensive security/privacy discussion
... the mechanism you put here is similar to the work by IRTF's T2T group
... taking this proposal as input for our use case work is good

max: great
... will also join IRTF meeting myself

matthias: would suggest you talk with Oliver (the security TF moderator) as well

Report from the Type System breakout

taki: optimized JSON Schema
... possibly explore the possibility of mapping the optimized JSON Schema to JSON Schema
... what is the objective of Type System on the WoT layer?
... need to allow the use of existing type systems like RDF
... property needs to have both input/output definition

joerg: next steps?

taki: Dave and Sebastian start their investigation on the Optimized JSON Schema

<scribe> ACTION: Dave and Sebastian to investigate on the Optimized JSON Schema [recorded in http://www.w3.org/2016/07/14-wot-minutes.html#action09]

Report from Subscription breakout

jhund: report on the GitHub

-> https://github.com/w3c/wot/blob/master/meeting-results/beijing-f2f/wot-f2f-beijing-subscriptions.md Report from the Subscription breakout

jhund: self-containing vs delta
... severity of loss / ensured delivery
... equidistance in time vs spontanous occurence
... history/buffer vs only most recent value
... Micro Use Cases
... 5 type of clusters
... 5 different types of application patterns

dsr: reading several data topics at the same time
... we should use more time to collect use cases

jhund: ok

kaz: had similar discussion yesterday during the breakout
... our strategy is collecting this kind of micro use cases first
... and think about how to manage multiple data at once later

sebastian: what does "delta" mean?

jhund: one of the distinctive requirements
... "delta or not" means "whether a single sample make sense or not"

sebastian: ok

jhund: the whole idea of this practice was how to handle implicit subscription

joerg: we'll take this as the starting point
... and continue the work
... any further comments?

(no comments)

[ lunch until 14:00 ]

IG organization

joerg: ToC
... report from the Comm TF
... IG Charter
... WG Charter
... Deliverables documents
... PlugFest prep
... Meeting logistics

-> https://www.w3.org/WoT/IG/wiki/images/f/fd/W3C_WoT_Logistics_160413.pdf Joerg's slides

sebastian: regarding the deliverables, how to handle the outcome of the group meeting?

joerg: adds that point
... Yingying can you talk about the Comm TF?

Comm TF

yingying: 6 topics here
... IG blog
... Testimonials on the WoT landing page
... Call for Implementations
... todo: restructure the wiki
... Liaisons
... no one responded so far
... todo: speicific contact person per each liaison
... Events
... todo: identify the key eents
... need resources
... Flyers and Salessheet
... whitepaper generated

joerg: tx
... comments?

sebastian: collections of Implementations
... just listing implementations wouldn't make much sense
... we should have discussion on this

dsr: how to handle the results is important
... which one would fit with the Current Practices document, etc.

joerg: we could go through each entry of this list
... and see how to handle each entry
... into several categories

dsr: sounds like a reasonable idea
... possible key point is what kind of protocol they're using
... would like to build good relationship
... regarding the other Comm task, how to encourage people to blog the group's work, etc.

-> https://www.w3.org/WoT/IG/wiki/Implementations WoT implementations list

jhund: it might be quite confusing if they are working with us
... so should clarify who are working with us
... what kind of approach is used on their side
... outreaching to the people behind the implementations themselves would be helpful

dape: we do have a list of categorized participation in PlugFests
... we could refer to that

kaz: can you put the resource of that information?

joerg: we discussed outcome from PlugFests
... using an Excel sheet
... the first step could be putting the information together
... who participates in PlugFests

dsr: @@@

joerg: PlugFest online?

dsr: some people could join online

jhund: we can somehow arrange to contact people who implemented these implementations?
... joint activity is good
... some people may not join f2f and need to join online

dape: we could have opened the port to report participants
... but there was a difficulty
... during the next meeting, we should set up remote configuration and make sure it will be stable

joerg: for example, IRTF T2T guys could join remotely
... why not to try to find out a convenient day for them?
... maybe we could even try a completely online PlugFest

<DarkoAnicic> +q

joerg: 2 step approach
... do the excersise within the group and @@@

jhund: it would be hard to understand the mechanism/technical issues if completely online

darko: would agree with Johannes
... how to make sure the demo scenario is already difficult
... using a template (as Matthias suggested) would be useful

sebastian: maybe we should use not only one day but some more days for preparation

yingying: how could we reachout these guys?

darko: maybe we could start with Members

sebastian: we could see how other groups manage this kind of work

<yongjing> have to leave early. Nice meeting you all this week. bye :)

jhund: maybe I could take out an action to reachout an expert

joerg: shows the Status page again
... updated the TODO list for "Call for Implementation"
... restructure te collections on wiki, outreach to the people to get engaged, conduct also PlugFests online

yingying: there are only limited people in the Comm TF

joerg: these actions are for the whole IG
... we as the IG will do the categorization of implementations
... Daniel, can you check the descriptions on the list?

dape: will do

joerg: and we'll discuss this based on that

<scribe> ACTION: dape to check directly with the implementers and see who have participated in the PlugFests so far [recorded in http://www.w3.org/2016/07/14-wot-minutes.html#action10]

<trackbot> Created ACTION-71 - Check directly with the implementers and see who have participated in the plugfests so far [on Daniel Peintner - due 2016-07-21].

joerg: move forward
... IG Blog

dsr: would encourage more people to contribute to the Blog
... suggestion is
... would like to have blog posts by the PlugFest participants

joerg: even with pictures
... taki on template
... as we need the scenario template document anyway
... to contact the participants and compile the scenarios
... we have pitch slides and could have some more text (based on the template)
... and we could have some pictures
... those could be input for the possible blog post

<scribe> ACTION: taki to generate a template of PlugFest description [recorded in http://www.w3.org/2016/07/14-wot-minutes.html#action11]

dsr: Daniel is working on the Flyers
... would some sponsorship for printing

joerg: updates the Status slide
... IG Blog: Draft a blog entry reporting about the last PlugFest (including a picture) [PlugFest Participants]
... and about the Flyers?

dsr: yes

joerg: do we need to add anything here?

(some more discussion about flyers)

yingying: reports the cost for printing

joerg: todo: review in IG, check the cost and make them ready before TPAC
... there is a link on the Status slide
... any other concerns?

(none)

joerg: next, Liaisons
... need care takers for each liaison
... shows the wiki

-> @@@l

joerg: comments?
... discussion on ITU-T yesterday
... this is something the Comm TF bring to the main group, and the main group can review it
... we need to go through the list
... let's say in 3 weeks
... and ask for volunteers
... for the contacts from our side
... August 3
... 3 weeks to check with

(no more comments)

joerg: further comments?

dsr: maybe people here are not enthusiastic with outreach
... but there may be somebody from your company who work on outreach

joerg: next is IG Charter status

-> https://www.w3.org/2002/09/wbs/33280/wot-ig-2016/results AC review results (member-only)

joerg: 31 positive votes so far

dsr: may be sent to W3M next week

joerg: complementary to upcoming WG Charter
... next steps
... looking for a co-Chair
... will reorganize work on the deliverables
... we have some outcome from the meeting discussion
... some probably prefer the Architecture and the Current Practice
... and some more in scenarios
... we had controversial discussion on subscription
... scenarios behind
... important to handle Use Cases/Requirements and Scenarios
... what would be the best way?

kaz: how about creating dedicated TFs for each deliverable document?

<sebastian> ack

sebastian: there are many existing solutions and we should see those practices

dsr: some regular slots could be assigned during the IG call

joerg: during the last several months, we've been working on the Charters
... having said that it's important to have technical discussion
... also we should ask others for contributions

liu: I'm not an expert of Web but maybe how to deal with IoT technology is an important question

jhund: we're discussing how to make the Web accessible to the devices
... for constrained devices, we may use EXI as the data format

liu: for the application layer some optimization is needed (?)

jhund: we're still keeping the design

liu: we should think about optimization (on each layer?)
... on the application, there are so many message handlers

joerg: cross-layer optimization is important
... and it's a trade-off
... simplicity of application vs cost
... we need to experiment how high the cost would be

dsr: in the architecture of WoT, a lot of communications are allowed
... CoAP, HTTP, etc.
... we should do what kind of protocols are used

joerg: how do we arrange our calls and actions?
... reserve certain time for technical discussion is good
... we need responsible persons for these deliverable documents
... next, WG Charter draft
... we discussed it this morning
... p2p feedback
... on track wrt the WG roadmap
... comments?

(none)

joerg: next, Logistics
... work setup
... fix time slots
... restart on 20 July
... agenda includes: open actions, technical discussion, housekeeping deliverables, focus of next call?

jhund: follow-up on subscription/events/streams -> UC&term

joerg: one other topic is sketching out the TPAC meeting
... share ideas how to setup (technically) the demo at TPAC
... then, time to discuss the next f2f
... IETF 96, RIOT Summit in Berlin
... and TPAC 2016 in Lisbon on Sep. 22-23
... expected demo session on 21?
... preparation on 20 afternoon?
... is a small room available for that purpose?

kaz: will check with the Meeting planner team

joerg: WoT IG f2f on Sep. 22-23
... joint meeting with IRTF on Sep. 24-25
... may be different place than the TPAC venue
... meeting after TPAC?

kajimoto: April would be a very good season for Japan :)
... Panasonic can host a meeting

joerg: have idea on a concrete date?

kajimoto: let me check

joerg: updates the slide
... January, idea in US?
... April, in Osaka, Japan

-> https://www.w3.org/2016/09/TPAC/schedule.html TPAC schedule page

dsr: regarding US, possibly could get a company instead of MIT

joerg: all are encouraged to see the possibility of hosting the January meeting within the upcoming three weeks

kaz: the expected place for January is US?

joerg: yes
... the expected date is Jan. 23-27

dsr: if we have a WG at that time, how do we want to arrange the meeting?

joerg: maybe we might want to keep the current configuration
... WG guys might be going to join the IG meeting as well
... let's keep the initial proposal as 4 days

jenny: not a good idea to hold the meeting at that time due to the Chinese New Year holidays

<inserted> joerg: updates the slides and put "Jan. 30-Feb. 3" as the candidate for the January meeting

joerg: we should see if there are any other conflicts
... Kaz, please conduct a poll to see people's availability
... July, possibility in Europe/Germany
... before closing the meeting, would like to appreciate the host, CETC, again
... there were many activities during the meeting
... would appreciate the W3C Beihang Team
... also other W3C Team colleagues who took minutes
... have a nice time and travel back home

<scribe> ACTION: kaz to conduct a WBS poll to see people's availability for the January-February meeting [recorded in http://www.w3.org/2016/07/14-wot-minutes.html#action12]

(and thanks to our friendly Chair :)

[ f2f adjourned ]