SV_MEETING_TITLE -- 17 May 2017

Agenda

TD

<kaz> seba: gives basic background

<kaz> maria: talks about ontology work

<kaz> mm: possibly multiple serializations

<kaz> ... we could omit some of the information

<kaz> ... simplify some of the information

<kaz> ... different serialization for different people

<kaz> (looking at "Proposal of TD Model)

<kaz> seba: having one core TD model and various serializations

<kaz> mm: one serialization could include everything and possible subsets

<kaz> (discussion on model and serialization)

<kaz> remote: Maria_Poveda, Michael_Koster, Yingying_Chen

<kaz> seba: summary

<kaz> ... simple understandable model which is independent from serialization

<kaz> yz: UML-based model?

<kaz> seba: simplified Maria's proposed model

<kaz> mk: you can put the slides at somewhere and we can continue discussion

<kaz> seba: will put the resources on the server

<kaz> mm: we should consider which tool to use

<kaz> mk: you can create an issue on github within the TD repo

JSON-LD include - Kajimoto

<kaz> kaji: introduces Echonet spec

<kaz> ... can be converted to JSON-LD

<kaz> ... inclusion and removal of part of JSON-LD definition

<kaz> dsr: different SDOs have different approaches

<kaz> seba: is this proposal part of JSON-LD itself?

<kaz> mk: we had discussion in Santa Clara

<kaz> ... there was the person in charge of JSON-LD 1.1 spec

<kaz> ... may be difficult to reflect to JSON-LD itself

<kaz> ... maybe we can have some specific discussion on how to reflect this idea to RDF triples

<kaz> kaji: we have research society in Japan

<kaz> ... RDF experts there are interested in this

<kaz> mk: are you planning to propose this idea to JSON-LD guys?

<kaz> kaji: yes

<kaz> seba: you can send an email to the WoT group as well

Transfer-of-ownership issues (from T2TRG Chicago discussion) and relation to abstractions

<kaz> Dave: this relates to work on personal zones and the social web of things. The challenge is to find ways to create simple user interfaces that non-geeks can use.

<kaz> br: we need a control panel?

<naomi> mm: we should building a map, what things in a house.

<naomi> we should building a map, what things in a house.

<naomi> barry: but other devices no more relevant to a house for example on a toaster

<naomi> mm: ownership, household. issue is to access network is the key. Need to describe too access control.

<naomi> mathias: it's in a system. smartphone communicates devices who to access. It could be possible to @1. It's a good starting point. Idea of map, usage of description. It will be an intermediate goal.

<kaz> [morning break]

<kaz> and then breakouts

<dsr> scribenick: dsr

oneM2M HAIM - WoT TD mapping

Slides at https://github.com/w3c/wot/blob/master/liaisons/onem2m/oneM2M-HAIM-TD-mapping-discussion-Osaka-F2F.pdf

Yongjing shows the oneM2M meta model for the home appliance information model.

This includes non-functional information such as a product’s serial number, as well as functional information such as the device’s propertied, actions and events.

Michael describes the relationship to the OCF models

Yongjing talks about modularity and how devices can be embedded in other devices.

Michael: I don’t see links, nor the idea of collections

Yongjing “link” is like a property

Michael: one requirement is to assign the value of a property for a collection of things
... rather than having to do this explicitly for each member of the collection.

Yongjing talks about the hiearchy of modules in HAIM.

HAIM has an ontologyRef that links to an ontology that relates to the thing’s type.

Dave: HAIM properties could be mapped to thing properties or metadata depending on their nature.

Sebastian makes the same point.

Dave: the SDO’s like oneM2M need to define their Linked Data namespaces to allow us to define the mapping to thing descriptions.

Yongjing: so properties are more like functional information, right?

Sebastian: yes

Yongjing: any oneM2M device should be describable as a thing for the Web of things.

Dave: my mapping of HAIM to things is at https://www.w3.org/WoT/demos/td2ttl/m2m.html

Yongjing: I struggle a bit between retaining the HAIM hierarchy and flattening it when mapping to a thing description

Yongjing talks about the challenges for the metadata needed for the protocol binding.

Sebastian: I would approach this simply.

They stand at the display chatting about the details

Dave: we want to decouple applications from the specific IoT platforms, and to keep the thing descriptions as simple as possible. A oneM2M driver will know a lot about the details for oneM2M, but not about specific oneM2M devices. If the thing model is a natural representation of the HAIM model, the oneM2M specific metadata in the thing description can be minimised.

Yongjing: in my exploration, I’ve tried to be explicit (e.g. he includes the PUT method in the metadata)

oneM2M doesn’t support attribute addressing, everything is at the level of modules (aka resources)

He shows a table summarising the mapping principles.

Device maps to thing. Property to property. Action to Action. Event to Event.

It isn’t clear what a ModuleClass maps to

Yongjing talks about the oneM2M specific HTTP headers, e.g. X-M2M-Origin

Sebastian: one approach is to describe the protocol information in detail. It is quite hard to do that.

The other approach is for the thing description to identify that this is a oneM2M device along with metadata that a oneM2M driver could utilise.

Yongjing: I was previously thinking that a thing description would be sufficient to access a oneM2M device without a oneM2M specific driver.

Dave: the URI for oneM2M could be dereferenced to obtain information about how to obtain and install a driver.

Michael: there’s two levels of adaptation. Aspects that can be automated would be in the driver, but other aspects should be in the thing description so that the application can adapt as appropriate.

Yongjing discusses device firmware update as an example use case

One idea is to write metadata to the thing and then command it to update its firmware based upon that metadata.

Yongjing: there can be a need for atomic transactions

Michael: an IoT platform driver may translate a thing action to multiple IoT platform specific actions.

Sebastian repeats the point that we don’t want to model everything in the thing description.

Michael: if oneM2M mandates firmware management capabilities, this doesn’t need to be mandated in the web of things, as you could instead use the oneM2M management interfaces directly.

Sebastian: that sounds like something for this afternoons break out session with Johannes and Zoltan.
... we break for lunch …

Yongjing: oneM2M specs are publicly available so everyone is free to join the liaison task force.

Michael: that looks like being the OCF policy too for future releases.

<naomi> scribenick: naomi

<scribe> scribenick: kaz

Marketing strategy - Michael McCool

mm: [Marketing Planning - Brainstorming Session]
... there is another session on Friday as well
... [Purpose]
... brainstorm topics to discuss on Friday
... think about what we want and need
... [Messaging]
... need to clarify our message

bl: difficulty with the second topic: focus on key value/deliverable of WoT

mm: what's the key value?
... we could have offline discussion as well
... could list things
... what would be the "one thing" for an elevator pitch?
... [Collateral]
... presentation material
... keep it up-to-date
... different length
... different audiences
... history vs base materials for new presentations
... Materials for developers
... tutorials, examples and documentation

dsr: would be useful to have videos as well

mm: presentation tutorial?

dsr: plugfest as well
... we don't have resources to maintain presentation materials
... great to have help from the group

mm: we have to get permission for images
... there is a datasheet
... (shows the current version of the datasheet)

-> A4.pdf

mm: [Online Presence]
... Web site, Wiki, Github and evangelism (Webinar, etc.)
... [Evangelism]
... Events and Liaisons

<inserted> ... [Recruiting]

mm: how to recruit new Members?
... who would be valuable to have?
... (lists some stakeholders)
... also about timing
... would have a list of questions
... [Logistics]
... what are the deliverables?
... by when do we need them?
... who does the work?
... started to collect presentations on GitHub

presentation area

mm: comments?

<inserted> mm: shall we try some exercise?

<kajimoto> Open,Enhance, Flexible by WoT

kaji: who would be our audiences?
... browser vendors? service providers?

mm: e.g., Google is both

<barryleiba> Too geeky, but "We're building a data model for the Internet of Things, which programmers can use to make 'things' sold by different companies work together."

<barryleiba> 'tis a start...

<yongjing> what i used in presentations in other events is to position WoT as the 'glue' at the metadata level to enable cross-platform communication/interaction by the powerful descriptive capability of TD.

<McCool> My messaging proposal: The Web of Things defines an open, free standard that describes IoT devices in enough detail that other devices, people, and services can communicate with them.

WoT as a universal connector for various IoT technologies/standards

<McCool> I think the WoT is the thing we are introducing, let's assume people know what "IoT" is (IoT: known; WoT: new concept)

<barryleiba> I don't see a substantive difference. I think we're better off conflating them.

<jhund> where can I find the webex coordinates?

<barryleiba> Here's a question to tease that out: Do we really want to have a set of people who think that they care about IoT, but they don't care about WoT?

<McCool> My messaging doesn't really refer to WoT except as the name of the group. Instead I think we should focus on the key deliverable: the open "description" (the TD) and why it is useful

<barryleiba> If the answer to that is "yes", then describe that set of people.

<barryleiba> McCool: Yes, exactly.

<mkovatsc> W3C WoT aims at complementing existing standards and platforms by providing semantic descriptions and horizontal technological building blocks to pick from, instead of prescribing a full vertical architecture.

<zkis> WoT: do IoT with web concepts ( in addressing, access, ...) using TDs to describe interactions and interacting entities.

<McCool> https://en.wikipedia.org/wiki/Elevator_pitch

Matthias: who would handle this?

<zkis> WoT compliance: TD compatibility (ontology, semantics, ...)

Matthias: we could discuss the strategy during the breakouts

<naka> WoT: interconnect different IoT standards

mm: will take an action item

<dsr> The potential for the IoT is huge, but is being held back by fragmentation. W3C is defining an interoperability framework that reduces the effort and risk for developing services across a wide range of platforms. Our unique selling point is cross platform metadata for describing services based upon W3C’s extensive experience with Linked Data and APIs.

<k_nimura> wot provides abstruct way to use things. less programming

<elena> Hi, am I confusing smth? There is noone on the webex for security breakout

<mkovatsc> * breakouts have not started yet

<zkis> not yet, I guess. I am switching to the scripting breakout webex

[breakouts start]

<elena> oh, ok, but it is time, right? just to make sure I didn't confuse timezones..

<mkovatsc> * we are finishing up the marketing stuff

[this channel will be used for Scripting API]

<mkovatsc> * yes, yes, you are up next

[Security at 101]

<mkovatsc> https://lists.w3.org/Archives/Member/member-wot-f2f/2017May/0003.html

<mkovatsc> Scripting API in 1.

<mkovatsc> Security in 2.

<zkis> * someone please share the webex URLs for scripting and security breakouts, there seems to be only one link?

<mkovatsc> zkis still missing in 1. from https://lists.w3.org/Archives/Member/member-wot-f2f/2017May/0003.html

<elena> zkis, use main for scripting and for security is breakout one

<elena> that is strange, because I am in that webex now...

<zkis> * room has too much echo, please use microphone when speaking from the room

Issue 2

jh: wrap up

<jhund> We have concluded upon these points:

<jhund> * scripts have a context (resembling the "origin" in UA)

zk: need to discuss the relationship with "tab"

<jhund> * scripts run in a script execution context

<jhund> * we should define the interrelation between the origin and the execution context

zk: the first thing I get is request if I'm a runtime

<jhund> * we should formulate the guarantees/contract that a script developer can rely on (single-threaded execution etc.)

<jhund> * when starting a script, the runtime needs to know in which context it runs

mk: maybe we don't have to manage this at all, do we?

zk: don't think there is any implicit origin

<mkovatsc> no kaz

<inserted> mk: requests from the outside to start scripts are irrelevant

<jhund> * origin / context does not relate "1:1" to the browser world

<mkovatsc> s/mk: the origin of the request would start the script/mk: requests from the outside to start scripts are irrelevant/

Zoltan's slides

zk: [WoT Runtime]
... management of Things as part of the runtime
... separate mechanism for security

[here: Kajimoto, Yamada, Ohura, Nagao, Kaz, Toumura, Matthias, Uday, Mizushima, Matsukura, Taki, Yongjing, Osamu, Shigeya, Uchida, Nimura, JooYoung, Youngmin]

<jhund> regarding Zoltan's slides:

<jhund> * we conclude on encouraging encapsulating functionality (such as accessing the system) into thing interfaces

<jhund> * such local things are accessed in the script just like remote things (discovery etc.)

mk: in the early version of the architecture diagram we had legacy api
... non-standardized access
... need special functionality for system access, e.g., Echonet or I2C?

jh: client api for physical interface?
... or need specific physical api?

<kajimoto> Physical API/Legacy API might be out of scope of standardization, isn't it? Because those APIs exist so script only call them. Scope of standardization is client API for calling WoT servient, server API and discovery API.

<zkis> as example for high and low level IoT APIs: https://github.com/01org/iot-js-api

mk: to change your script for GPIO kind of specific interface or do we need another layer?

sk: [Request to run script]

jh: would talk about this during tomorrow's session

https://www.w3.org/TR/mmi-arch/#ArchDiagram

kaz: clear separation between the management side and the device handling side might be useful

jh: summarizes the session
... management interface session tomorrow

<zkis> * I will be back in 40 minutes.

[afternoon break]

till 4pm

Synchronization of WoT Servients - Ryuichi Matsukura

Matsukura-san's slides

<inserted> rm: [WoT Servient architecture]

rm: 2 types
... type A: uses scripting API to execute
... type B: ues WoT API to execute

kaz: so type A has script on itself
... and type B means external script

rm: yes
... [Overview of processing flow]
... [Discovery and Provisioning from device]

[here: Yamada, Nagao, Kajimoto, Ohura, Kaz, Toumura, Matthias, Mizushima, Shigeya, Taki, Yongjing, Nimura, JooYoung, Youngmin, Uchida, Matsukura

<inserted> rm: [Discovery and Provisioning from App.]

rm: type A search and check to TD repo and search for the legacy device
... [Application searches TD]
... [Application gets data from device]
... consumed Thing retrieves TD from the repo and sends "get" to the device via the legacy device adapter
... [Application type B searches TD]
... application B asks consumed Things if the device is available now
... and searches the TD corresponding to the device in the repo
... [Application type B gets data from device]
... [Why synchronization is required?]
... synchronization mechanism is required in some cases of management for multiple TD repos on multiple WoT Servients
... server-client/master-slave, distributed, redundant/multiplexing
... [Some issues on multiple WoT servients]
... access control for the distributed devices
... [Example diagram for server-client]

kaz: which is the server?

rm: right side "Cloud (WoT servient)"

kaji: maybe the left-side "Gateway (WoT servient)" is also a server?

rm: [Device registered to master repository]
... [Another way on TD synchronization]
... [Application on cloud searches TD]
... [App on cloud gets data from device]
... [Conclusions and proposals]
... conclusions:
... synchronization mechanism is required for multiple WoT servients
... there are some methods to manage TD repos on distributed servients
... 2 types of application for the WoT servients

yz: question on slide 5 and 6
... [Discovery and Provisioning from App.] and [Application searches TD]
... what is the difference?

rm: this process an be omitted

mk: discovery api is missing here

yz: Matsukura-san proposes 2 ways

mk: one option is more searching and another might be push

yz: pull vs push
... Matsukura-san, do you have any preference?

mk: core resource directory is getting a standard
... you could use some lookup mechanism depending on the underlying mechanism

<mkovatsc> jhund/zkis, do you have audio?

<zkis> *yes

<mkovatsc> We had a question about the status of the Discovery API

rm: [slide 2]

<mkovatsc> Are there drafts that could be used to implement the presented use case

rm: would have the resource model separately from the runtime

nimura: [Device registered to master repository]

mk: we discussed synchronization of data in Santa Clara
... maybe you might be able to have a smart implementation which has prediction capability
... need to clarify the logic how to copy the TD between the local side and the remote side

uhcida: not sure if synchronization would be always the best way
... we should clarify issues and requirements first
... and then solutions next

rm: yeah
... would like to clarify issues based on use cases

yz: what would trigger the data transfer

rm: tx

[ Day 1 ends ]

- DRAFT -

SV_MEETING_TITLE

17 May 2017

Attendees

Contents

Agenda

TD

JSON-LD include - Kajimoto

Transfer-of-ownership issues (from T2TRG Chicago discussion) and relation to abstractions

oneM2M HAIM - WoT TD mapping

Marketing strategy - Michael McCool

Synchronization of WoT Servients - Ryuichi Matsukura

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output