WoT WG/IG F2F meeting in Dusseldorf

9-13 July 2017

group photo

(Some more photos are available online.)


Summary of Action Items

Summary of Resolutions

9 July 2017


Matthias_Kovatsch(Siemens), Victor_Charpenay(Siemens), Christian_Glomb(Siemens), Sebastian_Käbisch(Siemens), Darko_Anicic(Siemens), Linoel_Médini(University_of_Lyon), Daniel_Peintner_Siemens), Yoshiaki_Ohsumi(Panasonic), Kazuo_Kajimoto(Panasonic), Katsuyoshi_Naka(Panasonic), Masato_Ohura(Panasonic), Keiichi_Tokuyama(Panasonic), Takeshi_Yamada_Panasonic), Uday_Davuluru(lemonbeat), Benjamin_Piepiora(lemonbeat), Dennis_Knake(lemonbeat), Michael_McCool_Intel), Michael_Koster(SmartThings/Samsung_Research), Ryuichi_Matsukura_Fujitsu), Kazuaki_Nimura_Fujitsu), Tomoaki_Mizushima_Internet_Research_Institute), Kunihiko_Toumura_Hitachi), Takuki_Kamiya(Fujitsu), Kazuyuki_Ashimura(W3C), Soumya_Kanti_Datta(Eurecom), Benjamin_Klotz(Eurecom), Jiye_Park(University_of_Duisburg-Essen), Luca_Roffia(University_of_Bologna), Fabio_Viola(University_of_Bologna), Francesco_Antoniazzi(University_of_Bologna), Daniel_Wilms(BMW)
Matthias, McCool, Kajimoto

Meeting Logs

PlugFest preparation

plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep plugfest prep

PlugFest presentation

Siemens & Univ. Lyon - Scripting

plugfest pitch plugfest pitch

sk: explains the summary

mk: explains the procedure
... cross-domain/vendor interoperability
... difficulties with mappings

da: [TD repository]
... [Thing Description with Semantic Annotations]
... [How-To]
... step 1-4
... step1: include WoT common context in TD "@context"
... step5: discover a Thing
... (clicks the link of http://plugfest.thingweb.io:8081/td-lookup/sem?query=YOUR_ENCODED_QUERY)
... (clicks the link of http://plugfest.thingweb.io:8081/td-lookup/sem?text="Temperature"
... [Sum-Up]


plugfest pitch

da: TD repository
... More details on GitHub (github.com/thingweb/...)


plugfest pitch

sk: small automation scenario
... node wot scripting
... local system connected by CoAP
... node WoT to integrate different devices
... temperature sensor still not working

mk: new version of TD
... need cross-vendor testing
... data types to be understood
... would clarify what is working and what is not


plugfest pitch

lm: new version of SSN and TD


plugfest pitch

mo: will show a demo having many devices in Osaka
... lights, air conditioner, etc.
... [Panaonic Demo System Configuration]
... use Amazon Echo for speech input
... control devices in Osaka
... using a command


plugfest pitch

nk: [WoT Scripting API Implementation]
... scripting API provides abtract API of things, and enables developers to implement apps based on WoT

Univ. of Bologna

plugfest pitch

lr: our vision proposing a solution to interoperability problems
... proposed architecture named "SEPA" (SPARQL Event Processing Architecture)
... 3 different contexts
... cards, colors and users
... context manager handles those 3 contexts
... this is our research topic
... explanation on SEPA, PAC pattern, SPARQL 1.1 Secure Event Protocol


plugfest pitch

bp: : a water tap and a sensor


plugfest pitch

bk: BMW demo


plugfest pitch

mm: OCF demo
... CoAP-based
... REST APIs as well
... the goal is not translating each OCF device
... but translating all the OCF world
... starting with motion sensor
... (shows TD example dynamically generated by an OCF device)

[Mr. Ohsumi and Daniel join]

mm: whole bunch of stuff here
... 10 devices included
... (clicks on of the links)
... gasSensor

ud: how to proceed
... people come to each table

[ break ]

Discussions between PlugFest Teams

plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion plugfest discussion

[Taki joins]

Summary and logistics for tomorrow

mk: we'll have demo tomorrow
... how/when to give the wrap-up?


plugfest summary plugfest summary plugfest summary plugfest summary

mk: gives quick summary on testing things
... error handling as well

sk: connected to lemonbeat device
... shows scripting part as well
... also typical network issues
... with node wot

lm: semantic annotation

da: what kind of Things are available?
... you need discovery
... how would you find Things to connect to?
... so discovery is important


plugfest summary

kn: Panasonic demo
... also Darko's discovery
... trying Matthias's device
... issue with security server
... will try tomorrow again

mk: need to describe security mechanism
... accessing token, etc.
... what to do with HTTPS?
... will work on the issues
... how to model this for TD?

plugfest summary


plugfest summary

kn: need to think about online testing for better use of time
... performance test as well

mk: demo is a specific use case
... component test and combining test


plugfest summary

<inserted> ud: mentions lemonbeat demo

ud: next step would be automatic connection


plugfest summary

dw: it was interesting to see the current status. made progress in understanding the context better

Univ. Bologna

plugfest summary

lr: semantic web and IoT
... semantics is also important
... security and privacy
... not clear yet

mk: most of the participants come from protocol level
... how to automate interaction between various devices based on semantics
... loose coupling
... possibly handy query language
... would be a library for all the implementers
... to make it easier for developers
... what kind of tools are needed?
... input would be helpful


plugfest summary

mm: OCF mapping
... what is missing?


plugfest wrap-up

sk: would be good to have even nicer setting for preparation
... to have enough time for actual PlugFest

(question on how to organize PlugFest prep. and PlugFest demo)

mk: fully agree
... could have more discussions beforehand
... for tests as well
... e.g., dedicated online meetings for PlugFest preparation

[ PlugFest Day ends ]

10 July 2017


Lindsay_Frost(NEC_Europe), Kaz_Ashimura(W3C), Kazuo_Kajimoto(Panasonic), Masato_Ohura(Panasonic), Takeshi_Yamada_Panasonic), Katsuyoshi_Naka(Panasonic), Keiichi_Tokuyama(Panasonic), Yoshiaki_Ohsumi(Panasonic), Stefan_Schmidt(Bosch), Kazumasa_Okabe(Yahoo!_JAPAN), Kenichi_Kuromusha(Yahoo!_JAPAN), Kazuaki_Nimura_Fujitsu), Ryuichi_Matsukura_Fujitsu), Kunihiko_Toumura_Hitachi), Daniel_Wilms(BMW) Tomoaki_Mizushima_Internet_Research_Institute), Tobias_Kaefer(FZI), Michael_McCool(Intel), Eric_Eggert(W3C), Uday_Davuluru(lemonbeat), Darko_Anicic(Siemens), Jens_Reinelt(Lemonbeat), Gina_Strodal(Lemonbeat), Benjamin_Piepiora(lemonbeat), Guido_Vogel(Lemonbeat), Frank_Reusch(Lemonbeat), Lionel_Medini(Univ._Lyon), Benjamin_Klotz(Eurecom), Michael_Koster(SmartThings/Samsung_Research), Christian_Glomb(Siemens), Victor_Charpenay(Siemens), Sebastian_Käbisch(Siemens), Daniel_Peintner_Siemens), Takuki_Kamiya(Fujitsu), Soumya_Kanti_Datta(Eurecom), Matthias_Kovatsch(Siemens), Jiye_Park(University_of_Duisburg-Essen), Dave_Raggett(W3C), Joan-Carlos_Zuniga(Sigfox), Oliver_van_der_Mord(Lemonbeat), Francesco_Antoniazzi(University_of_Bologna), Fabio_Viola(University_of_Bologna), Luca_Roffia(University_of_Bologna),
Yongjing, Yingying
Matthias, McCool, Kajimoto
kaz, dsr

Meeting Logs

Greeting from Lemonbeat


<kaz> scribenick: kaz

oliver: CEO of lemonbeat
... happy to host this event

oliver: [The Lemonbeat GMBH]
... origin is smart home
... happy to contribute to IoT space
... would introduce Andreas

Keynote speech - DESIGNEZ, Toolbox Energy-Transition-from individual solutions towards an efficient...


andreas: [BMWi* Funding programme]
... 2 step approach: sketching and actual project
... [The 5 "SINTEG" showcases]
... [know-how for the region]
... we can cover all the energy transitions
... high-load areas, medium-load areas and low-load areas
... combining 3 different areas
... getting funding
... [Experienced partners from on of the economically strongest regions in Germany]
... 31 project partners, 15 associated partners
... [The energy system becomes more distributed and complex]
... in the past - in the future
... [The distribution network - Backbone of the energy transition]
... EHV - HV - MV - LV
... more than 90% of the renewable energy systems are fed into the German distibution network
... [Sokutions which ensure that the region actually benefits from the energy transition]
... huge infrastructure
... self-learning by AI
... out of experience
... [Designets integrates individual solutions from various sectors]
... overall system, e-mobility, intelligent grid, digitization, distributed generation, flexible industry
... no standard protocol yet
... standardization would be very helpful
... [Just ike DNA in cells, our lemonbeat software stack with our LsDL empowers each device]
... offer flexibility and get flexibility from the market
... [We make the energy transition easy to grasp with the "ENERGY ROUTE"
... demonstrators come alive
... signage of demonstrators along the "energy route"
... access to demonstrators, "showrooms", events and open-house days
... combination of different projects
... sector coupling for different energy transitions
... [Five answers]
... our motivation, our goal, our approach, our path, our showcase
... need to be neutral to various vendors
... tx!
... questions?

lindsay: web protocol working so far?

and: lemonbeat implementations?

scribe: yes, there are

dsr: electric car is one challenge, and...

and: e-mobility massively effects our infrastructure

scribe: shift the systems
... 2 opportunities
... challenge is renewing the end
... huge tech problems
... e.g., voltage drops
... infrastructure like cables
... using IoT compensate usual consumpation

mk: how many different protocols/standards are there?

and: can share my feeling :)

scribe: the solution provides flexibility
... heat pump, heating system, water system, etc.
... not based on standards so far
... there are different manufacturers
... using different protocols
... standard interface would help interaction
... if you want please follow the slides and contact me
... tx!


uday: meeting followed by a social event in the evening
... city tour and dinner
... looking forward good discussions

W3C Patent Policy for WG discussion


<dsr> scribenick: dsr

Kaz Ashimura (W3C) introduces the W3C Patent Policy and its implications for our work.

W3C advances specifictions through 5 steps from an initial Working Draft to the final Recommendation (W3C’s term for its standards)

W3C Recommendations must be available to implement on a royalty free basis.

You are encouraged to join the Working Group if you haven’t done so already, and to make the corresponding licensing commitments.

The WG Chairs can invite guests to WG meetings, however, we need to be aware about potential IPR issues that could arise from contributions from people who are not formally part of the WG.

Kaz shows the important points from the W3C Patent Policy document

When contributions are being considered for inclusion in a document intended to become a W3C Recommendation, the WG Chairs should ask the contributor to disclose any essential claims that they would not be able to provide royalty free licenses as per the W3C Patent Policy

Kaz lists the managed repositories relevant to the WoiT WG

If the WG is unable to secure licensing for essential claims under the W3C Patent Policy, the Chairs should endeavor to steer around the concerned technical aspects.

Iotschema.org and semantic interoperability


Michael Koster (SmartThings/Samsung) presents.

There are many standards organisations, and these have taken their own approach, and in some cases are competing with each other.

The approach we’re taking is to enable semantic interoperability at the application layer

We’re looking at well known formats to describe how applications can interact with things.

We’re adapting the patterns from schema.org that were developed for smart search results, and combining this with other ontologies and vocabularies.

We want to do this in an open process that doesn’t require formal membership of a standards development organisation..

Contributions based upon either the W3C Community Group or the schema.org frameworks

Michael presents a semantic stack model

This has the ontologies at the top, the web of things in the middle, and specific IoT standards suites at the bottom

We want to enable a means to abstract capabilities, e.g. motion sensing, turning something on and off and so forth.

Actuation may be incremental, e.g. light levels and colours rather than simply on and off

Michael describes how the iotschema,org capability pattern relates to the web of things.

Essentially a capability is mapped to an interaction pattern with its associated properties, actions and events.

Michael shows a JSON based representation of an example capability

We’ve done some initial work to prepare a charter. We hold monthly teleconferences and we’re about to apply the charter to the W3C Web of Things Community Group.

We plan to use the CC-SA license for contributions.

Collaboration with the W3C WoT IG and WG

We’re aiming to collaborate with other organisations to enable re-use of existing ontologies

Work on factoring out differences across ontologies, semantic annotations and support for composing services.

Zoltan: I really like the notion of capabilities

Michael: At Smart things, we have had several years experience with capabilities

Capabilities also help with security

<zkis> capabilities could be used as funcionality units for permissions and policies

Capabillities are building blocks for things and not for use on their own

We don’t need to express capabilities directly in thing descriptions, but rather to use them to describe relationships between things and capabilities

Stefan: is this approach already accepted by schema.org ?

Michael: that’s an interesting question. We’re really at an early stage where we are working on a proposal that we want schema.org to take on board

Matthias: in the Web of things, we want to model the physical world. We need to relate the interaction model to the physical capabilities

Dave: we need to recognise that different communities will develop different vocabularies, so we need bridging ontologies that allow search using shared concepts rather than having to use the different terms for each of the different vocabularies

Lindsay: ETSI is also working in this area. The problem of relating different models can be likened to the parts of an iceberg that is under the water - it is very much larger and risks sinking the ship of interoperability

Philipp Hoschka: what is the relationship betweeen schema.org and W3C?

Tobias: how do you exploit these descriptions in applications?

Michael: the combinations of these different kinds of descriptions can be used to support discovery, composition and adaptation by smart services

The Web works because it is simple, much simpler than some of the older ideas for hypermedia

We want to make it easier for people to innovate and contribute new ideas

The protocol binding for the web of things maps the abstract models to the concrete protocols

We want to avoid the complexity of the Semantic Web and make life easier for regular developers.

Michael_McCool: there is a risk of alienating developers if we don’t do a good job on that.

Kajimoto-san: one challenge is what things call themselves, another is who owns the things.

Michael: we need a means to describe the interaction model and also a means to describe the relationships between things at a semantic level

There is a lot of other categories we need to look at including security policies

Luca: we should exploit the work that has been done for the Semantic Web, why aren’t we using RDF rather than JSON?

Michael: we trying to use the framework of RDF but to avoid the need for developers to first become semantic web experts

We have some choices to explore for this

Dave: we need to keep distinct the serialisations from the underlying framework.


LP-WANs with SigFox


Presented by Juan Carlos Zuniga (Sigfox)

Juan introduces Sigfox. This is a company that focuses on low power wide area connectivity for IoT devices.

Key goals include low cost and low data rates

Sigfox is a connectivity provider that builds and operates the network with regional SNO operators

We charge for connecting devices to the Internet

Sigfox can be applied to a wide variety of domains, including assisted living, home alarms, smoke detectors, precision agriculture, tracking moving assets.

5 main business benefits.

Sigfox coverage in the USA, South America, Europe, South Africa, Japan and Australia

Sigfox is designed to scale to very large numbers of devices,

The sigfox foundation supports applications such as tracking protected species like rhino’s

Sigfox uses ultra narrow band and frequency hopping.

This relies on software defined radio technology, also know as cognitive radio

Messages are sent with multiple copies in different frequencies

Uplink messages have 12 byte payload, downlink 8 bytes

Up to 6 messages uplink per hour and 4 messages downlink

After sending, the device listens for a reply in a short window of time

Devices spend most of their time asleep with negligible power drain, allowing for years of battery operation.

Devices are pre-provisioned with their credentials. Standard APIs are provided for accessing data on common cloud platforms.

Keen on standards based interoperability.

Collaborative approach to security, and design for privacy

SCHC - static context header compression for sigfox and LoRa from LPWAN WG

Demos of IPv6/CoAP over LPWAN

Interoperability at the application layer - demos for IETF

Privacy focused on explicit personally identifiable information

Example: if a trash bin is used, you know that someone is in the house.

Proactive privacy by design principles.

Resilience to botnets and tempered with devices - blocking and blacklisting capabilities in the cloud

Different levels of security according to the criticality and type of application.

Michael_Koster: what do you mean by device autonomy?

Juan: devices can talk whenever they want, there is no need to synchronise clocks etc.

some discussion around IPv6 via header compression

<scribe> On-going work on layering CoAP on top of this.

We’re looking at supporting message fragmentation and reassembly

Matthias provides some additional context

Juan: our cloud APIs provide metadata that comes from the cloud for the device, but is not held on the device

IETF work as a collaboration across several technology groups, e.g. sigfox, LoRa and 2 others

Darko: what format are you using for metadata and how is it managed?

Juan: right now every device maker does their own thing. We are seeking ways to converge. We’re not pushing on a single approach, but want to encourge convergence

Introduction to the BIG IoT EU project


Presented by Stefan Schmid (Bosch).

The project started 18 months ago and is half way through

The project name is an acronym for bridging the interoperability gap of the Internet of Things

See: http://big-iot.eu/project/

Photo of busy city street with cars, trams and pedestrians, and many kind of IoT devices

Each of the IoT systems form independent silos

The objective is to enable interoperability across these silos

We want to foster and incentivize collaboration via a marketplace of services

The marketplace includes support for monetizing services.

The marketplace is aimed at developers not end users

Example for a smart parking service where street sensors report which spaces are not in use

This could involve a mix of technologies and communication standards

We need to support evolution of services and technologies. How can we enable applications to take advantage of new capabilities?

Service providers and consumers with authentication, registration, discovery, subscription and accounting

The service offering description specifies the access control policy

We use JSON-LD for the descriptions, based upon the work by the W3C Web of Things IG

Stefan talks us through the different kinds of information in the description.

We provide a simple API that abstracts away from the details of the underlying platform.

We can provide a gateway service for accessing non Big-IoT platforms.

Likewise, we support proxies when it isn’t appropriate for apps to directly access devices.

Big-IoT is working witg Eclipse IoT for our open source strategy

We plan to contribute semantic models to schema.org

We expect to very soon have approval from Eclipse for our proposed open source project.

Demo of the smart parking service in Barcelona

Stefan talks us through how a company could add its parking lot to the service.

You can query for parking space providers within a given radius of a given location.

A new provider needs to register its offering with the marketplace

This involves customizing some Java code …

The end user app shows available places and pays for the parking charge.

Juan: do you see a single market or multiple marketplaces?

Stefan: many marketplaces, first because of the amount of data, and secondly due to regional and domain specific variations of requirements

Kaz: are you interested in a standard API for payments from web browsers for web based applications?

Stefan: this is a research project with limited resources. There are many options for commercialising our work.

Philipp_Hoschka talks about the Compose EU project which also worked on marketplaces for IoT services.

Stefan notes there are already many IoT marketplaces.

Matthias: how did you survey the developers for the marketplace requirements?

Stefan: we learned that different developers prefer different programming languages, and that Java isn’t a universal solution.

<kaz> [ break ]

Context Information Management and Privacy - Lindsay Frost (ETSI ISG CIM/NEC Europe)


<kaz> scribenick: kaz

Lindsay: charing ETSI ISC CIM
... experience is very diverse
... [Audience Calibration: Hands up who knows of ...]
... SF book of "1984" and "Future Shock"
... also "Shockwave Rider"
... and then "General Data Protection Regulation" by EU Parliament
... starting in May 2018
... smart city/parking would require much private data
... companies are not good at this kind of regulations
... organization in breach of GDPR can be fined up to 4% of annual global revenue or 20M Euro
... [Audience Calibration: Hands up who knows of ...]
... manipulating genes
... changing DNA structure
... whole bunch of scratch pads
... like RFID embedded in cells
... [cell genome "recording of event histories"]
... transilation for "1984" and wiki-leaks readers
... cell genome could be made to inpact "your" cells...
... [Outline of this talk]
... ETSI ISG work
... main work is how to make exchange semantic data
... how to interpret it
... what would happen government set requirements for smart city trials?
... [Digital Transformation for Wellington, New Zealand]
... half as NEC and half as ETSI
... measuring the quality of city
... how to improve comfort order
... sensing overcloud, etc.
... using video data, etc.
... tracking people
... [Digital Transformation for Christchurch, New Zealand]
... traffic jams
... tracking number of people
... [Smart Cities ... and standards]
... [Standards help all stakeholders]
... Standards help
... voluntary/dynamic
... creates an ecosystem of experts
... reduce risks
... governments/citizens need to ference standards
... issues with execution risks, cost explosions, obsolescence, privacy, physical risks and liability
... have to worry how to record provenance
... need to know about your data
... license, quality, freshness, etc.
... [IoT-related SDOs & Fora: "Formal" overview]
... De Jure: ITU-T, ITU-R, ISO/IEC ETSI, ...

De Facto: W3C, oneM2M, ...

McCool: OCF as well

Lindsay: [Smart City related Groups in ETSI]
... ISG CIM (Context Information Management)
... oneM2M here in the middle of the picture
... IoT systems are annotated
... problem from me is having a lot of stakeholders
... [Currently >300 EU IoT/SmartCity RnD projects]
... examples of A-B
... all those working on IoT and APIs
... [Work Item Scopes of ETSI ISG CIM]
... 6 different work items
... https://portal.etsi.org/tb.aspx?tbid=i54&SubTB=854
... ontology to describe information model
... no. 7 is security and privacy
... [Privacy Issues and Exploring Solution ...]
... [ETSI ISG CIM: Problem space and solution space]
... mind map
... goo.gl/1zFPRz
... [Context Information Management: Issues]
... enlarged mind map
... what kind of identifiers to use?
... privacy by design is a hot topic
... need to have some usage data
... what if including privacy information?
... [Context Information Management: Privacy]
... you can find these by visiting goo.gl/1zFPRz
... using blockchain to secure the data
... serialization of the data
... possible attack, e.g., by undermining
... de sur SDOs here
... ISO/IEC 27550
... OASIS PMRMv1.0
... ISO/IEC 20547-4
... etc.
... [Links]
... [Help on ETSI ISG CIM Discussion Issues]
... 1. requirements for exchange of cross-cutting context information, to be fit for purpose in Smart Cities, S,art Agriculture and Smart Industry use cases
... 2. How to ensure ISG CIM API is flexible to cope with all desirable types of context data and instance data
... 3. Requirements for ISG CIM API to express the important kinds of queries for heterogeneous databases of context information for cross-cutting domains
... 4. Managing the identifier(s) for entities and referencing them in API queries, even across legacy databases
... Ensuring privacy protection (fine-grained access control, encryption) on specific context data, efficiently!
... different identifiers based on various stakeholders
... most of the systems are walled garden
... usually not available by external parties
... [How to help]
... Ask an expert on any of the 5 Discussion Issues to contact me
... Download the CIM-mindmap goo.gl/1zFPRz and suggest to me your additions
... Email me about other events/organizations which I should contact
... Recommend to your organization to join ETSI iSG CIM
... thank you!

Koster: question@@@

Binding the Web of Things with LwM2M for a vehicular use case - Benjamin Klotz (EURECOM)


Benjamin: [Goals]
... Interest of WoT
... integrate data from the vehicle with external knowledge bases
... adds a semantic enrichment layer
... can be linke with the work of the W3C AUtomotive WG (and GENIVI)
... [General architecture and parts]
... WoT Servient on the left side
... OEM cloud on the right side
... HTTP between them
... and CoAP between cloud and car
... [Protocol binding: LwM2M]
... WoT methods -(Python snippet)- HTTP methods -(Leshan API)- LwM2M methods
... [Demo setup]
... OBD dongle
... browser as a WoT client
... OEM cloud
... connected using HTTP
... protocol binding and finding the device
... [Thing description: context]
... need: sensor/actuator ontology, car ontology
... w3c-wot-td-context.jsonld
... w3c-wot-common-context.jsonld
... schema.org
... linked version of GENIVI's VSS
... [TD retrieval and parsing]
... the TD file is stored in the dame repo as the WoT server
... [Thing description: sequence diagram]
... changed from yesterday
... discovery -> consume TD -> read speed
... communication among browser, WoT server and LwM2M API
... [WoT communication]
... WoT server: python script with Flask
... WoT client
... [Final interface]
... API
... endpoint/consumed
... [Conclusion and future work]
... challenges faced
... remote access to vehicle data
... protocol binding between WoT and LwM2M
... link between W3C WoT and W3C Automotive
... future work
... questions?

McCool: translation to TD?
... automatically?

Benjamin: hand coded

kaz: using VISS or VIAS from the W3C Automotive?

Benjamin: VSS as the data model

Lindsay: subscribe the data?

Benjamin: can subscribe or get data at once as well

[ Everybody moves to the parking lot to see the demo]

[ PlugFest Day ends and everybody leaves for the social event ]

11 July 2017


Kaz_Ashimura(W3C), Lindsay_Frost(NEC_Europe), Kazuo_Kajimoto(Panasonic), Takeshi_Yamada_Panasonic), Katsuyoshi_Naka(Panasonic), Ryuichi_Matsukura_Fujitsu), Kazuaki_Nimura_Fujitsu), Keiichi_Tokuyama(Panasonic), Masato_Ohura(Panasonic), Michael_McCool(Intel), Soumya_Kanti_Datta(Eurecom), Tomoaki_Mizushima(Internet_Research_Institute), Kunihiko_Toumura_Hitachi), Uday_Davuluru(lemonbeat), Kazumasa_Okabe(Yahoo!_JAPAN), Kenichi_Kuromusha(Yahoo!_JAPAN), Philipp_Hoschka(W3C), Stefan_Schmidt(Bosch), Christian_Glomb(Siemens), Victor_Charpenay(Siemens), Darko_Anicic(Siemens), Sebastian_Käbisch(Siemens), Daniel_Peintner_Siemens), Takuki_Kamiya(Fujitsu), Jiye_Park(University_of_Duisburg-Essen), Dave_Raggett(W3C), Michael_Koster(SmartThings/Samsung_Research), Matthias_Kovatsch(Siemens)
Carsten_Bormann(TZI), Zoltan_Kis(Intel), Niklas_Widell(Ericsson)
Matthias, McCool, Kajimoto
kaz, mjkoster, dsr, uday

Meeting Logs

<inserted> scribenick: kaz

Tech welcome

mk: welcome to the 3rd meeting of the WG!
... would remind you of the W3C Patent Policy for the WG work as Kaz mentioned yesterday


mk: you need to become an official WG participant to make contribution
... we're taking minutes on IRC
... please help minutes taking

dsr: microphones are available

Agenda Bashing

Agenda wiki

mk: agenda bashing
... would like to start with Mozilla's contribution
... they've just made a Member submission
... after the morning break
... TD serialization
... open-source strategy
... won't go into the detail but the proposed agenda is available online

mm: maybe short summarization from the Osaka meeting?

mk: good to repeat what we discussed in Osaka
... we should talk together
... we go for single slots this time
... and then Day2
... security use cases/scenarios
... security next steps

dsr: can contribute to serialization today and data types tomorrow

mk: data types
... Victor?
... status, etc.

victor: maybe shorter than 1h?

mk: and the last day, Jul 13th
... security, Elena will join remotely

mm: threat model, etc.
... would like more input
... online questionnaire

<inserted> scribenick: mjkoster

mccool: has a questionnaire for security requirements

please fill out in preparation for the meetings this week

<inserted> scribenick: kaz

mk: please give your input
... next LD
... and in the afternoon, marketing topics
... and then modularization of TF work

kaz: planning session?

mk: right. TPAC, security conf., etc.

mm: for next year

mk: will talk with McCool offline as well

Mozilla's submission



mk: would impact our work

mm: important to consider this
... and other input from Members
... this proposal is descriptive
... here we do action, event, etc.
... need gateway and other things
... our work is different
... we should take this proposal seriously and think about the pros/cons

mk: let's look at this
... would have much more fruitful discussion from this
... could be discussed during TPAC as well
... straight description on what they want
... ideas on a possible default binding

mm: could be a default HTTP binding

koster: this is a concrete API

dsr: agree inviting them to give talk on this
... very similar with what I'm proposing

seb: 80% of this proposal is copied from what we've been doing
... related to the serialization discussion
... almost aligned with what we've been doing since 2 years ago
... this is a JSON approach

mk: this shows developers' hypothesis
... kind of JSON serialization option

mm: need some tweaks

mk: let's look at this


mm: this is descriptive
... they're doing exposing thing

mk: we do both expose/consume
... they're doing another side of consuming

mm: they're using only expose, so simple

mk: if you look at "actions" here...



"actions": {

"reboot": {

"description": "Reboot the device"




mk: there is no detail on how to handle this yet
... it's a draft

dsr: good to have their proposal

mk: want to go through this


mk: goes through 2.5-
... 3. Web Thing REST API
... defining resource type

Thing resource

scribe: example in JSON

mm: there is a "links" section
... shouldn't be in the example

koster: design in progress

mk: individual URIs and fragments to be concatenated
... 3.2 Property resource


mk: doesn't really comply

seba: our approach is just using name-value pair

mk: would see RFC@@
... there are so many different IoT platforms

json interchange rfc

mk: we kind of got stuck with actions

mm: they have concrete idea

koster: expressing some intention we should look at this
... to see what the main idea is

mm: scripting API
... you could expose different APIs
... and this could be a default API
... we already had discussion when we generated the Charter

mk: network API could be REST API

mm: not conflicting

mk: identify actions and retrieve them

mm: websocket is another option

mk: there is websocket proposal as well
... goes down
... 3.4 Events resource

koster: our concept of "events" is a bit different

mk: 3.5 Things resource
... 3.6 Alternative Protocol Bindings


scribe: 4. Web Thing WebSocket API


mk: easy coupling between the server and the client
... need to talk about protocols for various vendors, though
... how to open WebSocket, etc.
... establishing connection
... 4.2 setProperty message


mk: here you have socket connection
... and 4.3 requestAction message


scribe: then 4.4 addEventSubscription


scribe: 4.7 event message


mk: equivalent to the REST API
... wouldn't go deeper here
... 5. Web Thing Types


mm: simple built-in vocabulary

mk: 5.4 Extensibility with JSON-LD


<dsr> Dave: we should also consider this from the perspective of what would be needed from a thing description to support the Mozilla IoT platform, given that the web of things needs to support a very broad range of IoT platforms

mm: having simple default Web API
... mentions OCF approach
... RAML and Swagger
... Swagger more momentum these days

mk: RAML and Swagger are tightly coupled to what the server is offering
... the key is loose-coupling

koster: big plus

mk: how should JSON serialization should be?
... concise and developer friendly way
... so that we can convert it to another serialization
... we saw a parameter of "actions" here
... there are patterns of property, action and event
... may need some interaction pattern

dsr: we have metadata for TD
... we have to live with driver model given existing various devices
... simple interaction model
... TD just has minimal information for drivers

mk: you can't model that simple interaction model

lindsay: do you plan to enforce some guideline?
... setting actions and write parameters, etc.

mk: there is a device with some property
... the other thing has reset button, etc.
... think about interaction between them
... layering on top of discussion yesterday

victor: this is already modeled
... e.g., for building automation services
... action on some property
... equivalent to changing property

mm: we need response from Mozilla

<mjkoster> victor: modeled in SAREF

mm: how to integrate with our document

mk: we have good questions about this proposal
... it's a complicated theme

mm: having an analysis would be good

mk: we'll have activity on JSON serialization
... and see gaps
... this is another IoT platform which we (WoT) would like to describe
... any other opinions?

mm: the other possibility is defining a simple default
... simple descriptive definition

mk: we won't create yet another standard
... our description should be easily mapped

mm: there is a definition on eventing
... could be a hybrid way

<dsr> mm: we should seek to make it really easy to provide a thing description for their platform.

kaz: this proposal is about interface between component, e.g., servient A and sevient B, with our context

mk: they don't have servient, so maybe gateway and client possibly

kaz: let's invite them to our telcos and TPAC f2f, etc.

<inserted> next

<inserted> mk: summarizes the discussion and defines the nest step

RESOLUTION: next step is (1) draft response to them by Thursday, (2) get JSON serialization TF which compare/integrate/extend Mozilla's proposal, (3) have a joint call with them and (4) invite them to TPAC
... go through possible responses on Thursday and let's invite them


Serialization - Daniel

Daniel's Slides

Carsten's Slides

dp: [TD Serialization test-bed]
... on github: github.com/w3c/wot-thing-description/tree/master/test-bed
... started to collect data from various sources: WoT CP document, PlugFests, SDO mappings
... [Measurements Osaka PlugFest]
... shows graph including the data serialization variations: JSON, CBOR, SMIL, EXI4JSON
... [Measurements Dusseldorf PlugFest]
... [Outlook]
... how can we improve even further?
... [Optimized JSON-LD Example]
... shows an example

(got a trouble with screen sharing...)

victor: devices are deployed somewhere not owned

carsten: shows his slides

<McCool> McCool: ways to reduce size: standard fields in fixed order; defaults; query parameters on API to get td (eg include semantic tagging only if asked)

carsten: [Objectives]

<McCool> McCool: regarding very small devices (eg SigFox) - might be best to return a simple identifier (eg a URL) rather than a TD; we want a TD to describe how to talk to small devices, but those devices don't necessarily need to generate or consume TDs themselves

carsten: represent TD information
... what do we want optimize? - compactness/usefulness for processing?

<McCool> McCool; BTW, defaults and multiple serializations also lead us to one possible way to align with the Mozilla/Evrything "prescriptive" network apis

carsten: what are our assumptions about the devices - holding TDs?
... [Maximizing compactness]
... use traditional data compression
... e.g., deflate, LZ77
... need some memory for decompression

<McCool> McCool: eg one particular choice of serialization (and the defaults in that serialization...) could end up looking a lot like the Mozilla proposal... but still could be serialized in a more explicit, expanded serialization that make all the default values explicit could still be available.

carsten: [Choosing a compressor]
... LZ77: sharing via <distance, length>
... need entropy encoder too
... classical algorithms: deflate (LZ77+Huffman), LZ4 (low complexity)
... [Maximizing processability]
... [Experiment]
... wot-thing-description/test-bed/data/plugfest/2017-05-osaka/MyLED_f.sonld
... JSON file: 3116
... JSON withoug whitespace: 1447
... deflate: 323, lz4: 415, lz4hc: 411
... CBOR: 1210
... deflate: 325, lz4: 416, lz4hc: 404
... CBOR packed (semantic sharing only): 793
... CBOR packd (prefix compression, too): 564
... 2 steps
... semantic sharin gonl vs prefix compression as well
... [Conclusion]
... packing (exploiting structural sharing)
... maintains processability, saves 1/3 (implementation not yet complete)
... prefix sharing helps with URLs, another 20%
... but reduces processability
... could further improve by adding static dictionary?
... in the example: 119 bytes of mostly static data
... name, type, links, application/json, outputData, mediaType, href, etc.

dp: ideas we can share
... get rid of static data
... different ways to achieve it
... questions?

mm: 3000 characters reduced

(Carsten goes back to [Experiment])

carsten: yes

mk: would go for easy processing, e.g., CBOR, EXI

seba: deflate-based compression would be useless, I think
... quite heavy to install on small devices
... what can be the maximum compression ratio is not the best question
... need some more clarification how it works

mk: TD includes set of property, action, event
... same way of having a dictionary

dsr: could do compression on Arduino, etc.
... but keeping battery down

dp: you need more memory for data without compression
... processing may be ok
... on a powerful device, it's worth trying

mk: we have deep dive on JSON and CBOR
... Mozilla proposal also mentioned JSON serialization

seba: what is the next step?

mk: we can collect examples
... people can present like Carsten too
... size of the representation, compression ratio, ability/usefulness, etc.

dp: which data should be used as the basis?

dsr: have some material on GitHub

mm: can do the discussion offline

mk: let's put the items on a short list

Open-Source Strategy


zk: [WoT WG deliverables]
... normative specs: WoT Arch, TD, Scripting, Test cases
... [Implementation(s) as Deliverables]
... WG Charter says under "Success Criteria"
... requirement for implementation experience
... [W3C Software...]
... [node-wot]
... should node-wot be a WG oss implementation?
... if yes, need to apply W3C license

mk: we've been contacting eclipse as well
... open source management in general
... possibly on eclipse foundation with W3C license
... we need 2 implementations anyway to make specs RECs

mm: do we need a resolution?
... implementation deliverable

dsr: proposed resolution given not all of the participants are here

kaz: also suggested that to McCool

mk: do we need to update our Charter?

dsr: don't think so

kaz: agree

zk: also talked with Anssi about this
... and the Chair can make decision

mm: the Chairs would recommend to make the wot-node implementation a deliverable of the WoT WG

Web of Things - Dave


dsr: [Developer Feedback]
... startups and SMEs
... [Current Practices]
... TD based on JSON-LD and JSON Schema
... some drawbacks
... [Mozilla Web Things]
... simple, obvious use of JSON for TD
... [My proposal]
... similar to Mozilla's proposal
... PoC server implemented with node.js
... tested against OCF, oneM2M, Echonet
... [Mapping JSON to Linked Data]
... property names treated as either predicates/names
... predicates mapped to RDF URIs via @context
... enumerations as JSON arrays
... short cut when you only need to state property type
... JSON object property reserved terms: types, properties, actions, events
... names must not start with "@"
... (shows GitHub repo)
... w3c/wot/proposals/dsr-td/json-to-ld-dsr.md
... www.w3.org/WoT/demos/td2ttl
... would group's review

mk: this is an example serialization proposed by you

dsr: yes
... (shows jsonto-ld-dsr.md again)
... "properties" is metadata
... acceleration is a name
... shows spec on what I'm working on

mm: good to have multiple options for serialization depending on the need
... could have a library for node.js

dsr: good idea
... so far quite flexible

seba: TD is generated automatically by servient
... why do we need to think about non-semantic-based TD serialization?

mk: we should think about different serialization examples
... there are proposals for serialization
... actual data is semantic data
... we need tools for serialization
... essential building block is still TD

mm: agree we should handle core TD model and serialization separately
... regarding another point that developers don't touch TD

seba: agree to need for easy structure for TD

mm: we need more concrete examples

mk: you have prototype
... some parts missing

dsr: idea here is extensible support for Linked Data
... generic mechanism for mapping JSON to LD

mk: but seems like you're reinventing JSON-LD...
... that is not good for WG discussion

dsr: the idea is that LD is underlying data model
... simple JSON it's simpler than JSON as a possible serialization

<mjkoster> matthias: how does protocol binding work with this?

victor: this is not 100% corresponding to what we've been doing
... can try to link it to our spec?

dsr: depends on which predicate is used

victor: compatibility with our proposals so far?

mk: we have a problem
... this is a different proposal than Mozilla's proposal
... there is no connection at the moment

kaji: agree with Matthias
... as WG, we should fix the spec asap
... and as IG, this is a new input for v2
... so would ask Dave to split this proposal from WG work
... this should be an input for IG
... we should be careful how to handle this

lindsay: interested in the problem space
... extensible exchange of metadata
... would be good to have a beauty contest (survey?)

mk: would wrap up
... we decide core model
... this is a model formally defined by semantic web technology
... e.g., JSON-LD is already a standard
... we could do some beauty up things
... there is still constraints with JSON-LD of course
... there is no concrete specification on serialization
... as Kajimoto-san mentioned this could be an input for next version
... concise serialization also possible
... let's continue the discussion tomorrow as well

kaz: purpose of this?
... who/how/where to use this?

dsr: consume thing and expose thin

kaz: e.g., between consume thing servient and expose thingg servient

[ lunch ]

Binding Templates


<dsr> scribenick: dsr

Michael Koster presents some slides setting out the background to protocol binding

The protocol binding refers to the information needed for a driver for the chosen IoT platform/protoocol

Shows a JSON example with protocol binding within a “links” section

Introduction using OCF as an example platform

Michael shows how @type can be used in JSON-LD to identify the OCF type for each property

In addition, there are fields for href, content-format, method, resource type etc. as needed by OCF.

Michael displays a slide the depicts two ways to intergrate with OCF. One is where a WoT application acts as a client for a thing provided by an OCF device. Another is where a WoT application provides a thing that is exposed to clients as an OCF device.

In otherwords, both providing and consuming things using the OCF standards

Discovery: enabling apps to discover thing descriptions containing given semantic constraints

Discovery could be supported in terms of WoT thing descriptions as well as in terms of the OCF discovery protocols

Sebastian: are you assuming CBOR?

Michael: you could use CBOR, but this is not specific to CBOR

Matthias provides his personal summary

When mapping from the interaction by apps to the protocol level, the mapping depends on the protocol. This could be very simple for JSON based protocol payloads

Dave: where is the IoT platform identified?

I would expect a link to a platform identifier

Zkis: we have properties, actions and events for the interaction model, do you see a reason for exposing capabilities?

Matthias: I will let Michael respond to that one

The same capability could be exposed via different interaction models

Michael: we could refer to a shared vocabulary for the capabilities

It could be useful to include this directly

Dave: this is really part of the semantic models

Zoltan: do we need standard vocabularies for capabilities?

Matthias: this is something from groups that define domain specific vocabularies, and not something we will do in this group

Zoltan: an example is an on-off capability

Matthias: this could be used as part of a semantic query

Zoltan: how is this attached?

Matthis provides an explanation …

Darko: capabilities are essentially semantic annotations

<zkis> * DarkoAnicic please move closer to the mike

This is to be discussed

We need to look at how the annotation mechanisms

Dave: we need to distinguish interaction models and semantic models. The semantic models describe the capabilities and how a specific device implements these in its specific interaction model that may vary from one device to another

Not all apps will need the semantic models, so we shouldn’t require them to be included in the interaction model

Sebastian: such apps could ignore the semantic annotations
... what is the status of the node-wot implementation in respect to the OCF binding?

Kaz displays a slide by Kajimoto-san on a protocol binding building block

This has a protocol binding module that in turn binds to IoT platform specific modules.

Examples include oneM2M with JSON over HTTP, OCF with CBOR over CoAP, WoT with CBOR over CoAP, WoT with CBOR over HTTP, and WoT with JSON over HTTP.

Kajimoto-san describes his ideas for identifying the IoT platform, transport protocol, serialization format and security technology

He shows a slide with mapping from abstract operators to HTTP/CoAP Methods

Panasonic have been exploring some ideas for implementing this, along with the details for the thing description

Dave: the protocol and serialisation could be part of the platform identifier, and the operations could be implicit, resulting in considerable simplications in the thing description.

Matthias: yes, there is a choice in how this is done
... there are many web platforms, where the transformations are very simple

Michael_McCool: this could be a useful default, as a further means of simplifying the TD

Kajimoto-san: my approach is applicable to the Mozilla proposal

<inserted> kaz: right. that's why I also confirmed at the end of the morning session that Mozilla's proposal was about inter-component I/F


OCF Binding Prototype - McCool


<kaz> scribenick: kaz

mm: [Outline]
... goal is working perfectly at TPAC
... [Goal]
... consume OCF metadata
... output a TD
... attempt *automatic* translation of metadata
... for better scalability
... [Prototypes]
... ocf-bridge, ocf-generator and ocf-client
... different project for ocf generator
... also testing
... issue on name collision
... [Architecture]
... issues come from multiple places
... need to extract OCF metadata from multiple sources
... integrate instance metadata, type metada and OCF standard metadata
... how to get introspection
... which resource is actually useful?
... implicit in the spec
... most of them are currently encoded in my code
... some additinla hand-written metadata required per OCF "resource type" still needed
... annotation metadata
... would make it (hand-written part) as small as possible
... [Annotation Metadata]
... semantic tagging, which resourece types should be exposed?, which combinations of interfaces make sense?, actions/events, names and writable properties?
... [Annotation Example]
... currently doing some cheat and would like to gather information automatically in the future
... a bit different from what Koster does
... protocolCOntent shows mapping between protocol and data format
... [TD Example (one Interaction)]
... [Prototype Limitations]
... one complication
... extension mechanism of OCF
... doesn't handle multiple rt/if combinations
... including some unnecessary "OCF internal" resources in the output
... [Issues]
... [TD Example (one Interaction) - revisit]
... offline device joins the network
... [Suggestions]

<dsr> OCF device identifiers are dynamically generated each time the device boots

mm: protocol binding templates as strings
... separate template media type that can be converted to wire media type
... alternatives: make template always be JSON, get rid o template and make it equivalent to parameter map, e.g., make generation of payload the full responsibility oof the driver
... add additional "driver" parameter so that target device ecosystem, e.g., OCF, can be identified
... [Next Steps]
... update to intercept protocol binding protocol
... implement protocol binding templates
... implement oocf-gather to ingest existing OCF type metadata
... additional semantic annotation mechanisms
... pull request on node-wot
... try some other IoT standards
... [Conclusions]
... it's possible to do mapping automatically
... but OCF is relatively easy
... since webish
... need to repeat this exercise with additional standards

lindsay: would go back to some slide

mm: [Prototypes]

lindsay: have to have some software package?

mm: modular decision
... rather than implementing bridges
... you can use bridges
... consumes OCF TD
... generator is more online

<inserted> scribenick: dsr

Kaz: how to integrate this work with the plugfest?

Mm: ideally we would get this running with a variety of devices for the next plugfest

Matthias: we need to agree on the details for that

mm: more generally we need a translation, OCF is an easy case, so we need to look at a more challenging IoT platform

Matthias agrees

mm: we can say it is the driver’s responsibility to create the payload, so we can then drop the details in the protocol binding

Matthias describes how whether we use JSON or CBOR, we can keep the translation simple

mm: JSON over CBOR is straightforward, but for other cases the driver could transform from JSON to the on the wire format

mk: LwM2M is such an example

Dave: as we expand beyond REST, we will need a more general approach - an identifer for the platform and the associated metadata

mk: some of those platforms are migrating towards IP and REST

Sebastian: iot would be helpful to have a set of online devices that we can experiment with

mm: we can do that for OCF

using virtual devices.

Sebastian: we want this for a broad range of platforms

mm: if anyone wants to look at code and has any questiions please contact me
... I am thinking now about other platforms

LwM2M is a good candidate as it also uses CoAP, as is oneM2M

<inserted> [ break ]

IoT Marketplace


<kaz> scribenick: uday

Seba: Need standard way to deploy IoT capabilities
... there is also an economic perspective to IoT Marketplace
... describes the motivation and scope of IoT Marketplace

Philip: what other marketplaces out there?

Stefan: lots of marketplaces but none for IoT data

Matthias: should consider this while designing TD

Mccool: can distribute scripts, thing and data
... Bid IoT mostly concentrates on data but can share other oarameters to


stafan: cannot share code

Seba: need to setup a charter, what to be in the charter, licensing info, pricing info etc.,
... Describes the architecture
... marketplace to be aligned with WoT concepts, thing's metadata ...

Dave: idea to allow people to design services and instantiate it with specific devices, discover and consume these services. Then what kind of APIs doe we need to support that?

Darko: Most will be covered with the idea of recipies

Lindsay: description of data in the project called "Inspire"

<dsr> I very much support starting work on this and will also do my best to channel the lessons learned on IoT marketplaces that we learned in the EU Compose project on highly scalable IoT cloud based platforms

Kajimoto-san: Marketplace is a good idea, can refer to advertisement technology

Seba: software not in scope. Idea is to have semantic description to setup and interact with a service

Mcool: to limit the scope, search which connects to linked data- discovery

Seba: Marketplace is just a href

Matthias: could use manager thing mechanism

<dsr> Dave: there is a business opportunity for installable services, e.g. to install them on a home hub, perhaps from the vendor’s websiite or in the case of native apps, from Google Play or the Apple app store etc.

<dsr> so I respectfully think it would be a mistake to preclude installable services

stefan: discovering things is linked to TD

Nimura-san: missing point would be related security. How do we deal with this and also the payment?

<mjkoster> sebastian: download a servient component in the process of receiving a service

<dsr> Sebastian: the metadata could list preconditions such as services or drivers that need to be installed. These could be referenced and hosted elsewhere

<McCool> McCool: I think that a marketplace that just includes existing services and data makes sense to START; but it naturally leads to installable services

Seba: consumer has always to request the thing to get the data

<McCool> however, there are some preconditions to installable services: a secure runtime implementation that can run untrusted third-party code

<McCool> accomplishing that will probably require some collaboration with eg. OpenFog, etc.

Seba: should be complete independent of the protocol used
... who do we address: IoT Platforms, Cloud providers, Infrastructure providers

Dave: also add search engine providers

Seba: is WoT the right place?

Mcool: falls in general category of discovery, so in scope

<dsr> Search engines will be interested in indexing services advertised via metadata on vendor’s websites

stefan: as long as open issues in TD it may be early, but if TD is done then this might be the right time

Matthias: might be implications on requirements, good startting point if Big IoT could share their findings

Stafan: decided not to limit to things, want to deal with data from many things

Seba: most of the content is the same as current TD

Matthias: good to have pointers form project working for the future

Seba: its a bit early now, might meet after 6 months to move forward
... can invite e-commerce partner as well

Local device protocol

<kaz> WoT Stack

Mcool: could a thing access interfaces of the device

Matthias: how to handle local hardware is 1 year old discussion
... too big of a topic. Interaction to local hardware should also go through the thing.

Mcool: should we define standard local things?

Dave: W3C has experience with APIs which can be used

Mcool: GPIO thing accessible to the outside world is chaotic. Good to have it within the local network
... Can I put in examples in node-wot folder?

Matthias: defining various API should be marked in a branch

<inserted> scribenick: dsr

Dave: we can provide some guidelines, but we can’t preclude IoT platforms from exposing their own APIs (e.g. Arduino modules) locally to application scripts.

<uday> Kaz need some help with scribing

Michael and Matthias discuss the idea of some standardised local things

<uday> thanks Dave, please add what you can!

Matthias: as Dave mentiioned we could consider adopting the browser APIs for local hardware and seeing what we can learn from their approach to security and privacy

<inserted> scribenick: kaz

Kajimoto-san: [WoT Model Description and APIs]

<inserted> scribenick: uday

Kajimoto-san: explains two API concept. one for physical world and one for cyber world

Mcool: treat both physical and cyber things same, so we can have a common API

<inserted> scribenick: dsr

mm: the conclusion from the Panasonic F2F was to use things and thing descriptions for both

<inserted> scribenick: uday

Dave: what about arduino, rasberri APIs

Mcool: can wrap them to have access to the hardware

Matthias: need the API available everywhere, gets hard with individual APIs

Mcool: we need to make a list of resources

<dsr> Dave: we need to clarify our messaging: things provide an elegant means to wrap access to local hardware, but platform specific APIs are also going to happen, and will require care with security

Matthias: more important to document the learnings

<dsr> Matthias: the thing approach offers greater portability

<kaz> [ Tech Day 1 ends]

12 July 2017


Kaz_Ashimura(W3C), Michael_McCool(Intel), Masato_Ohura(Panasonic), Katsuyoshi_Naka(Panasonic), Takeshi_Yamada_Panasonic), Keiichi_Tokuyama(Panasonic), Ryuichi_Matsukura_Fujitsu), Kazuaki_Nimura_Fujitsu), Takuki_Kamiya(Fujitsu), Soumya_Kanti_Datta(Eurecom), Tomoaki_Mizushima(Internet_Research_Institute), Kunihiko_Toumura_Hitachi), Uday_Davuluru(lemonbeat), Kazumasa_Okabe(Yahoo!_JAPAN), Kenichi_Kuromusha(Yahoo!_JAPAN), Francesco_Antoniazzi(University_of_Bologna), Fabio_Viola(University_of_Bologna), Victor_Charpenay(Siemens), Darko_Anicic(Siemens), Sebastian_Käbisch(Siemens), Daniel_Peintner_Siemens), Dan_Brickley(Google), Michael_Koster(SmartThings/Samsung_Research), Dave_Raggett(W3C), Matthias_Kovatsch(Siemens)
Elena_Reshetova(Intel), Zoltan_Kis(Intel), Achille_Zappa(INSIGHT), Niklas_Widell(Ericsson)
Matthias, McCool
kaz, dsr, McCool

Meeting Logs

Security Use Cases and Scenarios - IG


<inserted> scribenick: kaz

elena: [WoT F2F Dusseldorf]
... Security Use Cases and Scenarios

<elena> https://github.com/ereshetova/wot/blob/master/security-privacy/SecurityScenarios.md

elena: shows MD page
... scenario 1 - Home environment
... user privacy is important
... what are the WoT security objectives?
... goes through the table of Threat name and Examples
... important to gather different use cases
... scenario 3 - Industrial/Critical infrastructure environment

danbri: user privacy

elena: collecting first ideas so far

mm: general use cases on both privacy and security
... medical is an important use case
... devices in hospitals communicate with each other
... and industrial
... 2 use cases
... full automation case
... and another case employees are included
... not sure about agreement between employees and employer

elena: medical use case require high privacy

mm: automation within industrial environment
... 2 cases
... 1. not directly monitoring people, e.g., fully automated factory
... 2. employee monitoring

mk: maybe more concentrate on some core part?
... definition of privacy concern, etc.
... privacy and efficiency

danbri: small badge system?

(improving microphone setting...)

mm: repeats the industrial use case including 2 possible settings

mk: please don't combine the 2 use cases

mm: ok
... maybe can split out into 2 use cases

<dsr> Some differentiators: privacy when people are involved, safety when critical infrastrure is involved

<dsr> another is cost, e.g. when failure results in equipment damage and a cost to business

<dsr> smart cities may be interesting as it is a public environment with lots of people

mk: wondering about the goal and what to record here...

<dsr> mk: what is the goal for this exercise?

<dsr> scribenick: dsr

elena: the aim is to group security advice to make it easier for people to see what to apply

mk: it is worth looking at other IoT alliances and SDO’s to see how they are approaching this challenge

elena: sure, and we will want to see what security approaches are relevant to each layer in the comms architecture

mm: IIC is focusing on industrial use cases, as an example

the use cases are important as we are bridging different domains

mm: we may also want to consider mobile use cases

kaz: if the aim of this session is reporting the security TF's work to the group and getting feedback/advice from the group, maybe it would be more effective to do this in a break out session?

mm types in short descriptions of the broad kinds of use cases we should work on

Dave suggests adding law and order to the smart cities use case consideration

mm: also fire and emergency services

uday: we may want to consider coupling between use cases, e.g. smart homes and smart cities

mk: I like the idea of a decision tree as an outcome of ths study

elena: I agree

you usually extract the differentiators from the use cases

mm attempts to list some of the factors, e.g. different classes of people, whether the devices are personal or not, etc.

elena: we can think about what is the impact

mm: we can refer to existing materials, most of which are specific to a given domain

you might be unwilling to share information with insecure systems

danbri: devices in a home may be used to identify empty homes as targets for burglary

mm: personally identifiable information, e.g. for personal devices vs tracking people in a street in an anonymous approach

elena: confidential information may not be tied to people

mm asks elena if there are any standards we can refer to here?

the IIC security framework for instance, talks about several categories of risks

this could help us with scoping our discussion

kaz: maybe we need to look at both providers and consumers of services

mm: the flow of risk may be in the opposite direction

i.e. the risk could come from the consumer


mm: fake data where false information is being propagated by an attacker

elena: that is a very different level of use case

Dave: fake data can compromise safety

mm: and physical security
... asks for a show of hands for people interested in brain storming on use cases (Soumya and Dave raise their hands)

elena: we will continue with security tomorrow, right?

mk: Review of Existing/Proposed Security Architecture

elena: after that we will have a session on privacy

mm points to the security and privacy questionnaires that Elena has created.

<zkis> https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf

mm: this was inspired by IETF work
... let’s give people a chance to review the email I just sent on this

mm thanks Elena, who leaves …

<kaz> [break]

<inserted> McCool's Notes

Security Next Steps


<inserted> scribenick: kaz

mk: comment on next step for security
... we ran into security discussion
... need to look at practical aspects
... let's clarify the next steps and roadmap

mm: think about relevant use cases
... generate concrete document
... and think about APIs
... next step is working down use cases including mitigation
... one category is existing mechanisms
... and then what kind of scripting API needed
... couple of recommendations for security APIs

mk: security vocabulary
... Panasonic was thinking about security for exposed things
... let's see what is included in their implementations
... we also have some ideas
... then OCF as well

mm: next iteration of OCF binding should include access control
... prioritized list of what to do
... third category is kind of bottom-up

mk: right progress with the Security TF so far?

mm: individuals are liaison communities
... bubble up during the security tf calls

zkis: based on case by case
... in order to have security use cases
... should get members' input
... also OCF network
... deployment is out of Charter
... but we can describe requirements
... and have demo deployment

<zkis> proposal: WG and IG members should describe typical deployment scenarios

<zkis> we should solve security issues cases by case, for those deployment scenarios

<zkis> for instance, in OCF, a WoT bridge is needed that undergoes the OCF security provisioning

mk: would like to encourage people to think about how to transfer this

mm: making issues on GitHub
... discussion during the main call as well

mk: presentation by IETF ACE
... Ari and Carsten
... OCF want to reuse IETF idea

<dsr> scribenick: dsr

Synchronization [IG] - Nimura

<kaz> scribenick: kaz

nimura: review the discussion from the Osaka f2f
... [Conclusions and Proposals]

Servient Synchronization

<kaz> https://www.w3.org/2017/05/wot-f2f/slides/Sync-WoT-Servient-170517.pdf

<kaz> https://github.com/w3c/wot-scripting-api/issues/28#issuecomment-308526421

<kaz> https://github.com/knimura/wot-scripting-api/blob/master/ReverseProxy.md

<inserted> scribenick: dsr

presented by Nimura-san

<kaz> nimura: discussion during the scripting calls

This relates to use cases for synchronising proxies, e.g. a proxy in the cloud for a thing behind a firewall

Nimura-san leads us through the reverse proxy use cases

This covers the use of a cache for operation when there are connectivity problems

This may involve republishing a thing description in the cloud when creating a cloud-based proxy for a thing hosted behind a firewall

<McCool> couple of questions - first, is the TD repo a Thing with a TD? second, what about security? Access to the proxy should require the same credentials as access to the device, and what about encrypted connections and/or payloads?

<McCool> also, can TD repo and/or TD recognize when something is a proxy for another thing?

Nimura-san: we will need to think about that

Michael_Koster: we should talk about the details of the design pattern

<McCool> koster is noting we are working on some related design patterns for links

and related work we’ve been doing

<McCool> I actually think "proxy" should be built into the scripting API so it can be done in a consistent way...

<McCool> perhaps with some controls, eg. to override or hide specific resources

mk: we could learn from the web architecture, e.g. the proxy looks like an origin server to the client

If a client (consumed thing) is not connected to the network, the state can be accessed from a cache

<mjkoster> zoltan: this is an application pattern

mm: should proxies be built into the architecture or treated as an add on - there is a case for the former to promote re-use

mk: I would advise against standardising this

mm: a library would promote consistency

<McCool> having a utility library at least would promote consistency

Zoltan: I agree with Matthias on this, but wonder about necessary network elements such as the TD Repository ...

<McCool> having standard proxies as services is similar to having particular system services... can be adopted or deployed if required...

mk talks about repositories …

<mkovatsc> +1 to Zoltan's comment over WebEx

<mjkoster> matthias: td repo and CoRE resource directory are similar patterns

mm: we could support this via open source implementations of the pattern

Nimura-san: this is an application layer, right (checking with Zoltan)

Zoltan: I am more interested in this kind of caching and synchronisation

mk: this is a good test of whether our scripting API is sufficient

mm: we should be documenting design patterns

perhaps on the wiki?

<McCool> where do we document these "design patterns"

mk: prefer to use the wot github repository

<McCool> matthias suggests putting in architecture repo

<McCool> kaz how does this relate to specification? appendix?

Kaz: I would like to find a way to publlish Nimura-san’s work

mk: perhaps as an appendix?

<McCool> matthias: should go into architecture document...

mk: my main point is that it is premature to decide where to put it

mm: we need to clearly mark it as informative

<McCool> early break for lunch...

<kaz> [ lunch ]

Script Management

<kaz> Nimura-san's write-up

presented by Nimura-san

<scribe> scribenick: dsr

WoT ManagerThing as a thing for managing servients

Commands include script installation and uninstallation, script execution (start and stop).

A set of optional commands.

The ManagerThing can be used by clients to remotely manage the servient.

Nimura-san leads us through the document (see link above).

<McCool> Wondering: if device reboots, and is running a script, is it restarted automatically? In other words, how do the managerThing verbs map onto systemd-like installation semantics? (stop/start vs enable/disable).

<McCool> idea is that start (eg run) is only for the current instance of a running device, but "enable" implies it starts automatically at boot

Zoltan: why are you using CoAP for the manager thing?

Nimura-san: this is just an example

Zoltan: do we have any requirements, e.g. for the use of HTTPS or a standard port etc.?

mk: I don’t think we need to standardise the choice of a port or HTTPS etc.

We should advise the use of a secure connection though

Zoltan: do you want to standardise the manager thing?

mk: no, as there are many choices people could make, it would be good to establish the design pattern though

Zoltan: this is not only the application space as it also impacts the system space

mk: it is good to provide a design pattern, but other ideas may come along, so we shouldn’t be prescriptive here

mm: I want to +1 the idea of the example using a secure connection

we may want to discuss whether we want to recommend a port

mm: is running persistent across restart of a server machine?

Dave: we need to make this clear and to provide use cases to back this up

<McCool> to consider: should there be an "update" verb?

<McCool> so install creates a new thing, but update only works on existing things

<zkis> +1 for update command

Zoltan: we also need to consider the vocabulary implications

<zkis> We need help from the TD taskforce for defining vocabulary and TD for Script Management Thing

<McCool> also: decomissioning. I assume "uninstall" should also delete all data associate with the Thing instance

Sebastian: should we define a standard vocabulary for management actions etc.?

mk: we should defer standardising the vocabulary until there is plenty of experience

<McCool> another set of verbs: debugging...

Zoltan: I agree we should distinguish from the core TD vocabulary and we should continue our work on exploring the space of management services

mk: we should use these experiments to verify that the core vocabulary and APIs are adequate

mm: we may also want to work on exploring logging and debugging services

<uday> Should we couple manager thing with Discovery?

The manager thing is a back door and the security needs to be well thought through

mm: the question is whether we have a front door for debugging or some back end solution

the former would seem preferable

mm: I am raising this for future discussion

Zoltan: this is a separate functionality from the management services and we should open this as a separate github issue

<McCool> where should I post issues? Can create two: update; debugging

<McCool> should issues go here? https://github.com/w3c/wot-scripting-api/issues

Nimura-san talks about associating scripts with a handle for identification purposes

Zoltan: we need to experiment with how to identify scripts

mk: we could use URIs and look for inspiration from hypermedia controls

we could then define a REST API for alignment with how the Web works

Kaz: these mandatory and optional commands are for managing the state of the servient

we should clarify how the management vocabulary relates to the servient state

Darko: do we need metadata for scripts?

e.g. for versions of scripts

Zoltan: we could re-use ideas from the web app manifest for this

<zkis> https://github.com/w3c/wot-scripting-api/issues/29

Dave: do we want set some expectations for using a ManagerThing in the next plugfest?

<mjkoster> mkovatsc: HATEOAS pattern for script management

mk: I want to set out some ideas for hypermedia controls based approach

Sebastian: I would prefer to see further demos before we bring it to a plugfest

<mjkoster> zoltan: expose OCF resources in wot thing and add scripts

Zoltan: we could create a demo of dynamically installing and running scripts for some OCF devices

mm: this could be quite challenging, e.g. as it involves discovery, I would think that small technical demos would be fine.

<mjkoster> mkovatsc: sensor fusion like pattern

Zoltan: we can indeed do some demos but still have lots of things to work on

mk: we can use the main call to coordinate ideas and converge on a common understanding

<zkis> please add use cases to https://github.com/w3c/wot-scripting-api/issues/23

Michael_Koster: I don’t see a clear explanation of the script handle

We need a semantic explanation …

Zoltan: yes, this is work in progress

Nimura-san: how should we handle this topic going forward?

Sebastian: we need to gather idea for the TD vocabulary for managment services

Zoltan: we can use the scripting repo in the interim

mk: we need to make it easy for people to find this information

Kaz: may be a subdirectory?

mk: yes

Nimura-san: I will make pull request with the updates from today’s discussion

Data Types [WG]

<Victor> http://w3c.github.io/wot/current-practices/wot-practices.html#type-system

<Victor> Dave's demo: https://www.w3.org/WoT/demos/td2ttl/

<Victor> data type comparison: https://github.com/vcharpenay/wot/blob/master/proposals/dsr-td/td-type-system-comparison.md

<kaz> scribenick: kaz

dsr: [Formal Basis as Linked Data]
... where the type systems come from?
... properties, actions, events and metadata
... core types: boolean, number, integer, string, enumeration
... compound types: can be nested
... object, collection (array), vector
... thing meaning URI to TD
... univons of types for flexibility
... basic constraints: ranges, patterns, readonly/writeable, optional/required

mm: existing ontology on type systems

dsr: if there is something we can use

seb: something missing
... max/min

dsr: that's included in range

seb: schema or json.schema

<McCool> is there an existing ontology we can adopt; an example would be SCRO

<McCool> http://www.indiana.edu/~awny/index.php/research/ontologies/10-scro

<McCool> but dsr did make the point that we conversely don't want to adopt extra baggage (and SCRO has a lot...)

seb: maybe we could complete this list in accordance of those existing mechanism

dsr: number depends on platforms

mk: what is the goal and to achieve?
... how to represent the type on the other side of the system?
... most of them could be modeled by JSON types

<McCool> comment - we could define our own system, but still associate it with an external ontology, such as SCRO, for reference

mk: you could reshuffle this list and make it in order
... could you see simplified types in JS?
... and see how to model this
... basically we want to use JS as the basis, why do you want to consider types?

dsr: probably would better match with objects from OCF, etc.

mk: special kind of array?

dsr: typedef is common for programming
... some of programming languages only have core types

mk: this would require something that JS doesn't have...

koster: not comfortable with these types

<soumya> +1 for koster's comment on vectors

<mjkoster> mkoster: seems like number types and structure types may need to be handled differently

<McCool> kaz: resolution of numbers important

koster: we should think about UC...

danbri: Google has started to participate in WoT
... important area but way too much for W3C

dsr: we can incrementally work based on experiments

mm: how do we specify what the data type system is?
... clear specification is needed
... we should narrow the focus based on our need
... we don't have to think about this until we have specific use cases
... think we should see minimum set

<mjkoster> mkoster: structures are needed to describe payloads, value constraints are needed to describe instances of interactions

dsr: e.g., CSS, started with minimum set of features (and now has various features)

mk: this would help our discussion on scripting API but you don't have to jump into the details of extension of type set for JSON/JSON-LD

<mjkoster> mkovatsc: the type system is decoupled from the semantics and makes it hard to do some filters like units

taki: working on creating new type systems would take much time
... would see if json.schema is really not enough
... choice could be better fit for union mechanism

vic: there is choice in json.schema
... just saw examples from OCF. can show them.

<mjkoster> mkoster: "oneOf"

dsr: e.g., new features of CSS would allow you easier styling

<danbri> some related experiments from ericp at w3c: https://www.w3.org/WoT/demos/shrl/test.html http://tinyurl.com/y9fm2zsy http://tinyurl.com/yay2xzjd (using Shex over the RDF graph data model).

seba: why we need vectors, for example?

<McCool> sebastian: is there an example for vectors?

<McCool> McCool: RGBcolor uses a 3-tuple

<McCool> used in lighting, of course

<McCool> RGBled in our OCF demo used it

<McCool> of course we could also use an array, but it was also a specific length

<mjkoster> mkoster: a map is suitable for RGB or RGBW

<mjkoster> else you would need 2 types, etc...

<McCool> true, and basically that is how it is done in JSON

<McCool> and was done in the OCF example

mm: very complicated data cases
... jpeg, png, etc.
... we should work case-driven

<mjkoster> jpeg and png are mediatypes

<mjkoster> not datatypes

<Zakim> kaz, you wanted to wonder if we want to make JS yet another mathematica

<inserted> kaz: do we really need to extend JS to make it yet another mathematica? we should clarify use cases based on plugfest demos, etc.

<McCool> what I meant, was that we should only define what we need for OUR scripting API, not for all possible scripting APIs

<Zakim> danbri, you wanted to ask if there is an explicit list of usecases for the type system (e.g. validation? codegen? ...)

<McCool> defining a mechanism for defining all possible scripting APIs is beyond the scope of this particular WG (not that it would not be useful, it just is not in scope here)

<McCool> let's just define our scripting API and introduce definitions only for the types we need

<mjkoster_> danbri: need to be explicit about what the type system is used for

mk: we should start with some initial set
... not sure what the blocking point is
... from different data models

<mjkoster_> mkovatsc: define how data are presented to the application

mk: need schema information and semantic annotation

<mjkoster_> ...it seems like the json types are sufficient to get started and build upon

<mjkoster_> dsr: we gain convenience

<danbri> (for the notes - dsr responded to my request for usecases for the type system, by pointing to the introduction of https://github.com/w3c/wot/blob/master/proposals/dsr-td/td-draft-spec-dsr.md)

<danbri> ... including code generation (if I understand right), definitions for actions/events/properties, and also validation.

mk: seems to be too ambitious...

seb: would be helpful to show us why we need these additional types

<mjkoster_> sebastian: +1 what Matthias said, the json types seem sufficient

<danbri> Maybe these can be requirements and SHACL or SHEX can be taken as candidate ways of meeting those?

<mjkoster_> dsr: if we use low level constraints, there is a lot unspecified

<mjkoster_> dsr: numbers mean different things in differnent programming languages

<danbri> on screen: comparison of OWL and JSON Schema from (somewhere in https://github.com/w3c/wot/tree/master/proposals)

<mjkoster_> victor: presents json-schema vs. owl chart, including OCF resource type examples


dape: you can reuse json.schema if it works

vic: schema.org also?

danbri: schema.org is declarative not validator
... btw, how deep this group work on SHACL?

<mjkoster_> victor: it amy be difficult to map OCF using SHACL, for example

vic: need for concrete examples of each feature
... your listed additional features of type systemss
... myself will continue this way of comprison (e.g., JSON vs OWL)

mk: feel as if we were back to Montreal...
... we looked at json schema, etc.
... could use metadata for modeling linked data with some restriction

<McCool> time check... we are well into the break. Can we wrap up?

<mjkoster_> mkovatsc: mapping from json-schema types to linked data, with additional constraints added using linked data

<mjkoster_> danbri: look at what is done in json-schema and express in RDF rather than referencing json-schema directly

<danbri> danbri: "my advice would be not to normatively reference JSON Schema, but take its actual use for IoT as driving requirements for something similar but on top of the Linked Data (i.e. RDF) data model. I'd predict SHACL/Shex will be the main focus, but RDFS/OWL used for basic term declarations too."

[ break ]

TD and Links [WG]


<scribe> scribenick: McCool

victor: presenting what did for plugfest

wrapping SSN in things

use links to get values

or invoke actions

for now links are abstract

but we might (want to) make them more concrete

SSN/SOSA model

important classes are observable properties and feature of interest

sensors can make observations

observations are events where properties are associated with values

values are string, number, or more complex structure

made an alignment with our resource model

feature or interest -> Thing; observable -> Property; observation -> Event

but association is not exact

maybe we could use links to model the whole thing

SSN dataset usually has several observations

cannot have this in a TD; cannot have histories

servient can subscribe to an event to get a result, but cannot get previous events

so... what if we had a history, or previous, or client

also, uri templates

we haven't done anything with those

relation types that are already registered for CoAP, etc

already have some interesting semantics, such as collections

presented a TD eample with an SSN dataset

had mechanism to get latest, but also history

proposal: add a relation type to each link

so you can ask for the latest, or older observations using a timestamp

using relation type history

some alternatives here: queue like in the Mozilla proposal; or query to search over timestamps

matthias: rel is used for something else, doesn't think semantics

michael (k) may have some comments

dsr: can we connect to linked data model

victor: normally made links with URI templates

but may be tricky to do validation

but if use JSON-LD features...

either we have a predefined set of relation types are define as properties

validation may be hard

matthias: alt to rel property would be to have two related properties

victor: could distinguish links with different @type

questions about mapping

Darko: should both event and property be observable properties since they produce data?

victor: if you look at other systems, can have complex input data to queries

but did not think of this, should experiment in this direction

mk: been looking at a lot of use cases for linking

not even sure about rel

but if are using links only to point to endpoints, don't need rel

if want to build a td that points to other tds as an index, for instance, then we might want to use rel

it does things that attributes don't do

dsr: don't think we need this; can use an API
... also think timestamps should come explictly as part of the data
... no need to expose that as part of the TD
... did example with electrocardiogram data

victor: understand argument that we could have simpler solution

<mjkoster> (comment) We should not be too focused on this one use case for linking, and this one link term "rel"

matthias: going back to mk's comment

how rel was used in this example makes things more complicated

mk pointed out where it would make sense

where one thing is related to something else, eg composition

when we have to express HOW things are related

<mjkoster> mkovatsc: showing how things are related does make sense in some cases, but not this case

URI template should be considered in protocol bindings

<mjkoster> mkovatsc: should consider this mechanism also in the binding templates

McCool: looks similar to the issue we have with multiple if types eg in OCF bindings

would be nice to solve this and that the same way

<mjkoster> mccool: could use links to express/select query parameters at the protocol level

what do we do next in the td?


started with serialization

we have discussed compression using shared knowledge, we have an enhanced data set, and then we have the proposal from Mozilla

<soumya> Benjamin and I will participate in the future TD works regularly

seb: it would be very good to involve Ben from Mozilla in this discussion

Matthias: have drafted quick response to Mozilla, sent to team-wot for review

will invite him to give a presentation to group, probably in two weeks or four weeks

26 July or 9 Aug

we have discussed JSON serialization before; Mozilla proposal may bump up the priority

we have a baseline using JSON-LD that works for now though; but would be fine to look at additional serializations

<mjkoster> (comment) danbri may have some input to the JSON serialization question

iot.schema.org - next Plugfest would be interesting to actively use, but maybe not so easy

mk: no showstoppers, but there is work to do

need to arrange for access, and have some experimental vocabularies

next, we want to enhance the core vocabulary

need for instance we might want a "method" (POST, PUT, etc); may need URI template

<mjkoster> sebastian: protocol binding is priority 1

<mjkoster> ... semantic annotation is priority 2

who is on the team?

matthias: this IS a new TF, since it is associated with a deliverable

<mjkoster> mkovatsc: protocol binding is a new task force and a new deliverable

<soumya> I will join this as well

also uday

matthias: unfortunately, still in IG as a proposal

maybe can resolve with matthias making another proposal

then we can start populating the wg

next, managerthing

will have a deep discussion

will define a set of vocabularies to support it

then look at a set of examples, aim for some demos in the next f2f

show some managed things

next, data types

dave to provide some concrete use cases

then define mapping between linked data and JSON schema

use ShEx and/or SHACL for validation

victor: define mapping using OWL and JSON-Schema; equivalent

correction: ShEx and/or SHACL for validation; OWL and RDFS

matthias: have to avoid referencing JSON-Schema

instead we will model features using RDF so things are formally defined in an equivalent way

dsr: use cases from Echonet, oneM2M, etc. that can support each of these features

matthias: start with core definitions that come from JSON-Schema for instance; it would be good to establish that we CAN extend to more abstract types, but we may not use them right away

let's start with a core that we can use right away

dsr: worth having some plain prose descriptions

mccool: formal is normative, prose description to be informative

next, links

victor: proposal to use IANA rel for links

but, based on feedback, will look more at using this for relations

darko: this is a recipe idea (relations)

example, a group of lamps can be related to each other

or a room could be a collection of things

McCool: I think we need to do more work on events and actions

<mjkoster> mccool: example ROS functionality for long running actions, check status, cancel, etc.

matthias: we can treat the Mozilla proposal as a prescriptive proposal we can try to describe

mccool: we can look at other things as well, such as MQTT/ROS for events, and ROS for actins

mkoster: in proposals folder there is something for events

for events, who can work on it?


mccool: my use case is ROS, which has both events and actions

kaz: example td, possible relation between manager things and action/event discussion

mkoster: simple actions are already there, just need more definition

move to adjourn...

<kaz> [ Tech Day 2 ends ]

13 July 2017


Kaz_Ashimura(W3C), Michael_McCool(Intel), Masato_Ohura(Panasonic), Katsuyoshi_Naka(Panasonic), Takeshi_Yamada_Panasonic), Keiichi_Tokuyama(Panasonic), Ryuichi_Matsukura_Fujitsu), Kazuaki_Nimura_Fujitsu), Soumya_Kanti_Datta(Eurecom), Tomoaki_Mizushima(Internet_Research_Institute), Kunihiko_Toumura_Hitachi), Sebastian_Käbisch(Siemens), Victor_Charpenay(Siemens), Daniel_Peintner_Siemens), Takuki_Kamiya(Fujitsu), Darko_Anicic(Siemens), Michael_Koster(SmartThings/Samsung_Research), Dave_Raggett(W3C), Matthias_Kovatsch(Siemens)
Elena_Reshetova(Intel), Zoltan_Kis(Intel)
Matthias, McCool
dsr, kaz

Meeting Logs

Review of Existing/Proposed Security Architecture [WG]


<dsr> scribenick: dsr

mm: reads out Elena’s slide

There’s multiple places where security matters, internal and external

When we are using security mechanisms for particular protocols we need to reflect this in the thing description

For external security mechanisms, yesterday we decided to create a separate security github repository

<elena> guys the line has no audio

We need to work with external organisations to document their security mechanisms

mm: any volunteers …
... I can work with Zoltan and Elena for OCF.

Dave: any IETF experts?

mk: Panasonic could document what they’ve done with HTTPS

mm: we want to describe existing security mechanisms

<soumya> i can look at oneM2M

mk: Siemens can contribute, I can’t say exactly and need to talk with Oliver. It is likely to focus on IETF work

mm: We should review what the IETF recommend

Soumya: I can look at what oneM2M are doing on security and also OMA’s security for LwM2M

mm: for HTTPS, I also want to consider OAuth, and to see what Amazon IoT is doing.

Michael asks Elena for guidance


<inserted> Privacy questionnaire

Elena presents

mk: unique identifiers, e.g. for a device may be important for some use cases, but not for others

The challenge is how to restrict access to this

mk: so far we haven’t define any vocabulary terms for this. Panasonic’s work on lifecycle is relevant, but nothing is set in stone as yet

Sebastian: the JSON-LD @id feature is relevant

Dave thinks that the RDF node for a thing description for a specific instance of a device is such an identifier

mm: the issue is to whom the id’s are exposed

This gets us back to the question of whether you can control what you get back when requesting a thing description, e.g. based upon an authentication and access control mechanism

OCF has a device identifier (“di”). We can look at the OCF approach, and I believe that the device identifier is only available after you’ve being authenticated with the relevant credentials

Elena: you’re describing the OCF perspective, but we need to look at the WoT layer

mm: the OCF device id is freshly coined each time the device boots

mk: we want to provide core building blocks, e.g. the life cycle management
... we have a tight schedule in our charter

so we can’t expect to solve everything in that time frame

Elena: we need to ensure that we (WoT WG) don’t make matters worse …

mm: we shouldn’t propagate publicly information that is supposed to be private, we need some privacy principles, we need to consider bridges and what information should/shouldn’t pass over it

mk summaries

<kaz> dsr: maybe we have to introduce mechanism to identify sessions

Dave: RDF relies of URIs for naming things for describing them and their relationships. This implies a degree of persistance. We should introduce the notion of session so that the descriptions are only valid for that session.

mk: RDF is about knowledge management, and typically for longer lived descriptions

We need a way to provide shorter lived information subject to access control

mm: IPSO have struggled with this, we could talk with them

Dave: we need to consider access control to RDF graphs and the life cycle for such graphs

mm: RDF id’s for people are privacy threating

Dave: only if shared, so we need to deal with restricting sharing such ids
... this brings back to discovery and ensuring that the URI for a thing description is only shared with entities that are authorised to see it

mm: we could look at proxies with temporary ids (personae) with persistent ids hidden behind them

Victor: RDF blank nodes could be relevant as they are restricted to a given context

Elena: we need a small group of us to brainstorm on the principles

mm: any volunteers?

Michael McCool, Elena, Dave put themselves forward

<inserted> scribenick: kaz

kaz: wanted to mention 2 points
... 1. it seems to me that there is a need to handle several levels of lifecycle, e.g., static/eternal lifecycle, hardware-dependent lifecycle, software-dependent lifecycle, session-dependent lifecycle. so we might want to think about those possible levels of lifecycle based on concrete usecases from our plugfests/
... 2. there had been similar discussion on identification within the Web&TV IG's GGIE TF, and now they're working with some IETF group, so we might want to refer to their work as well

<inserted> scribenick: dsr

Taki-san: to whom you provide an id is a means to protect privacy

<victor> I can also participate in this discussion about IDs

mm: what over standards groups have Ids we need to consider, LwM2M. for instance

Michael_Koster: the IETF work on resource directories is relevant (CoAP)

<mjkoster> in IETF, it is the resource directory specification that describes the persistent endpoint identifier ("ep")

<mjkoster> This mechanism is reused by LWM2M

mk: we shouldn’t attempt to standardise identifiers, but rather to work with what vendors and SDOs already support

Elena reitterates the principle of being careful not to make thing worse

<mjkoster> The other identifiers in LWM2M, i.e. object IDs and resource IDs are just number codes for the same class ID as e.g. OCF resource types

Private information shouldn’t be made public, for instance

mm: the privacy work should be part of the IG

We need to work with existing approaches, and we can work on guidelines

<mjkoster> mccool: "privacy proxy" is an example pattern

mm: we need to explore use cases to mature our understanding

<inserted> [There is a question on use cases on the page 5 of the questionnaire.]

Elena: we need to provide clear guidance to implementers

mm: we need to consider what capabilities are required by legal constraints

This merits a further question for the questionnaire

mm: the EU GDPR is one thing we need to look at

Elena: this could be hard to answer in a questionnaire

Different countries’ law will vary considerably

mm: I care more about the implications of legal requirements on the technical requirements

Kaz: I was worrying about the regulations in different countries

mm: there is a lot of variation, so the challenge is to boil these down to a set of technical requirements, this may have already been done, so we should look for that

Kaz: I would suggest moving this use case question from page 5 to page 1

mm: we should make a stab at trying to answer the questionnaire ourselves

<kaz> [so far McCool, Elena, Dave, Victor, Kaz]

<kaz> [possibly start the initial call the week after, and will hold a doodle poll for that]

<inserted> -> @@@ McCool's note

<kaz> [ break ]

<elena> The privacy form is updated with the changes discussed

Vocabularies for Semantic Annotation of Thing Descriptions [IG]


<kaz> scribenick: kaz

dsr: will talk about general things
... Darko will give details on recipe
... [Benefits of Semantic Models]
... interaction models describe the properties, actions, events
... interaction model provide what the property means
... semantic models describe the meaning and relationships between things
... allows providers/consumers to agree on the meaning
... idscovery based on the purpose of things
... designing compositions of services with the confidence that they will work as intended
... adapting the UI and service logic to deal with variations in capabilities from one device vendor/sdo to another
... [Semantic Models]
... thing as an instance of the class of things
... things may be declared as instances of other more specific kinds of things using rdf:type predicate (or subclass with rdfs:subClassOf)
... for properties, actions and events
... number of possibility about the solutions
... there is a scaling issue
... OCF, oneM2M, Echonet (etc.) cover smart home area
... how to relate with different standards?
... [Bridging Communities]
... OCF ontology-bridging ontology-oneM2M ontology

mccool: might want to talk with Alan from Qualcomm as well
... OCF looking at oneM2M as well

dsr: how about you, Soumya?

soumya: Yongjing would be the best person
... can talk with Orange guys as well

mm: Alan is working on bridging between OCF and oneM2M

dsr: great
... [Exploring the Design Space]
... generated linked data interaction models for OCF and oneM2M
... in the process of doing this for ECHONET
... plan to follow on with Bluetooth and LwM2M
... next step will be to craft the corresponding semantic models for each IoT standard suite

mm: should consider not bridging between SDOs but bridging up to some standard/common concept

dsr: proposing we try some experimental work

kaz: we've been doing PlugFests as interactive experiments
... so this sounds like an improvement of PlugFest and think about how to connect/bridge some std-based device and another std-based device

seb: seems good idea but think it's very difficult
... we're working on TD ontology and we could upload information there

dsr: bridging ontology would be enough
... we don't have to standardize everything

<McCool> in fact, we just want to standardize the hooks to support semantic models, not (necessarily) (all) the semantic models themselves

Thing Description Recipes [IG]


darko: part of the LD TF work
... [Thing Description Recipes]
... problem statement: how to easily enable thing interactions, thereby creating WoT applications?
... proposal: interop client creates a WoT application based on a Recipe.
... discovery of Things is automated thanks to the semantic specification of TD and the recipe
... recipe interactions are implemented with WoT API
... propose a recipe format base don TD and capabilities from iot.schema
... [Current Situation: Discovery with TD Repository]
... 1. WoT Servient (on the left side) register/update/delete TD
... 2. WoT Servient (on the right side) search/querying/lookup
... 3. and gets TD/subset of TD content from the TD repo
... [Recipe Example 1]
... simple example
... turn a light on when motion is detected in a room
... recipe consists of ingredients and interactions
... e.g., MotionStatus Property - SUBSCRIBE MotionStatus
... could also graphically represent this
... Motion Sensor (including MotionStatus property) <-status-> LightSwitch(including TurnOn Action/TurnOff Action)
... Ingredients are TD Interaction patterns & iot.schema.org capability
... Interactions implemented by Scripting API
... (shows some UI on this idea)
... (and TD example)

mm: you have multiple different roles for an action
... success/failure kind of status
... multiple links linked to multiple roles

<mjkoster> ...could use multiple links in TD using link relations for which "role" e.g. invoke, cancel

darko: (shows TD example again)
... metadata kind of recipe here
... first Ingredient, second Ingredient
... motion detecting for turning on or off
... one more slide
... [Recipe Example II]
... search for a think on some repo or marketplace
... if there is not the expected Thing available, there is a recipe (temp sensor, air temp controller)

<inserted> discover things that implement the recipe

darko: discover things that implement that recipe
... temperature sensor TD, air temp controller TD

mm: recipe could be a hook

<mjkoster> ... the recipe could contain a hook to the application logic

darko: [Benefits of Recipes]
... recipes offer the following
... discovery of recipes for various applications
... easy implementation of applications with recipes

<McCool> to clarify: my thought is that the "process" part could be another component, referenced by URL, that implements the "algorithm" part of the recipe.. but the ingredients are found as described, separate from the process

darko: efficient discovery of things required for recipe apps
... easy creation of recipes based on existing apps
... easy sharing of recipes on a marketplace/repository
... easy extensions of existing recipes on a marketplace/repository
... Web links of an app in TD
... sematnic dosumentation easies maintenance of application lifecycle

dsr: recipe is declarative mechanism
... doesn't have to be a code

darko: maybe a good idea to build procedural part on the top of recipe
... e.g., control the switch for lights

dsr: also security aspects

mm: how the actual processing happens?
... linking to urls
... similar procedure like the one built in the recipe
... can imagine some simple tags
... nice to separate discovery from process
... don't have to install scripts

darko: interaction between ingredients

<Zakim> kaz, you wanted to mention the need for thinking about states corresponding to the ingredient and to ask about the relationship between recipe and management thing

[discussion based on "Current Situation: Discovery with TD Repository"]

kaz: given your clarification, I think the main purpose of this "recipe" proposal is providing syntactic sugar kind of help for developers so that developers can generate WoT apps easily. on the other hand, the capabilities mentioned here are quite related to ManagementThing, so I'd suggest you collaborate with TD guys (esp. ManagementThings guy).

dsr: trying discovery on the semantic layer would be complicated

<McCool> mccool: the way I see this: recipes are an application layer that uses wot. you find a recipe you want in a marketplace and want to instantiate it using your devices. One step of that is the discovery of local things that match the necessary ingredients for the recipe. but in addition to discovery of local services, you may also have to instantiate (a thing), install (a script), or find (eg on the cloud) processing services

dsr: and maybe should be done on the application layer

darko: how to know what devices are online, etc.
... would be good to provide this kind of "recipe"

dsr: would continue the discussion
... how to handle change of the things

mm: regarding collaboration
... what's the plan of the prototype?

darko: continue to work on open source

mm: on the thingweb

mk: we can have some more local chats before lunch (if you want)

[ lunch and chat ]

Marketing [WoT]


(naomi joins)

mk: generated some rough sketch here
... landing page is the overall information
... it's a lot of work to maintain this
... (shows several examples)
... also updated the whitepaper page
... link for developers

dsr: should put as an agenda item for the Chairs meeting

koster: calendar!

mm: 2 large categories
... f2f meeting
... presentations

mk: so much to do

<naomi_> kaz: there is a specific calendar page

<naomi_> ... we might be able to pick up wot events to link here

mk: need for calendar: easy for people to get information and easy maintenance
... and then Charter, ML, participants, join the group

dsr: maybe could start with some intermediate page

mk: would update step by step
... that is the starting point
... for www.w3.org/WoT

dsr: outreach point of view?

mk: we should make better impression
... but don't have enough time for blogging

dape: thre should be something up-to-date

dsr: blog post is some story on each event
... could add a link to the blog page

dape: missing community group

dsr: trying to reboot the CG
... need a link to the CG

mk: what's the status?

koster: IoT vocabulary?
... probably as related work?

mk: should clarify the purpose, etc.
... we have too many MLs, etc.

dsr: could simply add a link

(some more discussion)

mk: would add icon for vocabulary work?

<naomi_> kaz: we need to specify what kind of page should be linked


intermediate page

mk: will update the initial draft pages

Messaging [WoT]


mm: [Messaging]
... [Key Message Components]
... [Existing Key Value Message]
... What is the WoT and What is its value?
... need to sharpen the Charter text up
... essential difference between WoT and OCF
... [Proposed Key Value Messages]
... longer version
... 1. The Web of Things extends Web technologies to the IoT. It enhances interoperability by providing a standardized descripton of IoT network interfaces so that everyone can use everything easily.

dsr: how to fit people's business?

mm: related to the #3
... The Web of Things approach enables a larger ecosystem of things. IoT devices can use Web of Things standardized descriptions to adapt to and communicate with devices from multiple IoT ecosystems
... #2
... These standardized descriptions are based on standard web technologies in common use such as JSON. An extension point to support W3C semantic technologies provides powerful tools for semantic interoperability.
... avoid using tech term, "protocol binding", etc.
... #4. Horizontal building blocks that span ...
... [Proposed Differentiation Messages]
... How is the WoT different from otehr IoT standards?

<mjkoster> (comment) need to focus more on delivered value in the value points page

mm: powerful
... 1. The Web of Things describes how to interact with things. It does not prescribe specific network interfaces for things. Because it can describe how to interact with many different standards it can be used as a basis for a common ecosystem of things without mandating how those things operate or communicate.
... 2. The W3C standards process is open and royalty-free. W3C standards can be used by anyone and all specifications are public.
... 3, 4, ...
... [Planning]
... online presence
... other collateral
... presentation material
... images and diagrams
... datasheet/brocure
... webex
... white papers
... tutorials
... executive summary
... online demos
... books
... executive summary for business people

kaz: proposals for the landing page?

mm: mostly

koster: 2 things
... historical stuff
... best practice

mk: meaning current practice?

koster: no, what we have doing

mk: working group lists drafts
... IG also lists notes

mm: use cases are important
... references for security as well
... links as kind of footnotes

dsr: sometimes better to describe keywords?
... should work with the BusDev Team

kaz: already working with the MarComm Team
... and Coralie Mercier, the MarComm head agrees

mm: should have joint calls with them
... maybe in 2 weeks or so

<scribe> ACTION: kaz to talk with MarComm/BusDev Teams about the expected joint calls [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action01]

<trackbot> Created ACTION-108 - Talk with marcomm/busdev teams about the expected joint calls [on Kazuyuki Ashimura - due 2017-07-20].

Next steps for PlugFest


matsu: we had some missing functions during the PlugFest on Monday...
... so would propose something
... [DONE until Dusseldorf meeting]
... [Next step of plugfest]
... consider more practical use cases for the next plugfest
... cooperation of two/more WoT Servients
... entegraton of scripting apps and WoT devices
... e.g., the diagram at "5.4.2 Smart home" from the Architecture draft
... [Some requirements for the next step]
... how to exchange TD between WoT servients
... how to manage TD among WoT servients
... how to connect WoT servients via firewall
... how to manage data of the devices to cache on the Internet/Cloud
... should refine the Architecture draft and make spec!

kaz: you want to define "WoT interface" as the inter-servient interface. right?

matsu: yes.

mm: next plugfest would include bridge between wot and ocf
... and possibly use recipe for automatic bridging

kaz: what do you mean by "recipe"?

mm: some kind of additional semantics

mk: we can look into the "WoT interface" here
... e.g., oneM2M ones
... and wondering if it's possible to have yet another servient

matsu: possible

mk: local servient's capability mirrored by firewall gateway

mm: have to sort out how it works
... with untrusted network

mk: part of other proposal on security mechanism
... in addition to that viewpoint, various interfaces to be connected
... HTTPS can be something related to authentication

soumya: @@@

mk: specific scenario or technical scenario?

soumya: technical scenario

mk: everybody doesn't have to do everything
... we can share

mm: consider expected technical infrastructure
... cloud, local network, firewall, etc.

mk: can provide cloud side in Munich, etc.

matsu: [Overview of our demonstration in Osaka]
... smarthouse demo
... in Kanazawa far from Osaka
... also Nagoya
... HTTPS is one of the possible secure connections

kaz: so you want to try some other security mechanisms?

mk: e.g., CoAPS
... and proxying

mm: patterns we discussed regarding node-wot
... single servient as a proxy
... can take on and make it work

kaz: will generate a wiki for TPAC f2f
... so please put your scenario on the wiki asap :)

Next f2f


mk: need to talk about the next f2f
... will be held during TPAC
... update on the preparation?

kaz: to be confirmed

mk: need confirmation for Sunday
... and Wednesday demo

(like we did in Lisbon)

soumya: what for Sunday?

mk: preparation for plugfest
... need more preparation for smooth plugfest
... maybe full weekend (=2 days)?

mm: happy with 2 days during weekend
... we could split plugfest into 2 pieces
... demo and presentation

mk: we don't really have "openday" during TPAC
... Wed is the plenary day
... with several breakouts
... last week we talked with the Eclipse Foundation

mm: do we want to talk with others, e.g., Amazon?

mk: maybe weekend or maybe Wednesday
... Mon/Tue we have our meeting
... because some people need to leave on Wed

mm: maybe some others of us can make presentation, etc.
... Amazon has a (separate) hackathon place (Amazon Lab26)
... maybe kind of open
... in downtown SF area
... great way to get an engaged venue for plugfest prep

mk: Koster, could you please reach out them?

kaz: please let me check within the W3C Team about that as well

[note: we mean Nov. 4-5 by "during weekend"]

mk: PlugFest possibly on Nov. 4-5
... and WoT demo on Wednesday

<scribe> ACTION: kaz to talk with mtgplanner about WoT demo on Wed, Nov. 8 [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action02]

<trackbot> Created ACTION-109 - Talk with mtgplanner about wot demo on wed, nov. 8 [on Kazuyuki Ashimura - due 2017-07-20].

koster: possible a WoT hackathon?

mk: maybe too ambitious

kaz: do we want to invite non-Members to this PlugFest during the weekend?

mk: that's my expectation
... then
... after TPAC
... collocated with the Security Conf
... Spring 2018, USA?
... we should outreach them

mm: IEEE conference may be more appropriate

mk: waiting until May for the IEEE one?
... you can discuss this internally
... not sure about CfP about this one (IEEE)
... also collocating with IETF
... same week?
... goes through the lists
... USA in spring, China and Lyon?
... regarding the spring one, not sure about the logistics

mm: was thinking mainly about San Jose
... maybe Qualcomm is active on the February one

mk: we're still quite flexible
... spring and summer
... collocation with related conferences would guarantee people for longer stay
... possibility in Princeton?

dsr: maybe MIT in Boston

mm: OCF has no information yet (for summer)

mk: TPAC in Lyon, France in Oct.
... would continue discussion on spring in US/summer in Asia
... WG roadmap
... this is the original one
... the red part is where we are
... Architecture is high priority
... we have nice picture on the building block
... Kaz's figure as well
... device directly vs on cloud
... also Matsukura-san's work
... design patterns on proxy, etc.

mm: we can split design pattern from the Architecture spec

mk: regarding security review
... the questionnaire is not really appropriate tool for "security review"

mm: architecture definition is not yet completed
... we have to move faster
... the questionnaire is rather information gathering
... limited scope for security review
... still gathering requirements

mk: and something after Dussedorf

kaz: wonders about the concrete publication date for the deliverables
... we could publish the Architecture document as a FPWD shortly, for example

mm: need to define the minimal requirements for security review here

mk: would ask all the Editors for opinions

kaz: could ask the security tf to review the documents as an initial review

mk: Zoltan is one of the key persons for scripting
... Kajimoto-san, Nimura-san for Architecture?
... Koster for binding

dape: we should keep the exploratory parts as well

mk: need to distinguish them from stable parts

kaz: we can distinguish unstable parts using, e.g., "Editor's Note"

zkis: regarding scripting, please right an email or issue
... and let myself, Johannes and Nimura-san know

mk: would like to talk with Editors

kaz: tx

mm: we need test suites as well

kaz: would be better to have a table of progress on our deliverables

publication schedule

<scribe> ACTION: kaz to generate table of deliverable status to manage the progress [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action03]

<trackbot> Created ACTION-110 - Generate table of deliverable status to manage the progress [on Kazuyuki Ashimura - due 2017-07-20].

<scribe> ACTION: kaz to generate a doodle for the Chairs/Editors call to see the updated publication plan [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action04]

<trackbot> Created ACTION-111 - Generate a doodle for the chairs/editors call to see the updated publication plan [on Kazuyuki Ashimura - due 2017-07-20].

<scribe> ACTION: kaz to create a GitHub repo for the Security TF [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action05]

<trackbot> Created ACTION-112 - Create a github repo for the security tf [on Kazuyuki Ashimura - due 2017-07-20].


Some more wrapping-up discussion on f2f

mk: possibility in Asia at Keio or Beihang

<scribe> ACTION: kaz to ask Keio and Beihang about possible WoT meeting in Asia in spring or summer [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action06]

<trackbot> Created ACTION-113 - Ask keio and beihang about possible wot meeting in asia in spring or summer [on Kazuyuki Ashimura - due 2017-07-20].

Modularization of TF Work [WoT]


mk: we have so many calls
... (shows slides)
... [Binding Templates TF]

mm: OCF Liaison TF might be able to shutdown at the moment given we're doing discussion on binding

mk: WG (delivery deadline 2018)
... vocabulary proposals for TD TF (under "link")
... targets: HTTP, CoAP, OCF, oneM2M
... [Scripting API TF]
... [Security TF]
... have to change some hybrid approach, top-down and bottom-up
... for security review

mm: review Editor's drafts
... creating a new GH repo for the TF
... security sections for other deliverables
... need coordination

mk: is that all?

dsr: semantic part of the LD TF would go for part of TD
... there is an overlap

mk: let's do a doodle for the binding template tf call
... TD TF
... WG: TD core model and JSON-LD serialization
... IG (validation): JSON serialization
... Binding Templates TF
... default interactions

mm: secure connection, e.g., HTTPS, CoAPS

mk: IG (validation): WebSockets
... IG (explorative): MQTT
... Panasonic is using WebSocket for event handling
... what's the difference with Mozilla's proposal?
... (WebSockets goes to WG)
... OMA LwM2M goes to IG (validation)
... SSE added to IG (explorative)

(discussion on how to deal with ECHONET, BACnet, etc.)

(binding template implementations)

mk: have an implementation in node-wot

mm: mentions web storage kind of mechanism

mk: have local communication in node-wot
... local communication added to IG (explorative)
... check with Web APIs
... Scripting API TF

zk: we made a decision for a device expose capability as service rather than api
... WG: scriptin gAPI, servient architecture

dsr: semantic annotation

mk: how semantic annotation would appear within scripting api
... (adds "support for semantic annotations and other TD customization")
... [LD and Semantics TF]
... (asks Zoltan to review the Scripting API part)

zk: ok

mk: [Security TF]
... WG: review all the Editor's drafts

mm: who is in charge of which?
... can we securely connected with WoT?

[ network disconnected ]

[ some more discussion based on Matthias's slides ]

At the end of the meeting, Matsukura-san suggested the following regarding the Architecture work:
- We publish the Archtecture document as the initial draft asap.
- We reboot the Architecture TF and start detailed discussion on inter-servient interface and its security.
- We update the Architecture draft based on the feedback of that discussion.
- If it's OK, Matsukura-san is happy to join the Architecture TF to make contribution.

And Matthias updates his slides based on that suggestion.

See Matthias's slides for the record.

[ Dusseldorf F2F adjourned ]

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.147 (CVS log)
$Date: 2017/07/21 14:06:52 $