Group photo from the WoT F2F Meeting in Bundang on June 30-July 5
(Some more photos are available online.)
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
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
... http://192.168.1.25
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
... http://192.168.1.25/right{?p,d}
... 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://192.168.1.187:1883/lightSensor
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
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
... http://192.168.1.241:8000/api...
... 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
Lagally: 4 TD files
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",
]]
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"],
]]
Sano: not specifically changed from Prague
Sano: updated the TD
Fujitsu-RotalyBeaconLight.jsonld
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
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
[[
"base": "http://10.0.0.23/api/b5q6DpQiIp6lAbc4TTv4PNd0w7pPJyrDfV0tBx9m/",
]]
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
Koster: using "id": "urn:uuid:2d5e84f6-85c9-4436-b53f-c0669dfd1603",
mj: ok
Sebastian: remotely accessible?
Koster: light TD is remotely accessible
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]
scribenick: kaz
<kaz> W3C Patent Policy
<kaz> Patent Policy FAQ
<kajimoto> Kaz: W3C Patent Policy explanation session
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
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
<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
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 …
<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
speaker: Soumya Kanti Datta
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
<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
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
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
<dsr> intro to GraphQL https://dzone.com/storage/assets/6811883-dzone-rc249-graphql-10-03-2017.pdf
Youngmin: (shows the demo)
Danh: topology?
Youngmin: can show you
-> preparation.md tbd@@@
-> 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
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
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.
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
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
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
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]
<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
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
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
[break until 10:45]
<taki> scribe: TK
<taki> scribeNick: taki
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...
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.
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.
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
<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.
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
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)
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
<kaz> scribenick: kawaguch
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
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]
<kaz> scribenick: kaz
Koster:[Links]
... 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?
(none)
Matthias: tx!
remote+ Ege_Korkan, Jan_Lauinger, Michael_Koster
McCool: object linking and semantic linking
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?
(fine)
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
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,
</TheBook/chapter4>;
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
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
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
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]
<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
thanks
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.
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
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
<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]
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
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
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.
[TD]
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
[Binding]
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
[Scripting]
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
[Security]
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]
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
Matthias: Keio university is a
candidate.
... TPAC 2019 will be in Fukuoka, Japan
... Other candidates are UK, Sophia Antipolis (ETSI), and
Munich (Siemens)
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.
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]
