WoT WG/IG F2F meeting in Osaka
15-19 May 2017

group photo

(Some more photos are available online.)


Present (Monday, May 15: PlugFest Day):
Dave_Raggett, Kaz_Ashimura, Yingying_Chen(remote), Naomi_Yoshizawa, Shigeya_Suzuki, Matthias_Kovatsch, Sebastian_Kaebisch, Uday_Davuluru, Yongjing_Zhang, Michael_McCool, Youngmin_Ji, JooYoung_Ahn, Ryuichi_Matsukura, Taki_Kamiya, Takeshi_Sano, Takuya_Sakamoto, Kunihiko_Toumura, Masato_Ohura, Katsuyoshi_Naka, Kazuo_Kajimoto, Takeshi_Yamada, Yoshiaki_Ohsumi, Keiichi_Tokuyama, Shinichi_Motomiya, Norio_Uchida, Koji_Miura(observer), Naoki_sekiguchi, Koichi_Takagi, Radim_Zemek, Shigeyuki_Sakazawa(observer), Naoshi_Kobayashi(observer), Mitsuhiko_Kosaka(observer), Syuri(observer), Kento_Kumaki(observer), Kenichi_Nunokawa, Sumie_Miki, Takuya_Shigemura(observer), Keita_Kurabayashi(observer)
Present (Tuesday, May 16: OpenDay):
Dave_Raggett, Kaz_Ashimura, Yingying_Chen(remote), Naomi_Yoshizawa, Osamu_Nakamura, Shigeya_Suzuki, Matthias_Kovatsch, Sebastian_Kaebisch, Daniel_Peintner(remote), Johannes_Hunt(remote), Uday_Davuluru, Yongjing_Zhang, Barry_Leiba, Michael_McCool, Masahiro_Shimohori, Zoltan_Kis(remote), Elena_Reshetova(remote), Youngmin_Ji, JooYoung_Ahn, Ryuichi_Matsukura, Taki_Kamiya, Kazuaki_Nimura, Takeshi_Sano, Kunihiko_Toumura, Masato_Ohura, Katsuyoshi_Naka, Kazuo_Kajimoto, Takeshi_Yamada, Yoshikazu_Ishii, Yoshiaki_Ohsumi, Keiichi_Tokuyama, Kanji_Mihara, Norio_Uchida, Hiroyuki_Nishida, Koji_Miura(invited_speaker), Masaaki_Morishita(observer), Naoki_sekiguchi, Koichi_Takagi, Radim_Zemek, Tetsushi_Matsuda, Teppei_Katatani, Shunsuke_Furuya, Kenichi_Nunokawa, Sumie_Miki, Keita_Kurabayashi(observer), Yoji_Nagao, Norikazu_Yamasaki(invited_speaker), Michael_Koster(remote)
Present (Wednesday, May 17: Tech Work Day 1):
Katsuyoshi_Naka, Keiichi_Tokuyama, Takeshi_Yamada, Dave_Raggett, Michael_McCool, Elena_Reshetova(remote), Hiroyuki_Nishida, Kazuo_Kajimoto, Masato_Ohura, Kaz_Ashimura, Kunihiko_Toumura, Matthias_Kovatsch, Kazuaki_Nimura, Ryuichi_Matsukura, Taki_Kamiya, Yongjing_Zhang, Takeshi_Sano, Norio_Uchida, Youngmin_Ji, JooYoung_Ahn, Naoki_Sekiguchi, Radim_Zemek, Shigeya_Suzuki, Osamu_Nakamura, Tomoaki_Mizushima, Uday_Davuluru, Naomi_Yoshizawa
Present (Thursday, May 18: Tech Work Day 2):
Keiichi_Tokuyama, Takeshi_Yamada, Michael_McCool, Hiroyuki_Nishida, Kazuo_Kajimoto, Katsuyoshi_Naka, Masato_Ohura, Kaz_Ashimura, Kunihiko_Toumura, Matthias_Kovatsch, Barry_Leiba, Kazuaki_Nimura, Ryuichi_Matsukura, Taki_Kamiya, Yongjing_Zhang, Sebastian_Kaebisch, Norio_Uchida, Takeshi_Sano, Youngmin_Ji, JooYoung_Ahn, Shigeya_Suzuki, Tomoaki_Mizushima, Yoshi_Ishii, Dave_Raggett, Michael_Koster(remote), Carsten_Bormann(remote), Maria_Poveda(remote), Daniel_Peintner(remote), Johannes_Hunt(remote), Darko_Anicic(remote), Victor_Charpenay(remote), Takuya_Sakamoto(remote), Zoltan_Kis(remote), Elena_Reshetova(remote), Achille_Zappa(remote), Danh_Le_Phuoc(remote), Toru_Kawaguchi(remote), Yingying_Chen(remote)
Present (Friday, May 19: Administration Day):
Dave_Raggett, Kaz_Ashimura, Yingying_Chen(remote), Naomi_Yoshizawa(remote), Shigeya_Suzuki, Matthias_Kovatsch, Sebastian_Kaebisch, Daniel_Peintner(remote), Uday_Davuluru, Yongjing_Zhang, Barry_Leiba, Michael_McCool, Ryuichi_Matsukura, Taki_Kamiya, Kazuaki_Nimura, Takeshi_Sano, Kunihiko_Toumura, Masato_Ohura, Katsuyoshi_Naka, Kazuo_Kajimoto, Takeshi_Yamada, Yoshi_Ishii, Keiichi_Tokuyama, Norio_Uchida, Hiroyuki_Nishida, Tomoaki_Mizushima, Michael_Koster(remote), Carsten_Bormann(remote)
Matthias, Kajimoto, McCool, Yongjing
kaz, naomi, dsr, taki


Monday, 15 May 2017: PlugFest Day

AM - preparation

plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest

PM - demo (13:30-14:10)

plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest w plugfest plugfest

PM2 - discussion at each table

plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest plugfest

Cross Interaction Demo

closs interaction demo

Today, we achied following cross interaciton:


[ PlugFest Day ends ]

Tuesday, 16 May 2017: Open Day


remote: Michael_Koster, Yingying_Chen

Welcome Speech - Yoshiaki Ohsumi

<inserted> scribenick: kaz



Expectations for W3C/WoT Activity - Hideshi Fuchiue



Instruction & Today's agenda - Katsuhoshi Naka


naka: explains today's schedule
... and provide logistics information
... coffee and lunch will be served at the HUB space
... demo available at the presentation room during coffee breaks
... wifi available
... demo tour and social dinner in the evening
... leaving here at 16:40
... ISO rep not available, so Naka-san will give brief explanation

naka: [ISO/IEC JTC1 SC41 work]

... scope and standards
... explains the work briefly

kaz: notes that IRC is available at #wot

WoT Getting Started - Kazuo Kajimoto



naka: Getting Started with WoT Project

kaji: [ Conceptual Architecture and Objective ]
... [ Practical viewpoint of Silo vs WoT ]
... one-stop universal platform
... [ WoT Framework example ]
... [ Usage of Semantics on WoT ]
... global identical vocabulary needs to be defined
... regardless of languages, etc.
... attribute for discovery
... [ WoT Framework example ]
... WoT client and WoT server
... [ WoT Servient building block ]
... servient has both the capabilities of server and client
... [ WoT server in device itself ]
... [ WoT server for constraint device ]
... [ WoT interoperability PoC in Panasonic ]
... 5 different services included in Panasonic demo yesterday
... smart apps platform
... smart home platform
... IRKit platform
... Hue platform
... Alexa platform

<naomi> kaji: [ Cross Interaction Demo ]

kaji: KDDI tmp sensor and Siemens app
... Siemens app controls Panasonic light
... Fujitsu app also controls Panasonic light
... [ Standardization process in WoT ]
... Yongjing mentioned the story during the AC meeting in Beijing
... please join WoT IG/WG!
... questions/comments?

(no specific questions/comments)

kaji: shows photos
... from Santa Clara meeting
... and video from Osaka
... and then video from Santa Clara again

Logistics note - Naka-san

naka: IRC channel: #wot
... can join using http://irc.w3.org/?channels=#wot

Star Micronics introduction - Koji Miura



koji: tx for inviting me
... 3 main products
... automatic lathes, small printers, precision products
... legacy POS printer
... 2nd top world share
... also mobile POS printer
... 1st world share
... various partners
... POS market pyramid
... mobile POS market is our focus
... why Star is No.1?
... keeping up with the trend of smartphone/tablet market
... many innovative solutions
... MFi certified
... multiple lineups
... easy-to-use SDK freely available
... so easy setup
... original software services like WebPRNT, PassPRNT and AllReceipts
... that's why Star's printers are de-facto
... software solutions including Star SDK
... both for iOS and Android
... not only APIs but also source codes
... Star WebPRNT
... from iOS, Android and Surface
... HTML/JS + StarLine XML/HTTP over wifi
... web bridge function for Bluetooth
... Star PassPRNT as software-based printer server
... driver application

remote+ Sam

scribe: Star AllReceipts
... digital receipt is provided by AllReceipts service
... current situation
... our printer supports this kind of multiple I/F
... USB-A, USB-B, LAN and another USB-A
... tx

kaz: ok to upload this presentation?

koji: let me check

mccool: printer driver as a web service?
... payload as XML?

koji: yes

<inserted> scribenick: naomi

kaz: koji mentioned a difficulty of basic printer which restricts sizes
... in this case any data is available, the slide says
... do you have any specific problems?
... w3c wot group has difficulty of streaming data
... we need some method on it
... how to specify data

koji: BoS printer market we need to have 100% guarantee
... streaming idea works but not perfect solution for 100% guraantee
... we have to set data links inside of Thing Description
... client have to count data

mm; JSON market

scribe: tickets
... are you looking that market?

koji: we might sell ticket service

kaz: mm, you mean online store?

mccool: no, my point is point of sale
... we have IoT application to log in

koji: we support multipul language
... and right to left, left to right
... this is not for wot but we focus Thing Description

kaz: another question
... do you have usual http and @2 style of printing?
... W3C CSS writing mode spec
... do you use that kind of specs on printing?

koji: yes
... it'll fit our concerning point
... this software idea can fit as well
... inside of apps to generate convert commands
... it can easy to generate receipt

kaz: interesting point
... relationship between semantics and CSS style

koji: any questions?

<kaz> [ morning break ]

OCF 1.0 Overview - Michael McCool



<inserted> scribenick: kaz

mccool: [Outline]
... OCF history, background and markets
... OCF architecture and principles
... working on diagrams
... changes between OIC 1.1 and OCF 1.0 draft candidate
... [OCF - High Level Goals]
... easy for developers
... common data model
... initial target is smart home
... [OCF&IoTivity]
... , open source implementation
... budget under Linux Foundation
... C++ implementation and now Node implementation
... primary focus on CoAP
... [OCF - Conceptual Framework]
... profiles, core framework and transports
... core framework is standard mechanism
... interaction/data model, resource model
... discovery, data transmission, data management, device management
... transports: bluetooth, wifi, lte, ...
... [OCF - Resource Model]
... common properties and resource specific properties
... interfaces basically provide views
... sensor view, etc.
... [Resource Model - examples]
... resource URI: /a/light1 and /a/fan1
... /a/light1 - rt: oic.ex.light; if: oic.if.rw; prop: discoverable, observable; n: myHallWayLight; State: 0 (off); Dim Level: 0
... [Common Interaction Model - Transport Agnostic]
... Create, Retrieve, Update, Delete, Notify
... [Let's look deeper at a Resource ...]
... Server - DevA
... [There can be more Properties]
... [Resource Type - Data Modeling]
... 2 things to describe metadata
... first thing is set of properties
... by JSON Schema
... and verbs using RAML (ReStful API Modelling Language)
... describes the request and response
... and now the third option
... emerging standard, Swagger (aka, open API)
... OIC introspection
... [Table 19: oic.wk.p resource type definition]
... OCF specification defines "oic.wk.p" resource type for platform and its list of properties
... [Link]
... how to define te connection between two resources
... /a/room and /switch
... relative URL
... {
... "href": "/switch",
... "rel": "contains",
... "anchor": "/a/room",
... ...
... [Collections]
... also scenes
... set of devices
... can be stored
... [Collections...example]
... "Room" collection - room has lights and fan
... /my/room/1
... {
... "rt": "acme.room",
... "if": ["oic.if.r", "oic.if.rv"],
... ...
... [Interfaces]
... subset of resources
... interface provides a "view" into a Resource or Collection
... Interface defines allowed methods and semantics on that "view"
... OCF has a set of predefined Interfaces
... [OCF ER Model]
... not from the official OCF spec...
... platform-devices
... WoT semantics define similar model
... [Major Changes in OCF 1,0 (Draft) CR from OIC 1.1]
... Swagger/OpenAPI for: data modeling, introspection, RAML is still used in main spec definition
... Enhanced security: alignment with IETF ACE and AllJoyn
... better specification of uses of certificates
... better management of onboarding and offboarding processes
... mandatory access control, system management
... [Summary]
... resource-oriented architecture
... IoTivity
... New features in OCF 1.0
... Questions?

dsr: relationship between OCF and narrow band IoT?

mccool: OCF work is protocol/transport-agnostic
... CoAP designed based on UDP

T2TRG Overview Discussion - Michael Koster


koster: [T2TRG]
... started in March 2015
... chartered by IRTF
... investigate "Internet of Things" applications and architecture beyond IETF CoRE/CoAP
... [Topics]
... quite broad
... REST and Hypermedia for connected things
... Event-state duality, pub-sub pattern, notification
... Connected Thing Life Cycle
... Management and Operations
... Work with Industry SDOs and Fora - work with W3C WoT on data models and semantics
... Plugtests, Interop tests
... Practical Semantic Interoperability
... Mobile code
... Security
... [Research Drafts]
... RESTful design guidance
... Security challenges for IoT
... Hypermedia content types
... CoRAL - CBOR Encoding of Hypermedia Controls
... HSML - SenML + Link-Format Hypermedia Controls
... [Events]
... meet in conjunction with IETF and related activities
... joint meetings with Industry Fora, e.g., OCF
... semantic interop in conjunction with IETF 99 in Prague, July 15-16
... planning for semantic interop events
... multiple device ecosystems participating
... [Meetings]
... IETF 93, IETF 94, Jan 2016 (Sophia Antipolis Plugtest), March 2016 (with IAB Semantic Interop), IETF 95, IETF 96, Sep. 2016 (Joint with W3C WoT IG), Oct. 2016 (with Eclipsecon), IETF97, Mar. 2017 (joint with OCF), ...
... [Next T2TRG Event]
... T2TRG Joint Semantic and Hypermedia Interoperability Workshop
... with IETF 98, Prague, Jul 15-16
... OCF, LWM2M/IPSO, W3C WoT, iot.schema.org
... example topics: cross-ecosystem semantic interop planning, hypermedia controls for actions, hypermedia-driven apps, models and model translation
... [References]
... datatracker.ietf.org/rg/t2trg/charter/
... github.com/t2trg
... datatracker.ietf.org/rg/t2trg/documents/
... questions?

mccool: next f2f of wot will be held Dusseldolf

koster: ending on Thursday and will travel to Prague on Friday

Security Process in W3C WoT - Elena Reshetova


er: [Importance of Security for WoT]
... why security is important for WoT?
... 10 things to know about the Oct 21 IoT DDos attacks
... avarage IoT device is compromised after being online for 6 mins
... large-scale IoT security breach coming in 2017
... here are the biggest IoT security threats facing the enterprise in 2017
... very popular topic
... [Always good to remember]
... 3 principles: start early, involve everyone and explore existing solutions
... [How do we do it?]
... 1. threat model - understand what you need to protect and why
... 2. scoping - organize and prioritize threats, define security objectives
... 3. state of the art - study related areas and their approaches to security
... 4. solutions - find a suitable mitigation for each in-scope threat
... 5. implementation and evaluation - implement and test each solution
... questions?
... (continues)
... [1. Threat model - Understand what you need to protect and why]
... stakeholders, assets, attackers/attack surfaces, threats
... [Resources]
... WoT security documentation: github.com/w3c/wot/tree/master/security-privcy
... WOT IG security webconf: www.w3.org/WoT/IG/wiki/IG_Security_WebConf
... that's all

naka: questions?

kaz: everybody from this meeting room is encouraged to join the Security TF :)

elena: good point

[ Lunch ]

afternoon session will start at 13:30

remote+ Elena

OpenFog - Masahiro Shimohori



ms: [Building this necessary interoperability of fog-enabled applications requires a collaborative approach]
... funded by the 5 companies and one univ
... Intel, MS, Cisco, Dell, ARM, Princeton Univ.
... [OpenFog mission]
... mission statement
... To drive industry and academic leadership in fog computing architecture, testbed develpment, and a variety of interoperability ...
... [OpenFog COnsortium]
... 57 members
... 6 founders
... affiliations, contributing members, and other members
... [OpenFog Consortium goals]
... technology, innovation, education
... testbed to demonstrate interoperability
... ... evangelize fog computing
... doing a lot of efforts
... [Organizational structure]
... technical WGs
... architecture framework, SW infrastructure, communications, security, manageability, liaisons, testbed
... under the technical committee
... and marketing committee, social impact committee, americas committee, greater china region committee, japan committee and european committee (planned)
... [OpenFog Reference Architecture]
... www.OpenFogConsortium.org/RA
... [The OpenFog reference Architecture Framework]
... software/device developers
... interoperability in IoT, 5G, AI and other complex data/network intensive apps
... and creating common language for fog computing and wil help unify the edge/fog ecosystem
... under a single, interoperable, testable set of hardware and software standards
... [Key pillars of the OpenFog architecture framework]
... security, scalability, open, autonomy, RAS, agility, hierarchy, programmability
... [Architecture description with perspectives]
... green layer: sensors, actuators, control; protocol abstraction; hardware platform instracture
... dark blue: network, accelators, compute, storage; OpenFog Node Security; OpenFog Node Managment; Hardware Virtualization
... blue: Node Management & Software Backplane
... Orange: Application Support
... grey: Application Services
... vertical mechanisms: Security, Manageability, Data Analytics&Control, ...
... perspectives; node view (green), system view (dark blue), software view (blue);
... [A closer look at fog nodes]
... gog nodes communicate with each other in a distributed manner

<scribe> ... new value chain and business entities

UNKNOWN_SPEAKER: [Technical WG focuses]
... [Reference Architecture Contributions]
... [Node Security]
... basis of Fog security
... hardware root-of-trust
... physical security
... [Network Security Aspect]
... node to cloud
... REST over TLS
... node to node
... HTTP over TLS, CoAP over DTLS
... node to device
... IP adaptation
... [Data Security Aspect]
... Data in Use
... data in memory undergoing procesisng

<scribe> ... [New Work & Task forces]

<scribe> ... new TFs established

UNKNOWN_SPEAKER: [Security Requirement Taskforce]
... mission statement
... to define sets of requirements that has to express the fundamental security (and in the future evaluation) requirements for an OpenFog compliant (in the future certified) node and system.
... as a reminder, the work shall support both brown and green field implementations
... [Security Requirement Taskforce (contd.)]
... Method
... [Security MVIs]
... minimum viable interface
... [Smart Objects for an OpenFog Architecture: SW Infrastructure WG - Task Group]
... What are Smart Objects?
... Why do we care about Smart Objects?
... Smart Object Landscape, ...
... [What's a Smart Object?]
... an object that describes its own possible interactions
... can be physical, e.g., sensor, computing device, wearables
... can be cyber, elgl, data, executable code, apps, services, clouds
... [Why do we care about Smart Objects?]
... reduce time and cost to develop, deploy and maintain IoT applications
... data interoperability; service, object and software composition
... [Smart Object Landscape]
... W3C Semantic Web, W3C Web of Things, ipso, OCF, IIC, Haystack Connect, UPnP, Allseen Alliance, IETF, OPC, RDA, NIST
... [Smart Object Issues]
... a lot of challenges
... frameworks: standards, ontologies, interoperability
... [Charter]
... working closely with other SDOs including W3C
... [Transaction Management & Orchestration Princeples]
... [Logical Transaction Layers - concept]
... distributed resources
... 1. Fog Platform Infrastructure - Shared Resources
... 2. Microservice Logical Fabric assemblies
... 3. Data, Object, Interface&Access
... 4. Fog Transaction&Management
... defines scope of services
... e.g., with a building
... would control temperature and humidity
... resources are connected to storages
... project could be energy management
... [What is a Transaction?]
... transaction based TLA time (e.g., 10sec) consists of:
... Internet (3sec)
... Application (3sec)
... System+Storage (2sec)
... Network (2sec)

mccool: fog as distributed cloud
... micro services?
... access to a service, e.g., computer vision
... public devices
... difference in computing storage

ms: go back to the diagram of "Logical Transaction Layers"
... these are system infrastructure view (=Fog Platform Infrastructure layer)
... metrics of business for a transaction
... [Transaction Level Management Elements]
... the fog is logical description of resources
... on top of that, orchestration layer
... and delivery model
... on the left side
... transaction management e.g., by blockchane
... [Resource, Data, Object Transaction Management]
... [Moving forward...]
... [OpenFog Priorities (2017-2018)]
... technical WGs under the technical committee
... interface standardization with an SDO -> open reference implementation
... certification and interoperability fogfests
... regional use cases and test cases from regional committees
... APIs to standardize

mccool: questions?

unida: regarding smart object
... diversity is one problem
... how to overcome?

ms: study in the market
... e.g., W3C perspectives, OCF perspectives
... common vocabulary in those areas
... not to have one single standard
... but consider interoperability
... common vocabulary the use cases
... other SDOs like OIC, AllSeen
... maybe OCF would have different profiles

yongjing: similar question
... you plan to pick up one of existing standards
... or interoperability like WoT

ms: would take existing good things
... don't want to reinvent wheels
... interoperability with existing standards
... may work on open source project with other SDOs
... also testbed project

yongjing: common vocabulary?
... can be done with somebody collaboratively?
... how to host that?

ms: openfog has a liaison wg
... liaison from technical viewpoint
... communicate with other SDOs
... simple liaison and collaborative work on common vocabulary

yongjing: generating your own vocab?

ms: don't have to be a single entity

W3C Automotive - Kaz Ashimura


<dsr> scribenick: dsr

Kazuyuki Ashimura presents W3C work on automotive.

The automotive industry has seen lots of change.

Kaz runs through the list of Automotive WG meetings

He presents a diagram showing the vehical signal architecture.

The bottom level is the car’s internal system as exposed e.g. on the CAN bus

The Vehicle Information API is exposed via Web Sockets using a Vehicle server.

Kaz mentions the VW submission https://www.w3.org/Submission/2016/01/

Work has started on a test framework.

The Vehicle Signal Spec is defined by GENIVI not W3C.

Kaz lists some links to related other work.

The Web of Things architecture will enable an ecosystem of automotive related services.

The VIAS (Vehicle Information API spec) defines an API that is exposed to applications in a web browser.

The VISS (Vehicle Signal Spec) feeds a JavaScript library that then exposes the VIAS API to applications.

Michael McCool asks a question on how to satisfy requirements for functional safety certification.

One solution is to prevent the apps from being able to control the car in ways which would risk safety.

This may require a module that enforces this.

Kaz: the car maker is responsible for that.

Michael: this becomes very challenging for self-driving cars.

Kaz: web of things needs to handle safety and security

Kajimoto-san asks about requirements such as response time.

[afternoon break]

oneM2M Overview - Norikazu Yamasaki


<inserted> scribenick: kaz


norikazu: agenda
... overview of oneM2M partnership project
... standardization at IoT/M2M Service Layer
... release 2 and release 3 ...
... [Global Partnership Project
... 8 partner type 1: atis, TIA, ETSI, tsdsi, CCSA, TTA, ARIB, TTC
... also patner type 2 (vertical payers and industry groups)
... BBF, OMA, HGI (merged into oneM2M), New Generation M2M Consortium, Global Platform, CEN&CENTRIC
... [200+ Members Organizations]
... [Purpose & Deliverables]
... oneM2M purpose: to specify and promote an M2M common service layer
... oneM2M deliverables: technical reports (informative) and technical specs (normative)
... [oneM2M Organization Structure]
... Steering Committee - finance, legal, marketing, methods/proc., certification
... [Work Process]
... various use cases: enargy, enterprise, healthcare, public services, residential, other, transportation, industry
... common requirements based on the use cases
... that is stage 1
... stage2/3 is specification
... [M2M/IoT Common Service Layer]
... M2M Service Layer was defined by ITU-T FG-M2M
... software layer
... between M2M apps and communication hardware/software that provides data transport
... nomally rides on the top of IP
... [oneM2M Architecture Approach]
... Pipe (vertical)
... Horizontal Interoperability (based on Common Service Layer)
... [oneM2M Architecture]
... application layer (consists of Application Entity): device AE, Gateway AE
... Service Layer (consists of Common Service Entity)
... Network Layer (consists of Network Service Entity)
... defining interface between entities
... [Common Service Functions (CSFs)
... registration, discovery, security, group management
... data management&repository, subscription&notification, device management, application&service management
... [Communication Protocols]
... reuse IP-based existing protocols
... service layer core protocols: CoAP, MQTT, etc.
... [Timeline of oneM2M Key Events]
... 2012 - 2013 - 2014 - 2015 - 2016 - 2017
... oneM2M partnership project launch: Q3, 2012
... Release 1 Issued: Q1, 2015
... Interoperability Test Event #1: Q3, 2015
... Interoperability Test Event #2: Q2, 2016
... Release 2 Issued: Q3, 2016
... Interoperability Test Event #3: 2017
... [oneM2M Release 2 Features]
... oneM2M as eneric interworking framework: AllJoyn/AllSeen, OIC, LWM2M
... Semantic interoperability
... [Ongoing Collaborations]
... with other SDOs
... utiliaztion: OMA, BBF, OASIS, HGi, IETF, ETSI
... Interworking: Allseen, OCF (including OIC and UPnP)
... Collaboration: IIC
... liaison&collaboration: ITU-T, GSMA, W3C, 3GPP, IEEE, ISO/IEC JTC1/WG10
... related to IoT technology
... regarding collaboration with W3C, the detail will be explained by Yongjing
... [Toward Release 3]
... Release 3 planning
... work track 1: Market Adoption Track (high priority)
... work track 2: Industrial IoT and smart cities
... work track 3: Forward Looking Areas
... [Phased Approach for ertification]
... initial phase: Oct. 2016-
... Global Phase: 2Q, 2018?
... [OSS and Implementation]
... Industry-driven open source software/platforms
... Cisco: Open Daylight
... examples of commercial implementations/demos
... LG, Huawei, SK Telecom, Sierra Wireless, Ericsson, LG U+, kt, ...
... [Busan Smart City Project/Korea]
... [Smart City/France]
... [UK]
... [India]
... [LG U+]
... [Open IoT Platform (sensinov/France)]

Relationship between WoT and oneM2M - Yongjing Zhang



yongjing: [Technical Highlights]
... [Architecture Configurations]
... Infrastructure Node (IN)
... Middle Node (MN)
... Application Service Node (ASN)
... Application Dedicated Node (ADN)
... Non-oneM2M Node (NoDN)
... lot of options
... [Generic CRUD procedure]
... create request/response
... retrieve request/response
... [Communication Models]
... blocking synchronous
... non-blocking synchronous
... non-blocking asynchronous
... [oneM2M Resource Model vs WoT]
... CSEBase - base
... cseType - @type
... supportedResourceType, pointOfAccess, nodeLink - property?
... [Data Management]
... different resource types
... support hierarchical data model
... support semantic annotation
... can represent (depending on implementation context)
... eventable
... [Subscription & Notification (event)
... can set event criteria
... target address of notification
... [Device Management]
... mgmtObj as a template is specialized to individual management resource, e.g., deviceinfo and firmware
... some are actionable and some are not

mccool: hybrid function

yongjing: [Group Management]

mccool: OCF has same functionality

yongjing: [Semantics]
... RDF descriptors
... semantic discovery/query
... [Security: Enrollment & Security Association]
... enrollment phase and security association phase
... [Security: Encryption]
... [Security: Authorization (Access Control)]
... protocol specific
... [oneM2M Interworking Overview]
... to make different standards/technologies working smoothly together
... - transparent interworking
... - translucent interworking
... - semantic interworking
... [OIC/OCF Interworking]
... OIC/OCF domain and oneM2M domain
... [Ontology based Interworking]
... oneM2M based ontology
... the upper ontology serving as the anchor to facilitate/automate the mapping from external systems to oneM2M resource tree
... [Proximal Interworking via HAIM]
... mapping at the semantic level
... common template
... [HAIM example]
... SDT concepts vs WoT concepts
... [Interworking: WoT->oneM2M]
... exposing the WoT interface described in TD to oneM2M systems
... benefit: WoT services/data can be consumed by oneM2M apps
... question: do oneM2M apps need to understand WoT data model at all?
... [Interworking: oneM2M->WoT]
... exposing oneM2M interfaces to WoT systems
... benefit: oneM2M services/data can be consumed by WoT servients
... question: is WoT descriptive enough for oneM2M data models and interfaces?
... [Annex: oneM2M specification walkthrough]

kaji: comments/questions?

sebastian: we should look into the details
... possible scenario for the next PlugFest

yongjing: can provide further information for discussion

[ OpenDay ends]

Demo Tour at Panasonic Center Osaka

and then Dinner!

[OpenDay ends]

Wednesday, 17 May 2017: Technical Work - Day 1

Plenary Discussion

Thing Description: Model reflection (What is missing? How about the security and lifecycle aspect?) - Sebastian Kaebisch

[Sebastian's Slides]

[Maria's Slides]

scribenick: kaz

sebastian: gives basic background

maria: talks about ontology work

mccool: possibly multiple serializations
... we could omit some of the information
... simplify some of the information
... different serialization for different people

(looking at "Proposal of TD Model")

sebastian: having one core TD model and various serializations

mccool: one serialization could include everything and possible subsets

(discussion on model and serialization)

sebastian: summary
... simple understandable model which is independent from serialization

yongjing: UML-based model?

sebastian: simplified Maria's proposed model

matthias: you can put the slides at somewhere and we can continue discussion

sebastian: will put the resources on the server

mccool: we should consider which tool to use

matthias: matthias: you can create an issue on github within the TD repo

JSON-LD include - Kajimoto


kaji: introduces Echonet spec
... can be converted to JSON-LD
... inclusion and removal of part of JSON-LD definition

dsr: different SDOs have different approaches

sebastian: is this proposal part of JSON-LD itself?

matthias: we had discussion in Santa Clara
... there was the person in charge of JSON-LD 1.1 spec
... may be difficult to reflect to JSON-LD itself
... maybe we can have some specific discussion on how to reflect this idea to RDF triples

kaji: we have research society in Japan
... RDF experts there are interested in this

matthias: are you planning to propose this idea to JSON-LD guys?

kaji: yes

sebastian: you can send an email to the WoT group as well

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


dsr: 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.

barry: we need a control panel?

scribenick: naomi

mccool: we should building a map, what things in a house.
... we should building a map, what things in a house.

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

mccool: ownership, household. issue is to access network is the key. Need to describe too access control.

matthias: 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.

[morning break]

and then breakouts

Wednesday, AM2 - Breakout at Seminar Room

oneM2M HAIM - WoT TD mapping

[Resource models and mapping to TD]

[Liaison TF charter initial discussion

<dsr> scribenick: dsr

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.

Wednesday, AM2 - Breakout at Room 101

Matthias, Barry, Tokuyama, Nishida, Naomi, Nimura, Matsukura, Naka, Naoki, Radim, Kaz, Uchida

HATEOAS - Matthias Kovatsch


error objects/messages to throw in handlers (scripting) based on Symbolic Error classes (like HTTP 2xx, 3xx, 4xx, 5xx)- see also this reddit entry)

matthias: HATEOAS: Hypermedia-driven Actions and error handling
... [Be aware: WoT is Two-fold]
... complementing existing standards
... for binding templates, scripting API
... [HATEOAS/Hpermedia Controls]
... Entry URI -> Resource Directory -(follow links)-> Thing A
... how to handle multiple Things?
... [Prototype: ISO/IEC 15118-2 - Electric Vehicle Charging]
... a lot of steps here
... Siemens implements EV charging device
... setup phase and charging phase
... we can find use cases from this
... [Actions]
... short-lived actions and long-lived actions
... we might want to monitor them
... any implementations?
... ideas?
... in your prototype implementation, how to control the process?

radim: so far just reading data

matthias: what about air conditioners or robot cleaner?
... would like to have some brainstorm

nimura: related to management topic
... need some control mechanism inside Things
... HATEOAS might be applied
... some one need to provide management mechanism

matthias: definitely need new mechanism
... would like to start with this viewpoint
... related to Scripting API
... maybe we can connect this topic to the management topic, though
... you don't have to let the client know about concrete state transition model
... loose coupled interface
... (mentions a use case of online payment)
... having this mechanism for machines would be powerful

nimura: we need to think about concrete situation for this

matthias: maybe machines should know about basic state transition by vising the "next" link

radim: question about the "long-lived" action

matthias: there a lot of freedom here
... TD usually has some starting page and following consecutive links

nimura: need mechanism for error handling as well

matthias: [Error Handling]
... shows example code of .onInvokeAction
... but how to recover?
... handling status code internally?
... [Error Messages]
... provide means for recovery
... 404: link to the start page
... 401: link to "log in with Facebook"
... provide means for machines
... TD-like interactions
... action(?) to the get access token
... would like to get opinions from people

kaz: mentions SCXML as a detailed state transition mechanism for long-lived action transition
... but what kind mechanism would fit which level of action transition?

matthias: small high-level state transition mechanism possibly?
... (mentions an example use case of converting temperature by C to F)

Browser-based Servient - Radim


radim: [CHRIMEN]
... based on B2G
... reference open-source hardware board providing Web GPIO/I2C APIs
... [Exhibition/Event]
... try and touch event
... Interop Tokyo 2016
... Keio SFC 2016 event
... [Maker Fair]
... [Online Resources]
... chirimen.org, etc.
... [Web x IoT Maker's Hackathon]
... [Web x IoT Maker's Hackathon (cont.)]
... [Vision: Pervasive browsers]
... IoT devices into which Web technology ahs been introduced

matthias: chicken and egg problem
... hard to give enough information
... [Web GPIO/I2C API]
... work by the Robotics CG
... robot controlled by a browser (with GPIO/I2C APIs)
... can handle temperature sensors, etc.
... and export the information as a servient
... [Recent Activities]
... implementations by polyfills
... discussion on APIs
... should be more general APIs?
... security issues
... authentication and authorization
... some of the devices don't have displays
... browsers always send requests?

radim: [Browser has no server function]
... [WoT servient with browser]
... browser on th edevice communicates with WoT servient on cloud or gateway as a WoT client
... [Issues]
... authentication and authorization of browser/client
... setting properties should be allowed only to some specific client
... consistency between thing descriptions and devices
... distance sensor value should be set as a distance properties

kaz: interested in the DAP WG's generic sensor API discussion?

radim: possibly but so far interested in GPIO and I2C
... how to make the interface abstract

matthias: where to connect with the WoT discussion?
... Matsukura-san is working on abstraction
... this is related to hardware APIs
... how to talk with sensors
... are you aware of Johnny 5 project?
... similarity with TD as high-level interface
... can provide your ideas to the Scripting API discussion as well
... this board is usually connected with ubiquitous browsers
... possibly connection during the plugfest at the next f2f in Dusseldolf
... comments/questions?
... lunch and marketing strategy after that


Marketing strategy - Michael McCool



<scribe> scribenick: kaz

mccool: [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

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

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

mccool: presentation tutorial?

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

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


mccool: [Online Presence]
... Web site, Wiki, Github and evangelism (Webinar, etc.)
... [Evangelism]
... Events and Liaisons
... [Recruiting]
... 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

mccool: comments?

<inserted> mccool: shall we try some exercise?

<kajimoto> Open,Enhance, Flexible by WoT

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

mccool: 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.

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

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

Wednesday, PM1 - Breakout at Seminar Room

Scripting API: WoT Runtime clarifications - Johannes Hund

[Impulse slides]


Issue 2

zoltan: need to discuss the relationship with "tab"

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

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

zoltan: don't think there is any implicit origin

matthias: requests from the outside to start scripts are irrelevant

jh: wraps up the discussion:

<jhund> We have concluded upon these points:

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

<jhund> * scripts run in a script execution context

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

<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

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

Scripting API: WoT Runtime clarifications - Zoltan Kis

[Zoltan's slides]

zoltan: [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.)

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

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

sebastian: [Request to run script]

jh: would talk about this during tomorrow's session


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.

Wednesday, PM1 - Breakout at Room 101

Security - Elena Reshetova


[Security Summary]

[afternoon break till 4pm]

Wednesday, PM2 - Breakout at Seminar Room

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

Synchronization of WoT Servients - Ryuichi Matsukura


matsukura: [WoT Servient architecture]
... 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

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

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

matsukura: 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?

matsukura: right side "Cloud (WoT servient)"

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

matsukura: [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

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

matsukura: this process an be omitted

matthias: discovery api is missing here

yongjing: Matsukura-san proposes 2 ways

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

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

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

matsukura: [slide 2]

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

matsukura: would have the resource model separately from the runtime

nimura: [Device registered to master repository]

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

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

yongjing: what would trigger the data transfer

kaz: would suggest clarify the data transfer using a simple diagram which shows the inter-servent data transser

ladder diagram 1 ladder diagram 2

matsukura: tx

Wednesday, PM2 - Breakout at Room 101

Security: Review of related models (i.e., from IETF and IIC-SF) - Michael McCool


[Security Summary]

[Technical Work Day 1 ends]

Thursday, 18 May 2017: Technical Work - Day 2

plenary discussion on Thursday

AM1: Summaries and Next Steps

OCF 1.0 Review: Changes from OIC 1.1, Swagger (OpenAPI) and introspection, OCF 1.0 security model - Michael McCool


mccool: [Summary of Changes from OIC 1.1]
... introspection: swagger 2.0 (aka OpenAPI) available
... meant to augment (not replace) other introspection capabilities
... [Major Change 1: Introspection and Data Models]
... see pages 132-134, section 11.8 of OCF Core spec

OCF core spec

mccool: the intended usage of the introspection device data is to enable "dynamic clients"
... dynamically generate a generic "browser" UI, create translations fo the hosted resources to another ecosystems
... other usages of introspection
... [RAML vs OpenAPI/Swagger]
... both designed for Web APIs (not IoT)
... RAML is based on YAML (but can be encoded in JSON)
... Swagger uses JSON-Schema (but can also use YAML)
... for detailed comparisons:
... http://modeling-languages.com/modeling-web-api-compareing/
... http://nordicapis.com/top-specification-formats-for-rest-apis
... [RAML vs OpenAPI/Swagger] (sample codes)
... [Major Changes 2: Enhanced Security]
... details here: @@@
... property access, mandatory device state, software update, ...
... [Other Changes]
... [OCF ER Model]
... omitted/incomplete/wrong:
... mappings from abstract mechanisms to concrete mechanisms
... link is incomplete
... collections, links, scenes
... introspection: new in OCF 1.0, introspection resource is available to retrieve OpenAPI data model
... walk through the data model...
... properties have some flags
... resource types
... manager part optional
... [Issues with OCF ER Model]
... relationships need to be labelled and categorized
... links are incorrectly modelled right now
... certain other aspects not modelled yet
... [OCF Links]
... sample code
... "href": "/switch", ... target
... "rel": "contains", ... relation

matthias: this is not "OCF link" but "Web link"

mccool: depending on CoRE

matthias: core link format defined by some RFC

CoRE Link Format

mccool: [WoT Links]
... [Next Steps with OCF Model]
... converge notation with oneM2M, IoTschema, etc.
... formalize usimg RDF and define OCF ontology
... validate with OCF
... mirror work done with oneM2M
... [OCF/WoT Interop Demonstrator Planning]
... need to demonstrate WoT system interoperating with OCF devices
... select set of simple OCF devices to use at a test case
... generate a TD for OCF devices
... [OCF Smart Home]
... demonstrate multiple aspects and implementations of OCF
... requires special hardware to run
... physical sensors to be connected
... should be possible to convert to software emulation (using QEMU for Zephyr component)
... https://github.com/01org/SmartHome-Demo
... smart power meter on Zephyr
... [Smart Home Demo Enhancements]
... questions?

kaz: are you joining PlugFest from this viewpoint (as part of OCF) during the next f2f in Dusseldolf?

mccool: that is the plan
... possibly using multiple different platforms/backends
... have to look into the detail
... comments?

yoshi: interoperability between OCF and WoT
... what kind of architecture do you assume?
... function bridge

mccool: WoT bridge which exposes TD
... binding to OCF protocol
... possibly on a gateway

yoshi: possibly OCF, oneM2M and WoT

mccool: protocol binding discussion should handle a list of possible target protocols
... visits 01org/SmartHome-Demo
... Michael Koster will present his protocol binding proposal later

Thing Description: Data type with semantic annotation based on JSON Schema + TD Namespace - Sebastian


sebastian: [Agenda]
... JSON Schema
... [TD Current Working Assumption]
... [Missing Thing in JSON Schema]
... e.g., a TD servers a property 'status' of a thermostat
... 'status' defines an object with multiple data
... where is the temperature value measured in Celsius?
... [Agenda] again
... discussion with Henry Andrews in Santa Clara

sebastian: https://github.com/w3c/wot-thing-description/json-schema-spec

daniel: semantics could be edited using json schema
... Henry brought a comment

issue 309

daniel: would respond to that
... last comment made one hour ago

matthias: somewhere to store data
... and schema and validate the data
... different languages for humans
... TD tries to unify
... you don't have to have out-of-bound knowledge
... applicable from one platform to another

barry: thermostat might provide time/date

dsr: we don't want to make small devices handle complicated semantics

daniel: simple string might be useful in some cases for our plugfests

matthias: semantics and interaction model

<dsr> For the web of things we need both descriptions of interaction models and semantic models which deal with different concepts

matthias: we want to describe how machines handle semantics
... how one machine interact with another machine
... and understand what it can do

dsr: temp sensor provides temperature as simple number

matthias: number is not interaction
... important part is what kind of links/methods are used

daniel: links to different concepts

dsr: discussion later today
... what would be the cleaner way for interaction

taki: data types are some degree some kind of semantics itself
... integer, binary, base64, ...
... we need to convert one form to another
... we can't do automatic conversion

matthias: another question
... how you actually link to the linked data level
... text form vs rich level
... how to manage the gap?
... numbers and strings

dsr: linked data and RDF
... you can use json schema or json

matthias: in human mind, we can understand how to handle data
... but if we can't formalize the gap, machines can't handle the data
... we need concrete mechanism

sebastian: you should provide concrete proposal

kaz: we had discussion during the TD call the other day
... and I started to think it would be useful to have 2 separate layers for TD
... device-agnostic interaction layer
... and device-dependent layer
... was expected to create an issue on that
... but have not yet done...

dsr: shows his proposal

Dave's proposal

dsr: data types definition
... booleans, numbers, strings, objects, ordered/unordered collections, vectors, enumerations, unions
... how to formalize in terms of metadata?
... interaction model
... in terms of RDF

sebastian: difference from JSON-LD?
... how to integrate semantic meanings of particular data types?

dsr: we want to start with some particular things
... what kind of units are used

matthias: fundamental already we're doing
... the question is how to start something?
... how to formalize this for distributed "Thigns"?
... that's what we've been doing during our PlugFests
... this is fundamental we've been doing
... but how to build concrete systems?

mccool: replacing JSON-LD with RDF?
... what do we use JSON Schema for?

yongjing: maybe we should once go back to Sebastian's slide?
... [Missing THing in JSON Schema]
... the issue may not be te problem of JSON Schema itself
... rather how to represent the information model?
... for oneM2M spec
... you have "unit" value
... maybe need another level of hierarchy
... we can solve this issue by information model rather than JSON Schema itself

sebastian: that's possible
... but how to handle additional information within TD?

matthias: we don't have any specific semantic mechanism here
... we should fill the gap
... we don't want to start from scratch

barry: we're talking about 2 things now
... you can go with many levels of data

yongjing: if someone provides this kind of data model (on the left side)
... can't tell the semantics
... we should add additional semantics information

matthias: agree
... need to provide unified way

sebastian: would like to ask Yongjing and Dave to join the issue discussion on GitHub

kaji: we can use the open slot after the morning break
... also could shorten the lunch

kaz: btw, there are 2 issues: semantics and unit
... from the viewpoint of unit, we can simply use SI unit, e.g., kelvin for temperature
... each local servient can convert kelvin to C or F

[ morning break ]

Binding Templates - Michael Koster

Michael's slides

koster: [Protocol Binding]
... maps abstract operations on WoT meta types to concret operations
... WoT, OCF
... [Protocol Binding Template]
... a spec for the information included in a particular protocol binding
... [Thing Description (simplified)]
... semantic description and protocol binding
... [OCF Protocol Binding]
... avoid embedding knowledge of specific OCF resource type constraints in software
... basic form of a hypermedia control, extension to the "links" property
... [Generation of Thing Descriptions from OCF Introspection Data]
... generate TD and protocol bindings from introspection data (Swagger)
... Dave's tool creates TD from OCF resource descriptions
... OCF has an open source "swagger 2x" tool
... with input/output schemas
... [Strawman Example]
... highly explicit, identifies everything needed to use generic protocol engine
... [Alternate OCF resource formats]
... composite format and batch format
... this is an actuation format
... [TD - Interaction Description]
... JSON Schema + Extension
... "targetlevel": { "type": "number", "semtype": "sch:level"}
... protocol binding goes under that
... [TD - Protocol Binding (Composite Format)]
... links: [
... {
... "href": "..."
... "inputdata": {
... "type": "object",
... @@@
... CoRE link model


koster: going back to 2 different formats
... [Batch Format]

matthias: your implementation needs to know what OCF spec does here

mccool: need to be more general thing

matthias: you can look at this from technical viewpoint
... might be some specific options

mccool: e.g., nice to have a CoAP level
... and OCF level too

matthias: if we need to know the detail of OCF spec, there is no merit of protocol binding

<inserted> yongjing: who is in charge of the binding? refer to, e.g., oneM2M schema?

matthias: media type is missing

koster: possibly multiple resource types
... might have some kind of state machine

yongjing: wondering if it's really sufficient to use this information to generate OCF messages
... any OCF specific extensions?

koster: good question
... e.g., IoTivity is a client
... probably a bridge

yongjing: native WoT servient may not fully be able to interact with an OCF server

koster: WoT client should have capability to talk with an OCF server

mccool: a WoT client should be able to behave as an OCF client

koster: that's one case
... another case is
... using consumeThing interface

matthias: exposing a Thing to an OCF client might be difficult
... maybe need to think about on the next step

yongjing: possible need for additional oneM2M parameter

<toru> quit

kaz: draw a diagram
... and wondering who/what is in charge of generating the protocol binding part
... and how it generates the template?

mccool: would like to try protocol binding from WoT to OCF during the next PlugFest in Dusseldorf
... starting with manual generation
... and Swagger introspection is the second spec

dsr: should maximize the semantic information

(discussion on how to proceed)

matthias: would suggest we create an issue on the GitHub before starting yet another TF call

ladder diagram 3

[Lunch till 1:30pm]

Thing Description (contd.)

sebastian: [Missing Thing in JSON Schema]
... [What we need in JSON Schema]
... key elements and semantic annotation
... "@semantic": "http://example.com/..."

mccool: or add keywords to JSON Schema to point URLs

sebastian: this approach adding meaning of concrete instance as well

barry: what you're talking about here is not semantics but type
... semantics is something like "in-door temperature at this room"
... Celsius/Fahrenheit is not enough

mccool: unit and semantics

yongjing: not a set of RDF
... this could be multiple instances

sebastian: can be array?

yongjing: yes

matthias: link to a number of linked data
... this is a linked data model

barry: Celsius/Fahrenheit information is part of the data but we need some more information

matthias: temperature data may be described using kelvin as unit
... location (=at this seminar room) is possible semantics

sebastian: [TD Current Working Assumption]

mccool: maybe you could pick up some key concepts

matthias: this is extension to JSON-LD for semantics

mccool: this is not actual TD but JSON Schema. right?

matthias: this is not a good example
... so McCool has a question

mccool: putting Schema into TD?

sebastian: yes

mccool: so would have extension for JSON Schema

yongjing: what is your expectation? ontology or schema?

sebastian: want to introduce a tool to handle semantics in TD

matthias: in TD, we need some kind of vocabulary
... didn't want to reinvent the mechanism
... in JSON Schema, there are useful terms
... so might want to embed some of them into TD

dsr: JSON Schema is not a vocabulary
... that is a different task

matthias: but we can borrow the mechanism
... the question is which linked data vocabulary to start with?
... nice idea is combining the mechanisms
... can be handled by machines

dsr: linked data should be independent from serialization

matthias: JSON Schema would be a good starting point
... this is a subset of what we agreed on

sebastian: shows JSON-LD Playground: http://json-ld.org/playground/
... getting more challenging

yongjing: wondering about the difference between existing type and this additional type
... your problem scenario should be a complex type
... would ask Dave to provide concrete example with problems



"@context": ["http://w3c.github.io/wot/w3c-wot-td-context.jsonld",

{ "sensor": "http://example.org/sensors#" }


"@type": "Thing",

"name": "MyTemperatureThing",

"interactions": [


"@type": ["Property","sensor:Temperature"],

"name": "temperature",

"sensor:unit": "sensor:Celsius",

"outputData": {"valueType": { "type": "number" }},

"writable": false,

"links": [{

"href" : "coap://mytemp.example.com:5683/",

"mediaType": "application/json"






mccool: one option is adding keywords from JSON Schema to TD
... another option is adding custom types to JSON Schema

barry: "cvc" is just a number

mccool: we need richer type system

barry: right

mccool: use case discussion for tomorrow

sebastian: use case:
... servient 1 (weather station) just needs Celsius value

dsr: TD is abstraction and should be independent from serialization

matthias: problem of terminology
... combining two things
... serialization is a mechanism to serialize some data model
... JSON-LD is a serialization

dsr: am focusing on interface between apps

<elena> kaz, sorry to interrupt, is there a change in agenda? There is noone at the security meeting...

ah, yes

we've been talking about TD again

for 30 mins

but the discussion getting longer

<elena> so when should I join?

maybe in 5 mins but not sure...

<elena> ok, I will keep the meeting running then


taki: what is our scope?

matthias: starting point is ok with JS
... input/output on the Scripting API level

mccool: expressing the structure of the data
... JSON meant to be a universal data format

(some more discussion)

[we'll continue discussion on how to add types, semantics to TD based on generating concrete TDs and corresponding JSON Schemas]

Thursday, PM1 - Breakout at Seminar Room

Scripting API: Management interface - Nimura


nimura: [Behavior of management Interface]

zoltan: need to fix the figure

matthias: if you can't do something using property/action/event, something is wrong
... there are 4 management features
... but could be handled by action/event
... there might be a servient which doesn't provide functionality
... only allows proxies

nimura: [How to achieve the Synchronization]
... can be achieved by some scripting api
... not necessarily need to use management interface

matthias: quite similar to the management api
... what is the difference???
... why we need to create something new?

johannes: [slide 4]
... similar interface to other exposedThing

nimura: yes

matthias: the red box "management api" accessible from outside
... TD describing the management thing?

johannes: got consensus?

kaji: motivation to introducing management
... [slide 1]
... (2) Scripting API (Remote)
... some kind of tunneling functionality?
... directly connecting to the Servient would be easier

<zkis> *yes, but maybe through my new version of slides, so let's wait on their turn

kaji: not sure about the motivation

[here: yamada, nagao, kaji, ohura, kaz, toumura, matthias, matsukura, nimura, yongjing, sebastian, uchida, jooyoung, youngmin, shieya, mizushima, uday]

johannes: expose all the functionality to the network
... why not having exposedThing for this purpose?

<jhund> to clarify my view : Management Thing is a regular Thing to the outside, but it has more rights, as it controls the runtime

<zkis> Agree with Johannes - I have a new version of yesterday's slides that hopefully makes that more clear.

kaz: our impression is that we don't need specific new "management api" but can extend the capability of scripting api. would suggest we clarify our expectation for "management" based on some concrete use case (e.g., the plugfest demos in Beijing) by drawing a sequence diagram/

WoT Runtime,Scripting, Bindings - Zoltan

[Zoltan's slides]

zoltan: [WoT Scripting]
... do you agree this usage of scripting?

johannes: TD template pointing script is a new idea

zoltan: red line means script create things
... blue line means TD refers to script

matthias: green "TD" has new concept
... green "TD" is usually something related to yellow "Things"

zoltan: agree

nimura: what about security with remote servient?

zoltan: same for all the servients
... who is requesting what
... runtime checks access rights

johannes: we have a manager thing
... allows us instantiate runtime
... and script execution context
... discoverable by local discovery

<mkovatsc> Tried to incorporate my understandings here:

<mkovatsc> https://docs.google.com/presentation/d/10xeircxLQzC7cOgArfMkxPMd1_kFjlQjiyan5zT-11k/edit#slide=id.g223c523f22_0_224

johannes: and accessing outside sandbox should be done by scripting api/client api

<jhund> 1) There is a Managent thing that allows to download or receive a script and run it

matthias: is the plugin interface intended to standardize something? or implementation?
... can be done using system interface

<jhund> 2) scripts run associated to a script execution context. things in the same execution context are discoverable via local discovery

<jhund> 3) Accesses outside of the sandbox resp. the execution context should be done via a thing interface

<jhund> (those were 3 proposed formulations for consensus points, please feel free to correct&comment)

(showing Matthias's updated figure)

Matthias's update

zoltan: better figure

matthias: better to iterate discussion on this kind of picture

nimura: do we have one single event loop?
... or separate multiple loops?

matthias: safe to share the same event loop

nimura: how to protect the context?

matthias: no need to expose to the outside
... same owner of the device, then no need for separation

zoltan: we should come with updated slide set
... and update the rational document

matthias: +1
... having an accurate picture is very important
... relationship between boxes

zoltan: yes
... we can start with Matthias's diagram on Google docs

johannes: ok

nimura: btw, we were talking about synchronization as well
... how to deal with that part?
... e.g., using a 2-runtime model

Thursday, PM1 - Breakout at Room 101

Security: Classification and Prioritization/Summary and Next Steps

[Security Summary]

Thursday, PM2 - Breakout at Seminar Room

TD Serialization - Sebastian

TD namespace reserved

sebastian: how to manage versions?

<inserted> sebastian: [TD Namespace]

dape: what we discussed so far is reference to the latest version
... vs dated version

kaz: we can publish a specific group Note for each version of the namespace
... e.g., https://www.w3.org/TR/wot-thing-description vs https://www.w3.org/TR/NOTE-wot-thing-description- 20180101

sebastian: [TD Model Requirements]
... should be independent of any serialization format
... JSON-LD 1.0, 1.1, JSON, EXI, EXI4JSON, CBOR, ...
... TD model hsoudl be very clear and understandable by developer that have different backgrounds

dape: will share my slides
... some ideas
... [Goal]
... identify suitable serialization foremats for WoT TD
... what is not a goal?
... [What is important for WoT TD format?]
... adaption in communities/platforms
... acceptance by Web developers, embedded developers
... data exchange size
... processing speed, requirements
... royalty free
... free/opensource implementations?
... collect ideas?

sebastian: opinions?

cabo: for embedded environment
... should be interesting original requirements

dape: interested in what "processing" means

<cabo_> ... enable in-place processing

dape: [Possible Candidates]
... text-based ones vs binary-based ones
... EXI4JSON, CBOR, Smile

matthias: might want to say "constrained or not"

dape: 2 different use cases
... target to Web developers on the left side
... and embedded developers on the right side
... Web-friendly or traditional

sebastian: possible additional category
... semantic web developers

matthias: let's have a list
... and then could sort it

sebastian: possible to support all of them
... should we make examples?

kaji: agree
... first creating categories
... and then think about priorities

dape: somewhat tricky
... [How to do an evaluation?]

cabo: usual way in the past
... coming up with a benchmark scenario
... do the data model in the serialization required?

dape: size and processing

cabo: size is an interesting property
... but optimization as well

sebastian: how would you measure that?

cabo: not necessarily quantify

sebastian: comments?
... make sense to find some use cases and test beds?
... different sample TDs
... also some benchmarking

dape: wa're targeted more on embedded purposes

sebastian: Dave is not here but he had a proposal

cabo: more in favor for exposing
... explicit rule for interchange

dape: updates the slides
... creat embedded test-bed
... check conversion from/to Web to embedded format
... we could start with something simple
... TD files could do some initial things

sebastian: make sense to set up a test bed

dape: mix of TD complexity

cabo: 2 different objectives
... 1 is having examples
... structured element
... 2 is realistic examples
... various functions
... no need for benchmark for the coverage part (=#1 above)

sebastian: could have examples from OCF and/or oneM2M
... different kinds of examples

sebastian: any volunteers?
... maybe Daniel and Carsten?
... everybody who participates in PlugFest provides their generated TD

dape: as a starting point, can we collect TDs?

sebastian: information at: https://www.w3.org/WoT/IG/wiki/F2F_meeting,_May_2017,_Osaka,_Japan#Participation
... Daniel, can you organize this work with Carsten?

dape: try to start

taki: processing TDs for embedded devices
... how to find semantics

sebastian: we already have some semantics
... any other comments?


kaji: all the sessions for today ended
... tomorrow administration and next steps
... marketing and the next f2f
... originally planned till 5pm
... but would like to shorten till 3pm instead

Thursday, PM2 - Breakout at Room 101

Linked Data and Semantic Processing in WoT - Dave Raggett & Darko Anicic


[Technical Work day 2]

Friday, 19 May 2017: Administration Day

Security Summary - McCool


<inserted> scribenick: kaz

mccool: [Initial version of Threat Model]
... [Threat Model]
... stakeholders, roles, assets, adversalies, attack surfaces, threats, use cases, security objectives/non-objectives
... attack surfaces
... we have an opensource implementation
... hierarchy of trust
... different levels of trust
... [External References and Standards]
... if any ideas, please create an issue on GitHub
... External references
... industrial internet consortium security framework
... IETF ACE, RFC 7252 (CoAP) security model, RFC 3552, RFC 6973, STRIDE Threat Model, OWASP IoT Attack Vectors, IoT Security Foundation, FIPS and other national standards
... Liaison references
... OCF 1.0 Security spec
... oneM2M security solutions, OPC, Echonet, BACnet

kaji: can we add even more references?

mccool: see pullrequest 319

kaji: emotion technology consortium
... btw, what would be the concrete methodology for the security discussion?

mccool: shows [Process]
... opensource implementation
... also clarifying requirements
... 1. threat model, 2. scoping, 3. state-of-art, 4. solutions, 5. implementation and evaluation

nimura: regarding attack surfaces

mccool: protocol bindings execution boundary

nimura: distributed way
... with multiple WoT servients

mccool: multiple instances and bridges
... should clarify what would be in-scope and what would be out-of-scope

dsr: single system here

mccool: WoT is basically a bridge
... very important to be secure

nimura: use cases?

mccool: e.g., smart homes
... gateway as a firewall

kaz: the final deliverable would handle safety as well?

mccool: mainly security and privacy but would see the charter

Scripting API summary - Nimura


nimura: [WoT Stack]
... also [Role of scripting API]
... discussion on the management interface
... will update the rational document with the WoT stack diagram as well

kaji: registration of the WoT servient?
... possible need for a specific servient for management purposes

nimura: shows the slide on synchronization

TD summary - Sebastian


sebastian: TD core model, TD lifecycle, semantic annotation in JSON Schema, ...
... [Set this TD Model as Baseline]
... shows the basic TD model and sample instances in different formats
... [TD Lifecycle]

kaji: proposed to introduce additional operatons like "@remove" and "@include"
... to modify/update TDs over its life time
... collaboration with the JSON-LD team

dsr: similar topics for the API side as well

yongjing: dynamic modification or kind of static?

kaji: modify attributes
... e.g., when copy existing attributes, maybe don't need part of them
... also variation of products like air conditioners
... basic template and various additional features based on each product
... mainly thinking about lifecycle of products

dsr: possible live update

kaz: possibly update the OS or library weekly?

kaji: yes, so related to scripting as well

sebastian: [Missing Thing in JSON Schema]
... long discussion
... keep collaboration with the JSON Schema team
... reuse JSON-LD keys such as @context and @type
... would ask Dave and Yongjing to join the discussion
... [TD Serialization]
... TD core model could be serialized using various formats
... separation between text-based representation and binary one
... maybe should select one default text rep and one default binary rep
... but don't invent new serialization formats
... evaluation of binary versions (e.g., EXI4JSON, CBOR)
... how to evaluate?
... Daniel and Carsten are volunteering

yongzing: we should support all the possible formats?

dsr: how to work with broader communities?
... need to have a plan for that

TF-LD summary - Dave

dsr: relationshp between interaction models and semantic models
... scarable approach based on commercial reality
... need for bridging ontologies
... valuable discussion and working on a plan for a roadmap with clearly defined short term goals

sebastian: TD related to the semantic model

mccool: bridging multiple standards
... mapping of concepts for transformation

dsr: don't think there could be a single mapping

mccool: model for some given standard
... maybe need for an abstract model for IoT

sebastian: motivation of this mapping?

dsr: different vendors may have different models
... need to allow bridging different models

mccool: there are ontologies out there
... could have a common ontology and mapping to that

yongjing: the mapping itself is not in our scope?

sebastian: this TF is working on that

dsr: this is a TF of the IG side
... not for the standard work

mccool: we should have some concrete example
... possible output is about what should be added to TD

dsr: slides available from the agenda wiki

kaz: related to the discussion on TD vs protocol binding
... TD should handle abstract semantics and protocol binding should handle concrete information on the device level

separation of TD and Protocol Binding

mccool: but the separation is not that simple

Synchronization summary - Matsukura

matsukura: [WoT Servient architecture]
... 2 types of applications
... [Discovery and Provisioning fro device]
... [Example diagram for sever-client]
... one servient on the gateway
... and another servient on the cloud side
... [Device registered to master repository]
... will continue the discussion and clarify the requirements

yongjing: thought we had 2 approaches
... will support both?

matsukura: yes

[ morning break ]

<dsr> We also need to consider peer to peer approaches for fully distributed repositories which can offer greater security, e.g. against denial of service attacks.

[mornin break]


Use Cases


<dsr> scribenick: dsr

Michael McCool as the session lead.

(slides to be uploaded later)

Outline: discuss process and goals, gather/brainstorm, prioritize, derive requirements and incorporate into our plan. An example is the security objectives.

The goals: use cases as a basis for justifying specification design choices

Use cases for mindshare and building a concrete understanding, e.g. as a basis for recruiting new companies to help with work on standards

This needs concrete and compelling examples.

To drive requirements and test cases we need a range of use cases.

There are two broad axes: one is technical and the other the application domain

On the technical axis: simple use cases to explore the data types, interactions and architecture

Complex test cases to test boundaries including pathological cases

Distributed use cases, multi-device use cases, lifecycle use cases, different audiences, etc.

Including real time and streaming.

Example contexts: application domains such as smart Home, smart Building, smart *

We need examples that explore the use of contextual information richer semantics.

Other dimensions: simple to complex, local to global, trusted to untrusted, number of devices, number of ecosystems, asynchronous (deliver whenever) vs Synchronous real-time delivery

Lossy vs guaranteed (transactional)

My expectation is that we should start at the easy end of this multidimensional space and then expand along some key dimensions.

Issues to test: dependency chains, distributed race condiitions, translation of information, and possible loss of meaning and capabilities.

Performance and so forth.

For the smart home: connection of personal devices owned by a family (need to develop personae)

Some devices installed in house, some owned by family some by individual family members.

Assume that there is a firewall with a wifi network, and a gateway/hub that has capability for computation and storage, e.g. acting as a bridge and small services.

Some scenarios: onboarding a new device, controlling a single device, services coordinating multiple devices from different ecosystems, family member moving to new household, visiting guest need access to a subset of devices

Yesterday, Barry talked about some interest scenarios we should look at.

For smart cities: a constellation of smart buildings as well as city infrastructure.

System integrator that combines systems from different manufacturers.

Need for large scale monitoring and maintenance


The smart factory context involves a combination of IT and OT (operational technology), including strict requirements in respect to safety, reliability and so forth.

The need to address brownfield systems, pre-IoT OT systems.

The need to enable data driven decision monitoring of devices and processes.

More background available from the Industrial internet consortium.

Barry: we could take forever to think about use cases. It would be a good idea to constrain this by considering how use cases change what we think.

Is our goal to list the use cases on the website for internal use or do we want to publish them for external consumption?

Michael: we already have several external bodies working on use cases, perhaps we can leverage these?

Dave: I see a need for a small set of polished use cases for marketing materials in addition to those we use internally for technical guidance.

Michael: we need to decide on our key values and how we can show and explain these to others.

Barry: having simulated devices can be really valuable for ease of demonstrations

Michael: the benefits need to be really clear.

Sebastian: use cases can help with design choices in the architecture, e.g. thing to thing, thing to cloud

I think we can look at smart city use cases from the BigIoT EU project

This includes some automotive use cases.

Michael: we’re trying to enable larger ecosystems that span multiple standards

Smart cities could be fruitful in that regard

Kajimoto-san: what guidelines should we adopt for describing use cases, e.g. the granularity

Sebastian: in the early work of the Interest Group, we rapidly switched to focusing on atomic use cases.

Uday: we should consider use case scenarios involving a handover of domains

e.g. home, workplace and city

Importance of focus and prioritisation

Michael: perhaps we could survey existing use cases and identify a taxonomy

So an action on studying existing use case collections and identify use cases where the web of things would add value.

Another action is to take our key value(s) and brainstorm some example use cases that demonstrate it, and then build the corresponding demos.

<mkovatsc> http://w3c.github.io/wot/wot-ucr.html

<mkovatsc> https://github.com/w3c/wot/tree/master/ucr-doc

Dave: one idea is to make simulated deviced available by our member companies for use in demonstrating the power of the Web of things across ecosystems.

Michael: we could also support online information on how to download and install demos, e.g. onto a Raspberry Pi.

Likewise, we could make it easy for people to download and run simulations.

Some companies could offer evaluation kits

We could collect, maintain and publish a large collection of use cases — however that would be a lot of work.

Kaz: do we want to have an internal collaboration within W3C, e.g. across groups with demos at TPAC?

Michael: yes, e.g. with the automotive and sensor group.

Dave: how about some short term goals?

Michael: yes, we should soon decide on what is and what isn’t in scope.

I would like to assemble a list of references to IoT use case collections

Secondly to work on the marketing needs

For security, we will need to describe what we’re looking for from use cases.

Michael: any volunteers for driving the collection of references for use case collections?

Kajimoto-san: I have some use cases I can offer to the group for consideration

Michael: we should aim to work top down rather than bottom up, so that can ensure that we’re efficiently addressing our goals.

I will put this up on Github and we can use the issue tracker to work on it.

scribe: . we break for lunch ….

F2F Meetings and Roadmap - Matthias & Uday

[Matthias's Slides on the next steps]

[Uday's Slides on the upcoming Dusseldorf f2f]

<inserted> scribenick: kaz

matthias: [Change for 2018?]
... issue: little time between f2f meetings
... slow progress in PlugFest implementations
... still very little at f2f time for TFs

mccool: security input

matthias: no other comments?


matthias: would go for this
... proposal only 3 f2f meetings in 2018
... and having regional+online
... [Dusseldorf f2f 9-13 July 2017]

uday: give explanation

Dusseldorf f2f logistics

uday: airport concress center
... accommodation details to be followed
... f2f wiki will be created shortly

matthias: deadline for registration?

uday: not decided yet

mccool: need deadline for logistics (food, party, etc.)

matthias: hosted by RWE/Lemonbeat
... 9-13 July
... 2months to work
... todos:
... populate wiki: hotel list, collect topics
... block rooms in nearest hotel
... open registration (Kaz to help)

mccool: network connection (cable, wifi)

uday: looking into that

matthias: check network infrastructure of the venue
... usually I bring a wifi router
... got inquiry from possible attendees for OpenDay

uday: when would be the OpenDay?
... possibly Sunday for PlugFest preparation and PlugFest on Monday

matthias: good to have demos on OpenDay as well

uday: half day on Sunday (afternoon) for preparation?

matthias: yeah, don't want to work the whole Sunday
... btw, there will be the IRTF T2T meeting in Plague next week
... 9-13 July (Sun-Thu; Sat-Fri IETF in Plague)
... [F2F Meeting November 2017: Burlingame, CA, USA]
... TPAC 2017
... 6-10 November 2017
... 4 months to work
... plugfest preparation: open space or room on Sunday
... plugfest: request full-day room or at least 3 hours on Wed.
... plan observers/groups to meet

kaz: will talk within the W3C Team
... about the PlugFest planning

matthias: joint meetings?

kaz: automotive, DAS, TV, etc.
... will contact Chairs of those groups

matthias: accept observers?

kaz: yes

matthias: [F2F meeting spring 2018]
... in US?
... collocated with security conf?
... internetsociety.org/events/ndss-symposium/ndss-symposium-2017: San Diego, 18-21 Feb.
... ieee-security.org/TC/SP2017/index.ml: San Jose May)
... look at calendars
... IETF: London, UK, 18-23 March 2018
... OCF? oneM2M?
... todos:
... organize academic conf workshop (with T2TRG)
... will discuss in Chairs call
... good to have the ndss symposium as a fallback if we fail the possible workshop
... [F2F Meeting Summer 2018]
... Asia?
... China hosted by Huawei?
... look at clendars
... IETF: July 22-27 2018 (SF)
... OCF? oneM2M?
... X months to work
... todos:
... consider visas
... companies from Taiwan?
... check alternatives in Korea and Taiwan

yongjing: oneM2M meeting in Asia 21 May 2018

matthias: moves it to "spring 2018"
... OCF meetings?

mccool: will check

matthias: please check your calendar to see your schedule
... [F2F Meeting October 2018]
... TPAC in Lyon, France
... 22-26 Oct 2018
... look at calendars
... IETF: 4-9 Nov. 2018

mccool: for the Burlingame meeting
... IETF: 11-15 Nov. Singapore
... OCF: 6-10 Nov. Singapore
... no information on 2018

matthias: [WoT TFs]
... www.w3.org/WoT/IG/wiki/Roadmap
... OK to merge the Synch TF to other existing TF?

nimura: will check with Matsukura-san
... he was planning to merge it

matthias: Architecture
... TD
... Scripting API
... (shows the roadmap wiki)
... Synchronization and Management included here (=Scripting API)
... Binding TEmplates
... Security & Privacy

mccool: should go to which group (IG or WG)?
... possibly a separate GitHub repo

matthias: make sense to have a WG deliverable
... but having a TF as an IG TF would be good to get inputs
... informative deliverable as a WG Note or as an IG Note?
... would like to make sure that W3C wouldn't create a new security standard
... Binding Template: get input from OCF and oneM2M
... (visits the roadmap wiki again)
... green part is doen
... editors draft on GitHub
... graphical and RDF model of TD
... Osaka f2f

<inserted> ... pin topics are tbd

matthias: release candidate for WoT Architecture FPWD
... start security review for the WoT Architecture

mccool: would like to start that
... IETF guidelines should be included

matthias: RC is candidate for release
... note that finish security review for WoT Arch with Internet Drafts
... security concepts
... other RCs for FPWD drafts
... further topics to be discussed later

<inserted> scribenick: taki

Yongjing: I would like to contribute OneM2M binding to TD.
... Examples are in JSON formats.

Marketing and Outreach


McCool: More people need to be involved from those organizations.
... What is the key message about our value.
... showing "messages" from 5/17 minutes...
... How can we evaluate good message?
... Who we are targeting... Decision makers. ( business person).
... We are not targeting consumers.
... Trying to connect audio...
... Testing, testing tesing...
... Criteria about message.
... I listed goals. Give meesages to audience.
... They have to agree with us.
... How thimgs are differemt.
... They have to engage with us.
... Messages must be simple.

<naomi> +1 > must be simple

McCool: It is all about simple message, and repeat again.
... no jargon.
... You want to target one level lower.
... avoid confusing words. data model.
... for example.

Sebastian: JSON, XML are also maybe confusing.

McCool: You want to communicate concepts people already know.
... Key message. One key idea. Whats the one thing?
... I looked through. Key ideas.
... I saw Interoperability between multiple standards...

MM is going through the list "key value cadidates" in the slide...

McCool: Expand eco-system....
... Not crisp enough. We still have time. In Github, I can upload.
... I can create pull request.
... It is gonna be public, we have to be careful. can make private.
... As far as further discussion. Web presence.
... reinforces message, is important.
... Web presence and presentation, should be nice clean.
... Communication meeting. I try to get presentation template.
... Simple, practical template is what we need/

Matthias: When do we get good example?
... When do we get it applied?

McCool: This is difficult.
... I have been doing two months.
... We need some more proposals.
... By next meeting, less than a meeting, let's prepare for a proposal.

Matthias: We need to allocate time, or hire marketing people.

McCool: We could try to ask for intel marketing people help.

Matthias: Let's make a good concrete plan.

McCool: This is all on record, let's continue.

WoT Web Pages

Matthias: We use various content management.
... Dashboard in WG page.
... So much text.

<kaz> WoT landing page

Matthias: It has to be concise.

McCool: Content system is one reason.
... We need to make some good proposal.
... Make sure the very first thing in each page points to this page.

Matthias: We can even use static system...
... We need simple landing page.
... People should be able to be focused.
... Kaz, can we change content management system on WG landing page?

<kaz> WoT WG page (managed on GitHub)

Matthias: This is not good for marketing... Three pages has inconsistent information...
... As fast as possible, correct structure.

McCool: Landing page, someone is maintaining upcoming pages...

Matthias: Sometimes not updating.

Kaz: I will talk to W3C comm team.

Matthias: We could open issue in github IG space.

<kaz> ACTION: Kaz to talk with the W3C Comm Team about the landing page [recorded in http://www.w3.org/2017/05/19-wot-minutes.html#action01]

<trackbot> Created ACTION-105 - Talk with the w3c comm team about the landing page [on Kazuyuki Ashimura - due 2017-05-26].

Matthias: Or, do we need steering team?

McCool: every month, we used to have WoT Comm TF calls.

<kaz> WoT WG repo

Matthias: It is now part of main call.

McCool: yingying, naomi should be part of the discussion.
... We can find out where information on page is coming from.
... We can also poll.
... Remove page? Redirect better?
... Change content management, etc.

Matthias: Dave had opinion before. But he already left today...

Daniel: I had similar question several weeks ago. Dave said content is sometimes duplicated with multiple pages. It is difficult to maintain.
... We may want to converge them together.

McCool: Let's separate out what we want.
... Having a single page, clear messaging.
... Let's get a meeting with marketing people.

Matthias: We need something concrete as a result.
... We need to check whether it complies with W3C policy.

McCool: WoT, WoT IG, WoT WG, same look and feel is an objective.

Matthias: What are we telling people.
... and design page accordingly.

McCool: Get organization done.
... Then content.

Matthias: Let's see if there is any objection.
... With regards to policy.

McCool: We wanna say clearly and concisely what's our value.

Matthias: Can Daniel help?

Daniel: Sure.

Matthias: can't hear, naomi

<naomi> sorry to say this but w3c does't accept members directly to modify, write, update w3c pages so I'd like to collect your "raw" voices to reflect to our marketing materials. I don't recall marcomm had a place to hear voices from groups in the past.

Kaz: W3C doesn't allow members directly update these pages.
... Naomi-san says.
... Yingying and Dave are organizing TF. TF and comm team should work together. would like to talk with the W3C Comm Team.

McCool: I want comm team active on this.

Matthias: concise, consistent messages will stay stable.
... can naomi apply radical changes?

<naomi> Matthias, we'll change

<naomi> with hearing your inputs

Matthias: comm team can make private changes.

<naomi> exactly

Matthias: It also works.
... We will contact you guys.

<naomi> thanks Matthias!

Matthias: then please tell us what's allowed and what's not.

<naomi> wot groups++

Kajimoto-san's remark

Kajimoto-san: thank you very much for cobtribution.
... Dusseldorf meeting is coming shortly.
... Let's prepare quickly.
... I hope you guys can go home safely, and enjoyed here.
... If you have a chance, it is good chance to go to Osaka castle.
... Ohsumi-san also suggested to visit Kyoto.

Sebastian: I really enjoyed the week.
... Very organized. Thank you for great food.

Uday: It was so such delicious food.
... Thank you for hosting.

Kajimoto-san: Thank you.

[Osaka f2f meeting ends]

Summary of Action Items

[NEW] ACTION: Kaz to talk with the W3C Comm Team about the landing page [recorded in http://www.w3.org/2017/05/19-wot-minutes.html#action01]

Summary of Resolutions

[End of minutes]