Call with Markus Jung re WoT & IoTivity -- 20 May 2016

markus: focus on the service layer

dsr: can you explain IoTivity?

markus: C++ and C-based IoT approach
... 2 parts: discovery using CoAP, data transmission
... useful for demonstration to show interoperability
... 1.1 version released last month
... any questions?

dsr: July may be difficult for demo, so might aim September in Lisbon

markus: could work
... my question
... on the IG's work
... what kind of practical implementations?
... just curious

dsr: open source development and lab-based ones

markus: you're planning plugfest in Beijing as well

dsr: yes
... trying to invite other organizations

kaz: do you know Sanjeev BA?

markus: yes
... IoTivity has 6 domains
... smart home, automotive, etc.
... IoTivity is a generic framework to be extended
... resource model of WoT would be useful to IoTivity

kevin: from JLR
... interested in IoTivity

dsr: some more questions on IoTivity
... what is exposed to apps
... low-level? high-level?
... data type?

markus: multiple options
... C language SDK
... in this case, basically CoAP implementation
... low-level server connection
... similar to several APIs like entity handler
... low level like CoAP request header
... key-value map
... that is the basics
... this is low-level API
... and we also have high level API
... data state driven APIs
... there is still a potential W3C WoT IG's work would be helpful

dsr: tx

markus: simple key-value data type

-> http://www.slideshare.net/SamsungOSG/iotivity-connects-the-genivi-demo-platform-to-tizen fyi, Sanjeev's slides

markus: if you want something complicated, can use collected types

dsr: including nested model?

markus: yes

dsr: questions from others?

cabo: familiar with OCF's work :)
... could improve descriptive capability
... that's interesting work

markus: question about interoperability
... data model of OCF and WoT
... what do you want to show for the interoperability demo?

dsr: that's good topic to discuss
... demonstrate high-level APIs
... what kind of architecture should be use?
... C++, etc.

kevin: what is the underlying communication protocol?
... part of the spec?

markus: basically build on the constrained application protocol
... optimized version of HTTP
... additional interaction patter could be added
... RESTful communication over CoAP
... binary representation of JSON

kevin: binary representation of JSON over WebSocket?

markus: IoTivity follows RESTful approach

matthias: what we want to achieve?

dsr: next phase?

matthias: what OCF would offer?
... in Thing Description
... what the interaction pattern should be?
... pretty close resource model
... Thing Description should have better design

markus: Thing Description for OCF devices?

matthias: TD is meta data model based on RDF
... can handle constraints, etc., automatically
... could be applied to the model of OCF
... W3C can publish TD as REC track document, and OCF can refer to that

markus: most of the information by RAML and JSON Schema
... TD could be useful

dsr: what kind of use cases do we want to show at the demo?

cabo: safe description for resource
... making IoTivity devices available for TD
... and inverse would be also useful

kaz: maybe we might have some concrete timeline for the September meeting in Lisbon

kevin: mechanism and description language for automotive purposes
... we (=automotive wg) are thinking about websocket-based service layer
... complex entity may have complex structure
... in side vehicle, need to identify things
... different mechanism to describe signals for complex objects

dsr: maybe need to handle it separately since automotive area is a big use case
... do you think automotive would be an interesting use case for TPAC demo?

kevin: have to be careful about what we could commit to
... our (=automotive wg's) deliverables are specs
... should focus on our specs
... but think we need to work for OCF-based demo as well
... can't commit at the moment, though

dsr: participating in BG or WG?

kevin: WG

dsr: if you have separate resources outside of the WG, maybe you can do something

kaz: would suggest we once bring back this idea to the automotive side and have some discussion there

kevin,dsr: ok

markus: basic question
... looked at the WoT Architecture
... what is the goal?
... protocol as well?
... only Thing Description?

dsr: IG is on the process of rechartering
... WG is generating a draft charter
... need to reach out external SDOs
... build common understandings
... looking into APIs, semantics, etc.
... joint study with external SDOs
... TD as metadata vocabulary
... there are already similar approaches by other SDOs
... WG will be launched maybe in October

-> http://w3c.github.io/wot/current-practices/wot-practices.html current practice

dsr: there is a document on Current Practice

markus: we can allow different device architecture

dsr: what platform?

markus: plug-in of Eclipse
... on Linux
... IoTivity is currently developed for Linux and Android
... main platform is Linux

dsr: can use on an emulator?

markus: can check
... for mobile demonstration setup, etc.

dsr: what's the requirements for boards?

markus: basically embedded pc like Rasberry pi(?)

dsr: networking, etc.?

markus: a few KB is not ok
... if Linux can works

dsr: so relatively powerful device is expected

markus: for running emulator, you need a PC

dsr: nice to have a real board, but could do by an emulator
... resources from your end?

markus: have to check
... think can make contribution

dsr: would have brainstorming about the scenario

markus: Matthias's suggestion was OCF device
... this kind of requirements?

dsr: yes
... one OCF device talks with other devices

matthias: would be better to have IoTivity on the one side and WoT TD on another side
... to see the interoperability

dsr: multiple platforms together is good
... how to handle discovery?
... multicast?

markus: currently using CoAP multicasting

dsr: do you have existing protocol's registering?

markus: yes
... some discovery API provided

dsr: we used some repository for our PlugFest demos
... something else to integrate

cabo: the repository was a shortcut
... in the long run approach, we need some mechanism for discovery

dsr: abstraction of discovery is needed

cabo: interoperating with resources
... population of information

dsr: would see interoperability with the IoTivity approach
... what we need to do then?
... write up a plan

markus: should be feasible
... would see the demonstration scenario first
... and would like to know about the IG's work including the TD
... who is sketching the plan?

matthias: can set up how things should work together

dsr: when do we need the first description
... e.g., end of June?

markus: fine

matthias: would see how much text is needed

dsr: Markus could make contribution

kaz: maybe we might want to have a regular call for this work?

dsr: we can have another call at the end of June

kaz: yeah, monthly call like that

dsr: try to write up the plan and have a call at the end of June
... and another one after the Beijing meeting
... initial description on the demo is needed for the first call
... any other comments?

(none)

dsr: we need a use case for the demo

kaz: maybe we can start some initial discussion using a keyword "[iotivity]" on the public list

dsr: action on kaz/dave to talk with the automotive group
... use cases and requirements for the possible automotive demo

kaz: will do

dsr: tx
... and tx a lot for your participation, all

<scribe> ACTION: kaz to talk with the Automotive WG about the possible automotive demo with WoT during TPAC 2016 in Lisbon [recorded in http://www.w3.org/2016/05/20-wot-minutes.html#action01]

<trackbot> Created ACTION-58 - Talk with the automotive wg about the possible automotive demo with wot during tpac 2016 in lisbon [on Kazuyuki Ashimura - due 2016-05-27].

[ adjourned ]

- DRAFT -

Call with Markus Jung re WoT & IoTivity

20 May 2016

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output