WoT F2F in Bundang
30 Jun 2018-5 Jul 2018

group photo from the WoT F2F meeting in Bundang

Group photo from the WoT F2F Meeting in Bundang on June 30-July 5

(Some more photos are available online.)


Summary of Action Items

Summary of Resolutions

WoT F2F in Bundang - PlugFest Day 1
30 Jun 2018


Kaz_Ashimura(W3C), Michael_McCool(Intel), Sebastian_Kaebisch(Siemens), Matthias_Kovatsch(Siemens), Soumya_Kanti_Datta(Eurecom), Youngmin_Ji(KETI), Takeshi_Sano(Fujitsu), Takuki_Kamiya(Fujitsu), Ryuichi_Matsukura(Fujitsu), Kunihiko_Toumura(Hitachi), Takeshi_Yamada(Panasonic), Kazuo_Kajimoto(Panasonic), Toru_Kawaguchi(Panasonic), Michael_Lagally(Oracle), Michael_Koster(SmartThings;remote), Danh_Le_Phuoc(TU_Berlin), Tomoaki_Mizushima(IRI)
Matthias, McCool, Kajimoto

plugfest day1 plugfest day1 plugfest day1 plugfest day1

Online TD playgraound site: http://plugfest.thingweb.io/playground/?

<mjkoster> I have 2 TDs that I'm trying to register to the directory at http://plugfest.thingweb.io:8081/td

<mjkoster> They pass the playground but get a 500 error at the directory

<mjkoster> I dont see any other TDs registered yet

(There was some trouble with memory handling for the Directory server and we had to reboot the server.)

<mjkoster> <h2>HTTP ERROR: 500</h2> <p>Problem accessing /td-lookup/sem. Reason: <pre> java.lang.OutOfMemoryError: Java heap space</pre></p>

<mjkoster> OK, I can work on the node-wot proxy in the meantime

<mjkoster> I will use MQTT as the tunnel to pass interaction data between the cloud side and LAN side node-wot proxies

<mjkoster> It will a consume-side script and an expose-side script using the scripting API

<mjkoster> I will push a TD template from the consume side to the expose side scripts using a well known MQTT topic

<mjkoster> Also working on getting node-wot to consume a Philips Hue using a protocol binding and re-expose using the default binding

<mjkoster> I have the light and motion devices from the last plugfest exposed and was trying to register them, with new format TDs, when I got the error

WoT PlugFest - Day 2
01 Jul 2018


Michael_Lagally(Oracle), Toru_Kawaguchi(Panasonic), Kazuo_Kajimoto(Panasonic), Takeshi_Yamada(Panasonic), Kunihiko_Toumura(Hitachi), Ryuichi_Matsukura(Fujitsu), Kazuaki_Nimura(Fujitsu), Takeshi_Sano(Fujitsu), Tomoaki_Mizushima(IRI), Soumya_kanti_Datta(Eurecom), Dave_Raggett(W3C), Michael_McCool(Intel), Matthias_Kovatsch(Siemens), Sebastian_Kaebisch(Siemens), Takuki_Kamiya(Fujitsu), Kaz_Ashimura(W3C), Michael_Koster(SmartThings;remote), Youngmin_Ji(KETI), Danh_Le_Phuoc(TU_Berlin), Yasuhisa_Tamura(Sophia_Univ)
Matthias, McCool, Kajimoto

plugfest day2 plugfest day2 plugfest day2 plugfest day2 plugfest day2 plugfest day2 plugfest day2 plugfest day2 plugfest day2

Review of registered TDs

* Siemens

Matthias: (shows Siemens TD)


discussion on security settings

Matthias: set security configuration at the top level

McCool: can override it as well

Matthias: specify the basic security at the top level
... and can override it at the form levels

McCool: maybe we need some additional tag for that purpose
... who is implementing security?

[Matthias, Lagally and Soumya raise their hands]

Taki: we also have barerer token

Matthias: in the config file we specify what kind of key is used

McCool: barerer token is easier but OAuth is standard

Matthias: we should check the spec and see what to do
... barerer key for out of bound case, etc.
... (continues the review)
... @context
... normal context file
... prefix for iotschema.org
... feature of interest setting: festPA
... @type
... Thing
... iot:Pump specifies capabillity
... based on iotschema.org

Danh: different components here

Matthias: a Thing can have multiple interfaces
... e.g., pub function, valve function, ...

Danh: if you have a car including multiple sensors
... different type of things

Matthias: several components could work individually

Dave: issue with binding
... e.g., car with 4 wheels
... how to identify those parts?
... mapping between the actual parts and semantics

Matthias: standard vocabulary here
... name: FestoLive
... id: urn:dev:wot:siemens:festolive

Dave: developers might want to have freedom
... coupling between the object and interfaces

Koster: relations are very structural only
... not constraining anything

McCool: we should move the discussion to the f2f tech discussion
... loosely binding things

Kaz: we already identified the issue of "how to handle a group of features/capabilities" last week
... so we should discuss the issue in detail during the tech days
... and we can quickly review all the generated TDs and identify additional issues based on those TDs

Danh: (missed the question)

Matthias: specifying overall capabilities here under @type
... e.g., color capability, brightness capability
... (here, pump, valve, floatswitch, ultrasonicsensing, proximitysensing)
... 2 aspects here
... property for specific actions
... realize some capability as property
... or the other guy may identify it as action
... what Darko told me was that this notation was for discovery
... this property here is part of pump capability

Koster: we just can label the capabilities
... as Matthias said
... some may use property and some may use action

Taki: it's called aggregation model?
... people often do this
... specialization for convenience for aggregation

Danh: we can go into the detail later

Matthias: we need more concrete proposals
... and need to identify all the issues
... containment might be better
... may be different capabilities within a container
... e.g., switch, color, ...
... master thing for sub things
... maybe need some guideline for that containment

Koster: also agree
... it's a matter of best practices

Danh: seems to me you're trying to compact things for discovery
... maybe will bring chaos...

Matthias: (continues the review)
... iot:isAssociatedWith
... properties
... pipe model
... similar instance here
... Tank102LevelValue
... iot:CurrentLevel
... maybe good starting point for Feature of Interest
... let's not go into the details at the moment
... (goes through another TD)


Matthias: for the rabbit there
... protocol binding vocabulary
... GET for this URI

McCool: method or methodName?

Matthias: will check it

Koster: it's methodName

Matthias: ok
... will fix it
... control for ears
... split up into various actions

<mjkoster> 3.3.1 HTTP form vocabulary http:methodName [ "GET", "PUT", "POST", "DELETE"] http:headers example: [ {"http:fieldName": "accept", "http:fieldValue": "text/plain"} ] http:fieldName [ accept, content-type, transfer-encoding ] http:fieldValue

Matthias: strawman proposal about URI Schema
... maybe URI template would be better term
... and semantic information here by @type
... example:SomeKindOfAngle

McCool: security portion, e.g., for IP camera

Matthias: wouldn't specify security here
... we already have basic security setting at the top

McCool: security-ready one vs non-security one

Matthias: RightEar
... set property
... matching scripts
... might want to look at higher API for the next Charter period
... some kind of query parameter

Sebastian: URI schema to be moved?

Matthias: post in the payload would be cleaner
... but issue with serialization
... alternative way for applications

McCool: query parameter and data in the body
... have to deal with in multiple places
... could be binary data

Matthias: detailed discussion during the tech days
... good to learn if TD is enough
... (goes to another TD)


Matthias: for the raspberry pi


Matthias: and small sensors
... brightness, color, etc.
... another one


Sebastian: MQTT-based parking lot sensor
... how to address sensor
... local prover
... some addition for MQTT
... quality of service
... provided by TD
... quite simple but works well
... node-wot implementation with bindings
... submitted on my branch

Matthias: goes to node-wot site
... pointing to the broker which publishes data
... mqtt://

Koster: this is the way I handle a motion sensor as well
... MQTT for observing events

Matthias: need to fix int as integer
... who wants to do next?

McCool: will

* Intel TD



McCool: will go into each TD


McCool: iotschema.org

Matthias: this context https://w3c.github.io/wot/w3c-wot-td-context.jsonld is common setting

McCool: going down
... doing rgbValue
... one type for all elements
... or indicate it individually
... choose what color to be controlled
... iot:RcolourData, iot:GcolourData, iot:BcolourData

Matthias: closure of objects

McCool: interesting question about the nesting :)
... array with several entry points
... non-secure version here
... and the other 2 with proxying
... basic vs digest
... and https://portal.mmccool.net:9023/api...
... no security, basic, basic, digest and digest

Matthias: multiple different entry points here

McCool: multiple ways for a device
... HTTPS doesn't work well with local link
... might be different strategy for local vs remote

Danh: up to the client to discover

McCool: no information about network latency here
... need to try out

Matthias: which language to be used to show the possible settings?

McCool: 4 different directories
... going down
... "Turn on" action
... only input data and output data
... id is empty and optional
... supposed to work
... the rest is easier to understand

Matthias: interesting questions here
... how to use the interface

Danh: if you have a big TD file like this, any problem with interaction?
... you have to download the whole TD file. right?
... 1 form with 5 links, etc.

McCool: this is TD of a local device
... may want to customize based on the need

* Oracle

Lagally: 4 TD files

Oracle TDs

Connnected car (Audi)

Lagally: connected car
... can easily access them
... ASCD, ActiveParkAssist, AdaptiveCruiseControl, AutomaticBrakeActuator, ...

Sebastian: what kind of string is expected?

Lagally: no constraints so far

Kaz: theoretically, we can reuse GENIVI's VSS for the vocabulary

Matthias: converted from the device model automatically
... maybe better to provide base on enum
... for semantic annotation

Lagally: would be nice
... the point here is it can be created easily

Matthias: expectation we can put anything

Kaz: btw, you generated this using your md2td tool?

Lagally: yes
... goes to another td


Lagally: you can generate another TD easily
... another device simulator


Lagally: easily extensible
... currently working on importing TDs generated by others

Taki: security setting?

Lagally: just using basic auth at the moment

Matthias: should have security at the top level with basic

Sebastian: additional setting here?

"createdAsString": "2018-06-27T13:06:18.617Z",
"created": 1530104778617,
"lastModifiedAsString": "2018-06-27T13:06:18.617Z",
"lastModified": 1530104778617,
"userLastModified": "auto-generated by dm2td converter",
"support": "https://servient.example.com/contact",

* Panasonic

Panasonic TDs

Yamada: generated TDs here
... we set up online WoT service provider

Panasonic WoT Server Simulator

Matthias: is this the actual UI when we see?

Taki: the UI is copied here

Yamada: last point
... simple websocket endpoint
... PanasonicAirConditionerP1, etc.


Matthias: authorizationUrl: https://plugfest.thingweb.io:8443

Taki: this TD is kind of dummy and the actual URI is hidden

Yamada: this part is for the simple websocket connection

  "href": "https://yyyyyyyy/poll/airconditioner/1/operationStatus",
  "mediaType": "application/json",
  "subProtocol": "LongPoll",
  "rel": "observeProperty",
  "security": []

Matthias: security empty?

Yamada: no security for this

Matthias: enum here

"enum": ["Auto", "Cooling", "Heating", "Dehumidifying", "Blast"],

* Fujitsu

Sano: not specifically changed from Prague

Fujitsu TDs

Sano: updated the TD


Sano: the status is on or off

Matthias: could you provide concrete values by enum?

Sano: will do


Sano: sensor connected via wifi
... sometimes get the value but sometimes not
... so please try several times

Kaz: this is the small sensor board you brought from Japan?

Matsukura: shows Fujitsu's sensor board
... sensor module which includes WoT capability and Wifi connection
... based on Echonet
... you can get the status of the device
... change the property to control the device
... that is Echonet's system mechanism
... we use properties for this

Matthias: similar to OCF
... property-based approach

Sano: other devices
... like air conditioner are the same


Matthias: no security?

Sano: no security yet

Matthias: TDs for close and open?



Matthias: kind of confusing

Matsukura: because it has 2 separate motors :)

Yamada: requires barerer token?

Sano: this time no security setting

Matthias: please check if the URIs are correct
... also please add enum values

Sano: will do



Youngmin: 7 sensors there
... can get events using these TDs


Youngmin: sound, humidity, etc., can be detected
... based on wifi mesh network

Matthias: custom entry here
... to be included in @context
... issue on counter examples

* Eurecom

Eurecom TD


Soumya: 5 sensors/actuators
... how to identify them?
... didn't write headlights
... for windows, want to have multiple levels
... what I did here is gear position, status of 4 windows
... using properties
... windows as actions
... deleted the capability
... so far all the TDs on the BMW cloud
... values should be provided using enum

"type": "object"
"properties": {"value": {
  "type": "string",

Soumya: @type: iot:TurnOn
... another possibility of doing that in 3 steps

Matthias: you design it first and iotschema should fit it

Soumya: will update it with 3 steps

Matthias: window takes some time to move
... so maybe you need 2 actions?
... maybe just integer value for 0-100?

Soumya: sometimes the position/speed depends on how to push the button

Sebastian: also tested the TD and apparently many bugs

Soumya: will fix them

Matthias: might want to think about caching/prefetching
... you can check the TD using TD playground

* SmartThings

HUE light

"base": "",

Koster: apikey as part of the URI
... any questions?

Matthias: a bit shocking to see this :)

Koster: api prefix

Matthias: the protocol is HTTP
... maybe to be secured?

Koster: yeah
... the API key is generated dynamically

McCool: how to handle secret keys

Matthias: it's not secret within TD
... some implication you shouldn't share this with everyone
... need to identify who to share

McCool: you don't need security declaration here
... doesn't add any information here

Koster: yeah, kind of felt strange
... let's just go through this
... on property, saturation, ...
... controlling the light by changing the properties
... binding directory to HUE
... to control HUE bridge
... split into separate properties

Matthias: specific bug on lights/24/state and lights/12/state

McCool: have a template for OCF

Matthias: TD for individual lamp

Koster: setting UnitScaleFactor
... 0.1 second
... ScaleUnits is another one
... specifying the color based on the color wheel
... another one on ct
... iot:DegreesKelvin
... interesting features

Dave: ScaleMaximum is larger than ScaleMinimum?

Koster: that's intentionally
... might want to have better way which fits ordinary feeling

Matthias: which color model to be used?
... regarding ct, maybe we can simply use Mired

Koster: there are many different color scales

Matthias: how much information for the conversion?
... where to start with?

Koster: yeah


Matthias: this part (@context) is fine
... but do we really need http: http://www.w3.org/2011/http# ?

Koster: good point

Matthias: need some core vocabulary

Koster: for security, put something here

"security": [
    "scheme": "coap+dtls",
    "id": "DSAzac0V7VzQc",
    "psk": "F0YpBnSCL9rXowZ8"

Koster: PSK-based one

Matthias: question issue on node-wot repo
... PSK is currently missing

McCool: issue with GitHub now
... will look at the issue
... local HTTPS using self-signed maybe?

Koster: property part
... simple ones
... on/off property, brightness property, and a couple of others
... iot:LevelData
... flexible about this?
... it's array here
... kind of like this way
... processed with TD playground fine

Matthias: talking about the brackets
... array first?

Koster: we do need this
... expected to see one item

Matthias: defining 2 different types
... you can't have array for 2 instances

Koster: right
... this was not correct
... will fix that

Matthias: any reason about 254 as maximum?

Koster: due to Zigbee

TD light

Koster: using "id": "urn:uuid:2d5e84f6-85c9-4436-b53f-c0669dfd1603",

mj: ok

Sebastian: remotely accessible?

Koster: light TD is remotely accessible

TD motion

Koster: "href": "mqtt://0m2m.net:1883/plugfest/subscriptions/Motion",
... different security binding for remote connection

McCool: we need a scheme

Matthias: possible hacking of MQTT and find the credential

McCool: any scheme for MQTT to add?

Matthias: should see AWS, etc.
... for HTTP, we have knowledge

McCool: basic vs encoded

Matthias: good to have MQTT binding for node-wot

Sebastian: what does commandCode mean?

Koster: mapped to 2 parts

Matthias: method name GET and POST for HTTP
... for MQTT get commandCode as 8

Sebastian: we'll have a breakout session about MQTT
... commandCode is new to me

Matthias: need method for HTTP as well
... one which going out and another coming back

Sebastian: if you want to describe Things, need to consider if it publish and/or subscribe

Matthias: would omit "connect" here
... already know we have to connect with the broker

McCool: redundancy with MQTT protocol

Matthias: would wrap up the session

Koster: no change with motion sensor

Matthias: after the lunch, will test Sebastian's TDs

Koster: would test node-wot binding

McCool: would test video camera
... have not done this through the TD playground yet

[lunch till 3pm]

WoT f2f - Open Day
02 Jul 2018


Barry_Leiba(Huawei), DanhLePhuoc(TU_Berlin), Kaz_Ashimura(W3C), Matthias_Kovatsch(Siemens), Jiye_Park(Univ_of_Duisburg-Essen), Sebastian_Kaebisch(Siemens), Michael_McCool(Intel), Dave_Raggett(W3C), Barry_Leiba(Huawei), Takeshi_Horiuchi(RICOH), Takeshi_Sano(Fujitsu), Kunihiko_Toumura(Hitachi), Takuki_Kamiya(Fujitsu), Takeshi_Yamada(Panasonic), Toru_Kawaguchi(Panasonic), Kazuo_Kajimoto(Panasonic), Michael_Lagally(Oracle), Dangyong_Gil(Oracle), Tomoaki_Mizushima(IRI), Youngmin_Ji(KETI), Ki-Eun_Shin(LINE), Naohisa_Ichihara(LINE), Joo-Chul_Lee(ETRI), Soumya_Kanti_Datta(Eurecom), Michael_McCool, JaSeung_Song(Sejong_Univ), Yasuhisa_Tamura(Sophia_Univ)
Michael_Koster(SmartThings;_Invited_Expert), Tetsushi_Matsuda(Mitsubishi_Electric)

Matthias, McCool, Kajimoto
kaz, dsr, McCool

scribenick: kaz

W3C Patent Policy for invited guests

<kaz> W3C Patent Policy

<kaz> Patent Policy FAQ

<kajimoto> Kaz: W3C Patent Policy explanation session

W3C Web of Things - Matthias


Matthias: greetings and basic introduction about WoT
... [W3C Web of Things - Summary]
... not building a new silo
... but creating building blocks for interconnection
... counter fragmentation in the IoT
... make the Web scalable and interoperable
... WoT vs IoT similar to Web and Internet
... take patterns from the Web and adapt/apply them to IoT
... JSON, Schema, Linked Data
... URIs and Media Types
... JS runtime
... TD, Binding Templates and Scripting API
... [W3C Web of Things - Activity]
... workshop in 2014
... identified stakeholders
... WoT IG started in 2015
... still continues to work
... exploration and liaisons
... generated the Charter for the WG
... WoT WG started at the end of 2016
... normative spec work
... [W3C WoT Approach - Building Blocks
... SDK, information model and protocol
... central one is WoT Thing Description
... Thing's capability described using JSON-LD format
... machine readable/processable
... extensions for industry domains
... 3 concepts: properties, actions and events
... TD is "index.html" for Things
... next
... WoT Binding Templates
... mapping to the other standards
... last part WoT Scripting API
... like JavaScript for the Web
... standardized JS object API for an IoT tuntime
... and
... WoT Security and Privacy
... metadata and guidelines for existing security
... [Deployment Scenarios - Full-stack Devices]
... how it works
... WoT client on the left side
... Servient Hosting Scripted Things on the right side
... behavior of the Thing is deployed
... and alternative example
... constrained Device as Thing on the right side
... can be consumed using the same way based on the WoT technology
... [Deployment Scenarios - Retrofitting Devices]
... Existing sensor Device on the right side
... [Deployment Scenarios - Web Integration]
... Servient in Browser - Servient on Cloud - Servient on Gateway
... connected with (1) TD-based Servient Cleaner, (2) TD-based LED lamp Thing and (3) Legacy Device
... [W3C WoT Integration Patterns - Things AND Cloud
... thing to thing interoperability
... things and cloud here
... things become interoperable with each other
... [Photo from the W3C AC Meeting in Berlin in May, 2018]
... Oracle cloud, bunny robot, BACnet controller, smart appliances, etc.
... this demo can be set quickly
... [WoT Thing Description]
... the core part
... [WoT WG Changes to "Simplified TD" in March 2018]
... changed to JSON-LD 1.1
... W3C CG work moving into a WG, JSON-LD WG
... changes
... objects instead of arrays
... allows default values, e.g., writable: false
... and framing mechanism to serialize and preprocess
... also
... semantic annotations optional
... TDs can be treated as simple JSON format
... no JSON-LD keywords or processing required
... properties, actions, events on the top level
... no LD convention of terms being singular
... new media type "application/td+json"
... context and terms know implicitly
... then
... JSON Schema fully compatible
... data schema syntax now also identical
... payloads can be validated directly with JSON Schema implementations
... and the last thing
... new terms for generic metadata, e.g.: id, label, description, support, ...
... human readable as well
... [Diff for ...]
... [WoT WG Changed to "Simplified TD"]
... example diff between the prev version and the current version
... old version left side and new version on the right side
... (goes through the changes)
... description added
... array to object
... property is now data point
... allow recursive definition
... you can use JSON Schema validator
... (continues the comparison about actions)
... we can reuse datapoints here
... (and then events)
... HTTP doesn't have push capability itself
... also works with websocket
... various possible sub protocols
... [WoT Thing Description (TD) - Minimal Form]
... semantic markups
... and way more annotations
... [WoT Thing Description (TD) - Annotated Form]
... explicit context
... W3C WoT TD vocabulary
... domain-specific vocabulary
... security metadata
... "forms" for protocol bindings
... JSON Schema to specify semantic meanings
... [WoT Binding Templates - Instantiated in TDs]
... basics to build the request first
... targets like BACnet and OCF
... default assumption as deviation from defaults
... this example is about OCF device using CoAP
... using "coap:methodCode"
... [WoT Thing Description (TD) - Model]
... good illustration of what we have
... (shows the diagram of the data model)
... still have interactionPattern class
... we can extend the interaction pattern
... capability of "X" attached with generic way
... DataValue and DataSpecification
... once some action is invoked we get an instance
... on the other hand, property is a data point itself
... at the moment, event is similar to property
... but event is not an instance
... we need another data specification for events like properties
... event should be more inline with actions

Dave: wondering about how to handle data streams

Matthias: the means are already there
... to handle time series

Kaz: streaming issue is already registered with GitHub
... so we can continue the discussion later
... maybe during the rechartering session?
... also we can talk with the Media&Entertainment IG guys with possible use cases during TPAC in Lyon in October

Taki: maybe we should talk about this during another session later?

Matthias: some more slides
... [WoT Things Description - Terms]
... now JSON-LD @context is optional
... @type capability

McCool: question about common context?

Matthias: adds some explanation
... we moved to iotschema
... (continues the description about other changes)
... "id" as the identifier
... discussion with ETSI ISG CIM

McCool: note on privacy
... who accesses what
... there are 2 issues
... "name"
... "description"
... optional human-readable description
... Q: how to deal with languages?
... the model must be able to hold multiple languages to serialize language-specific TDs

Kaz: maybe we can have a joint session with the I18N WG during TPAC

Matthias: sounds good
... "support"
... should be mandatory or ok with optional
... should force authors of TDs to fill out to make TDs better?
... "base"
... base URI for optimization to enable short relative URIs in forms
... "security"
... we have security field now
... mandatory or not?
... no-security must be an explicit choice and security should be used by default
... also
... what about the vocabulary?
... need more feedback

McCool: would like to see feedback

Matthias: TD includes core vocabulary, data model vocabulary and security vocabulary
... "properties", "actions" and "events"
... now data point
... Q: should use term "name"?
... maps to "rdfs:label"
... web linking has term of "title"
... now the situation is complicated
... should have input and output for events?
... "links"
... linkes are meant to correspond to web resources which are fetchable

Dave: there may be some opinions
... [WoT WG Changed to "Simplified TD"
... (other examples)
... old version on the left and new version on the right

Introduction of ECHONET Lite Web API - Tetsushi Matsuda


Kaz: please send you slides to the group later

Matsuda: slides prepared by Mr. Teramoto from Echonet but he is not available today
... so I'll explain it for him
... [IS Documents on ECHONET Lite]
... what Echonet Lite is
... detailed controlling commands on over a hundred devices
... [Outline of ECHONET Lite (Protocol)]
... any transport protocols are applicable
... [Outline of Control Commands]
... ECHONET Objects has classes, devices/appliances
... e.g., air conditioner, fire sensor
... you can access the properties using the ECHONET APIs
... [Background and Objectives]
... guideline for Web APIs
... in accordance with recent advances in IoT technologies, it's expected that service offering through server
... generating guidelines
... [ECHONET Lite Web API - Timeline]
... expected timeline
... release 1 guideline by Aug, 2018
... [ECHONET Lite WEb APIs: Scope]
... Web APIs expose ECHONET Lite devices to clients
... should be able to deal with multiple controllers in one home and multiple homes
... should be able to deal with non-ECHONET Lite devices as well
... [Use Case: Getting Status/Controlling/Notification]
... get status of a target device
... [Use Case: Getting a List of Devices/Getting Management Information]
... [Use Case in the 1st Guideline]
... 1st guideline in Aug, 2018
... 2nd guideline in Mar, 2019
... use case and 1st guideline policy
... [Guiding Principle for the Web API]
... use JSON (RFC8259) as the primary format
... follow consistent RESTful style/syntax
... handle CRUD actions using HTTP methods
... other basic policies
... all API access over HTTPS
... HTTP 1.1
... [Resource Specification Pattern]
... speciry versions, resources and devices
... resource specification example and description
... Resource Concept]
... may support multiple types of resources
... one or mre resources such as devices, controllers, sites, users, groups, etc.
... [Device List]
... how to get resources of devices from the server
... an array composed of id, type, protocol and manufacturer
... can use Japanese and English
... [Resource Specification Pattern]
... device list, device description, properties, actios, events, etc.
... would like to know the details of actions and events from WoT
... so far, we only use properties
... also would like to clarify the difference between observable properties and events
... [Device Description]
... would skip this for today
... [Device Description - Example]
... example of general lighting
... brightness, etc.
... [Appendix: Data Types]
... details of the data types for handling various objects and properties
... we can share the presentation material later

Matthias: the question on actions and events
... how to proceed?
... can have discussion now or another dedicated call?

Matsuda: or email discussion?

Kajimoto: after some more email exchanges, we can have a call

McCool: OCF also have that issue
... have a question
... have you looked at the updated new TD spec draft?

Matsuda: no, not yet

McCool: any feeling about the feasibility, etc.?

Matsuda: don't have any opinion yet
... (shows [Device Description - Example])
... description using Japanese language

McCool: language tag of "ja"

Kaz: related to our issue on I18N

Matthias: JSON-LD framing has capability to specify languages
... we had a joint call with the JSON-LD WG Chairs
... possible meeting at TPAC

Sebastian: validation challenge as well

Matthias: related work at IETF
... title and "*"

Dave: any interest from Echonet in iotschema.org?

Matsuda: need to talk with the Echonet guys

McCool: question about the data model

Matsuda: not machine-readable

Matthias: you don't have data schema?
... any data model behind that?

Matsuda: you can get device description by accessing the server

Matthias: some language annotation, so thought possibly inline with TD

Matsuda: (shows the slide of "Device Description - Example" again)
... brightness has description

Matthias: maybe we can have detailed discussion later?
... some latest change here

Kajimoto: yeah
... there was some recent change which causes confusion
... (explains the example)
... within "enum"
... value: night, ja: 常夜灯, en: Night Lighint, edt: 0x43

Matthias: changes on not using schema
... enum defines possible values
... probably need longer discussion and would postpone

[break till 11:30]

Kaz: scribes for the rest of today? - Dave and McCool volunteers

Industrial IoT Use Cases

<dsr> scribenick: dsr

presented by Michael Lagally (Oracle)


Some things are hard to predict - you can only observe and see them fail, IoT isn’t a silver bullet!

A list of industries starting with manufacturing and ending with safety

For manufacturing, predictive maintenance and maintance automation

Predictive maintance allows you to fix equipment before it fails so saving lots of time and money

By continuously monitoring machinery you can improve quality and further more reduce the likelihood of industrial accidents

Opportunities for environmental monitoring, real-time monitoring etc.

For transportation & logistics, you can track shipments en-route condition, quality, temoerature, humidity etc,

Similarly for fleet tracking, e.g. to monitor fuel costs for trucks and improve maintenance and work assignments.

Cold chain monitoring is related to food safety regulatory requirements for shipping refrigerated food.

Michael McCool adds the opportunities for detecting when packages have been tampered with

Environmental monitoring of bridges, dams, levees, canals etc, for structural integrity water levels etc.

Smart parking - tracking usage, matching people to spaces, billing and so forth.

Further examples for smart lighting in cities and buildings, waste management and monitoring of garbage bins

Michael McCool notes that in Japan, security concerns would make chemical sensors interesting for garbage bins in the wake of Sarin attacks etc,

Monitoring of highways (how busy they are, potholes, break downs), Environmental monitoring of air and water pollution

Smart metering e.g. residential meters for gas, water and electricity. Distributed energy suppliers and consumers, e.g. solar panels at homes, wind generators.

Michael McCool notes that energy management may apply within buildings (nano grids)

Offshore platform monitoring, likewise for pipelines, tools for predicting leakage

Monitoring levels in tanks and reservoirs. Automatic stock taking for distributed stocks, e.g. across various storage tanks and delivery trucks

Opportunites for insurance industry: monitoring, usage based insurance premiums, safety monitoring

Garaging fleets of vehicles in bad weather, e.g. to reduce damage from hail

Monitoring assets at construction sites.

Healthcare: data collection for clinical trials, medicines throughout the supply chain, patients after they are discharged from hospital

Smart farming: irrigation, fertilizer, pesticides, etc. can be optimised through monitoring

Smart buildings: energy usage for lighting, and air conditioning based upon monitoring patterns of occupation

Remote monitoring and diagnosis of automobiles

video and motion sensors for safety and security

In general the industrial use cases involve asset monitoring.

Management of assets, detection of alerts and anomalies, predictions of failures.

Work by Oracle of mapping W3C thing descriptions to Oracle device models

Simulate devices that continuously transmit data

Michael Lagally shows us a demo for monitoring simulated devices

e.g. HVAC for a building

This uses the Oracle digital twin simulator

A map user interface to IoT asset monitoring cloud service

Michael summarises the opportunities and relationship to big data.

Horiuchi: how does the WoT WG prioritise these use cases?

<kaz> Kaz: we should update our use cases document with this kind of industry use cases

McCool: interest in a uniform interface for monitoring assets from many different companies.

DaveRaggett notes connection to enterprise data governanance and management - enterprise knowledge graph that includes the things and their digital object memories. Need to identify which use cases have interesting requirements, e.g. for telemetry streams and handling for big data

<kaz> Matthias: use cases depends on each company's industry/business, so we would like to get more use cases from more participants

<kaz> ... priority depends on the participants

Michael: W3C needs to ensure that horizontal standard fulfills a broad range of requirements across many domains

<kaz> Kaz: so RICOH also can join the WoT IG/WG and provide some concrete use cases :)

Matthias: we need to work on prioritising use cases to drive our future work

iot.schema.org Brief Update

Presented by Michael Koster


The semantic vocabulary sits just above thing descriptions in the layer cake of abstractions

iot.schema.org is an extension to schema.org and a meta model for the semantics of interactiing with connected things

It addresses the challenge of creating and using formal semantic descriptions without requiring in depth expertise on knowledge engineering

dealing with the lack of common semantic vocabularies and conceptual models which can be used across multiple domains

Capabilities, interactions and data schemas as building blocks

Features of interest for describing relationship to the physical world

Multiple domain specific vocabularies

A capability is associated with a set of properties, actions and events along with associated data schema

Michael shows us some example definitions

We are interested in using RDF shapes for semantic constraints

Features of interest include location

scribe: and the equipment being sensed

Further examples - liquid mixing system and pipe containing a liquid

Working on a roadmap for convergence/merging with schema.org

Prototype website: iot.schema.org with 20 or 30 definitions for people to look at

We’re looking at using the W3C Web of Things Community Group plus further CGs for specific domains

Useof the Creative Commons CC-BY license

We’re participating in the W3C plugfests and the WISHI workshop at the IETF 102nd hackathon on 14-15 July.

<kaz> Dave: background about the concept model?

<kaz> ... would be helpful

<kaz> Koster: good point

<kaz> ... information model from GENIVI, etc.

<kaz> ... we don't really have conceptual model

<kaz> ... actions, properties and events may be useful for people to understand

<kaz> Dave: ok

<kaz> ... would like some clue for external people to understand

scribe: on 14-15 July

Some Q & A

Dave: it would be helpful to have some introductory materials that explain the assumptions in the context of some use cases - what this is good for and where you’re looking for help.

This could cover such ideas as class-subclass, part-whole relationships and units of measure

McCool: interested in validation when using an external vocabulary, is there a solution for that?

Koster: not really

McCool: ideally something that can handle linked sub-schemas

Matthias asks about the expected timeline for work

Koster: we’re volunteer based and don’t have funds for people to work on this

We’ve been working on this for about 18 months. It will probably take another 12 or 18 months for things to settle down to a broadly usable point

The momentum is really good with about 40 participating organisations

Matthias: during the plugfest some people were asking how they can add terms to iot.schema.org

we need a well defined process for submitting ideas and reviewing them

<kaz> [lunch till 2pm]

scribe: we break for lunch and will resume in just over one hour …

oneM2M and testing activities, by JaeSeung Song of Sejong University

<McCool> scribenick: McCool


Song: speaker is also a member of KETI, also oneM2M WG6 chair
... working on test specifications
... various experiences with tools, certification
... understand that we are working on testing too
... want to collaborate, share experiences, work on interop
... have also been working on semantic annotations
... so have similar constraints and goals, tooling issues, etc.
... in short, how to test semantics and semantic interop?
... for semantic interop test, just started 6mos ago
... so still in early phases
... good time to start talking
... four topics; interop & conformance testing
... testing activities
... interop events
... certification program
... also there are several community activities around testing, eg self-testing tools
... subtopic: interoperabilty testing
... three types, interop testing is first
... two entities work with each other
... usually scenario-based testing
... just shows that two specific products interoperate in the specific scenario
... does not show that devices are fully conformant with the relevant standards
... conformance testing
... uses testing device and testing system
... checks for compliance with base specifications
... tests one system in isolation
... and confirms a single device is compliant with the relevant specifications
... also field testing...
... interop testing is appropriate when standard is in devel phase
... conformance for stable specifications and for testing products
... interop testing helps to validate the standard
... conformance is good for product validation
... oneM2M testing specifications
... TS-0015: Testing Framework
... for various network configurations
... eg cloud-gateway-device, phone-device
... require different testing setups
... TS-0013: Interop Testing
... set of several scenarios
... and network configurations
... for each configuration, is set of scenarios: discovery, recovery, etc.
... then have preconditions, triggers, message flows, pass/fail criteria
... conformance testing: TS-0017, TS-0018, TS-0019
... conformance on oneM2M primitives
... conformance is testing compliance
... example, if we want to registration
... look at message flows for this
... have to send message to testing system, which will take appropriate role, eg as server
... will then check parameters, etc.
... specification gives all the details of what needs to be sent and received
... then based on scenarios, have to develop actual test cases
... could hire testing company based on the specification
... or can have a dedicated WG
... oneM2M used the Testing Description Language to develop tests
... which is a standard
... so can be used by testing lab
... developed similar specification for security
... TS-0027, Ts-0028, TS-0029
... some challenges... large specification
... many features
... so takes ages to develop test cases
... want to focus on real implementations
... so pick up real devices
... capture profiles, develop test cases only for profiles
... product profiles are captured in TS-0025
... currently are 9 profiles
... if new devices fit into one of these profiles, can use existing tests
... otherwise, a new profile needs to be defined
... in addition, there are Developer Guides
... help developers build systems that will pass testing
... in addition, developers can run tests themselves, and there are several self-testing and debugging tools

Barry: is the testing aimed at testing error cases?
... is there any testing to see what happens when a device sends bad data?

Song: yes, we do check this
... this is a difference between interop and conformance testing
... interop does include error cases

Lagally: manual or automatic?

Song: for the moment, manual
... but there is a company working on semi-manual
... that can generate test cases from a model

Lagally: and how do you ensure coverage?

Song: different kinds of coverage
... from spec retreive test requirements
... map to single sentence in test requirement
... then mapped to test cases
... then make sure test cases coverage requirements

Lagally: so it depends on the coverage of the initial requirements

Song: right
... as you know there are certain shall, must, etc. statements
... these are the architectural requirements
... need to get mapped into test requirements
... we do need to review test requirements to see if there are any gaps
... during testing we may discover some gaps

Lagally: so there is a feedback loop

Song: yes, and interop test is important to uncover these gas

Kaz: W3C also has test platform for web
... and now we are looking at IoT
... but in WoT we also have the problem of multiple standards
... and are considering the role of simulators

Song: we are looking at building common service functions for IoT
... domain-specific functions are out of scope...
... we test the common functionality, eg. registration
... there are 200-400 features for the server
... but no server implements them all
... so again, we look only at profiles
... and then only have to look at features in a specific profile
... so manufacturer declares they support a certain subset of features and a particular profile
... then we test the device against that

Matthias: do you also have tests that are product independent?
... we want to look at the "in general" case

Song: yes, there are also general cases
... there are however also issues with regulation
... for example, around privacy
... might be additional test cases for specific markets

McCool: WoT is about interop between standards
... how do we do this?

Song: oneM2M deals with this too
... but right now our approaches are a little weak
... and we would like to do better and help developers work with this case
... so we do have work on "hybrid systems"
... so in testing scenarios
... add important parameters that need to be followed by manufacturers
... for interop testing, already finished phase one
... of TS-0013 R1; stable and used in interop events
... note that we are always one release behind
... because we have to wait for spec to be stable before can release spec
... first release is the hardest
... took use 3yrs to create initial release
... but R2 and R3 will be faster
... now looking at semantic testing, security testing, interworking testing (eg with Zigbee bridges), etc.
... other relevant oneM2M standards
... TS-0001, functional architecture
... and feature catalogues, TS-0031
... and product profiles, TS-0025
... then generate abstract test suites, etc.
... for now, R1 defines 7 profiles
... use formal notation for tests
... use TTCN-3: Testing and Test Control Notation Version 3
... internationally standardized language
... ETSI MTS technical committee
... see portal.etsi.org
... want to avoid have specific company developing test cases; had consensus that wanted to use standard
... good tools support

McCool: are there OSS implementations?

Song: yes, several
... both compilers and frameworks to run them
... Ericsson provides a suite that is OSS on Eclipse

<dsr> http://www.ttcn-3.org/index.php/downloads/standards for TTCN-3 standards

Song: also we have an internal process to validate the test cases
... and the tools
... collect two testing systems, and cross-check on multiple tools
... if show same result, pick up devices/tools/cases as "validated"
... then can use for certification
... subtopic: events
... twice a year, have event, open to all companies
... testing done under NDA, no company results published
... generate issues, if due to ambiguity in spec can feed back to oneM2M
... important technical feedback to oneM2M technical committee
... also, last year Dec 2017 for the first time did semantic interop testing
... did work in Pangyo, Korea
... Global IoT Certification Centere
... for semantic testing
... looked at basic scenarios
... for example, discovering four lamps by semantic query
... also semantic access control policy (ACP): do applications have the right to run semantic queries?
... issues: are semantics properly annotated; can query find information as expected?
... but there are still a lot of open issues
... if semantic information is available in a WoT description, would like to be able to use...
... subtopic: certification
... very political, very hard
... needed to set up a new legal entities
... but not all SDOs want to do certification
... TTA volunteered to run certification program
... as they were a legal body that can do this
... modelled after existing programs like Bluetooth
... agreed in Sept 2016, officially launched in Feb 2017
... oneM2M is actually not involved directly in certification
... provides help and support
... TTA develops certification plan to be used by authorized testing labs
... oneM2M only provides and validates test cases
... certification is done by oneM2M CB, not oneM2M directly
... also, now migrating to GCF
... Global Certification Forum will take over program from 1Q 2019
... the problem is TTA is local to Korea
... by giving up CB role, TTA can adopt ATL role
... one body can't do both; conflict of interest
... some tools...
... IoT packet analyser; looks at packet flow, "learns" a test
... also oneM2MTester
... by KETI; Titan as core engine
... is a web-based tool
... code is available in github
... also TTworkbench, tools from IBM, etc.
... there is also an ontology validator
... developed by EGM
... supports popular reference ontologies
... based on RDF technology
... also F-Interop H2020
... tests CoAP, oneM2M, 6TiSCH

McCool: services as well as devices?

Song: actually, just test software
... don't actually test real devices...
... so services do fit into this framework

Matthias: interop similar to ETSI plugtests?

Song: yes, similar

Matthias: it was interesting that you started with interop, and only then did conformance

Song: the issue is that conformance requires a lot of effort
... and may not find gaps in the standard
... but interop testing validates the standard and make sure it works in practice

Matthias: it's also interesting that you focused on only a subset of the standard

Song: yes, many "optional" features
... actually impossible for an implementation to use them all

Matthias: how are devices connected?

Song: everything... multiple network configurations
... and then scenarios on top of that

Lagally: what happens in Korea?
... three operators have deployed services using oneM2M
... also, mandate for all Smart Cities to use oneM2M
... three Smart Cities
... tried a project before without standards...
... used proprietary solutions
... after three years, useless
... so gov't specified use of a global standard
... any adoption somewhere else?

Song: some projects in EU

Taki: R3, mentioned looking at interop tests
... how do you pick standards to test against?

Song: DDS is a requirement for industrial internet
... so this was added for R3
... many "interworking" goals nows
... also ontology-based interworking
... we are now investigating what is the best approach
... for interworking testing

Raggett: W3C ERCIM host recently joined F-Interop project
... would like to align our approaches
... initially though for WoT is to do the testing at the scripting API levels
... blurred a little with conformance testing
... have to have some minimal level of conformance testing

McCool: basic conformance, then interop, then more conformance testing...

Song: ha ha

Raggett: to go to CR do need to have a testing plan, and demonstrate the spec can be implemented in an interoperable way

Song: went through a certain process, including sitting down with manufacturers and testing experts
... a long iterative process

<Zakim> kaz, you wanted to ask about the slides

Kaz: can you provide slides?

Song: sure

Kajimoto: do you have any technology to measure coverage?

Song: it really depends on languages used in your implementation
... each language has their own tools to check
... not really a silver bullet
... in PhD thesis, tried to automatically generate tests to follow paths in code
... but also had several contraints
... only Java or C
... source code needed to be available
... you needed to be an expert on the protocol

Kajimoto: what about performance testing?

Song: since we are not testing devices, do not have those requirements
... but in R4 will be looking at industrial internet, may have some real-time requirements, eg for DDS

Semantic Interop Testing in F-Interop

speaker: Soumya Kanti Datta

Slides and demo videos

Soumya: following up from last presentation in Prague
... since then have implemented a tool
... this time will talk about that
... interoperability is the key to acheive the full potential of the IoT market
... lots of issues right now affecting usability
... as an engineer I can get things to work, but...
... semantic interoperability is a way to solve this problem
... but it needs to be tested to validate compliance
... created a tool to test semantic interop
... part of this project I did a study of the current status
... concept exists in four areas
... architecture, ontologies, application, iot platform
... but very few tools
... existing tools may only look at one of these layers
... new tool: SemTest
... conformance first, then interop
... will talk first about F-interop platform
... four main components
... web interface
... then event bus that routes messages
... orchestrator has administrative rights
... then have testing tools
... have many; test execution, analysis tools, generators
... also use AMQPS for messaging
... use agents to connect to IUT
... subtopic: implementation
... have F-interop GUI, use GUI enabler to support that
... upload semantic data, four steps to testing
... first, XML or JSON parser to check syntax
... then RDF parser; is it a valid model
... then extract vocabulary
... then do semantic validation
... then look at interoperability testing
... take date from two users, run through four steps, then compare
... how do annotations from user A and user B compare?
... can do this by testing if queries sent to two servers returns the same result
... checks if two annotations are interoperable
... note that we only check RDF sources
... no capability to check non-RDF sources...
... Demonstrations
... sent out an email if you want to try for yourself
... can use through the web interfaces
... create account, add device, choose a scenario
... (pause while we recover from projector crash)
... give up, have to proceed with webex demo only
... there are three kinds of scenarios
... first is conformance testing
... choose RDF serialization format
... example uses a smart parking use case
... example generates a report, show some errors
... three kinds of errors
... (coffee break while try to fix projector)

<scribe> scribenick: McCool

Soumya: demo
... create device, create demo session
... go into semtest
... conformance, user to user, sut to sut
... look at conformance testing
... can upload various forms of RDF serialization
... can also support owl, etc.
... can give error report...
... this stage checks conformance with RDF and OWL
... second test is user to user
... need two sessions
... add ip addresses for servers
... third one is similar; going to skip
... have some information on community feedback
... asked if anyone can name a testbed for semantic interop
... got a couple of hits for WoT, though...
... but also asked if existing tests are enough
... wanted more focus on data processing level checks
... eg send a query, run, validate result
... conclusion
... semtest semantic interop tool
... added value, F-interop did not have semantic testing capability
... now working on Industrie 4.0, planning to use WoT there as well; related to F-Interop H2020 projectd

McCool: what needs to be done to extend to similar coverage to oneM2M
... I think we need a set of test cases, e.g. queries that can be applied in SemTest

Raggett: seems we can start with some natural language descriptions of the test
... good place to start
... in terms of semantics tests
... could look at shape rules

Soumya: yes, shape rules are on list of things to do

McCool: it would be interesting to have a tool to go from JSON-Schema to SHACL... would help target devs who are used to JSON-Schema

Raggett: any more tools or papers?

Soumya: there is a paper, available on EURECOM website, will give a pointer

Learning Analytics and WoT - Yasuhisa Tamura

<kaz> scribenick: kaz

-> Slides

Tamura: from Sophia Univ
... working on learning technology, digital text books, learning analytics
... formarly worked at Hitachi, 30 years ago
... also work for ISO/IEC JTC1/SC36 & WG8
... SC36: information technology for learning, education and training
... working with Kaz for some digitalization of eduction
... [Why IoT in Educational Domain]
... recent trends to acquire learners' fine-grained behavioral/biometrical data
... multimodal learning analytics
... fits well to utilize IoT
... big data connected with Learning Management System
... [Learning Analytics (LA)]
... acquisition, collection, analysis, and feedback of learners' achievement/behavior
... [Learning Analytics in Educational Domain]
... univ professors started to use LMS
... to let students access contents
... upstream/learning/downstream
... [Learning Analytics (LA)]
... need fine-grained data
... [Learning Analytics Overview]
... basic overview
... dedicated device and generic device (pc)
... for data collection
... then data filtering
... [Classification of LA Objectives]
... we tend to assume types of students
... but students have their own speed/tendency of learning
... some university started to use this technology (categorization, etc.)
... [Learning Analytics: Target Transition]
... granularity vs year
... paper-based => digital => email => material access
... using additional information like page flip, note taking, camera vision, voice/sound, GPS, ...
... and some professors started research on wearable devices, i.e., body/eye motion, blood pressure, sweating, heartbeat, ...

McCool: webcam to check students

Yamada: information about human being
... should be careful about privacy issues

Barry: monitoring blood pressure, etc., without student's permission would possibly cause ethical issues in many countries

Yamada: right
... so this is still under research
... this technology started just 10 years ago
... major conferences EDM and LAK
... [LA Example: Page-flip Action Analysis]
... would show you some examples
... to understand learners' material viewing behavior in the class
... this is the results from my class
... for 90 mins
... I myself showed slide 1-3 here
... but many students didn't look at the slides at the first stage (maybe sleeping?)
... and started to look at the slides at some point
... [Class Comparison]
... 2 examples
... different classes
... information literacy vs educational technology

McCool: in the first class, many of the students were quite qualified?

Yamada: right
... we can analyze students' situation based on this
... evidence of education domains
... powerful tool for evaluating students understanding
... [Technical Standards on LA Data]
... xAPI from ADL, data description using JSON
... no framework to describe the semantics itself
... the other one Caliper
... IMS Global
... data and semantics
... [Rough Comparison]
... IMS Caliper has both semantics and data
... W3C WoT also has both metric profile (TD/domain-specific data) and information model (WoT Binding)

McCool: what kind of data model do you use/expect?

Yamada: [ISO/IEC JTC1/SC36 WG8]
... SC36, information technology for learning, education and training
... also WG8 for learning analytics from June 2015
... convener is Yong-Sang Cho from i-Scream
... monthly online meetings
... [Current status in SC36/WG8]
... presented WoT at SC36/WG8 meeting in Daegu, KOrea on 20 June 2018
... many of the attendees were interested in WoT
... would see use cases for utilization of IoT
... will have a f2f meeting in October this year
... [Challenges]
... market demand estimation
... how many teachers/professors really want to utilize IoT data to education?
... ethically ok or not
... and
... integration/interoperability of existing mechanisms
... WoT, Caliper, ADL
... also privacy issues

McCool: REST API interchange JSON data
... conceptually similar to RDF model?
... first step might be compatibility with RDF model

Matthias: how many IoT devices available?
... products? prototypes?

Yamada: we can use many existing devices
... like eye tracking device
... but it's impossible to incorporate expensive devices for all the students
... so would be better to use additional software as a hook for actual devices

Kaz: that's kind of simulator

Yamada: that said, many students started to wear wearable devices
... so some time it would be possible to use actual devices

Matthias: yeah
... standardization would be helpful to use wearable devices for educational purposes

Yamada: right
... but please note that we have difficulty with public students

JSON-LD Frame and GraphQL extensions for Thing Directory - Danh Le Phuoc

Danh: from TU Berlin
... active also at semantic data TF

-> slides tbd@@@

Danh: JSON-LD Frame and GraphQL Extensions to Thing Directory]
... (shows Thingweb Directory)
... who knows this UI?

(Soumya raises his hand)

Matthias: this tool itself doesn't tell there is an error?

Danh: can test it using TD playground before hand
... register -> discover -> frame
... we can specify concrete SPARQL query here (discover window)
... but maybe people don't want to do so directly
... (go back to the slides)
... [Query Thing Directory with JSON-like structure]
... SPARQL endpoint - Thing Directory (RDF engine) on the left side
... JSON Frame/GraphQL endpoint - Thing Directory (RDF engine) on the right side
... [JSON-LD Frame: Filter the properties of interest from matched TDs]
... (shows TDs/Intel/intel-light.jsonld)
... snipet for the Thing Directory
... and nice TD format on the right side
... [JSON-LD Frame: Integrating THings from different vendors by Semantic Types]
... next example from Panasonic
... another example
... Intel again
... can get matched TDs
... [JSON-LD Frame: Filter by for multiple branches that match a type]
... example from Siemens/FestoLive,jsonld
... type for operating status
... [Limitations of JSON-LD Frame]
... output of JSON-LD Frame is only JSON-LD
... only can filter by type of branched properties
... can't handle complicated joins among TDs
... can't filter by values of object attributes
... [GraphQL]
... increasingly popular language describing queries
... provides much richer capabilities than JSON-LD Frame
... integrated on to commercial RDF engines
... [Integrating Things from different vendors by Semantic Types with GraphQL]
... the query looks similar
... first one is Panasonic
... and searched result is Intel
... [Complicated filtering directives with GraphQL]
... detect match of IP addresses

McCool: what about local vs global?

Danh: [Implicit Semantic Abstraction in IoTSchema.org]
... [Semantic Reasoning with GraphQL]
... reasoning between AirTemperature ExpectedAmbientTemperature

Matthias: no definition at TD?
... where the knowledge comes from?

Danh: you can go with abstract scope

Sebastian: WoT itself doesn't require any specific directory service
... also a bit skeptical about GraphQL
... make sense for TD to have extended vocabulary?
... GraphQL doesn't have to be the best solution

McCool: automatic approach would be ideal
... any concrete tool available now?

Danh: have to see what's coming up

McCool: what SPARQL can do which GraphQL can't?

Danh: SPARQL is very powerful

McCool: any visual languages?

Danh: many trials for visual version for SPARQL
... but not sure about opensource version

Dave: potential relationship with ETSI's CIM work

<dsr> https://www.etsi.org/deliver/etsi_gs/CIM/001_099/004/01.01.01_60/gs_CIM004v010101p.pdf

McCool: we should look into more use cases
... to see what query mechanisms would be useful

Danh: there is no exclusion policy

<dsr> GraphQL https://graphql.org

<dsr> JSON-LD 1.1 frame https://json-ld.org/spec/latest/json-ld-framing/

Matthias: JSOL-LD framing is in the JSON-LD WG's scope

JSON-LD WG charter

Dave: should think about liaison with ETSI CIM work

Kaz: we're already planning to have some joint call with ETSI ISG CIM
... so we can have some discussion at that time

Matthias: nice to have reports from the LD TF during the main call

Danh: ok

PlugFest demo

<dsr> intro to GraphQL https://dzone.com/storage/assets/6811883-dzone-rc249-graphql-10-03-2017.pdf

KETI - Youngmin Ji

Tech Day 2

Youngmin: (shows the demo)

Danh: topology?

Youngmin: can show you

-> preparation.md tbd@@@

Panasonic - Toru Kawaguchi

-> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/preparation-panasonic.md preparation-panasonic.md

Toru: simulator Things
... you can operate devices online
... (turn on the lights)
... (shows the TD)
... you can control Things remotely
... worked on 5 simulators

<ryuichi> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/PlugfestSummary_rev3.pdf

<ryuichi> plugfest summary

Panasonic - Takeshi Yamada

Yamada: simple TD endpoint
... using node-RED
... connected to Siemens' simple websocket endpoint
... application receipts events from Siemens websocket
... payload shown on the right side
... (shows a video)

Matthias: what's happening here?

Yamada: air conditioner is working

Oracle - Michael Lagally

Lagally: using Panasonic's air conditioner
... (changes power property)
... read value
... also integrating the simulator
... KETI sensor as well
... (shows monitor page)
... set temperature for Panasonic air conditioner
... changes the temperature to 30 degree
... on the simulator side
... KETI IoT sensor
... taking some data like this
... VOC, threshold VOC, etc.

Siemens - Sebastian Kaebisch

Sebastian: MQTT experience
... small micro controller here
... parking slot sensor
... MQTT working inside
... second scenario
... MQTT client with Michael Koster
... (shows TD for the sensor)
... publish the data to change the status of the sensor
... light sensor and parking slot sensor
... motion sensor from Michael Koster

-> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/TDs/Siemens/parkingSlotSensor_mqtt.jsonld parkingSlotSensor_mqtt.jsonld

Sebastian: and consume TD here
... (shows Visual Studio codes)
... works very well
... (and then turning on node-wot)
... feel free to check out

Siemens - Matthias Kovatsch

Matthias: something quick
... now we have websocket-based push event mechanism
... and secure connection
... use this leshan public key
... several client end points
... switch to TDs
... LWM2M client
... here what's happening
... new cleint for coaps
... and here
... communication with secrete credential
... received message "endpoint is mandatory"
... good news is that CoAPS worked

Fujitsu - Ryuichi Matsukura

Matsukura: generated clean version of the connection results diagram
... Fujitsu directory here
... works with Panasonic application (node-red and scripting)
... also collaborated with Oracle
... implemented a bridge for Oracle cloud service
... can control the rotation light

Sano: (shows the demo)
... Oracle simulator UI
... and video from the smart house
... try to control the devices using Oracle simulator
... open the blind now
... (opens the curtain)
... and then close it
... (closes the curtain)
... then control the rotation lamp
... and it works
... and turn off

Hitachi - Kunihiko Toumura

Toru: I myself don't have any device this time
... just application
... diagram of panaosnic light, OCF light, Fujitsu light, Siemens Nabaztag
... implemented on Node-RED
... developed node-red-nodegen
... and Things as nodes
... Nabaztag.jsonld
... create resources for the node
... we can use this wotnabaztag node
... can see properties/actions/events using Node-RED
... configured node properties
... control the rotate light
... nabaztag as well

-> https://github.com/node-red/node-red-nodegen node-red-nodegen

Kaz: great OpenDay meeting
... will wrap up/summarize plugfest achievement tomorrow?

Kajimoto: yes, there will be sessions for that purpose

[OpenDay adjourned]

WoT f2f - Tech Day 1
03 Jul 2018



Kazuo_Kajimoto(Panasonic), Toru_Kawaguchi(Paanasonic), Takeshi_Yamada(Panasonic), Kunihiko_Toumura(Hitachi), Ryuichi_Matsukura(Fujitsu), Takeshi_Sano(Fujitsu), Tomoaki_Mizushima(IRI), Kazuaki_Nimura(Fujitsu), Dave_Raggett, Michael_Lagally(Oracle), Barry_Leiba(Huawei), Wonsuk_Lee(ETRI), Youngmin_Ji(KETI), Michael_McCool(Intel), Sebastian_Kaebisch(Siemens), Matthias_Kovatsch(Siemens), Koster(remote), Ege(remote), Matsuda(remote), JinHyeock_Choi(Samsung), Seunghun_Ob(ETRI), Daniel_Peintner(Siemens), Zoltan_Kis(Intel), Elena_Reshetova(Intel;remote)
Matthias, McCool, Kajimoto

<ryuichi> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/PlugfestArchitecture180703a.pdf


scribenick: kaz

Kaz: am1

taki: am2

barry: pm1

Toru: pm2

<ryuichi> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/PlugfestArchitecture180703a.pdf

PlugFest reports


Matsukura: [Achievements of the previous PlugFest]
... from Prague plugfest
... application servients and device servients
... [Checking points for Bundang PlugFest]
... 10 points
... 1. multiple proxy interaction
... 2. application servients/device servients
... 3. node-wot as a servient
... transformation between wot and other mechanisms
... 4. scripting api
... some of the participants implemented it
... compatibility between the two
... 5. thing directory operation
... compatibility and integration of multiple implementations
... 6.device simulators
... 7. semantic integration by iotschema.org
... 8. security
... 9. accessibility
... 10. events
... [Achievements of this PlugFest]
... gathered information and generated this diagram based on the results
... please review it
... applications at the top
... mid range for proxies
... and devices at the bottom
... fujitsu-based connections on the left side
... oracle cloud service at the center
... and siemens directory on the right
... tried to connect between fujitsu and siemens but not done yet
... on the other hand, fujitsu-oracle is connected
... are siemens node-wot all implemented by node-wot?

Matthias: not all

Matsukura: this part (IoT Dev. Sim)

McCool: motion sensor from Intel should be connected with ocf
... will let you know the detail later

Sebastian: Michael Koster and myself worked on MQTT connection

Matsukura: smartthings devices are not included here
... please let me know the detail so that we can add them

McCool: which connections are secure ones?
... this diagram is quite busy
... we should break it down into each scenario

Kaz: +1
... should break it down into each scenario including specific components

Matthias: can add CoAPS connection

Matsukura: ok

McCool: Michael Koster, how about you?

Koster: still having some problem
... I have several check points as well
... would put my points to the diagram
... worked with Sebastian

McCool: you used UDP?
... have you done TCP as well?

Koster: no
... maybe for the next plugfest?

McCool: ok
... OCF has CoAP over TCP

<McCool> here is a ref for coap over tcp: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-10

<McCool> regarding coaps+tcp above: this is a better link (released rfc instead of draft): https://tools.ietf.org/html/rfc8323

Ege: mashed up GP
... and testing framework?

Sebastian: I tested it
... could only work without security constraint
... test bench didn't work with security
... but I used the test bench

Sebastian: we need to take security into account next time

Matsukura: ok
... please review this again and give comments

report from MJK


Koster: inter servient connection
... [Client-servient Roles]
... [Proxy Roles]
... connection with proxies
... kind of tunnel
... 2 thing directories
... consuming proxy here on the local side
... (explains the sequence about how the 2 proxies work with exposing servient (device server) and consuming servient (application client)
... make sense?

McCool: possible other settings?

Koster: this is just one possibility
... let's go ahead
... [Tunnel Protocols]
... WebSockets
... may or may not including caching
... 1.1 expose to consume relationship
... push protocol mapping to interactions
... MQTT many to 1 and 1 to many?
... yeah
... many to many as well
... [MQTT Tunnel]
... [Things]-[Consuming proxy servient]-[MQTT Consume Script]--[MQTT Broker]--[MQTT Expose Script]-[ExposingProxy Servient]-[Clients]
... [Security Considerations]
... channel security plus auth
... app layer security indicated
... multiple security goals
... websockets and MQTT
... part of the servients are proxy-based and some are websocket-based

McCool: wondering about MQTT
... protocol binding for MQTT includes various options?

Sebastian: default port using TLS
... and websocket-based connection (not secure)

Matthias: you have to have some sub protocol for websocket
... there is TLS version of websocket as well (wss)
... talked with Koster at the prev IETF meeting
... someone working on MQTT to be involved

McCool: ok

Matthias: some requires to use URI as the identifier

Koster: structural syntax for scheme name
... big debate within IETF
... MQTTS uses TLS
... also has basic auth
... a lot of possibilities for security
... btw, wondering about management things
... how to discover and read TDs
... possibly proxy talks with the broker
... all special cases of proxies
... [Tunnel Protocols]
... [Proxy Roles]

McCool: 2 categories
... true VPN or tunnel
... maybe true VPN is overkill
... some change to the addresses using the thing directory
... if you have limited ports for tunneling, what would happen for multiple devices on the local side
... maybe having 2 directories would be cleaner

Nimura: end-to-end security?

McCool: several possibilities
... both would work
... would write up them within the security document
... need more balanced discussion on proxy
... including proxy security, end-to-end security

Nimura: maybe end-to-end security would be needed

McCool: security within the local network
... you can have 2 separate mechanism
... so can have some different mechanism for the global side

Matthias: there are some trade-offs
... need to update the architecture document

McCool: also part of the security document as well

Dave: this is more about tunneling
... what about other mechanisms?
... open market services

Kaz: have already recorded the point within the minutes
... and would suggest continue the detailed discussion later

Dave: ok

Koster: we should consider how to manage proxy

Dave: am interested in handling market services included in plugfest :)

Kaz: next step?
... report and possibly proposal for the arch doc?

McCool: possible standard proxy and apis?

<McCool> McCool: next steps would be to define or document apis for proxy service management

<McCool> ideally for multiple patterns, maybe even including tunnelling

Koster: that's good
... we need to continue to work
... and identify what we should do for the next plugfest

Nimura: you described 2 directories here
... but we just used one thing directory
... part of the connections are invisible from the device

Koster: we could still use one single directory
... seems to me a bit complicated to have 2 separate directories
... so maybe easier to have one single directory

Kaz: yeah
... as McCool also mentioned the next step should include our clarifying/documenting how to use proxy services

Matsukura: yes, we should clarify proxy roles
... I have similar idea like you
... so described the concrete sequence about how Fujitsu proxies work and update the architecture document

Koster: yeah
... we should update the architecture document

Kajimoto: agree we should add descriptions to the architecture document
... these bullet points 1-6 are good summary on what proxies do
... should be included in the architecture document

Koster: ok
... basic setting
... and proxying
... and tunneling

Kaz: so how to update the architecture document?

Koster: can make pullrequests
... and also start discussion during the main call
... and plugfest call also

Toru: prior to integrate these documents into the architecture document, we should have some more discussion about terminology
... e.g., consuming servient, exposing proxy

Kaz: agree

Koster: agree

Matsukura: would have some more discussion today

Kaz: and also continue the discussion during the main call and pf call

Kajimoto: ok

Matthias: quick note
... Daniel want to change the slot for Scripting API
... also changed some of the moderator assignments
... also note that we have kind of short slot for rechartering, etc. on Thursday
... wondering about if we have hard cut at 2:30pm on Thursday?

(some discussion and 3:30pm is fine)

Matthias: will update the agenda, please check if it's OK

updated f2f Agenda

[break until 10:45]

<taki> scribe: TK

<taki> scribeNick: taki

Events with input and output (Matthias)

Matthias: What are events?
... can be pushed out.
... is a notification.

MK showing definition of events...

Matthias: comes from programming model
... observable property models state.
... such as coap observe.
... events are for processing
... e.g. click events

McCool: the slide should compare with observe.
... filtering, also.

Toru: event sources?

Matthias: TD describes event sources.
... not events.

McCool: We should use "events" in TD.

Toru: event source interaction?

Matthias: In TD, we continue to use "events"
... action has input and output.

MK showing information model...

Lagally: event source is a source?

Matthias: there are diverse aspects to think about this.
... thing pushes out events, then it is an event source.

Dave: event groups, and filters. where do we describe them?

Matthias: input of events are filters.

McCool: input and output mediatype?

Matthias: it is a reminder. TD currently do not have them for actions.

McCool: for security, we allow three levels. thing, interaction and form level.
... we should make it consistent with this way.

Matthias: should we do this? input/output for events.

McCool: who requested it?

Matthias: we have an use case.

Lagally: I am not fully clear about this.

Matthias: input is for specifying filters.
... when you subscribe to events, in the subscription message, you can specify filters.

McCool: no filter, simple filter, and more complicated case.
... simple case stays simple.

Dave: we need to be careful on terminology.

McCool: we can ask Mozilla first.

Matthias: the process is first specify, and then try in PlugFest.

Lagally: you send a payload with input/output specification.
... distance and temperature. you will never get temperature.

Matthias: that's user's problem.
... every ten minutes, temperatures above 30.
... those are examples.

Koster: protocols has single channel, and multiplexing is another use case.
... filtering on multiplexed event channel.
... many protocols operates this way.

Dave: Input-only case. output is optional.

Matthias: it is like action.
... still get confirmation.

Sebastian: same media type announcement for input and output becomes complex.

Matthias: properties are different from action and events.
... that is why it is different in information model.

Toru: input filter use case, I understand. Doesn't observe property do the same?

Matthias: No. It is different.

Toru: we cannot specify temperature threshold, then.

Matthias: URI template schema. we can hack it to communicate that.

McCool: complex observe, it can use event source.
... property should stay simple.

Toru: events are visible state changes.

Matthias: property, you can read it anytime. Events are different.
... Query parameter makes different properties in some sense.
... are you suggesting to ta e a look at SSE definition?

Koster: Yes.
... it may provide a standard way.

Matthias: can we prepare for next plugfest using different patterns?
... input with callback url, input with filters, etc.

Koster: We need to be able to map to existing protocols.

Legally writing on whiteboard...

Admin Day

Lagally: temperature, humidity properties...
... not a property. it is an object.
... subscription mechanism.

Matthias: it is protocol specific.
... Oracle provides events. message and alerts. it will be described in event source definitions.
... there is an use case.

Lagally: also there are different way to unsubscribe.

Matthias: forms can describe it.

McCool: unsubscribe has different input.
... input needs to have subscribe and unsubscribe descriptions.

Koster: CoAP has built in mechanism. For other protocols it makes sense.

Lagally: options go into form.

<McCool> suggest that rather than input we have subscribe and unsubscribe

Lagally: we need a concrete example.

<McCool> then use rel to distinguish the two forms...

<McCool> of course there would be other patterns, too

Kajimoto: Panasonic could not read Siemens events

Matthias: We currenlty has output definition.

<McCool> but those other patterns should still work, you just might not use the unsubscribe schema (for instance)

Kaz: how to proceed?

Matthias: I will update the slide, and follow up with node.wot update.
... In binding template call, we should write up something.
... Webhooks, websockets, etc.

Summary of new patterns (Koster)


Matthias: we should be done in 17 minutes

Koster: OK

Koster presenting "WoT Protocol binding New Features" slides

Koster: simplified TD, extnded action patterns, event delivery on websockets, webhooks, etc.
... Extended action pattern has input and output mediatype.
... you get an address of a thing.
... outputmediatype can be application/sd+json
... we do not have output form.

McCool: prescriptive is good in some sense.
... for existing devices.

Koster: do you have an example?

McCool: has an action. In thing directory, it describes action. we can get from 3rd source.

Koster: it is not about an action instance.
... existing devices would not return output.

McCool: we should do home work on existing devices.

Koster: industry practices... there are many patterns. We cannot accomodate them all. we need an example.

<McCool> anyway, I think this pattern is good and we should include it, but it is only good for "wot native" devices

Koster: I am presenting a simple pattern. we probably need to extend it.
... let's see what is required.

<McCool> like was captured, we need to look at existing devices to see if there are other requirements to describe existing devices that do things like this

Koster showing an example TD that has property and action...

Matthias: Default context does not have to be mentioned. iotschema needs to be declared.

Sebastian: You get back this TD, right?

Koster: when you do action.

Sebastian: so this is TD of an action.

Koster: yes

<McCool> my comment was regarding whether or not we should include context in the ad or inherit it from the thing it is created from

<McCool> pros and cons either way; we should explore

Koster: it could return a location.

<McCool> for now, let's leave them out and see if that works...

Matthias: there is a session about entity Descriptions.

Koster: there is an collective action issue there.
... event delivery on websocket.
... has multiplexing and non-multiplexing events.
... event delivery over webhooks.
... suitable for miltiplexed events.
... much more reliable.
... can be used for orchestration, too.

Koster showing an example of TD...

Koster: action that uses webhooks...

Koster showing entity description...

Matthias: where do I get it?

Koster: that is a good question.

Matthias: is this response to subscribe request?

Koster: yes.
... it also should have delete.
... it does.
... multiplexed events using eventsource as a subprotocol
... there is a concept of notification collection resource.
... selected notification based on filter or list.
... event collectors dynamically created.

Koster showing an example TD...

Koster: it uses event source.
... Definition of collection, and how to deliver them.
... the two are separate issue.

Matthias: we should not disable these option. We should consider carefully.

Koster: URI templates.
... RFC6570
... JSON schema to describe variables.
... Use "uri-properties" in interaction description.

MQTT Binding (Sebastian)

Sebastian: I implemented with a scenario.
... It is on a branch now.
... microcontroller has three topics, and three data.
... I setup a TD for that.
... defined as events.
... it has IP address of broker
... node.wot consumes TD. automatically takes care of subscription.
... script comsunes TD, and subscribe.
... second scenario.
... MQTT client provides actions.
... light changes green to red, for example.
... call an action to broker.
... can simply call an action from script.

Sebastian showing an example TD...

Sebastian: In TD, it provides broker URI.
... topic is a part of URI.

McCool: publised topic, is it a property or an action?
... when I want to publish.

Sebastian: Publish to a topic, it is an event.

Matthias: client is not accessible, it has to go through a broker.

Koster: publishing to a topic maps to an action.

Sebastian: publication can map to an action.

McCool: I am thinking about bidirectional communication.

Sebastian: two clients roles.

Matthias: MQTT events and WoT events are different.

Sebastian: MQTT does not have mediatype, but TD has it. It is a big benefit.

McCool: meta-data is more useful in MQTT
... broker can return all TDs.

Sebastian: publication as property+observable=true. This sounds reasonable.

Koster: disabling read, and just enable observe may solve an issue.

Sebastian: how about the retain flag?
... I would propose when retain is true, use property. otherwise use events.

Sebastian showing a hybrid solution...

Sebastian: read with HTTP, write with HTTP, and observe with MQTT
... I propose to new TD terms.
... mqtt:qos, mqtt:retain, mqtt:dup

Matthias: MQTT 5 has new features.

Sebastian: At this moment, I would not consider MQTT 5.

Matthias: You will make a separate binding for MQTT 5.

Sebastian: yes.

McCool: MQTT will be a whole new protocol?

Sebastian: it introduces incompatibility.

McCool: I agree we worry about MQTT 5 later.

Sebastian: where are TDs? MQTT broker vs. MQTT clients?

Dave: anyewhere it is ok.

McCool: broker can have a topic to provide TD.

Matthias: I updated agenda.
... afternoon session starts at 2:30

<kaz> [lunch till 2:30pm]

<kaz> rsagent, draft minutes

IoT Exciting - Barry

<kaz> scribenick: kaz


Barry: (goes through the slides)
... [Why is this different?]
... [Can we move in that direction?]
... can we start ourselves on a path to get there?
... focusing our testing not just on interoperability of the protocols, but also on interaction of IoT components?
... how we move to that direction?

Matthias: not only demoing but also think about interoperability and interaction of IoT stakeholders

Dave: exciting business scenarios

Lagally: already started some discussion

McCool: semantic categories filled into the scenarios
... need to work on services instead of just devices

Dave: how to make it easier for people?

McCool: for external parties

Kaz: we already identified the need for attractive scenario for plugfests
... so we should continue that direction

Matthias: but our time slot is limited, so should be careful

McCool: also should think about online testing

Matthias: playground is an important tool

<barryleiba> OK, I can start scribing.

<scribe> scribenick: barryleiba

Dave: for recruiting, demo scenarios will be compelling.

properties/actions/events Links

TD issue 151

Matthias: presenting
... semantic annotation, special property
... if we have a link to actions, what does that mean? alert events, has a lifecycle, react to alerts and resolve them
... collection of active alerts
... what do you get from actions, events, other resources?
... features that many of us have use cases for. What do people think the right way to do this is?
... "links" property with resources under it (actions, events)
... use this to specify how it's done on this platform
... do people have implementations of these? How can we describe them in the TD?

Dave: I've implemented it so we get all the properties at once.
... I'm talking at the protocol level. What does it mean at the object level?

Matthias: sometimes need very specific connections — two properties that were measured at the same time, for example.
... how do you ensure that requirement is fulfilled?

Dave: seems to be a protocol issue. How do you define the binding templates?

Matthias: It's not at the template level, it's an application requirement
... part of this is bootstrapping a UI to populate everything
... two options: define property with specific semantic tag for all the properties inside. Other is with annotations.
... define a form in the thing at the thing level

McCool: a collection of actions in the thing. The form would have everything you need. Maybe a general mechanism for interactions within a thing.
... in HTML you refer to anchors within a document using hashmark syntax. This couldbe consistent with that.

Matthias: if client knows it has to get all the properties, we already have that.

McCool: another thought: href… should it be a complete form?

Matthias: this is a Mozilla proposal, and they have a lot of implicit assumptions
... one mechanism is that we use collections
... could then use a media type that refers to a link format
... if you have this requirement, document how you do it now, or guess how you might do it, and make proposals
... there's always a command to read out all values.
... need related data in one RT

Dave: how is this exposed through the scripting API? in a programming language I clone the object

McCool: how do we make it less redundant/verbose by defining this?

Matthias: special property for a structure that returns everything?

Dave: the use cases need clarification. Range of choices, don't understand the requirements yet.
... what are people doing in existing protocols?

Matthias: one special resource, read it to get all properties
... out of band mechanism because there's no defined way

McCool: need a form at the top level to get an entire data schema as a payload.

Matthias: thing itself becomes a property, seems weird.

McCool: should follow up on the issue tracker

Matthias: not everyone is implementing the scripting API

Dave: repeating that we need to better understand the requirement
... http server might allow you to access all properties at once, or it might not

Matthias: yes, and how do we best do it. Not everything will support the "retrieve all at once" feature

Dave: agree with following up on the issues list

Matthias: I will put a summary of this discussion in the issue tracker

Message flows - Toru Kwaguchi

message flow diagrams

Toru: presenting message flows
... looking at message flow examples. Changed the format

example of "read property"

Toru: coap binding is not here

these use http binding

going through the example: subscribe, notify…

Toru: scripting API might change a little, so I should check and incorporate the changes
... observe property: I have three pictures. I've added http server sent event
... (goes through the subscription phase, then continues to notify phase)

(case from last march)

Matthias: (comment adjusting the flow in the subscription phase)
... unsubscribe here is closing the connection

Dave: that's exaclty how sever sent events works, with a series of chunks

Matthias: yes, that's how this figure needs to be adjusted. These diagrams are very helpful for seeing that sort of thing

(discussion of how to update the diagram for this case)

now discussing simple web socket diagram

Toru: i have three bindings for the push notifications

McCool: this seems like it specialize for wot native apps

Matthias: this is using raw web sockets as a data pipe, just pushing the json instance through

(now looking at invoke action)

McCool: do we need subprotocols for some of these?

Matthias: this is a good basis to clarify ideas for further protocol bindings. Also separate them so there's a generic one in the arch doc, then each binding doc has a specific one
... this is an easy format to edit, so it's convenient to make the diagrams

Koster: I've already started out creating some of these for the document
... helps me, too, to organize my thoughts about the flows

what defines the message format through the websocket?

Matthias: in the curent charter we said we wouldn't define new protocols, but it's a topic for the rechartering.
... need to see what other protocols are there.

Dave: how many protocols do we need? have to think about that

Kaz: Wonsuk has been working on W3C Automotive VISS interface, so we might want to think about binding with that

wonsuk: when we use native platforms, they need to know how to contact the IoT device

Matthias: some people used mqtt over websockets; there's no coap over websockets.
... there's a combo of req/resp over websockets
... if we generalize some of these, could be a good basis for a protocol.

(now looking at "event")

Toru: further things to consider: coap, mqtt bindings; webhook binding; multiplexing of event; action and event with descriptors

Koster: thanks, I like this a lot

Matthias: (repeats comment about separating into generic and specific)

Matsukura: integrated servient architecture

(shows picture from plugfest summary)

(multiple proxy and directory integration)

(connection with Oracle IoT cloud)

Servients Integration - Ryuichi Matsukura


Matsukura: fujitsu implemented oracle binding to interface
... fujitsu remote proxy connects to siemens local proxy via websocket
... fujitsu synchs TD directory with siemens
... wot proxy servient can coordinate non-wot entities, such as oracle iot cloud service, echonet lite, ethercat, etc

(narrow waist model picture)

Matsukura: proxies coordinate the connections between applications and devices
... can connect not just with wot servients, but also non-wot
... consideration of possible connections

(slide from Michael Koster)

(summarizes different types of connections, such as "application servient directly connects to device servient")

(integrated servient architecture)

Koster: still looks like private and public to me

(discussion of some specific diagrams)

(servient and TD directory abstract interfaces)

Matsukura: should call these WoT interfaces

(looking at sequence diagrams)

Kaz: maybe we might want to think about even simpler connection pattern, e.g., just having one application servient and one device servient (as you showed at the beginning of these slides)

(address resolution on servients)

(address resolution with remote/local proxy)

<kaz> several possible patterns: (1) address resolution on the servients themselves, (2) address resolution by the proxy (one proxy) and (3) address resolution using remote/local proxies (2 proxies)

Lagally: how are the registration messages protected? HTTPS?

Matsukura: https, yes

Lagally: where are the https connections terminated? at the proxies? or passed through the proxies?

Matsukura: many combinations are possible

Matthias: (questions the registration connections in the diagram)

Kaz: (also questioning some of the connections and flows)

Matsukura: (further explains)

Toru: why is URL2 needed?

eases implementation

McCool: devices not usable outside the local network should not have the URLs

(interaction with non-wot devices)

<kaz> <img alt="url1"/> <img alt="url1+url2"/> <img alt="url1+url2+url3"/>

Matsukura: bridge can connect device servient and non-wot device

many non-wot devices have similar device models to TD

bridge function can be implemented in proxy instead of device servient

bridge can also connect application servient and non-wot application

bridge function can be implemented on proxy instead of application servient

(diagram of possible configurations with bridges)

(diagram of system architecture with non-wot)

<kaz> Kaz: diagram 33 is too complicated

<kaz> ... but diagrams 28-32 are part of the whole mechanism

<kaz> ... and concentrating on these parts one by one and clarify actual scenario for each part is inline with the discussion yesterday (or this morning?) during the plugfest report

<kaz> ... so I think you should work with Michael Koster and clarify the scenario and connection for each part as the plugfest report first

<kaz> ... and then after generating concrete description about that, you can create pullrequests for the architecture document

<kaz> Toru: question about what this diagram means from the concrete industry service viewpoint

<kaz> Matthias: explains an example of Oracle cloud

<kaz> Kaz: so I'm suggesting Matsukura-san and Koster should clarify actual scenario and setting based on the plugfest results

<kaz> Matthias: how to proceed with updating the architecture document?

(sorry, I've dropped it… it's hard to scribe these diagram discussons...)

<kaz> ... good candidate content for section 7

Matthias: maybe we can synch with toro and figure out what pieces we need in the arch doc

15-minute break.

<kaz> section 7 of the architecture document

<kaz> [break until 4:45pm]

<kaz_> Slides

<kaz> rssagent, draft minutes

Plugfest Security Review - McCool/Elena

<kaz> scribenick: kawaguch


Plugfest Security Review

McCool: more focus on security aspect
... will go to individual result document
... outline: who tried what, issues arising, TODOs
... intel: Authentication HTTP basic/digest
... Encryption HTTPs Proxy, direct HTTPS (Let's Encrypt, self-signed)
... self-signed is used for local devices but client has to accept it
... Secured services : Thing Directory, Playground, metadata bridge, CoAP/HTTP bridge, OCF device and so on
... Siemens: Authentication basic (HTTP/MQTT), JWT, DTLS-PSK
... Encryption via node-wot: HTTPS, WSS, CoAPS, MQTT/TLS
... Panasonic: Bearer token security, predefined.
... also used override security with no-security
... might be better to explicitly write "no-security"
... multiple security can be written
... 2nd implementation uses special header
... might better use bearer token rather than opaque apikey
... SmartThings:
... Eurocom: Authentication with bearer token, Encryption with HTTPS and pre-shared key for TD
... Issues:
... NAT Traversal on port 22, Pre-shared keys, Self-signed certificates (HTTPS local)
... Security definitions vs configurations
... many people misunderstand them, so now security definitions omitted.
... Multilevel security configurations all needed ?
... Do we need "add-on" security configurations, rather than overriding?
... One use case is public proxy
... Multiple security in one place means "AND"
... To represent "OR" use multiple forms.

Matthias: issue numbers?

McCool: some are already captured
... Next steps
... Try existing schemes
... Try new schemes as Local TLS/DTLS, MQTT CoAP OCF, Basic auth over HTTPS, Digest over HTTP

Kaz: Ajiotomi-san is leading local HTTPS CG, and we had some chat. he should be able to join one of the security call at some point. also we can have joint discussion during TPAC in Lyon

McCool: local CA is also topic
... certificate also includes CA
... IoTivity will implement security


Elena: section seven is focused on privacy
... feedback is appreciated
... Thing description might leak privacy -sensitive info as detailed configuration of a Thing
... Need to minimize publicly available info from TD and interface
... Authentication for obtaining TDs

Dave: two level TD?

Elena: yes, but not sure it's possible

Matthias: interaction level is also protected

Elena: multiple TD variants would exist based on access level

Kaz: what would be public and what would be private

Elena: not sure but owners might be private

Toru: cannot imagine any part for smart home will be public

Elena: hotel room case might be considerable

Kaz: so we should clarify concrete use cases and requirements including your use case of a hotel room

kajimoto: depends on service and situations

Matthias: smart city case

Elena: something could be still fully public

Matthias: create a process how to think about this

Elena: Disclosing WoT system configuration
... communication between endpoints, directories should be protected.
... casual observing such as home guest should be also avoided.

Matthias: JSON-LD loading context file might be observed

McCool: DNS snooping can read this

Matthias: JSON-LD 1.1 charter will be reviewed by security group

Elena: who would maintain cache?

McCool: assumption is only gateway might do that
... secure DNS lookup would avoid mitigating

Elena: user data
... privacy sensitive data should be encrypted end-to-end

Nimura: anonymising might be another protection

Elena: if end-to-end protection is difficult it might be so

McCool: state caching might be broken by end-to-end protection

Kaz: we might want to have joint session with web authentication WG during TPAC in Lyon

McCool: as well as general security

Elena: system user
... TD's id is unchanged so WoT system user can be tracked

McCool: one compromise is update id periodically
... no good recommendation from quick search
... immutability is big topic

Matthias: linked data might store such knowledge
... CPU ID is similar issue

Elena: user participation, consent

WoT Security Recommendations


McCool: should we publish Security Document as W3C Note?
... we should refer to possible external documentations

Kaz: we can start initial work on Github
... Best practice is better than Recommended practice

McCool: see the slide and make input

Sebastian: TD has implementation note section about security

<kaz> [tech day 1 adjourned]

WoT f2f - Tech Day 2
04 Jul 2018



DanhLePhuoc, Kazuo_Kajimoto(Panasonic), Toru_Kawaguchi(Paanasonic), Takeshi_Yamada(Panasonic), Taki_Kamiya(Fujitsu), Kunihiko_Toumura(Hitachi), Wonsuk_Lee(ETRI), Michael_Lagally(Oracle), Takeshi_Sano(Fujitsu), Tomoaki_Mizushima(IRI), Ryuichi_Matsukura(Fujitsu), Kazuaki_Nimura(Fujitsu), Barry_Leiba(Huawei), Danh_Le_Phuoc(TU_Berlin), Dave_Raggett(W3C), Seunghun_Ob(ETRI), Michael_McCool(Intel), Sebastian_Kaebisch(Siemens), Matthias_Kovatsch(Siemens), Kaz_Ashimura(W3C), JinHyeock_Choi(Samsung), Michael_McCool, Ege_Korkan(remote), Jan_Lauinger(remote), Michael_Koster(remote), Michael_Lagally, Zoltan_Kis, Victor(remote), Daniel(remote), Zoltan(remote), Ege(remote)
Matthias, McCool, Kajimoto
kaz, DanhLePhuoc, mlagally

<kaz> scribenick: kaz

Thing hierarchies - Michael Koster


... links field in the TD
... RFC 8288: Web linkin
... RFC6690: header
... core-links-json
... different Web link serializations
... collections and hierachies of resources
... (example links field)
... href: https://servient.example...
... rel: controlledBy
... mediaType: application/td
... can be a lot of different relations
... registered to new RFC8288
... mediaType as application/td can be defined
... additional vocabularies can be also defined
... this link describes resources
... that's general pattern
... any questions?

Matthias: should be application/td+json ?
... in web linking the term is "type"
... if you choose "mediaType", it would be incompatible
... no problem for JSON-LD to use "type" for "mediaType"

today's scribe: kaz, danh, lagally, sebastian

Koster: we could you both (type and mediaType)
... we can do either way

Lagally: question about "rel" field

Koster: if you want to add compatible web link, need to register it
... 3 different things
... there are some practical issues with web link
... but can look into it

Matthias: many of the short term are defined by IANA
... also stylesheet kind of resouces
... you can register your own term for "rel"
... we don't have any intention (at the moment), though

Koster: structural relationship depends on industries
... a lot of existing ones are reusable

Taki: maybe "mediaType" would be still better
... it would be clearer

Matthias: the question is that we ourselves are not defining this
... it's already defined by RFC8288, Web linking spec

McCool: feel inclined to get down to the standard


Koster: we need to decide what to do

Sebastian: maybe we can use "mediaType" and have some kind of mapping to "type"

Matthias: what do you mean by "mapping"?
... need to consider compatibility with RFC8288
... a lot of new concepts getting together but people have many different backgrounds

Koster: maybe we could add something like this
... rel: self
... describedBy: http://w3c.org/wot/td

McCool: rel as array?

Koster: core-links-json doesn't allow arrays
... just one item

Kaz: maybe we can talk with W3C TAG Team

Koster: makes sense

Dave: for that purpose, we should generate some concrete use cases

Kaz: we can do that based on this snipet

Koster: [Collection-Hierarchy]
... (shows an example code)
... controlledBy, partOf, hasController
... might have a semantic annotation
... these are usable patterns
... we can even compose TD dynamically
... links are more extension point

Danh: incompatible with form?

Matthias: form is for constructing request
... on the other hand link is for relation between one and another
... link just says that you have some resource
... specific relation and relation type

Koster: context of form is interaction
... read method, write method, etc.
... a lot of concept for link
... form for how to construct message and request

McCool: link is super class of form
... should use same terms

Danh: link and form should be at the same level

Matthias: what do you mean by "level"?

Dave: this is an instance of a template
... form is for interaction
... should clarify use cases

Matthias: there is a think using dynamic binding
... controlled by another thing
... not just knowledge representatioan
... more explicit to fetch the resource

JinHyeock: what about using anchor?
... link use 2 resources
... is that the case with form?

Matthias: form doesn't express relation

JinHyeock: in that case, they're different

McCool: running out of time?

Matthias: any further important points?

Koster: [Feature of Interest]
... [Thing Description Example]
... iot:isAssociatedWith: {"@id": "@festoPA:FESTO-1", "@type": "iot:LiquidMixingWystem"}
... definition of iotschema for them
... particular type
... annotation is sort of interest
... another patter to building foi
... foi is kind of haystack concept
... door, window, etc.
... more sense to define foi using triples
... we have some discussion
... that was the last point
... any questions?


Matthias: tx!

remote+ Ege_Korkan, Jan_Lauinger, Michael_Koster

McCool: object linking and semantic linking

TD Lifecycle, versioning, and new terms (Sebastian)

Sebastian: TD versioning and lifecycle
... also extensions for TD templates definitions
... [Versioning]
... add optional version term as container to manage the name of the current TD version
... also
... semantic versioning
... version number respecting a set of rules and requirments that dectate how version numbers are assigned and incremented
... (shows an example)
... "version": {"td": "V x.y.z", "iot:firmware": "V x.y.z", "iot:hw"...

Matthias: doesn't not mean SSN?
... possibly would have problem since there are already many semantic definitions

Danh: you can see the simple relationship using this?
... you set a rule
... expose an RDF triple with this

Sebastian: this is just an example

Barry: have a couple of comments
... overall experience is negative
... for example, HTTP uses 1.0 for years
... that's the case for many protocols
... just thinking about "versioning" in general
... x.y.z would be too much
... we should be careful

McCool: version of TD spec? or TD instance?

Dave: any semantics with version order?

McCool: should make versioning optional

Sebastian: [Versioning&Lifecycle]
... discussion in Prague
... detailed lifecycle of a Thing
... [Lifecycle Approach (3)]
... design phase or after it
... first version of TD started to be used
... [Lifecycle Approach (4)]
... manufacturing phase, maintenance/update, software/hardware upgrades

Lagally: guidance on how to manage the versions?

Sebastian: maybe some small patch to TDs

Kaz: question about how to manage the relationship between a version number and updated features
... the vendors need to manage/record the relationship, don't they?

McCool: would suggest we make versioning optional

Kaz: yeah
... if this feature is optional and the purpose is letting the manufacturers identify their product updates, that's fine

Sebastian: [Versioning Minor vs. Major]
... (shows examples of versioning)
... remove some properties and add new properties

Matthias: there was discussion yesterday
... versioning not as numbers but some variants

Sebastian: we don't have any documentation about how to manage the changes

(some more discussions about "versioning")

Barry: another question
... how can we identify the compatibility?
... how can we tell whether this TD is compatible with that TD or not

(we'll move a head to another topic)

Sebastian: [Extend TD Template Definition]
... master TD template providing all basic interactions and a huge set of identical Things implement these interactions
... would be beneficial to maintain only the master TD and all the Things would inherit the interactions
... each Thing's TD only extends its individual information or override the master TD's information
... ok to introduce an optional versioning feature?


Lagally: question on template definition
... what do you mean "overwrite master TD"?

Sebastian: anything you don't want from the master TD
... e.g., the name
... can inherit features like Java superclass

Matthias: Lagally means having not only "name" but also "mastername", etc.

Kaz: theoretically this is similar to Kajimoto-san's "@include" feature?

Sebastian: right

Kajimoto: if the term is not "extend" but "include", this is almost the same

Matthias: we need to define what would happen with multiple instances

Kaz: theoretically a Thing can inherit milk capability and coffee capability and become a latte Thing. right :) ?

Matthias: can be some stylesheet

Sebastian: will share the slides later

Taki: wondering about how to authenticate if there is a link to an external TD

Matthias: we need to think about that but basic assumption is something like Web resources

Human-readable fields: label vs name vs title and language maps (Matthias)

Matthias: how to cover different languages?
... shows RFC8288


Matthias: there are 2 fields
... let me show some example

Link: </TheBook/chapter2>;
    rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
    rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

Matthias: the issue here
... should TD include all the possible languages within it?
... or using content management mechanism to identify multiple languages?
... one possibility is keep the language as human-readable tag
... we should talk with the W3C i18n wg
... also JSON-LD WG

Danh: JSON-LD 1.1 already has language tags

Matthias: shows JSON-LD 1.1 draft


Matthias: shows example 39
... do you know how to generate this and relationship with language tags?

  "@context": {
    "ex": "http://example.com/vocab/",
    "@language": "ja",
    "name": { "@id": "ex:name", "@language": null },
    "occupation": { "@id": "ex:occupation" },
    "occupation_en": { "@id": "ex:occupation", "@language": "en" },
    "occupation_cs": { "@id": "ex:occupation", "@language": "cs" }
  "name": "Yagyū Muneyoshi",
  "occupation": "忍者",
  "occupation_en": "Ninja",
  "occupation_cs": "Nindža",

Danh: developer shouldn't need to handle all the details
... can use content negotiation as well

Matthias: are there any implication of using some ontology?
... possibly OLD ontology may have knowledge

Kaz: how to get terms in each language?

Matthias: where those multiple strings come from?
... example 40

  "@context": {
    "occupation": { "@id": "ex:occupation", "@container": "@language" }
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža"

Matthias: should propose how to define multilingual tags using usual JSON-LD 1.1 way?
... shows example 73

  "@context": {
    "vocab": "http://example.com/vocab/",
    "label": {
      "@id": "vocab:label",
      "@container": "@language"
  "@id": "http://example.com/queen",
  "label": {
    "en": "The Queen",
    "de": [ "Die Königin", "Ihre Majestät" ]

Matthias: will create an issue on TD repo
... so that we can continue the discussion

Toru: can omit content negotiation and simply describe multiple languages (e.g., just 2) inline?

Matthias: that's already possible
... and we want nicer mechanism to handle various languages
... using content negotiation
... creating an issue about this
... also another issue about linking

Sebastian: we still need to discuss one more issue about label/name/title

Matthias: shows issue 156

TD issue 156

Matthias: explains the background
... something specific to express the keys?

Sebastian: JSON Schema uses "title"

McCool: can make it optional?

Matthias: maybe I can reach out Henry
... it's quite messy already

Koster: "label" for human-readable information
... "title" is also fine
... we don't really have strong use cases about users' preferance

Dave: any guidance?

Matthias: there is a use case from Mozilla
... how to label this UI?
... add annotation to RDF

Danh: think "name" would be natural

Matthias: let's ask Henry for input

[break until 11:35am]

today's scribe: kaz, danh, lagally, sebastian

<scribe> scribenick: DanhLePhuoc

Morning Session II (Thing Description 2): Format definition in the spec: use JSON Schema, ABNF, ... (by Michael Lagally, Oracle)

This discussion was initiated in plugfest on how to validate TDs

current format is driven examples which leave a lot of room for interpretations

there is no formal validation mechanism so far

scribe: this lead to the request for a formal syntax description
... this will be making the the specs more precise
... we can use two current candidates for defining data formats such as ABNF and JSON-Schema

Dave: JSON-LD and RDF have its own model and also SHACL for that

Matthias: this is for the develop provide TD in purely in JSON
... an ABNF example ....
... JSON-Schema ...
... JSON-Schema is not an RFC yet, but quite stable, and there are several validation tools, .....
... ietf does not pick up,then, W3C can step in....
... JSON-Schema is more readable than ABNF...
... propose to make JSON-Schema as a normative part of TD Spec.....

McCool: it's fine to have JSON-Schema in the spec, but we need a validation to handle it

Kaz: what's status of TD playground, how it is related to this....

McCool: we might need something like test suite to make JSON-Schema version to be compatible with JSON-LD

<kaz> Kaz: also we can talk with the JSON-LD WG guys and ask them for opinions as well

Kaz: ... how about the assertions...

McCool: if we use JSON-Schema, we can pull out the JSON meta in the tool chains

sebastian: we should have a maintenance a mechanism to sync between two...

Matthias: we can take the same way we sync current HTML spec with its ontology counter-part

McCool: the question is should have an appendix for this....

Dave: should we have a vote?
... now we have vote, majority agreed...

<McCool> more importantly, no violent objectors

<kaz> [lunch till 1:40pm]

DanhLePhuoc: how can we the TDs in JSON-Schema into Thing Directory together with other JSON-LD ones?

McCool: that's what we need to do in the next step....

<kaz> scribenick: mlagally

Security Metadata Review - McCool


McCool: review of what we currently have
... security tag can appear at 3 levels, inner levels overwrite the outer levels
... each security configuration has a string based scheme
... scheme is a set of parameters, current validation does not check
... combination of schemes is possible
... 6 supported schemes
... offering different levels of security
... following the schemes of OpenAPI

Nimura: what about IETF ACE?

McCool: not yet covered, will have to cover ACE and OCF variant of that, MQTT, probably PSK

Lagally: your example shows a proxy security scheme as part of the TD. Does the thing need to know about the proxy
... yes, there may be also multiple routes to the thing. thing should know how it can be reached
... some things can be applied to multiple protocols
... some may need additional parameters for different protocols
... chains of proxies or parallel proxies are still an open issue
... we have fine grained security for each form, often repeating security configurations
... ... example of an extension point (blockchain)
... we need to test this mechanism
... perhaps all schemes should be included via extension points

Barry: how does it work with two baked in http based schemes baked in and two external ones
... basic would still be baked in
... you could bake in the context

McCool: perhaps we should include http vocabulary in JSON
... currently we have this multi-level override mechanism
... replicating information with the override scheme
... some disadvantages
... overriding is not JSON-LD like
... you could have an array of security configurations and reference them in a form
... perhaps make security tag mandatory and permit "scheme" "none"

Matthias: I would not worry about size, since JSON uses a lot of space anyway
... better see if author explcitly disables security

McCool: I prefer default value, however it should be "none"

Barry: I agree with mk - sending a few hundred bytes is not an issue

McCool: your default value cannot be a fixed value, depends on the scheme

Nimura: if none is explicit, it exposes a vulnerability

Barry: there's no big difference between "none" and not having security

McCool: validation tools should flag security sensitive issues
... should we separate security definition at the top and just use the name in the form?
... array of string or just a simple string

Lagally: would security definition still permit override mechanism, this is orthogonal

McCool: yes, we could have both

Lagally: what is the use case for override

McCool: exceptions, e.g. admin and regular users

Lagally: you could solve via admin-TD and user-TD

<discussion about machine generated vs manually written TD>

Kajimoto: introduce vulnerability by including security?

McCool: security by obscurity is not a good idea
... telling people the exact SW version of security stack could be problematic
... we could have internal version or external version

Danh: <inaudible>

McCool: ... protocol handshake identifies the supported security mechanism

Danh: some form may have just a read but no write data - can you describe that?

McCool: in Oauth you may have different permissions / access rights
... often you see read only or r/w access
... ACE has similar mechanism
... HTTP basic has realms that allow to give differnt roles to admins and users
... this is similar to ACLs
... we decided that roles are hard to define. This could be done via extensions
... we're not doing it in the base
... next step I'll come up with a proposal

Dave: how to get hands-on experience

McCool: we can do a PR for a full fleshed out version


<victor> https://github.com/w3c/wot-thing-description/blob/master/td-core-model/td-v0.2.2.PNG

Discussion about the TD Model

Koster: interaction property should not be a subclass but an instance

Victor: we don't agree if the meaning of the class is a schema
... it is aligned with the way how schemas work
... property definitions and value definitions

Sebastian: why some classes without relations

Matthias: this comes from schema.org, related to property value, i.e. semantically compatible
... this modeling is in-line with schema.org
... input and output defintions are compatible with value definitions of schema.org?

Sebastian: also specified in the ontology definitions?

Victor: different options - "subclass" or "related" relationship

Matthias: I prefer weak dependency from schema.org

Sebastian: if I look at ontology file, no schema.org definition?

Matthias: yes

Koster: tradeoff between decoupling data fragment and ?
... why subclass and not instance of?

Victor: this is just a piece of data
... an instance of the class property is one single thing with a value
... input is different from an invoke action
... instance validates against a schema
... schema for validation is an instance of data specification or data schema

Koster: does that make it a subclass?

Victor: no

Koster: value is not instance of a schema

Victor: it cannot be described in RDF terms

Matthias: the property node is not an instance, but a class

Danh: why separate classes

Victor: distinguish between unique properties and specifications of these properties

Danh: why you want to distinguish?

Matthias: you may have a value to read out, but action does not have data, when the thing is described

Dave: digital twin is a software object, you cannot instantiate it

Matthias: if there's an action, there's no representation to that

Dave: why does this matter?

Matthias: you get inconsistencies in the RDF world

TK: data field has a name, but data specification is a type. that's a clear distinction
... there needs to be a relationship between these two

Matthias: data value of a property and calling an action creates relation
... Victor fixed the model to address Maria's concerns

McCool: are we good, is this just informational?
... yes, but we want to get everyone on the same page

Dave: property values change over time

Danh: this new class wants to bridge

Matthias: properties some JSON schema, actions too

McCool: I would only cache values, not states

Danh: a subclass of data schema, can have property and subproperty

Victor: you have direct elation, can infer it
... I inferred name data schema from
... it really matters when we start semantic annotations
... action input of temperature would be a mistake, since we cannot get a value

Koster: it acts on a property

<dsr> I am unconvinced and think we don’t share the same assumptions.

Koster: I want to see what Maria says to the schema

Matthias: the reason for dataschema is that we used the term before
... we could start renaming it, perhaps dataor thing data

Koster: I like dataschema

Matthias: then we have to rename data value and data specification
... subclassOf relatino sdoes not make sense for Maria

<dsr> surely, we need to include data values for action input and output, and to have a predicate that links the data value to the dataschema

Danh: I think property can be direct subclass of data schema

Victor: we have the same properties and fields - they should be disjoint
... we would duplicate these fields

Danh: data filed and data value have disjoint content?

Victor: yes

McCool: an action can change a property
... might be a hidden property

Danh: only vocabulary with strong semantics is from OW

<kaz> scribenick: mlagally_

<mlagally_> <long discussion between danh and VC>

<dsr> I would model this differently, separating properties from values, then we can model action input and out in the same way and use a predicate that applies the data schema to values

<zolkis> I wonder wouldn't it be simpler to have DataSchema at Action (input & output) level, and DataValue that extends DataSchema?

<Zakim> dape, you wanted to minor issue/question: why does DataFragmentOrSchema not have class "Null"... even tough "Null" would be empty

Daniel: do we have a null class also?

Victor: yes

Daniel: we have a similar question in the scripting group too

<kaz> scribenick: kaz

Zoltan: I wonder wouldn't it be simpler to have DataSchema at Action (input & output) level, and DataValue that extends DataSchema?

<kaz> scribenick: mlagally_

Matthias: data value and data specification are different - both are derived from data schema

Victor: this is relevant for semantic annotations

Koster: individual data values are part of an action.

Victor: relationship is not in the core model, it is in the schema
... property is a subclass of some placeholder, which is data value.
... should be aligned with iotschema

Dave: time does matter, between it affects sequence of measurements
... this model is misleading

Matthias: you don't have the model of time

Dave: property describes only value at one time

Matthias: there's one more indirection

Victor: TD does not have temporal aspects

Dave: we need more explanation

<dsr> For me, the semantic story is about things having properties which have values that change over time and in principle, you could annotate the value at a particular time or time interval, e.g. that a given sensor reading at a particular time is bad (perhaps due to a power glitch).

<dsr> We thus should distinguish properties from values rather than stating that a property is a subclass of a data value

<dsr> It would help if we had a more detailed explanation so that we can be sure we’re talking about the same thing

<dsr> It would be helpful if we had an explanation of the schema.org approach and what we’re trying to do in aligning thing descriptions with that approach

<kaz> scribenick: kaz

McCool: we're out of time

Kaz: how to proceed?
... continue the discussion during the TD call, main call or an additional call?

<kaz> scribenick: mlagally_

Matthias: needs to be processed with more examples, SSN really to be shown, different layers to be shown

Lagally: it would help tremendously to have clear diagram semantics, i.e. know what an arrow means, what it means if there's an isolated box

<kaz> [break till 4pm]

Review of the API, issues, alignment with the TD spec (Nimura-san + remote Zoltan/Daniel)

<sebastian> scribenick: sebastian

Zoltan shows some slides

there are some issues in the current editor draft


one of them are naming related

renaming such as get-->read, set --> write

some names has conflicts such as 'required', 'const' etc

WebIDL use the same terms

request that TD spec do not use-conflicting names

McCool suggest mapping

Daniel: this would not work in some cases
... in out implementation we using handlers

McCool: Suggestion to use [] implemention instead . (dot) approach would solve the issue

Matthias: Dont see any conflicts. Just tested it in node-wot.

Zoltan: Maybe only works in node-wot, however, in other implementation not.

Sebastian: terms are from JSON Schema, we are not able to rename it

Daniel: regarding " [] vs . " JSON Schema follows the [] approach
... is worried to get apart between Scripting API and TD

Matthias: prefers the "." since you have code completion, syntax highlighting, etc

McCool: Is there maybe a lib where we can simple forward JSON Schema object?

Zoltan: we have to check this

Daniel: in that case we would end up what is not standardized

Dave: is this topic addressed by other groups?

Zoltan: don't know

<kaz> kaz: have we talked with TAG about this?

<kaz> zk: can talk with Marcos again

Matthias: Suggest to generate the WebIDL similar in the TD spec

Zoltan: suggest to have different documents. E.g., one document for implementators in coding style

Daniel: suggest to do this in same manner like in the TD spec such as for JSON Schema


<currently no slides in the meeting room>

Matthias: do not know what the alternatives are

<dape> https://github.com/w3c/wot-scripting-api/issues/126


next topic: Imlementation feedback

<kaz> issue 125

Matthias shows some code from node-wot

<kaz> and explains ThingFragment interface

<kaz> and ThingInstance as well

Matthias: explains how the Property is implemented

Daniel: there are conflicts with the get and set methods. We should use read and write again.

<McCool> my comment: all else being equal, I prefer read and write as they are easier to distinguish. As for conflicts, we need to check all runtime contexts (eg browser and node.js)

Matthias: shows a sample script how a TD is consumed and used

Zoltan: Has questions about the naming such as fragment.

Matthias: fragment is used for software object
... there are templates that is only a snippet of a TD

<dape> https://w3c.github.io/wot-scripting-api/#dfn-thingproperty

<McCool> i think "fragment" is a useful name that captures the intended idea very well

<McCool> and allows usages that are not tied to the lifecycle like Init or Template do

Daniel: there is a issue that methods overwrite the get method

<McCool> Zoltan: get and set don't conflit ct with getter

<McCool> ... but read and write avoid confusion

<McCool> Matthias: just a naming issues

<McCool> Koster: I had to mentally map, would like names to match protocol binding

<McCool> Zoltan: get and set usually local

<McCool> Koster: I was thinking of treating them as higher-level things

There are some discussions about git/set vs read/write

There is the tendency to stick with get/set and invoke.

Implementation feedback

Matthias shows how events are implemented in node-wot

Zoltan: we support different variants for the Events: It can be one function or three functions (such as used in subscribe method of node-wot).

<dape> node-wot code on the Eclipse GitHub repo

Matthias: the basic structure of the implementaion is already pushed to the master

<mkovatsc> https://github.com/thingweb/wot-typescript-definitions

wot-type-definitions are independent from node-wot and should belong to W3C.

<kaz> kaz: can talk with PLH and Antonio about that

Kaz will ask internally how to handle this.

<kaz> [w3.org or npm]

<mkovatsc> https://www.npmjs.com/org/w3c

have to be clearified for the src and npm

<zkis> https://rawgit.com/zolkis/wot-scripting-api/master/index.html

next topic: API handlers

Zoltan: there is the question if the handlers should have the same name as the basic methods that are specified in the scripting API?

e.g., setPropertyReadHandler

Matthias: prefers to overwrite them

next topic: emitEvent()

Zoltan ask for some opinion about this current definition

Matthias shows how it is implemented in node-wot

there is the opportunity to setup a filter and during the subscription there can be 3 functions be used: next, error, and complete

there are some discussion about the filtering

this approuch also allows server side filtering

Zoltan: Why we still have observable option in Property?

MKoster: There is coap and mqtt that allows kind of req./res + make subscription on the ressource

Test suite for Scripting?

McCool: Ask if Zoltan is available tomorrow?

Zoltan: not available

McCool: We need a plan for a test suite.
... Shall we have the discussion tomorrow afternoon?

Zoltan: How to evaluate the Scripting API?

Matthias: how the browser vendor handle this?

Discussion about tomorrow's agenda

test topics are moved to the afternoon session

Zoltan: concludes scripting session
... it is clear what are the next steps

Matthias: emitEvent should be moved to ThingEvent

<zolkis> also, there should be separate ConsumedThingEvent that has on() method and ExposedThingEvent that has emit() method.

end of day

WoT f2f - Admin Day
05 Jul 2018


Michael_Koster(remote), Zoltan_Kis, kaji, toru, yama, taki, tou, sano, nimura, tomo, matsu, lagally, wonsuk, dsr, mmc, seba, matt, kaz, Daniel(remote), Ege(remote)
Matthias, McCool, Kajimoto
kaz, taki

<kaz> scribenick: kaz


Matthias: charter extension and new charter

<kajimoto> 3 month extended depending on JSON-LD1.1 finalization

McCool: my ac rep interested in how to adapt wot to industry
... business plan expand to community

<kajimoto> And 1 more plugfest will be set up until RC

McCool: we can brainstorm it
... [Recharter Brainstorming
... would like to see business engagement

Matthias: long list we discussed in Prague
... [WG]
... (making the fonts bigger)

(brainstorming based on the slide)

Matthias: I see Thing Directory

<kajimoto> Matthias: presenting on WG issues

Matthias: how to apply/build real applications
... product instance

McCool: thing directory is higher priority

Matthias: it's more guideline work
... maybe also this outreach could be done by the IG
... WG for next building blocks
... we need to discuss more
... how it works

McCool: reasonable to include hypermedia pattenrs, action description, etc.
... can publish vocabulary
... for security, new protocol binding

Dave: maybe IG could stretch the target?

McCool: how to get community on board
... justification for thing directory
... figure out showcases
... easier to do so by showcasing

Lagally: interoperability promise of wot
... can show some slides on my idea
... maybe in 20mins

Dave: McCool, what you say is compatible what I think

Barry: drawing new companies is important

McCool: people are interested in high-level interoperability

Matthias: e.g., ericsson working on LWM2M and interested in WoT
... basic resource directory mechanism, etc.
... lookup capability restricted so far
... if this mechanism could be incorporated, would be very useful

McCool: some more companies

Matthias: some companies have patent issue

Dave: we could have a look at ETSI ISG CIM

McCool: also use cases like smart city
... background like Industry 4.0

Matthias: also AC reps mentions possibility of smart city, building, ...
... CG working on Charter
... possible liaison on smart city with ETSI ISG CIM

McCool: smart city is very broad
... smart home, smart city might be candidates

Matthias: should put effort to IG again and build liaison

McCool: showcasing semantic stuff

Lagally: vertical specific vocabulary
... one thing
... real demonstration
... if you have real product with concrete company name, would be great

McCool: vocabulary would make sense
... collaboration with another WG
... would motivate further work for WoT
... and then that group would get more interested
... collaboration done at the group forming phase

Matthias: new slide [Scoping]

Koster: different from semantic annotation?

McCool: more focused on vertical-dependent vocabulary

Koster: let's bring that into iotschema

McCool: not suggesting to create another competiter
... iotschema is in my mind

Dave: ETSI as well

McCool: right

Koster: we're generating a new Charter for the CG

McCool: what would be the best way?

Matthias: we need to build more concrete system
... we have to finish our work
... and look into multi stakeholders
... for them to refine their model
... (shows Linked Building Data CG)
... iotschema is horizontal
... and we have vertical-dependent industries

McCool: interested in documenting iot testbed
... haystack

Matthias: adds topics to IG scope

Kajimoto: Echonet is one possible candidate

McCool: right
... maybe they can use iotschema
... and model for Echonet devices
... Echonet is relatively smaller than others, so good starting point

Kajimoto: there are many sensors
... so good for iotschema terminologies

McCool: would convince OCF as well

Koster: collaboration by IG?

Matthias: we're thinking about that

McCool: may have particular organizations

Matthias: we start to talk about multi-stakeholder demo
... with vertical aspect
... and collaboration with other orgs
... if this is fine for everybody
... list of other orgs is useful

Koster: would totally support
... growing ecosystem by bigger demo would be good

McCool: not jsut connecting bunch of devices
... semantic capability is important
... services are based on semantics
... other non-iot ecosystem is also important

Barry: talking about iot device
... everything is part of iot

McCool: you can wot for services

Koster: accessibility scenario

McCool: semantic markup calendar

Koster: sunrise and sunset, etc.
... how to communicate with events

Barry: regarding smart home
... (describes some use case)

McCool: broader resource management for smart city

Barry: system automatically comprise
... smart thermostat

McCool: web simulation for things
... at large scale
... requires privacy consideration

Koster: we can create vocabulary by IG

McCool: reasonable collaboration

Matthias: nice discussion on what could be done
... on the IG side
... and regarding the WG side
... what to do in clear
... Thing Directory
... lifecycle management and servient IFs
... and what?

McCool: security guidelines
... e.g., for smart city

Matthias: maybe we're missing something?
... security can be updated with WG Note process

McCool: do you have a secure runtime?

Matthias: runtime must be secure

McCool: manufactures trust their actual devices
... what about (possible) untrusted third-party applications?

Koster: system-level policy?
... really hard to have guilelines for third party applications

Dave: what are the technical pieces

McCool: interested in some use cases

Dave: even for industry use cases, people are interested in applications

McCool: certain verticals to be prioritize?

Koster: actual policy is hard to standardize

McCool: we should based on browser policy
... for today, let's do doable ones, e.g., smart home

Koster: what to be added to the Charter?

McCool: new protocol?

Koster: new structure which accommodate more industry verticals

McCool: new interactions

Koster: entity description

McCool: new interactions for binding?

Dave: extension for scripting?

McCool: maintenance and update for scripting?

Koster: extension point is important

McCool: some extension point would be useful

Matthias: a bit worried with having more action points
... should nail down what's the problem
... adds maintenance topic which includes:
... binding templates
... security vocabulary

Lagally: sometimes you can add tweaks
... we need to accommodate people and may provide some wrapper

Dave: maintenance is ok but what would be the new topics?

Matthias: we've been discussing some topics
... type systems, etc.

McCool: two examples of binary background
... Echonet and BACnet

Matthias: some mechanism for vocabulary and payload

Koster: transformation language make sense
... maybe zigbee as well
... possible another candidate

McCool: type system issue on binary data

Koster: guess part of binding

McCool: schema for binary payload

Matthias: we have modbus
... first 3bits mean some and next 7bits mean another

Toru: annotate schema

Koster: semantic markup by iotschema

McCool: can we prototype existing mechanisms?

Matthias: JSON schema has some mechanism
... integer defined some meaning
... (shows prev list for WG)

McCool: proxies?

Matthias: it depends on what a servient does
... what should be the part of registration, etc., to be shown by the vertical demo

McCool: how to hook up and translate industry-specific data

Matthias: what a proxy needs to do?

Koster: maybe some protocol questions for proxy

McCool: manager thing
... maybe under lifecycle management

Matthias: should they be a deliverable?
... synchronization of servients

Koster: architecture sections would make sense

Matthias: how much learning for architecture?
... companies may want to deal with that

McCool: standardized proxy interface

Matthias: nice part of web technology is layered system

McCool: more about network api
... w\device talk to

Matthias: that's rather part of management?
... register and re-expose

McCool: ok
... lifecycle management can include proxy interface

Matthias: matsukura-san, what do you think?

rm: interoperability with other companies would be important

Kaz: what about stronger collaboration with browser vendors
... and I/Fs with browsers
... maybe for IG scope
... but possible tech discussion for WG
... we need to think about that

Wonsuk: scripting api could provide good IF for browsers?
... there could be some suggestion
... some possible library for WoT for browsers
... some company may provide a WoT-ready browser

Kaz: one possibility is ACCESS from Japan

Dave: WoT provides additional capabilities to browsers

McCool: for example, speech services
... one thing we should do is convincing people to differentiate technology
... maybe Mozilla might be a candidate
... need to convince them

Wonsuk: KaiOS uses Mozilla WebOS as the basis
... that's a smartphone
... if all the browser vendors could support scripting api natively, that would be perfect
... but could start with scripting api
... and would get feedback from industries

Matthias: think that would be a good strategy
... but how to make them engaged?
... wondering what would be the good strategy
... how to get people involved

Kaz: what about possible open/public plugfest as a hackathon?

McCool: maybe we ourselves join communities and let them participate

Wonsuk: yesterday, we discussed message format
... make sense to have broader industry requirements

McCool: need of web apps
... recent work on Web Assembly

Matthias: personally think too early

McCool: stick with JS is fine
... but might want to look into smaller node

Kaz: we can have joint discussion with Web ASM WG during TPAC

McCool: wondering about typescript as well

Matthias: (updates the list for WG)
... we had discussion on WoT mediatypes
... interaction description
... what mediatype means
... we haven't have understanding yet

McCool: main issue is time
... need to mature the specs first

Matthias: mechanisms beyond our mission

McCool: if we leave it out, how to accommodate various industries?

(Barry leaves)

Barry: calls in next week?

Matthias: would skip calls next week

Koster: a lot of things we can do
... how to re-expose existing capabilities

McCool: using webhooks?

Koster: a lot of systems use webhooks
... like OCF

Matthias: (changes the color of Hypermedir pattern, action pattern, event pattern)
... (adds "need entity description mechanism in current spec")

Koster: need to finalize documents by the end of extended charter first

Matthias: the question here
... what is the good extension point?
... one decision point
... specific mediatype for TD
... application/wot?
... one for TD and another for the other part?

Koster: we already have some within our examples

Matthias: simplified TD, you don't need states
... mediatype for property is application/td
... mediatype is the general type mechanism

Dave: should have some JSON example

McCool: service can b a Thing

Koster: entity description could be part of Thing

McCool: we have addtype

Matthias: we can reuse the mechanism
... we should consider to have some different mediatype

Koster: the question is whether we want to include semantics or not

[break till 11:20am]

WoT adoption - Michael Lagally


Lagally: [Driving WoT adoption]
... demonstrate WoT interoperability across products for different domains
... home, industry, etc.
... [Home integration scenario]
... monitor room occupancy (KETI)
... detect when room is empty
... close window blinds (Fujitsu)
... clean the room (Panasonic)
... stop air conditioner (Panasonic)
... MQTT devices (Siemens)
... lights (smartthings)
... etc.
... [Industrial integration scenario]
... monitor environment condition in multiple locations (KETI)
... discover anomaly, critical condition
... drain the tank in a chemical factory (Siemens)
... etc.
... [Integraiton with existing standards]
... demonstrate bridge scenarios with certified products from
... OCF, Echonet, OPC-UA, oneM2M
... presenting these slides for brainstorming
... promote WoT for TPAC

McCool: a bit worried about cross-domain demo
... maybe would be better to focus on some specific domain
... our use case on simulation of smart house
... I know OCF and OPC-UA
... in terms of scenario
... we should stick to end-user use cases
... combine many devices to provide some service
... use case you showed yesterday on calendar integration is useful
... technical components for use case scenario
... definition of use case scenario on what the users see

Lagally: agree
... and some integration scenario here

McCool: what the overall scenario?

Kaz: good components here
... we might want to have some concrete story based on this
... e.g., voice detection to open the entrance door

McCool: yes, some concrete script
... e.g., we can think about some simulator scenario

Lagally: actually, would like to think about simulator case later

McCool: we can have many OCF devices at once
... we should look more data model for OCF devices
... and can simulate all of them using WoT
... I can buy OCF-based air conditioner

Lagally: the scenario is not limited

Dave: btw, is this a possible scenario for TPAC?

Lagally: yes

Dave: in that case, the scenario should be clearer given those who are not sure about WoT

McCool: if we can have actual hardware, that's great
... but we may start with simulator

Matthias: some concrete product with logo would be useful

McCool: right


McCool: 3 things for IIC liaison
... 1. engaging testbeds
... using WoT for testbeds
... 2. get requirements/feedback
... next step to get concrete liaison contact
... myself to be the rep for IIC liaison
... 3. security review
... email to be sent around
... Intel is a member of both IIC and W3C
... who else?

Lagally: Oracle

Taki: Fujitsu

toumura: Hitachi

McCool: interested in collaboration
... similar organization is openfog
... IIC is a bit broader
... also IoT institution
... security aspect
... more manufacture viewpoint
... framework is broad enough
... suggest we leave some topics out

Dave: would see what they expect

McCool: don't need to worry
... testbed scenario, etc.
... interested in future things
... OCF, we had f2f last time
... one of the ways
... testbeds
... OCF device scenario
... including Echonet devices and BACnet devices

<dsr> It would be desirable to identify what IIC expect from W3C for IIC to decide to incorporate WoT into their testbeds.

McCool: need more proof points
... OCF is looking at extensions
... health care, institution for smart building
... smart building just started
... we can help them
... have a good footprint for smart building

Koster: zigbee-ocf gateway could be also
... OCF has a lot of potential

McCool: many in the pipe
... pushing things to the pipe
... by the end of year, would expect some product

Lagally: 13 in the pipe

Koster: protocol binding for HUE light, etc.?
... and OCF devices

Lagally: you could buy some OCF certificated products

Koster: hook up for winkers

McCool: good example Intel management framework
... these devices have web api
... trouble is that web api is not standardized yet
... the other large category
... Amazon, Google, etc.

Koster: working on LWM2M
... not only commercial products
... could be another candidate

McCool: working with IIC and OCF
... do you know recent activity between oneM2M and others?

Koster: not really aware

McCool: we should be engaged with SDOs

Koster: we could get more engagement
... OMA

McCool: 2 standards recently get
... Echonet and OPC
... how interested in joint testbed?

Koster: Echonet themselves generate standards?

McCool: you can get their standards from the Web

Toru: at the moment, what already published is in-house communication
... global connection is under work

McCool: the point is what currently published is not the whole story

Koster: relationship with other SDOs

Toru: they have a plan to publish updated Web APIs
... maybe in some months

McCool: should be compatible with TD

Toru: need collaboration

McCool: reasonable target
... the other one is OPC-UA
... smart building stuff
... official liaison with W3C?

Dave: yes

McCool: what about Echonet?

Kaz: originally with the MMI WG
... and they're holding discussion to switch it to WoT

McCool: OPC-UA involved in Induustry 4.0

Lagally: some other alignment?

McCool: smart building, smart city by Siemens, etc., and other SDO's ones

Dave: main problem with liaison
... sometimes request reviews
... progress of those reviews

McCool: would propose we focus on testbeds

Dave: some companies should be committed

Matthias: sometimes attended, e.g., OPC meetings
... many hardware vendors there

McCool: many pieces to be done on the application layer
... IIC would make sense
... rather than some standalone testbed

Dave: some small set for collaboration?

McCool: first of all we should talk with them to see what to be done for the testbed
... Dave and McCool to talk with their test group?

Dave: we talked about multi-vendor demo
... plugging into their systems
... no idea at this point

Kaz: and regarding Echonet, maybe Kaz and Toru-san (or somebody from Echonet) to work together
... they're still searching for an updated contact

McCool: if we bridge only 2 ecosystems, not very interested
... if we have 3, may be interesting
... and if 4, would be very interesting
... any comments?

Toru: liaison with JTC1 SC41?

McCool: pinged by Intel rep
... trying to think who to contact
... some univ members
... IoT vocabulary
... iot.schema.org is another possibility

Kaz: Prof. Tamura also is working for ISO and might want to have some discussion on the ISO side

McCool: Koster, any ideas?

Koster: engage verticals
... creating vocabulary would make sense
... lineup of TD

McCool: if people want to work on vocabulary with ISO
... might be a conflict with ISO standards

Kaz: there is PAS program between W3C and ISO
... so there is a possibility TD, etc., would become an ISO standard at some point

McCool: that was my point as well
... kind of worried about vocabulary at the moment

Toru: for the future, we could avoid overlap
... not only ISO but also ITU-T, etc.

McCool: should work jointly and avoid overlap
... e.g., we should let them know we're working on TD and will be shipping shortly
... (checking the schedule)
... break for lunch?

Matthias: updated the agenda

updated agenda for today

Matthias: lunch break till 1pm?

McCool: fine

[lunch till 1pm]



McCool: [Overview]
... progress
... asssertion extraction
... tool running
... [Normative Assertions: Markup Example]
... RFC2119 terminology
... to indicate assertions
... (shows HTML code)

<taki> ScribeNick: taki

McCool showing normative assersions examples

McCool: create list of assertions

McCool showing assertion extraction example...

McCool: no need to worry about synchronization.
... there is limitation. I am going to improve it.

Dave: There were some related tools.

McCool: I need command line tool.
... PR was already created.
... I need to carefully merge.
... Join based on ID...
... I only did TD spec.
... I am going to put the tool under wot repo.

McCool showing TD validation...

McCool: TD validation gives useful feedback.

<dsr> I could provide some help with a node based tool as part of my F-Interop funded work - this could for instance use an HTML5 parser to traverse the DOM

McCool: We need to go through every assertion.
... To make sure the tool works properly.

Sebastian: Content is generated automatically.

McCool: extension points...
... how does it work.
... Integrate external vocabulary.
... Schema that does not allow extension.
... give TD url, and gives feedback.

<dsr> Another idea is to write a script to mutate valid TDs to generate a comprehensive test set of invalid TDs

McCool: Ege is working on it.

Sebastian: example.com, this you cannot validate.

McCool: we need an example of validation.
... encourage iotschema.org to do grammar checking.
... online testing goals.
... validation suite. get report, whether things are correct or not.
... online service or commandline.
... we need online demonstration system.
... demonstration system needs use case.
... online integration testing.
... things in central place.

Dave: two servienets. two coordiator.
... using scripting api, connected to test suite.

McCool: open source and closed source tool.

Dave: use AMQP.
... the plan is to demonstrate at TPAC.

McCool: first test plan.

Kaz: if F-Interop is useful, that would be great, but we should think about that separately from our own test plan first..

McCool: right. our test framework should be independent from other frameworks. Let's discuss in test plan.
... Security testing.
... test system and purpose is to see I'd agree with McCool. if it is possible to secure things.
... reasonable to break into system.
... try to show all known attacks fail
... lean heavily on best practices.
... http certificates test.
... ssl server service, try to break into that.
... testing apis.
... servient is a server.

Nimura: what is pen test?

McCool: penetration.
... need to mark up specifications.
... test planing document
... test vocabulary, protocols, extension points.
... test each deliverable
... each TF takes care of the test
... ege has thing network interface test
... we need to putline test document
... we should schedule next call

Kajimoto: validation and demonstration separation is good

Kaz: two weeks no telecon call.
... week of 23rd, resume calls.

McCool: need to send an announcement about that to the groups

Next steps, TPAC and beyond

Matthias: roadmap.
... what's after tpac?
... f2f after tpac.
... one more f2f.
... make an appointment for online test.

McCool: test planning document, will be worked on next 2 weeks.
... validation suite is easy to run
... four things up there.

Matthias: we need deadline.

McCool: integration testing should be before tpac
... collaboration between systems.
... functional testing and interop testing
... interop test can derive from plugfest
... for demo, online physical things.

Matthias: concrete deafline.

McCool: test plan needs dealine. TPAC
... framework should be in place.

Toru: panasonic has online simulator.

McCool: needs examples. low level functional testing.
... dock container, test cases, testing.
... then also use simulator
... need to detect network interfaces.
... you can use tunnel.
... docker image, download bunary, and can run it.

Dave: scripting api.

McCool: testing document, make sure we have it.

<kaz> Kaz: meaning a possible group Note? or just some document on GitHub?

McCool: usually we don't publish testing document as a group Note.

McCool: wot repo is IG repo.
... we can create wot test repo
... now we have test dir under each project

Wonsuk: can we use W3C framework?

McCool: we are not only testing browser

Kaz: I thought ACCESS was interested in automotive platform test framework.

McCool: if it exists, we can use it.
... browser is not our primary target

Wonsuk: automotive spec defines interfaces.
... message is in json format.

McCool: going back to tpac.
... what other groups should we meet

web auth, html local, automotive, ...

McCool: web security is a generic group

Matthias: organize TPAC.
... outrach building data model.

we mentioned i18n as well

Matthias: f2f meeting after tpac.

McCool: about extension?

Matthias: Kaz, can you explaiin

Kaz: three months extension could simply pass in w3c.

Dave: management needs to see we are on track.

McCool: Ege, can you update?
... testing framework

Sebastian: I will integrate outcomes.

Matthias: correct ontology
... events, filter arguments

Sebastian: I will also fix bugs.

Next steps for each TF


Sebastian: end of july.

Matthias: end of july. release WD
... fix bugs and add PSK scheme

Sebastian: 20 July, resume TD call
... next step, integrate version field, input/output media type, etc.

Dave: "rel"?

Sebastian: let's first see what's defined already.

Matthias: generic rel can be defined.

Sebastian: TD model discussion continue.
... JSON schema in the spec.
... label, name, title issue is also not resolved.
... MQTT stuff
... TD model modularization.
... We need feedback from Mozilla.

McCool: we can invite mozilla to plugfest.

Matthias: TD context file is optional. we plan to do modularizaton

Legally: we need to discuss template.
... one thing and two TDs. we need to discuss this.

Toru: WD is public WD?

Matthias: It is gonna be 3rd WD
... TD WD last published April 5.

Toru: where can I find those documents?
... I visited WG page, and I could only foud links to documents.

<kaz> Kaz: sorry but the WG page should be also updated if needed


Matthias: Binding templates TF
... new Note?

Koster: I need to incorporate new patterns
... end of july

Matthias: you will attend IETF

Koster: next call will be 24th

McCool: CoAP security insights are welcome.

Matthias: we need client certificate.
... MQTT binding is described.
... sub-protocol vocabulary

McCool: How to import multiple modularized vocabularies/context files


Matthias: Scripting API TF

Zoltan: two weeks after TD is finalized
... mid-Auguest.

Matthias: 14 Aug

Daniel: do we integrate the outcome of yesterday discussion?

MK explaining what will go in...

Matthias: new extension, we should not.

Zoltan is explaining his understanding of yesterday's outcome...

Zoltan: next call 23rd.
... we go through issues. we have many.
... normative languages.

McCool: each assertion will be given an identifier.

Zoltan: API simplification
... Solve issue with dictionaries from external specs.

Daniel: webIDL vs Typescript.

Zoltan: we need to collect real-world script examples.

McCool: we need to think about scenarios.

Zoltan: collect scripts and feedback


Matthias: Security TF

McCool: Security consideration note update by end of July.
... industry use case and validation are missing.
... Recommendation document will be ready by TPAC
... industrial use case will be ready by TPAC
... security vocabulary for CoAP and MQTT ready by TPAC.


Testing Task Force

McCool: First draft done one month before TPAC
... Next call 25 july
... see list in McCool's presentation

<kaz> -> link tbd for MM's slides@@@

[Online PlugFest]

Online PlugFest

McCool: we can allocate two days.
... virtual F2F.
... we can allocate VPN somewhere.

Matthias: 3 Sep or 24 Sep are condidates.

McCool: 3 Sep is holiday in US

Matthias: 4 Sep is ok?

Koster: Yes

Kajimoto: 24 Sep is a holiday in Japan

McCool: two sequential days is possible for me.

Matthias: we can have two or three of those.

McCool: VPN.
... we need to check with F-interop.

Matthias: TPAC 2018
... PlugFest possibly at Lyon University.
... Charter extension. Short slides for W3M.
... Re-chartering. Need to have scope well defined.
... meet with JSON-LD WG and I18N WG

McCool: also with WebAuth WG
... automotive WG?

Wonsuk: interfaces to get vehicle information. this will be Candidate REC this year.
... it does not have datamodel. it is being done in GENIVI alliance.
... we have Volkswagen. They are using RESTful communication.
... WebSocket, RESTful. We support both.
... we need unified solution.
... For deployment, we need solid datamodel.

Matthias: We can start looking at RESTful interface.

Wonsuk: automotive WG does not have RESTful interface WD yet.

McCool: WoT WG and Automotive WG can work together.

<kaz> Kaz: my understanding is that VW proposal is using HTTP REST connection basically and use websocket for server push notification

<kaz> Wonsuk: right

<kaz> McCool: similar to Mozilla then

Spring 2019 F2F Meeting

Matthias: Keio university is a candidate.
... TPAC 2019 will be in Fukuoka, Japan
... Other candidates are UK, Sophia Antipolis (ETSI), and Munich (Siemens)

WoT Test Bench Presentation


Ege: motivation
... thing consumer. human.
... thing developer can test each time new functionality is added.
... testing every interaction
... test scenario, each interaction is tested.
... in different order, with different input data
... repetition
... testbench is available.
... configuration is optional.
... provide TD, and test is started.
... when the test is done, report is generated.
... configurations are properties.
... it is available in GitHub.
... here is the link.

McCool: backchannel can trigger events
... F-Interop uses AMQP backchannel.
... to trigger events
... We are going to explore this.
... We will discuss in next testing call
... Testbench is running?

Ege: you can download from GitHub and use it.

Kaz: note on the possible VPN server for online plugfest
... We should not depend on servers hosted by other organizations due to stabilities and IP/privacy reasons

McCool: I will look into OpenVPN

Matthias: Thank you everyone.

Wrapping up

scribenick: kaz

Matthias: goes through the discussions
... still many things to do
... but overall quite happy with transition to simple TD, etc.

McCool:> that was a painful decision but we're getting better

Dave: we need nice test suites for CR

Kaz: when we'll resume the testing call?
... July 25?

McCool: guess so but will confirm

Matthias: ok
... have a safe trip back
... hear you in 2 weeks!

<kaz> [f2f adjourned]

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/07/31 23:57:24 $