WoT IG/WG - Tech Breakouts -- 08 Feb 2017

[McCool] OCF interoperability

<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> 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

[Yongjing] oneM2M interoperability

<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

Johannes] Workshop Scripting: conclude upon Promises / callbacks, CRUDN/Things to provide a conseted spec for implementation and further evolution

<kaz> [ remote: Daniel, Darko ]

<kaz> (nimura-san is preparing for his presentation)

Scripting API - understanding the architecture (nimura-san)

<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

Linking

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 ]]

- DRAFT -

WoT IG/WG - Tech Breakouts

08 Feb 2017

Attendees

Contents

[McCool] OCF interoperability

[Yongjing] oneM2M interoperability

Johannes] Workshop Scripting: conclude upon Promises / callbacks, CRUDN/Things to provide a conseted spec for implementation and further evolution

Scripting API - understanding the architecture (nimura-san)

Linking

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output