See also: IRC log
<kaz> joerg: starts introduction on the IG work
<kaz> ... (WoT IG Roadmap (1/2))
<kaz> ... discussion on Use Cases; atomic use case to bridge application domains
<kaz> ... three building blocks: Script API/protocol mapping, Discovery, TD and Security/Privacy
<kaz> ... meetings in Sunnyvale, Sapporo, Nice and Montreal
<kaz> ... generating a document, "Current Practice"
<kaz> ... compilation of demo experience
<kaz> ... and in parallel working on the WoT Architecture document
<kaz> ... (WoT IG Roadmap (2/2))
<kaz> ... we're about to prepare for a Working Group
<kaz> ... identifying particular work items for the WG
<kaz> ... also generating a draft Charter for the WG
<kaz> ... we'll update the current practice document
<kaz> ... we have some more topics
<kaz> ... discussion on the concrete scenario
<kaz> ... that is a snapshot of the agenda for this meeting
<kaz> ... we're preparing the release of the IG deliverable documents
<kaz> ... also preparing for the WG expecting to start it by the end of the year
<kaz> ... identified how the IG will work for further exploration of new WoT building blocks
<kaz> ... comments or questions?
<kaz> (none)
<kaz> joerg: another slide
<kaz> ... (WoT IG Work in Iterations?)
<kaz> ... Use Cases/Requirements -> Identify WoT Building Blocks -> Tech Landscape -> Architecture and Current Practice -> External Communication & Collaboration
<kaz> ... particular discussion on the concrete scenarios
<kaz> ... iterating documents
<kaz> ... on the right side, we have more practical things
<kaz> ... demos -> PlugFest
<kaz> ... we'll have our next meeting in Lisbon during TPAC 2016
<kaz> Xuequin: resource on the documents?
<kaz> joerg: on the group wiki
<kaz> WoT IG wiki
<kaz> joerg: please see "Ongoing work documents" section
<kaz> Ongoing work documents section
<kaz> joerg: going through the agenda
<kaz> Beijing f2f agenda wiki
<kaz> joerg: 9:30 Breakout Introductions: Protocol Bindings, UC/Req, Type Systems, Resource Parameters, TD lifecycle, Scripting API
<kaz> ... after coffee break, we'll have 2nd breakouts
<kaz> ... then lunch
<kaz> ... after lunch breakouts again
<kaz> ... and afternoon break
<kajimoto> kaz-san, the lady who asks on the documents of WoT IG is Xuequin Jia from China Unicom
<kaz> joerg: and breakouts
<kaz> ... goes through Thursday
<kaz> ... we'll have a lot of breakout sessions
<kaz> ... below the agenda, there is "Input/Comments on the agenda"
<kaz> ... how we deal with these proposals
<kaz> joerg: discussion on "call for implementation" results
<kaz> ... follow up on IoT Open System Architecture discussion
<kaz> ... Kepeng Li: Contribution to WoT Security & Privacy
<kaz> (Kepeng is not here at the moment)
<kaz> joerg: do we have further contributions?
<kaz> xueqin: China Unicom: information exchange on common aspects related to TD
<kaz> joerg: right now we have TD-related breakout sessions, type systems and lifecycle
<kaz> dsr: how long do we need for each breakout?
<kaz> sebastian: resource parameters wouldn't take long
<kaz> matthias: we'll have quick pitches during the breakout introduction
<kaz> xueqin: would provide brief description
<kaz> joerg: everybody can provide quick pitch
<kaz> ... we also have follow-up discussion on the IoT Open Architecture
<kaz> dsr: yesterday's panel session was a good starting point
<dsr> we could make further progress in a smaller group
<kaz> ... and we could make further progress in a smaller group
<kaz> kaz: maybe their work is related to TD lifecycle as well
<kaz> matthias: detailed dialogues by a smaller group would be better
<kaz> +1
<kaz> joerg: coming back to the breakout introductions
<kaz> ... would like to have brief self introductions
<kaz> ... name, affiliation and background
<kaz> ... starting with myself
<kaz> (everybody introduces him/her-self)
<kaz> joerg: take a look at our documents
<kaz> ... joint meetings with the W3C Automotive group
<kaz> ... also IRTF T2T group
<kaz> ... welcome for security/privacy discussion
<kaz> ... second point is implementations by open source projects
<kaz> ... testing against our own implementations
<kaz> ... we'll discuss our "call for implementations" tomorrow
<kaz> ... now would like to start the breakout introductions
<kaz> matthias: Explicit Protocol Bindings
<kaz> ... 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
<kaz> matthias: explains the CoAP binding
<kaz> ... who is interested?
<kaz> ... 8 people raise their hands
<yingying_> https://github.com/w3c/wot/tree/master/proposals/subscriptions
<kaz> johannes: proposal on resourceful handling of subscriptions for REST (for Michael Koster)
<kaz> ... take a look at this during the breakout
<kaz> ... which solution would fit which issue
<kaz> ... what problems would be addressed
<kaz> ... who is interested?
<kaz> ... 10 people raise their hands
<yingying_> https://github.com/w3c/wot/tree/master/proposals/type-system
<kaz> taki: quick introduction
<kaz> ... (What is Type System?)
<kaz> ... (Type System in Human Communication)
<kaz> ... what kind of data you send to the counter part
<kaz> ... Date, Time, Number of people, Name, etc.
<kaz> ... (Type System in WoT)
<kaz> ... Semantics: Meaning, Intention, Purpose
<kaz> ... Type System: Abstract Type Definition
<kaz> ... Data Representation
<kaz> ... (Abstract Type Definition)
<kaz> ... Abstract Type Definition using JSON Schema
<kaz> ... representation binding with possible data formats: JSON, XML, EXI, etc.
<kaz> ... (Example 1 - Simple Data)
<kaz> ... Type definition -> JSON/XML binding
<kaz> ... (Example 2 - Structured Data - Object)
<kaz> ... ID and name
<kaz> ... (Example 3 - Structured Data - Array)
<kaz> ... (Type System Breakout Topics)
<kaz> ... comments on incorporating JSON Schema as a whole into the spec is too much
<kaz> ... but applications need to have type system anyway
<kaz> ... how to cooperate with deviation?
<kaz> ... semantic annotation by type system or external mechanism?
<kaz> joerg: who is interested?
<kaz> ... 9 raised their hands
<yingying_> https://github.com/w3c/wot/tree/master/proposals/resource-parameters
<kaz> sebastian: next topic addresses Thing Description
<kaz> ... (Resource Parameters)
<kaz> ... (Problem Statement)
<kaz> ... defining data model
<kaz> ... who is interested?
<kaz> yongjing: not sure about the point
<kaz> sebastian: resource description using query parameters
<kaz> ... or payload data
<kaz> ... query parameters are popularly used today
<kaz> yongjing: could join the discussion
<kaz> sebastian: who is interested?
<kaz> ... 7 raised their hands
<yingying_> https://github.com/w3c/wot/tree/master/proposals/td-lifecycle
<kaz> matthias: TD Lifecycle
<kaz> ... (Thing Description Lifecycle)
<kaz> ... Thing Description will grow and change over the lifetime of the "Thing"
<kaz> ... how to keep the information updated?
<kaz> ... who is interested?
<kaz> ... 16 raised
<kaz> joerg: the last one is scripting API
<yingying_> https://github.com/w3c/wot/tree/master/proposals/restructured-scripting-api
<kaz> johannes: Breakout proposal: Scripting API
<kaz> ... (Scripting API)
<kaz> ... portable script which could be transfered from WoT Servient A to another WoT Servient B
<kaz> ... (ConsumedThing)
<kaz> ... (ExposedThing)
<kaz> ... (Script Example (Client API))
<kaz> ... (Plugfest Findings / Topics)
<kaz> ... how to do local discovery
<kaz> ... need some way to access TD
<kaz> ... extend the spec with optional parts/hints for runtime implementers
<kaz> ... event handling and decorator
<kaz> ... some more points during the breakout session
<kaz> ... who is interested?
<kaz> ... 13 raised
<kaz> joerg: we should ask Chine Unicom as well for short introduction
<kaz> xueqin: Sharing China Unicom's Views on things desciption in IoT
<kaz> ... (Background)
<kaz> ... would like to share our views on things description
<kaz> ... ITU-T SG20 work item Y.IoT-things-description-reqts
<kaz> ... initiated by China Unicom, CETC, China mobile, etc.
<kaz> ... (Overview of things description in IoT)
<kaz> ... (diagram)
<kaz> ... mapping between Physical Thing and object using the Things description
<kaz> ... (Relationship between things description, information model and description language)
<kaz> ... need to clarify the concept
<kaz> ... Things description is composed by the information model and the description language
<kaz> ... (Things description methodologies in IoT)
<kaz> ... Semantics-based things description
<kaz> ... uses semantic description language like RDF
<kaz> ... relatively heavy and not popular for light-weight devices
<kaz> ... Abstraction-based things description
<kaz> ... JSON and XML are popular
<kaz> ... simpler and lighter, so widely used
<kaz> ... but weakness on the aspects of interoperability
<kaz> ... Hybrid things description
<kaz> ... special type of abstraction-based approach
<kaz> ... interested in working here
<kaz> sebastian: tx!
<kaz> ... we should organize a session to synchronize with each other
<kaz> ... maybe query parameter topic would not take long
<kaz> dsr: tx to introduce this work
<kaz> ... would like to explore the heavy approach and the hybrid approach
<kaz> darko: very interesting
<kaz> ... we're thinking about similar things
<kaz> ... schema org, domain specific information
<kaz> ... 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
<kaz> sebastian: I'd like to propose we talk about query parameter because it would not take much time
<kaz> kaz: many people are interested in many topics
<kaz> ... do we really want to have these sessions as breakouts?
<kaz> joerg: good question
<kaz> ... need some more adjustment on the agenda
<kaz> ... shows the updated agenda on the screen
<kaz> (some discussion on the agenda building)
<kaz> (moving TD contribution by China Unicom after the TD Lifecycle session)
<kaz> joerg: how to identify the breakout rooms?
<kaz> kaz: we can call this room the Big Room and another room the Small Room (or "Not so Big Room")
<kaz> joerg: adds the room assignment (with "Not so Big Room")
<kaz> [ 15-min break ]
<kaz> matthias: shows example TD
<kaz> ... how the document should look like
<kaz> ... at the time of design, there are properties already
<kaz> ... name, uris, encodings
<kaz> ... interaction properties which are rather stable: name, valueType, writable, hrefs
<kaz> ... remember that Panasonic had a question on the time of manufacturing, product sold, etc.
<kaz> kazuo: shows his slides
<kaz> ... (Things Description Template Concept)
<kaz> ... 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
<kaz> s/Yonying:/Yongjing:/
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 talks about service lifecyle
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
<kaz> s|talks about service lifecycle|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|
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 externa 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
Xuequin: we will try to join future meetings
<kaz> s/Xueqing/Xueqin/
Darko volunteers on behalf of WoT IG to act as liaison point for the ITU-T
<Yohsumi> quit
<kaz> [ lunch till 1:45 ]
<ying_ying> breakout session: Type System
<ying_ying> scribe: ying_ying
taki went through the proposal on github
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.
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> dsr raised his hand.
<ying_ying> matthias: where are you on plugfest?
<ying_ying> 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
<ying_ying> matthias: I will copy the coap and http to the table.
<ying_ying> ...to show what protocols we are targeting on.
<ying_ying> ...sebastian will continue on parameters.
<ying_ying> kajimoto: for thing server supporting coap or http, same app can work almost the same. protocol binding is very important
<yingying> scribe: ying_ying
<yingying> matthias: app needs to talk with scripting APIs. what do we need to modify in resource model then come to the protocol binding
<yingying> ...I would suggest to do experiments to see how far we will go to TD for legacy device
<yingying> sebastian: e.g. two device supporting ECHONET can recognize each other and communication directly.
<yingying> ohura: I will show you one slide.
<yingying> ...2 kinds of protocol bindings: red one is for WoT protocol binding. the other blue one is the binding for legacy devices.
<yingying> ...we think red area is our scope of WoT IG.
<yingying> ...blue area: there are so many legacy devices we need to leave them to each industy.
<yingying> ...what do you think?
<yingying> matthias: this part should be red in gateway for WoT interface.
<yingying> ...BT LE is very close to resource model.
<yingying> ...we started experimentation how far we could go there.
<yingying> ...ganesh is working on it on BACNet.
<yingying> ...I think it's hard to draw the line here. I would encourage people to do experiments. Evaluate the complexity and benchmarking.
<yingying> ...legacy box coupled with the specific legacy protocol in WoT Servient diagram.
<yingyingchen> scribe: yingyingchen
<yingyingchen> [some discussion on BT LE]
<yingyingchen> kajimoto: the scope of protocol binding?
* yingying has quit (Ping timeout: 180 seconds)
<yingyingchen> ...we try to map http, coap, mqtt, etc.
* yingying_ has quit (Ping timeout: 180 seconds)
* ying_ying has quit (Ping timeout: 180 seconds)
<yingyingchen> ...if it's related to Web API, it's better.
<yingyingchen> 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.
* yiyichen has quit (Ping timeout: 180 seconds)
<yingyingchen> ...it could be a generic one that can translate the models between WoT and Legacy parts.
<yingyingchen> ...could minimize the efforts on GW.
<yingyingchen> kajimoto: GW and WoT are written by us and we understand.
<tidoust> yingyingchen, wrong channel? (no RRSAgent here in particular and generic channel on testing)
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.
<scribe> ...new device connect and agnostic to apps
UNKNOWN_SPEAKER: 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.
->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.
<yingying_> scribe: yingying_
<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.
<ying_ying> ...href field assigned there for default value. can override the default values.
<ying_ying> johannes: like the idea of default sets. some parameters are optional. API level can be optional.
<ying_ying> sebastian: agree, just where to put it, in parameters or in href?
<ying_ying> ...any other questions?
<ying_ying> scribe: ying_ying
<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.
<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?
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 if the WoT IG can get a breakout session including PlugFest demo on Wednesday [recorded in http://www.w3.org/2016/07/13-wot-minutes.html#action01]
<trackbot> Created ACTION-68 - Check if the wot ig can get a breakout session including plugfest demo on wednesday [on Kazuyuki Ashimura - due 2016-07-20].
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 ]
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/2)/2))/ Succeeded: s/next steps/concrete scenarios/ Succeeded: s/@@@/Xuequin/ Succeeded: s/on IoT industry 2020/on common aspects related to TD/ Succeeded: s/xuequin/xueqin/g Succeeded: s/... would skip protocol bindings for the moment// Succeeded: i|https|-> https://github.com/w3c/wot/tree/master/proposals/explicit-bindings Succeeded: s/, etc.// Succeeded: s/for/as well for/ Succeeded: s/ad/and/ Succeeded: s/model/model and the description language/ Succeeded: s/q=// Succeeded: s/need update/need some more adjustment/ Succeeded: s/stable/stable: name, valueType, writable, hrefs/ Succeeded: s/Yonying:/Yongjing:/ FAILED: s/Yonying:/Yongjing:/ Succeeded: s/Yongying:/Yongjing:/ FAILED: s|talks about service lifecycle|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| Succeeded: s/actitivities/activities/ Succeeded: s/proceed?/proceed? there are several possible approaches, e.g., W3C Liaison, your direct participation in this WoT group or simply joint technical discussion./ Succeeded: s/there are/as Dave mentioned, there are/ FAILED: s/Xuequing/Xueqin/ Succeeded: s/Xuequin/Xueqin/ Succeeded: s/dsr:/dape:/ Succeeded: s/"numeric"/"number"/ Succeeded: s/compound/an object when you want / Succeeded: s/or/of/ Succeeded: s/it is up to the companies to indicate which uses cases are important// Succeeded: s/action?/action and event?/ Succeeded: s/TD>/TD/ Succeeded: s/@2/ohura/ Succeeded: s/agnostic to others./agnostic to apps/ Succeeded: i/ganesh:/scribenick: yingying_ Succeeded: s/@@@/very compelling to have interoperable testing by many countries/ Succeeded: s/add/adding/ Found ScribeNick: dsr Found Scribe: ying_ying Inferring ScribeNick: ying_ying Found Scribe: yingying_ Inferring ScribeNick: yingying_ Found Scribe: ying_ying Inferring ScribeNick: ying_ying Found Scribe: yingyingchen Inferring ScribeNick: yingyingchen Found Scribe: yingying_ Found ScribeNick: yingying_ Found Scribe: ying_ying Found ScribeNick: ying_ying Found ScribeNick: kaz Scribes: ying_ying, yingying_, yingyingchen ScribeNicks: dsr, ying_ying, yingying_, yingyingchen, kaz Present: DarkoAnicic WARNING: Fewer than 3 people found for Present list! WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 13 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/13-wot-minutes.html People with action items: kaz[End of scribe.perl diagnostic output]