<kaz> mm: shows the draft charter for the OCF/WoT Liaison TF
<kaz> ... will merge the latest pull requests
<kaz> ... scope
<kaz> ... Enabling the use of web technologies enabled by the W3C WoT recommendations to OCF devices
<kaz> ... OCF has its own data model based on RAML
<kaz> ... (put proposals on the whiteboard)
<kaz> ... Next plugfest:
<kaz> ... OCF
<kaz> ... -> convert RAML data models to TDs
<kaz> ... -> generate interfaces
<kaz> ... -> based on T.S. WoT-node interface
<kaz> mk: what kind of interface?
<kaz> mm: (draws a diagram on the whiteboard)
<kaz> <img />
<kaz> mk: description using TD for OCF devices?
<kaz> mm: may have multiple RAML files for one TD
<kaz> sk: mapping TD to RAML as well?
<kaz> mm: (adds another direction from TD to RAML)
<kaz> ... conversion from RAML to TD and then go back to TD from RAML, and get the same content
<kaz> zk: so the TD can be converted to RAML and work for the OCF devices using REST/CoAP protocols
<kaz> (discussion on action and operation)
<kaz> dsr: naming convention?
<kaz> zk: you need to generate OIC request
<kaz> mm: (adds test cases to the interface conversion portion)
<kaz> ... round trip tests
<kaz> dsr: what about IoTivity?
<kaz> mm: bunch of physical devices
<kaz> ... we can have a simulator
<kaz> ... how do we create that?
<kaz> zk: we could use real devices
<kaz> ... do we have RAML Things?
<kaz> mk: this is all scratch and handling both the areas (WoT and OCF)
<kaz> mm: we should accumulate our efforts
<kaz> dsr: could you please gather TDs from PlugFests?
<kaz> sk: we can upload all the TDs
<kaz> jh: good to have some specific repo for that purpose
<kaz> mk: do we want just TDs or including background information as well?
<kaz> zk: good to have background information as well
<kaz> dsr: collecting ideas is valuable
<kaz> mm: we need more structured approach for testing
<kaz> dsr: you can start with TDs
<kaz> ... but need some more data, e.g., JSON, to generate tests
<kaz> kaz: who would lead this work?
<kaz> ... part of this OCF/WoT liaison?
<kaz> mm: right
<kaz> yz: (shares his screen)
<kaz> ... Initial Discussion on WoT-oneM2M Interworking
<kaz> ... Content: Interworking Scenarios, Information Model Mapping
<kaz> ... (Interworking Scenarios (1))
<kaz> ... exposing oneM2M interfaces to WoT systems
<kaz> ... (Interworking Scenarios (2))
<kaz> ... transparent interworking
<kaz> ... encapsulate the whole WoT data model into oneM2M containers/flexContainers
<kaz> ... sensors expose interface using WoT I/F
<kaz> ... application entity (AE) as inter-working proxy encapsulates TD
<kaz> ... another AE uses the TD
<kaz> ... not the best solution, though
<kaz> ... (Interworking Scenarios (3))
<kaz> ... direct resource mapping with TD (like SDT/HAIM mapping or AllJoyn Interworking)
<kaz> ... fine granularity but still some limitation
<kaz> ... (Interworking Scenarios (4))
<kaz> ... semantic interworking (using generic interworking framework and base ontology mapping)
<kaz> ... semantic interoperability and automated
<kaz> ... limitation: ontology mapping may not be fully compatible
<kaz> ... those are potential scenarios
<kaz> ... (Information model mapping (1))
<kaz> mm: what is the priority?
<kaz> ... what to start with?
<kaz> yz: scenario 1 would be the best
<kaz> ... other scenarios would let oneM2M to consume TD
<kaz> mm: oneM2M might have more flexible mechanism than OCF
<kaz> ... automated test for oneM2M situation?
<kaz> yz: don't have clear view yet
<kaz> ... need some solution
<kaz> ... would ask oneM2M guys for ideas
<kaz> dsr: would like to continue collaboration for next plugfest
<kaz> mm: generating TD (for WoT) and RAML (for OCF)
<kaz> ... how do we arrange testing?
<kaz> dsr: oneM2M model is XML-based
<kaz> ... maybe we could generate TD based on that
<kaz> mm: who does what?
<kaz> dsr: need more volunteers
<kaz> yz: maybe somebody from the oneM2M side as well
<kaz> dsr: node.js for accessing oneM2M module?
<kaz> ... maybe we can look into that
<kaz> ... should be able to create one with your help
<kaz> mk: there is a oneM2M module
<kaz> mm: we need to have something opensource-based
<kaz> dsr: any companies for volunteers?
<kaz> yz: would like to check within oneM2M
<kaz> mm: is anybody here in the meeting room actively involved in oneM2M?
<kaz> (no...)
<kaz> mm: we should get some representation from oneM2M
<kaz> dsr: we could invite external experts to PlugFest as well
<kaz> mk: question on scenario 4
<kaz> ... have you identified the mapping issue?
<kaz> ... we might want to have a narrow base ontology
<kaz> ... for atomic use cases
<kaz> yz: conflict from one domain to another
<kaz> kaz: question about how to coordinate
<kaz> mm: discussion on testing
<kaz> kaz: maybe at some point we might want to have a dedicated testing tf
<kaz> mm: make sense
<kaz> ... any volunteers?
<kaz> mk: raises his hand :)
<kaz> ... already done some work
<kaz> ... can give some guidance as well
<kaz> mm: you might want to generate a charter for that
<kaz> yz: continues his slides
<kaz> ... (Information model mapping (2))
<kaz> ... oneM2M Base Ontology
<kaz> Yongjing's slides
<kaz> yz: note that oneM2M doesn't model 'event'
<kaz> ... base ontology deines upper layer semantics for human understanding
<kaz> ... (Information model mapping (3))
<kaz> ... (Information model mapping (1)) again
<kaz> ... WoT TD also describes interface while SDT doesn't
<kaz> ... instantiation as HAIM
<kaz> ... (Information model mapping (3))
<kaz> ... semanticDescriptor
<kaz> ... oneM2M SD (semanticDescriptor) supports semantic discovery/query while WoT TD doesn't yet
<kaz> ... oneM2M SD is more distributed to resource level while WoT TD is more at the "thing" level
<kaz> ... oneM2M SD is using RDF/XML while WoT TD uses JSON-LD
<kaz> ... (Information model mapping (4))
<kaz> ... there are a lot of more metadata points
<kaz> ... WoT metadata/data is stored in more centralized way in TD while oneM2M metadata/data is more scattered into different resource types
<kaz> mm: questions?
<kaz> mkoster: driving use cases?
<kaz> ... two way bridging from one to another
<kaz> dsr: use cases which the current TD don't cover
<kaz> mm: event model difference is generic
<kaz> ... should have concrete use cases
<kaz> zy: basic mapping rules then concrete use cases, maybe
<kaz> mm: you're using ER diagram and RDF diagram
<kaz> ... we need information for TD model
<kaz> ... discussion yesterday as well
<kaz> ... what's the right way for information model regardless of serializations
<kaz> zy: don't have any specific preference
<kaz> ... maybe RDF?
<kaz> mm: zoltan, can you mark observable within OCF?
<kaz> ... any way to distinguish property within oneM2M?
<kaz> s/zonlatn, can you/can we/
<kaz> sk: would like to see this oneM2M ontology within our PlugFest
<kaz> ... nice to include it
<kaz> mm: compatibility between oneM2M ontology and TD?
<kaz> zy: mapping or annotation link?
<kaz> mm: another point is modularity
<kaz> zy: note it's difficult for oneM2M people to understand different data model like TD
<kaz> mm: thanks, coffee break now
<kaz> mk: after break, there will be scripting workshop at Santa Clara
<kaz> ... and semantics/connection to RDF at Board room
<kaz> [ morning break ]
The IRC channel for the Linked data and semantic processing break out is #wot-ld
<kaz> [ remote: Daniel, Darko ]
<kaz> (nimura-san is preparing for his presentation)
<kaz> kn: (Scripting API)
<kaz> ... scripting API provides means for discovery, provisioning and control of Things
<kaz> ... programmers don't have to care about protocols
<kaz> ... (1. ExposedThing)
<kaz> ... provisioning: development and setup
<kaz> ... exposeThing generate a TD and expose the server API
<kaz> ... 1. developer writes an app script using exposedThing with callback accessing a Thing
<kaz> ... (Runtime: Control of Thing)
<kaz> ... (Runtime provisioning: add Thing)
<kaz> ... (ExposedThing can be used in any layers)
<kaz> ... omitting consumedThing intentionally
<kaz> ... (ExposeTHing in various layers and combinations)
<kaz> ... (2. ConsumedThing)
<kaz> ... Provisioning: search a device initiates a discovery and setup a thing API to use
<kaz> ... 1. discover device
<kaz> ... 2. download TD
<kaz> ... 3. parse TD
<kaz> ... 4. expose client API
<kaz> ... (Runtime: Control of Thing)
<kaz> ... (Runtime provisioning: search and use another Thing)
<kaz> ... (ConsumedTHing can be used in any layers)
<kaz> ... layered mechanism
<kaz> ... client, cloud, gateway, device
<kaz> ... (ConsumedThing in various layers and ...)
<kaz> ... (Example: WoT Server/WoT Client)
<kaz> ... electronic applicance with WoT server is controlled by a remote controller with WoT client
<kaz> ... (3. WoT Servient (Consumed/Exposed Thing))
<kaz> ... the server on the right side exposes "Thing"
<kaz> jh: device side on the server and application side on the client?
<kaz> kn: yes
<kaz> jh: same app script for various setup, e.g., direct connection or remote?
<kaz> kn: right
<kaz> mk: the light should be connected with the server side, shouldn't it?
<kaz> ... script for device control is for low-level hard ware control
<kaz> zk: TD repository includes TD instance?
<kaz> jh: we need to describe interaction model first
<kaz> mk: what is the expectation for TD template?
<kaz> mk: use case behind template?
<kaz> jh: possibly we could have one declarative template
<kaz> ... or generate it programmatically
<kaz> ... keep it open for the both way
<kaz> mk: TD is generated on-the-fly
<kaz> ... what is the right time to put that to the TD repository?
<kaz> jh: maybe not all the runtime support on-the-fly generation
<kaz> ... we don't have any method to communicate with the TD repository so far
<kaz> ... there is a TF for discovery discussion
<kaz> zk: we could have a property and interpretation by some ontology
<kaz> ... OCF has some meta property
<kaz> ... including if the Thing is discoverable
<kaz> ... ontology for that could be standardized
<kaz> kn: we don't have that kind of ontology now
<kaz> ... comments from the telco includes
<kaz> ... consistency with TD format of the Santa Clara version
<kaz> ... semantic expressions as an optional parameter to the addXYZ methotds of ExposedThing
<kaz> ... also ConsumedThing/Discovery does provide semantic part already by "discovery filter"
<kaz> jh: we don't need to change those methods if the ontology changes
<kaz> zk: implementations need to know what is provided
<kaz> mk: this is application level
<kaz> zk: what my binding needs to do?
<kaz> ... how to generate some concrete OCF binding?
<kaz> jh: I see your point
<kaz> ... we could offer an API for semantic annotation
<kaz> zk: assuming applications can get information transparently?
<kaz> jh: yes
<kaz> mk: we don't have a model in which property can be observed
<kaz> jh: so far all the interaction is request/response
<kaz> zk: need a separate request about observable or not?
<kaz> jh: let's take another example for this discussion
<kaz> ... what is needed for the Thing level or the interaction level
<kaz> mk: question on Scripting API
<kaz> ... page 1
<kaz> ... "using scripting API..."
<kaz> ... need addition, e.g., to tell what the vocabulary and annotation is like
<kaz> zk: how to do that in a generic manner
<kaz> ... giving an example would be helpful
<kaz> jh: let's go through Nimura-san's slides and then have discussion later
<kaz> kn: p14
<kaz> ... (Example: Voting)
<kaz> kaz: question about the "client" and "server" inside the servient
<kaz> ... maybe it's misleading to have them within a servient
<kaz> mk: we should fix the diagram and have discussion during lunch, etc.
<kaz> ... this diagram is a good starting point
<kaz> kaz: ok
<kaz> kn: (Comments from telco)
<kaz> ... how to deal with installing apps
<kaz> ... exposeThing is less important because Things are already there
<kaz> ... but not the case for gateway/edge, etc.
<kaz> ... inspection model of TD
<kaz> ... consistence with TD format of Santa Clara version
<kaz> jh: tx
<kaz> ... many discussions on exposeThings and consumedThings
<kaz> ... (shares his screen on WebEx)
<kaz> ... Open Issues on the W3C Web of Things Scripting API
<kaz> ... session tomorrow
<kaz> ... had discussion on ConsumedThing
<kaz> mk: had added some comments here
<kaz> jh: consumedThing API
<kaz> ... getDescriptin() call
<kaz> Open Issues
<kaz> [[
<kaz> interface ConsumedThing {
<kaz> readonly attribute DOMString name;
<kaz> Promise<any> invokeAction(DOMString actionName, any parameter);
<kaz> Promise<any> setProperty(DOMString propertyName, any newValue);
<kaz> Promise<any> getProperty(DOMString propertyName);
<kaz> ConsumedThing addListener(DOMString eventName, ThingEventListener listener);
<kaz> ConsumedThing removeListener(DOMString eventName,
<kaz> ThingEventListener listener);
<kaz> ConsumedThing removeAllListeners(DOMString eventName);
<kaz> object getDescription();
<kaz> };
<kaz> jh: do we need method to get property?
<kaz> zk: why the consumed side does discovery?
<kaz> ... not sure why we need getDescription here
<kaz> mk: how to access the semantic description?
<kaz> ... more specific access through API for semantic description?
<kaz> jh: properties that belong to the representation vs meta-properties that belong the ConsumedThing
<kaz> [[
<kaz> interface ExposedThing {
<kaz> readonly attribute DOMString name;
<kaz> Promise<any> invokeAction(DOMString actionName, any parameter);
<kaz> Promise<any> setProperty(DOMString propertyName, any newValue);
<kaz> Promise<any> getProperty(DOMString propertyName);
<kaz> Promise<any> emitEvent(DOMString eventName, any payload);
<kaz> ExposedThing addEvent(DOMString eventName, object payloadType);
<kaz> ExposedThing addAction(DOMString actionName,
<kaz> object inputType,
<kaz> object outputType);
<kaz> ExposedThing addProperty(DOMString propertyName, object contentType);
<kaz> ExposedThing onInvokeAction(DOMString actionName, ActionHandler callback);
<kaz> ExposedThing onUpdateProperty(DOMString propertyName,
<kaz> PropertyChangeListener callback);
<kaz> ExposedThing addListener(DOMString eventName, ThingEventListener listener);
<kaz> ExposedThing removeListener(DOMString eventName,
<kaz> ThingEventListener listener);
<kaz> ExposedThing removeAllListeners(DOMString eventName);
<kaz> object getDescription();
<kaz> };
<kaz> ]]
<kaz> jh: what invokeAction returns
<kaz> ... might be a simple type or an object
<kaz> [ Lunch until 2:30pm ]
<scribe> scribenick: dsr
Michael Koster introduces the session: linking in respect to related Interactions, sub-Things, groups, collections
or "WoT Linking and Collections"
Let's talk about when you have a collection of things, e.g. buttons, or a refrigerator with a freezer compartment and a cooler compartment.
Let's start with a row of buttons. This could be modeled as an array or a collection or ...
Dave: can you identify a button with a number in an ordered collection, or perhaps a name in an unordered collection.
Another consideration is hierarchical compositions of re-usable sub-things or capabilities.
We want to describe the things that we want to compose.
The properties of the items may be different, e.g. a switch on the left or a switch on the right.
How do you cater for indexing or grouping.
The collections and compositions could be dynamic
Dave: I found vectors convenient for some of the use cases where the items were named and had the same model.
e.g. x, y and z coordinates
How do you dynamically create, update or delete items in a collection/composition?
What are the set of verbs for operating on a collection/composition?
Dave summarizes his model of collections and compositions which is formally described in terms of linked data and graph unification.
Michael: I would like to understand how you do this for thing descriptions, what story do we tell to app programmers?
Johannes: you could have linked from one TD to another.
(Dave indeed, things as named properties, or import relationships)
What is the impact of collections on security?
Michael: access control lists need to be able to handle collections and items.
Sebastian: you can use contexts to reference the metadata terms.
Dave: with a property whose value is a thing, you need to link to the thing's model
Michael: we could introduce "link" as a peer of "property", "action" and "event".
We need to enable the IoT platform's support for multicasting to a collection of things, e.g. OCF batch collections.
The links between collections and items could be traversed in either direction, e.g. a light that knows the room it is in, and the room that knows the lights in that room.
If you want to invoke an action on a specific item in a collection, it can be convenient to model the item as a thing.
If you want to invoke an action on the collection you define the action on the thing with that collection.
Zoltan: when you have things that have things as properties, when do you instantiate them?
Dave: my Node servient does this automatically when the referring thing is created.
Zoltan: how do you refer to sub things, e.g. for discovery?
Dave: via a path expression as in JavaScript a.b.c[2].
You can update the thing model directly via the thing API as the model is exposed as a property of the thing.
Michael: we could also look at a declarative means to update thing descriptions.
<kaz> [[ wot-sync breakout minutes here ]]
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Day 1/Tech Breakouts/ Succeeded: s/Liaison/Interworking/ Succeeded: s|containers|containers/flexContainers| Succeeded: s/zy:/yz:/ Succeeded: s/hting/thing/ Succeeded: s/resources/resource types/ FAILED: s/zonlatn, can you/can we/ Succeeded: s/model/model like TD/ Succeeded: s/setup/setup, e.g., direct connection or remote/ Succeeded: s/fist/first/ Succeeded: s/application/interaction/ Succeeded: s/Isses/Issues/ Succeeded: s/invokeAction/what invokeAction returns/ Succeeded: s/link /linking / Succeeded: s/collection of things/collection of things, e.g. OCF batch collections/ Succeeded: s/Michae/Michael/ Found ScribeNick: dsr Inferring Scribes: dsr Present: Yongjing 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 WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 Guessing minutes URL: http://www.w3.org/2017/02/08-wot-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]