W3C

- DRAFT -

WoT IG/WG f2f in Santa Clara

06-09 Feb 2017

group photo

Agenda

See also: IRC log

Attendees

Present
Day 1: Austin S. Lin (Google), Barry Leiba (Huawei), Kirby Shabaga (Boeing), Kunihiko Toumura (Hitachi), Masato Ohura (Panasonic), Arzhan Kinzhalin (Intel), Heikki Mahkonen (Ericsson), Takeshi Sano (Fujitsu), Takuki Kamiya (Fujitsu), Henry Andrews (CloudFlare/JSON Schema), Johannes Hund (Siemens), Sebastian Kaebisch (Siemens), Kevin Jordan (PTC), Frank Reusch (RWE/innogy), Matthias Kovatsch (Siemens), Dave Raggett (W3C), Kaz Ashimura (W3C), Peter Jensen (Intel), Moh Haghighat (Intel), Zoltan Kis (Intel), Michael McCool (Intel), Katsuyoshi Naka (Panasonic), Takeshi Yamada (Panasonic), Keiichi Tokuyama (Panasonic), Ryuichi Matsukura (Fujitsu), Hyojin Song (LGE), Kazuaki Nimura (Fujitsu), Eve Schooler (Intel), Rechard Chow (Intel), Barbara Hochgesang (Intel)
Day 2: Henry Andrews (CloudFlare/JSON Schema), Barry Leiba (Huawei), Kirby Shabaga (Boeing), Ryuichi Matsukura (Fujitsu), Takeshi Sano (Fujitsu), Kunihiko Toumura (Hitachi), Sebastian Kaebisch (Siemens), Johannes Hund (Siemens), Hyojin Song (LGE), Heikki Mahkonen (Ericsson), Kazuaki Nimura (Fujitsu), Takuki Kamiya (Fujitsu), Kevin Jordan (PTC), Peter Jensen (Intel), Frank Reusch (RWE/innogy), Zoltan Kis (Intel), Michael McCool (Intel), Kaz Ashimura (W3C), Dave Raggett (W3C), Michael Koster (Smart Things), Masato Ohura (Panasonic), Katsuyoshi Naka (Panasonic), Gregg Kellogg (SPEC-OPS), Takeshi Yamada (Panasonic), Keiichi Tokuyama (Panasonic), Simon Mayer (Siemens), Dani Grant (CloudFlare), Matthias Kovatsch (Siemens)
Day 3: Henry Andrews (CloudFlare/JSON Schema), Kirby Shabaga (Boeing), Barry Leiba (Huawei), Takeshi Sano (Fujitsu), Heikki Mahkonen (Ericsson), Kunihiko Toumura (Hitachi), Sebastian Kaebisch (Siemens), Johannes Hund (Siemens), Hyojin Song (LGE), Keiichi Tokuyama (Panasonic), Takeshi Yamada (Panasonic), Katsuyoshi Naka (Panasonic), Masato Ohura (Panasonic), Zoltan Kis (Intel), Michael McCool (Intel), Dave Raggett (W3C), Kaz Ashimura (W3C), Matthias Kovatsch (Siemens) Frank Reusch (RWE/innogy), Takuki Kamiya (Fujitsu), Michael Koster (Smart Things), Kazuaki Nimura (Fujitsu), Ryuichi Matsukura (Fujitsu),
Day 4: Kirby Shabaga (Boeing), Barry Leiba (Huawei), Takeshi Sano (Fujitsu), Kunihiko Toumura (Hitachi), Sebastian Kaebisch (Siemens), Johannes Hund (Siemens), Heikki Mahkonen (Ericsson), Ryuichi Matsukura (Fujitsu), Kazuaki Nimura (Fujitsu), Takuki Kamiya (Fujitsu), Matthias Kovatsch (Siemens) Michael Koster (Smart Things), Dave Raggett (W3C), Kaz Ashimura (W3C), Michael McCool (Intel), Zoltan Kis (Intel), Masato Ohura (Panasonic), Katsuyoshi Naka (Panasonic), Takeshi Yamada (Panasonic), Keiichi Tokuyama (Panasonic),
Remote:
Day 1: Carlos, Daniel, Mehid_Barhami
Day 2: Carlos, Daniel, Darko, Victor
Day 3: Yongjing
Day 4: Yongjing
Regrets
Kajimoto, Ohsumi
Chair
Matthias, McCool
Scribe
kaz, dsr

Contents


Day 1, 06 Feb 2017 - OpenDay/PlugFest

<inserted> scribenick: kaz

starting the meeting

mk: this is a joint meeting of the WoT IG and the WoT WG
... the first meeting for the WG
... it's open day today

mm: host and another co-Chair

mk: third co-Chair, Kajimoto-san from Panasonic can't join this meeting in person but will join remotely
... Yongjing Zhang, the co-Chair for the IG also will join remotely
... (shows "W3C WoT Mission")
... (Semantic Metadata for Interoperability)
... communication between platform A and platform B
... designing simple interaction model
... essential elements: properties, actions and events
... all the information described by TD (=Thing Description)
... the challenge is protocol
... HTTP, CoAP, OCF CoAp, OneM2M CoAP, etc.
... how to configure them and let the other side understand?
... (Binding Templates)
... (Simplify Application Development)
... (Scripting API)
... (Portable Apps Across Vendors)
... (Across Components)
... from gateway to cloud
... (TD to Augument Existing Things)
... get TD from TD repository
... (W3C WoT Building Blocks)
... WoT Servient
... has both server/client capabilities
... WoT Scripting API
... WoT Thing Description (TD)
... WoT Binding Templates
... Security&Privacy

Contributions

[Johannes Hund] Some questions that arose while implementing a WoT Servient

-> http://plugfest.thingweb.io/ Plugfest.thingweb

-> Project Thingweb@@@

jh: (WoT Architecture)
... Scripting API
... Runtime Environment

-> http://w3c.github.io/wot/current-practices/wot-practices.html#quick-start-td-samples Example 1

jh: shows Example 1 and then Example 2
... (Feedback(1): Client side)
... can a ConsumedThing instance be narrowed to a single protocol?
... which protocol to choose if several are availabie?
... is there a use case for using different ones for each call?
... would I ever retriee the TD from the Thing itself and then use a different protocol to access it?
... why is Mediatype (serialization) on link and model (valueType) on interaction?
... (Feedback (2): Thing lifecycle)
... another feed back is lifecycle
... we have addXYZ but we need also removeXYZ
... we can create but not delete Things
... we can create but not retrieve existing ExposedThings
... where does the WoT object originate (global? require/module)?
... (Feedback(3) Accessing local Things)
... discover gives me a ConsumedThing, how do I retrieve an ExposedThing from my runtime?
... (Feedback(4) Security and scoping of scripts and things)
... Things have a place, a servient where they are hosted - how about scripts?
... Isolation: can I access exposed things on the local servient "priviledged"?
... Assumption made: scripts are sandboxed, they do not share global scope but sahre the local ExposedThings
... (Feedback(5): Multi-protocol)
... Resource structure: the same for all protocols?
... Or: is there a resource for each thing and each interaction and the protocols assign there specific URIs?
... Current assumption: rules to convert (Thing, Interaction) _> URI
... Protocols and Media Types are now on interaction level - why not thing level?

eve: : use case of driving?

jh: so far a gateway use case
... edge processing, local control and back-end processing
... huge variety of edge level devices
... main use case driving our discussion

austin: ConsumedThing vs ExposedThing?

jh: I expose thing to share service
... consume is using service

mm: one way to use HTTP esp. for events
... more than protocol than HTTP?

jh: thoughts about that
... exposing thing is some way of data analysis
... decoupling actual device from the data
... you could use multiple protocols
... so far focused on Node.js but interesting to see other implementations

@3: optional type of script?

jh: shows github.com/thingweb/node-wot.../consumed-things
... based on promises

peter: proper ECMAScript 215?

jh: possibly

dsr: thinking about generalizing TD
... security, access control, business use cases, etc.
... more heavy use of linked data
... people could use the same protocols for different uses

[Frank Reusch] Networks of autonomous devices and their impact on WoT

fr: (Success criteria for WoT)
... which kind of requirements are needed from an implementation perspective?
... (We are a global leader in wind energy and operate; More than 3100 MW of renewable capacity)
... (Future oriented products and services)
... decentralized IoT
... decentralized energy solutions
... (What if the complete genetic material of a human being was stored in a single cell?)
... (A life, depending on the proper funcitonality of a single cell, would be...)
... (With DNA ("the intelligence of life") ther eis a decentralized control...)
... (Lemonbeat positioning in the OSI layer model)
... application layer: Lemonbeat smart Device Language "LsDL" (XML/XSD/EXI)
... over HTTP/CoAP
... over TCP (for HTTP) and UDP (for CoAP)
... Network functionality: Lemonbeat Radio 868MHz, Long rage, low power (LoRa Modulation)
... (How to make devices intelligent)
... Lemonbeat DNA structure
... all necessary services on board - in every device
... (How to make devices intelligent)
... Lemonbeat Chip: Silicon Labs 32-bit, ARM Cortex-M3 CPU Processor; Silicon Labs SI 446x Tranceiver
... Flash memory inckuding Firmware, Stack
... Lemonbeat Studio: access to all devices, Initial implementation, Updates flash memory, 99% offline
... (Use cases for private households (B2C - Micro level))
... smart energy can be linked to eMobility and Smart Home
... Tesla Model 3, Chevrolet Bolt (EU: Opel Ampera-e, Aauxhall), Mercedes EQ
... (Use cases for private households (B2C - Macro level))
... a cluster of power storages in a decentralized use case
... (Self learning mechanism on field level (1))
... (Self learning mechanism on field level (2))
... (Self learning mechanism on field level (3))
... authorization
... (Benefits of an integrated Web of Things)
... the use of primary devices is benericial for WoT
... (Benefits of an integrated Web of Things - contd)
... benefits of integrated WoT
... use of primary devices leads to a cost reduction
... (Increasing total integration and value of all components of a network)
... devices as a data supplier, gateway with central controller
... devices as a data supplier, primary device includes virtual proxy
... network of autonomous devices without central control
... network of autonomous devices without central control, self learning mechanism on field level
... network of autonomous devices without central control, complex self learning mechanism
... (Alternatives for WoT)
... device to device communication
... options: physical gateway, virtual proxy, light WoT stack/full WoT stack, small WoT stack
... (Alternatives for WoT - contd)
... a power supply company ofers its customers power storages in different versions
... (Findings from Silicon Valley companies and pioneers)
... in each network, the benefit increases for all participants, when adding new participants
... the vlue of a telecommunications network is proportional...
... (Feedback "International VDI Conress on IoT" 14.12.16 - Berlin)
... how intelligent devices can enhance IoT
... (Feedback "IoT Tech Expo" 23.01.17 - London)
... (Suggestion: Adding these options to the WoT architecture)
... (1) Thing to thing interaction without gateway:
... (2) with gateway

jh: two different kind of WoT stacks
... what is the main difference?

fr: covering a lot of devices
... can speaking with constraint devices using light-weight WoT
... full-spec vs light-weight
... my best choice is light-weight WoT

moh: energy area?

fr: decentralized energy and IoT

moh: there is some active device

zk: can you configure 2 different services at once?

fr: we have one generic protocol
... if you want to use different use cases, you can use the lemonbeat chip for those use cases
... we could combine different things

zk: different protocols have different provisions for security
... do you have enough computing power for various provisionings?

mk: kajimoto-san is the editor for the architecture document
... you proposed via gateway communication
... that's already included in the architecture doc

fr: talked with Kajimoto-san several times

mk: e.g., they have gateways for ECHONET
... abstraction for them as well

mm: document now on GitHub repository

[McCool] OCF Architecture

mm: OCF Overview and Collaboration
... Open Interconnect Consortium + UPnP + Electrolux, Microsoft, Qualcomm + Allseen Alliance = Open Connectivity Foundation
... working on new standards
... sharing public resources today
... (OCF Basics)
... defining data model
... 4 main things: OCF Specification, oneIoTa, IoTivity Open Open Source, OCF Certification
... (OCF Goals)
... easy for developers, interoperability, future consolidation, multiple vertical markets, scalability
... (OCF Goals - Implications)
... (OCF & IoTivity)
... 2 different organizations: OCF and Linux Foundation (IoTivity)
... (OCF - Conceptual Framework)
... Resource Model & RESTful Interactions (RAML)
... Discovery, Provisioning, Comms
... security, identity & permissions
... Transports: cable connection, wifi, zwave, bluetooth, ...
... (Accessing Resources over the Network)
... Application of Service - Resource Model & RESTful Interactions
... (Some Details)
... I'm happy to talk with you about OCF
... Michael Koster is also available
... Interaction model based on CLUDN
... traditional web type of API
... request-response and publish-subscribe
... we can't mandate what devices do
... Data models are defined using RAML
... Standards status:
... only OIC and AllJoyn standards are currently public
... Current IoTivity release supports OIC 1.2
... OCF 1.0 standard is under development
... OCF 1.0 standard will merge features of OIC 1.2 qnd AllJoyn
... Bridges being developed to allow access to OIC and AllJoyn devices from OCF

[ morning break ]

<dsr> scribenick: dsr

JSON Schema

Presentation about the ongoing work on [Henry Andrews] JSON Schema: status and outlook

A series of drafts with draft 6 in final review in February 2017

Currently tidying things up and getting ready for a release

We now require references to be to whole schemas

We also now have more uniform treatment of terms that start with $ e.g. $id

Finalizing media type registration for IANA

Most of the validation keywords are stable, but we've added a few new ones.

We considering support for limited conditionals.

Hyper-schema is under active development.

This is about adding hyperlinks to JSON.

We're not trying to compete with other approaches, e.g. JSON-LD

We're looking into a UI schema for JSON, but this is at a very early stage

Another idea is to consider metadata keywords for document generation.

We expire our drafts after 6 months (like the IETF) and want to ensure that our working documents are updated in a timely fashion.

We plan to prove hyper schema with some automated user agents.

A some point we want to roll over into an IETF working group.

We're using URI templates.

Daniel: are there any plans to specify semantic properties, e.g. age in years?

Answer: so far no, there are other approaches that are better suited

Matthias: there are some mechanisms in JSON-LD for semantic links.

Driving the design through semantic vocabularies is a valuable approach to take

Sebastian: we want to build upon existing vocabularies where practical

Another consideration is suitability for resource constrained devices, is this something where we might collaborate on?

Henry: we're open for adding new keywords but less so for changing existing stable keywords

In particular, if you could point to where JSON schema proved difficult for some use case, we would definitely like to hear about that

We can express CBOR more or less, and am definitely interested in further discussion.

Gregg Kellogg talking about JSON-LD 1.1: status and outlook

Greg introduces himself. He is one of the co-editors for the JSON-LD spec

I want to talk about the change requests we've had and are considering for JSON-LD 1.1

An October 2016 common crawl revealed extensive use of JSON-LD

Some of the topics we're looking at include collections and hypermedia API

A design goal was to allow JSON developers to use Linked Data as regular JSON

These developers focus on accessing the data and not on RDF

We use @context as an object property that maps names to RDF concepts

It also enables us to describe the type for string values, e.g. IRIs, dates, numbers etc.

Arrays are treated as unordered unless otherwise noted.

We encourage the use of @id and @type for identifiers

JSON-LD has some core algorithms, e.g. to use the @context to expand terms to full IRIs

We expected a common use case would be canonicalise terms via an expand and compact steps, so we're strong on round trip without changes

Gregg and Matthias discuss some examples

We're trying to make objects easier to find using different keys

This makes use of @container together with @id within @context.

We want to make it easier to do a good job when mapping from RDF to JSON-LD via a document frame

We're addressed nested properties via a new keyword @nest

JSON-LD 1.1 adds support for scoped contexts with a means to implicitly insert @contexts.

The work is happening in a W3C Community Group. If there is sufficient interest, it could morph into a Working Group for an updated W3C Recommendation.

We're hoping to complete our CG drafts in Q2 2017

No C implementation, so volunteers are welcomed!

But the changes are easily applied to existing implementations, e.g. Python, PHP, Java, C# and Go

Today, only one implementation fully supports the CG spec (Greg's Ruby implementation)

Greg: RDF shape expressions could be interesting for JSON schema, and can be defined using JSON-LD

This pretty much allows for arbitrary validation of RDF graphs

Happy to talk about this tomorrow

scribe: we break for lunch and resume at 2pm PST

<kaz> [ lunch ]

Scott Jenson (Google) Humility and the IoT

UNKNOWN_SPEAKER: or what the Physical Web taught me about ecosystems

We have a huge vision for the IoT rather than just little devices.

The question is how we get there. We have some insights about the value for smart homes, but it can be a little underwhelming to explain.

[joke about digging through horse manure pile to find the "pony" that must be there]

Short story about a designer in Copenhagen who made a device that recognized when he put on safety glasses and turned the workshop grinder on and likewise off when he removed the glasses.

We are seeking to create a flexible platform

Video interview with Jeff Jaffe talking about the broader implications over time for the Web of things

Too many people are creating App store APIs rather than building blocks for everyone to build on

Scott says that too many people think that the Web sprang fully formed from TimBL's head - but it wasn't like that - Tim needed to find a way to share information across the heterogeneous systems at CERN

Back to the physical web. Having one mobile app you need to install for everything you want to do or to control doesn't scale

The location field at the top of the browser is like forcing people back to a DOS prompt when they've gotten used to high res color video

The physical web bypasses entering the web address taking you direct to the web app.

Rather than having an app per device, get the device to point to the web app!

People change the address (the beacon) the device emits according to the time of day and context

a 50 cent beacon could in principle be put into medicine bottles.

A video of a Bluetooth smart toy that embeds a beacon and can be controlled from a browser via the Web Bluetooth API

<scribe> New Bluetooth spec can allows you to scan for the set of beacons, causing the UX to change automatically as you walk around a store or museum.

We've been very pleasantly surprised by the awesome ways people are using the physical web

Beacons could also start to discover each other, e.g. via JSON descriptions.

IEEE Computer article on building a Lexus out of Lego.

(from Feb 2017)

The biggest problem we've had with the Physical Web are the onboarding issues for getting people up to speed, e.g. with security.

Right now adding a bunch of new devices to your home WiFi is enough to make you break out into a cold sweat

We've got to make enrolling new devices really really easy

So smart setup is key!

How can devices easily gain access to semantic descriptions, e.g. of the rooms in your house

So the semantic map is key!

We need standard descriptions so that devices can understand each other

We know that machine learning and big data are incredible. We need a way to pull data together from different devices into one place for that machine learning to take place. How can we tell devices where to send their data?

Some kind of middle layer for devices to communicate on

A first step is centralized data.

A further idea is centralized coordination - i.e. to be able to coordinate all the devices in your home.

"The best way to ruin your product's UX is to add security to it", that's because security is almost never fully thought through

My challenge to you guys is JSON+HTTP+JS = ?

Johannes: show the slide for the 4 points you have, can you expand ...

Scott: joining the network should be easy, and the device should at that time get information about the house and its context

I buy a new lamp, plug it in, and the nearest switch then controls it. This requires the house to learn about the new device and do something that is valuable and smart for me

Eve: How about a virtual centralized perspective, i.e. coordination rather than centralization

Scott: we want to see what happens when these semantic descriptions meet with the protocols

Dave: is this a re-run of the surprise that people find when they see freshly targeted ads, how do we avoid the uncanny valley/the spooky house?

Scott: we're already there!

Scott talks about the need to balance different human needs. We want this to evolve from simple actions.

Earlier Scott worries about the failures associated with spaghetti code

If we can have machines talking to each other with shared semantics then we can explore interesting emergent behaviors

Michael: distributed RDF database would allow queries across devices in your home

Scott: identity is a can of worms, it's hard ... can we avoid the battles it brings

Dave: its my home I can name things the way I want (e.g. as for mDNS)
... there will need to be systems of authentication through

Johannes: can we split discussion of identity into the human level and the machine level for lower layers of communication.

Scott: I want to avoid not understanding why things behave the way they do, and to avoid rigid control rules.

Bruce Fleming (HP): Ambient Computing

Bruce introduces himself as an HP Fellow

Bruce reminds us of Mark Weiser's vision of ubiquitous computing from 1988.

We've seen shifts from mainframes (many people one computer) to PCs (one person one computer) to one person many computers.

Ambient computing involves computers supporting you in making intelligent, helpful decisions, and in the process disappearing into the background of our daily lives.

He shows a short video

Bathroom mirror with embedded display, voice interaction to help prepare you for the day ahead

In the kitchen helping with preparation of dishes

Keeping you on track and always present during your day

Computers weren't visible, and all the interaction was triggered by your natural interactions including spoken requests

Bruce talks about the security and privacy challenges

With smart surfaces, the systems need to know who is in eyesight or earshot

The systems constantly learn from your reactions to each situation.

We have a long way to go, but the Web of things is clearly relevant

Ambient computing is a re-emerging buzzword (Deloitte, Gartner, Microsoft, TechCrunch)

People will get used to instant answers to their questions.

Bruce shows some video of smart surface desktop concepts

Behaviors suitable at home can't be assumed to be appropriate at the office

Placing your phone on the smart surface, your phone is instantly recognized, enabling the surface to pick up where you left off

Casting, voice & audio, computer vision, gestures, smart layout, connectivity, sensors, security and hardware

Bruce summarises challenges to overcom

These include self power devices that are always on always connected, sensors everywhere require strong security, constant connectivity can lead to constant work which can be a drawback

We need to figure out how to ensure ambient intelligence addresses societies needs

Questions?

Any thoughts on monetization?

Answer: today everything is transactional, but everything you saw here, assumes commodity computing

We've found several paths to monetization, e.g. frictionless services

What kinds of ecosystem does ambient computing enable/require?

Bruce: we're going to partner with companies for the solution spaces
... the operating systems will also be a commodity

This is a multi-device, multi-OS environment and there has to be interoperability

The OS is good at resource management, but everything on top of that is from an intelligent layer above

Don't you think that Microsoft, Apple and Google won't want to play in this area?

If you go to a Microsoft conference, all they talk about is services

Zoltan: are there one or more semantic spaces and how do they interact

Bruce: the difference between home and work is fading, you're probably better connected at home

The context will be different though.

Dave: we presumably need to work on human values and a shift to cognitive computing, how do you see that happening?

Bruce: we are exploring this through a number of different approaches.

This involves a major transformation and will require a major cultural change. We've been very selective about the standards group we participate in.

[in response to a question about HP as an original equipment manufacturer]

Some companies are entrenched and change will be forced upon them by "disruptors"

PlugFest

plugfest 1 plugfest 2 plugfest 3 plugfest 4 plugfest 5 plugfest 6 plugfest 7 plugfest 8 plugfest 9

<kaz> [ Day 1 ends ]


Day 2, 07 Feb 2017 - PlugFest/Tech Breakouts

Plenary

<kaz> scribenick: kaz

mk: check agenda
... and WebEx logistics

<scribe> ACTION: kaz to allocate another WebEx for the breakout session [recorded in http://www.w3.org/2017/02/07-wot-minutes.html#action01]

<trackbot> Created ACTION-100 - Allocate another webex for the breakout session [on Kazuyuki Ashimura - due 2017-02-14].

[Matthias] Scripting API vs REST/network API - API design for HATEOAS

mk: (WG Charter Feedback I)
... Scope:
... Make Thing Description the main deliverable
... TD work has priority in the case of conflicts
... RDF dependency:<br/>... don't reinvent a similar framework
... don't make RDF a prerequisite
... Security:
... conduct security reviews before releasing WG doc
... include systematic security testing in the test suite

mm: do we hire outside reviewers for security work?

mk: one possibility is submitting an internet draft and submit it to IETF
... IRTF T2T has joint meetings as well
... (WG Charter Feedback II)
... why a scripting API for interaction?
... we expect a REST API for Things
... go back to...
... (Scripting API)
... 2 different APIs: scripting API and WoT API
... Scripting API used inside the servient
... simplifies app development for the IoT using patterns from the Web

mm: note that Scripting API is an optional feature for Servient

mk: WoT API for interoperability
... (REST API)
... given by TD and its interaction model
... client-server, stateless, cache (tricky for legacy protocols; patch through TD?), uniform interface, layered system, code-on-demand
... similar elements: data, components, connectors
... (EVRYTHNG Web Thing Model)
... 4. Web Things Integration Patterns
... 5. Web Things Requirements
... 6. Web Things Model
... how does it compare to the current practices?
... (4. Web Things Integration Patterns)
... direct connectivity: WoT API on Things
... gateway-based connectivity: WoT API on gateway
... (4. Web Things Integration Patterns - contd)
... cloud - gateway - direct

(discussion on physical devices and its shadow on cloud)

mk: (5.1 Web Things Requirements)
... R0.1: MUST use HTTP
... R0.2: MUST have Entry point URI ("root resource")
... R0.3: MUST support GET, POST, PUT, DELETE
... R0.4: MUST utilize HTTP status codes
... R0.5: MUST support JSON
... R0.6 --R0.1 (MUST support GET on it)
... note the "MUST"s above came from the Member Submission

-> https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/ Web Thing Model Member Submission

(discussion on requirements for REST)

mk: (5.2 Web Things Requirements)
... R1.1: SHOULD use secure protocol ("HTTPS")
... R1.2: SHOULD use WebSockets
... R1.3: SHOULD support [6.] Web Thing Model
...
... (5.3 Web Things Requirements)
... (6. Web Things Model)
... 6.0: Standardized relative URI paths
... 6.1: Common Constructs
... 6.2: Link to related resources
... 6.3: Values
... 6.4: Typed resources (allowed verbs and responses)
... 6.5: Semantic Extensions
... (EVRYTHNG Web Thing Model)
... (WoT Current Practices)
... mostly in line with the Web Thing Model
... evolved to: machine-understandable descriptions, multi-protocol REST support
... hypermedia controls

(JSON-LD equivalent format for small devices, e.g., CBOR or EXI)

mk: in Montreal there was discussion on level of types

henry: looking at how put was described
... within: https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/

mk: our uniform interface is a bit higher
... (Hypermedia-driven WoT)
... TD already as hypermedia controls
... links: readable property, see linking breakout
... forms: inputData for actions
... (Start Work on Hypermedia)
... Actions: response to invoke might need to describe interactions on the created running Action, e.g., monitor, update, cancel
... Events: some events such as alarms might need interaction, e.g., confirm, mark resolved
... Errors: error responses should provide interactions to solve the problem, e.g., 401 unauthorized->link to auth server
... (Hypermedia Client)

-> https://github.com/t2trg/2016-03-san-jose/blob/master/slides/11-Kovatsch-2016-03-Interaction-Model.pdf pdf on github

mk: project of mine
... high-level browse path description to interaction resource based on link relation types
... programming abstraction based on Futures/Promises
... entry point
... link relation type
... returns Future
... lazy evaluation of Future, not GET

(discussion)

mk: (Generic Process Relation Types)
... detailed state machine and high-level state machine
... (Handle Change)
... control alternative things
... add new things
... still control old things
... also control future things
... (Idea)
... diagram of ideas
... programming abstractions?

jh: comment on hypermedia client

mk: we can extend the model based on this hypermedia model

henry: think it's something actually working for WoT
... building a hyper media client

mk: think about use cases like this
... would like to create a TF
... also work for error model
... report errors and recover from them
... overlaps between those two topics

dsr: overlap with semantic work as well

mk: next Sebastian?

<dsr> A thing description can be considered as an RDF graph with links to other such graphs. So for an RDF API you have a means to follow such links to access the linked graphs

[Sebastian] TD model (discussion of the TD model independent of serialization format)

sk: would like to go a bit backward
... to make clearer understanding
... (WoT TD Basic Assumption)
... Servient1 using JS and Servient2 using C/C++
... S1 provides information and S2 consumes it
... S2 understands what S1 provides
... what is the core information of the TD?
... TD should be independent of any platforms and programming languages
... reflect the core data model
... (JSON-LD vs TD Model)
... promising candidate for TD serialization
... quite human readable, good experience in plugfests
... (Inputs for the TD Information Model)
... (Tool?)
... what kind of graphic tools?

dsr: have some idea

sk: (TD (core) Model)
... Thing has name

(discussion on "name")

sk: (starts to draw a diagram on the whiteboard)

Sebasitan's diagram

mk: would suggest we clarify the basic pieces needed for implementations
... and then we can agree on the terms
... recommending bottom-up approach

mm: building a model based on use cases

mk: we can optimize the model but don't have to use the whole RDF mechanism
... would like to summarize the discussion
... we go based on implementations using bottom-up approach
... the most important point is how many boxes are needed here (=within the TD Model)

mm: we should write down requirements

dsr: we should look at existing specs generated by other SDOs, e.g., OCF

mk: we can see their implementations via liaison

mm: grounded with the PlugFest results is important
... prototyping using RDF

mk: we have the Current Practices as the starting point
... (draws a diagram of discussion cycle on the whiteboard)

Matthias' diagram

mk: RDF prototyype => Serialization => Implementation => ER Model => RDF again

mm: like that

dsr: in addition, other SDOs' IoT platforms as well

greg: mentions importance of test suites

mk: (adds "Existing platform")

mm: wonders how to handle, e.g., OCF test suite

kaz: would it make sense to invite OCF guys and/or oneM2M guys to PlugFest?

sk: already trying, though...

mk: why don't we have a morning break now and calm down :)

<kaz> [ morning break ]

Type system

<scribe> scribenick: dsr

Matthias introduces the session and talks about JSON Schema

A discussion around the type system and which one should we choose.

Can we use an existing one or do we need to define our own?

Greg: in any case you should ground this in RDF.

<kaz> Type System discussion on GitHub

Matthias displays a table that has rows for different kinds of types and columns for different type systems, e.g. JSON schema, Schema.org, and so forth

JSON schema can be mixed into other frameworks, e.g. RAML

Specs for JSON Schema have been geared around having a media type

Matthias: the aim is to have a machine interpretable format, so that a servient can understand the data model types.

<kaz> 3.2.4 Type System from the Best Practices document

Interactions can be considered as web forms that guide how to interact with a remote server

Hyperschema covers both client requests and server responses.

Some discussion around REST APIs in relation to what is needed in the request and response.

Matthias: the thing description enables a client to know how to interpret the server's response.

In the WoT IG current practices, we have used JSON Schema to describe the structure of the data in the requests/responses.

Greg: one of the reasons for using URIs for naming is to allow you to dereference them to get further information.

Time for thinking about how to evolve JSON schema to better support the increased level of interest in Linked Data and JSON-LD

Matthias: the recent discussion around iot.schema.org sounds promising.

Its great to have people from the different groups here today, and it would be great to continue this remotely (some discussion about number and timeslots for telecons)

Matthias: we need to be careful to avoid tying the data models to the serialization formats

Sebastian shows a slide where JSON Schema is used to link to an external model (modelReference)

Some issues around use of "properties" and potential role of scoped contexts in JSON-LD as a work around

<kaz> BIG IoT EU Project

Sebastian shows an example from the EU project BigIoT which he is a part of

MichaelK: I've seen "describedBy" rather than "modelReference".

Greg talks about having a document being both JSON-LD and JSON-Schema

Both specs need a namespace for their core concepts. In JSON-LD is is common to alias terms beginning with $, except for @context where must use the term as is.

The $id in JSON schema does provoke a lot of discussion as it can be a little confusing

There is a means to set the base URI when combining several schema into one document.

MichaelMc: We can used JSON-LD's scoped context to only apply some aliases within the scope of a valueType object.

Greg and Henry agree to further discussions on avoiding conflicting identifiers in JSON-LD and JSON Schema.

JSON Schema exists to describe the structure of a document, whereas JSON-LD exists to express Linked Data in JSON.

They therefore serve different purposes and are complementary.

Greg: it would be interesting to use JSON-LD to embed annotations into a JSON Schema description of a JSON document.

Matthias: for thing descriptions we have requirements where both JSON-LD and JSON Schema are relevant.
... we will have the security break out at 13:30 PST

<kaz> [ lunch ]

Security for the Web of things

Zoltan introduces the session, starting with a review of security in OCF.

A platform can host multiple devices, and a device can host multiple resources.

Security is needed for connectivity, discovery, access control and device management.

Each device as a globally unique UUID that is validated by OCF

Access control is granted on the level of the device resources

The access control information is held in secure storage.

All requests are passed through the OIC resource manager.

Security bootstrapping is complex: on-boarding, provisioning and configuration are defined by OCF.

Configuring resources and provisioning cloud services are application specific.

OCF hasn't discussed how to provision cloud based services.

OCF devices may act as clients and/or servers.

Access control lists are held in the server or in an external resource.

OCF on-boarding involves a transfer of ownership, which entails anonymous key exchange using the Diffie-Hellman algorithm.

Alternatively, you can use a clean room transfer (to avoid man in the middle attacks)

Or you could use a second channel, e.g. NFC or Bluetooth

Provisioning deals with certificate exchange.

This is followed by a configuration step.

Message integrity is based upon DTLS over CoAP, along with JSON Web Encryption + Web Signatures.

What are the prerequisites for the Web of things in respect to security?

Is on-boarding and provisioning in scope for the web of things, or are these something specific to the given IoT platform?

Zoltan: I've described OCF's approach to security as relevant background knowledge, but we need to discuss the requirements more broadly for the web of things

Do we go by the web browser security model along with an origin URI?

I don't think so, as it doesn't scale well.

Black listing is poor practice. White listing is better.

Zoltan: Ownership transfer is best done with manufacturer's certificates.

Matthias: we need authorization in addition to authentication

Dave: last year we were discussing organising a joint white paper on security with individual contributions from people from a broad range of organisations.

Zoltan: perhaps we just need to establish a secure tunnel and defer security to the platform.
... I have no opinion in respect to the joint white paper

MichaelMc: One suggestion is to involve the IETF to help drive a dialogue on security.

Matthias: We could write an Internet Draft on a particular scenario and use that for discussions within the IETF, and to focus on how to use the mechanisms that the IETF groups have developed.

Michael: the WoT WG charter makes a number of requirements on the work we are expected to do, including strong security review.

Matthias: different platforms use different security building blocks.

If a device hasn't been onboarded then we wouldn't have a means to talk to it.

Discovery is dependent on the kind of network things are hosted on.

Johannes: the IG discovery task force came up with a handful of categories of techniques for discovery.

In principle, thing descriptions could include certificates signed by device manufacturers.

The biggest problem is that we now need to attract security experts for the task force.

scribe: end of session ...

PlugFest (contd)

plugfest 1 plugfest 2 plugfest 3 plugfest 4 plugfest 5

<kaz_> [ Day 2 ends ]


Day 3, 08 Feb 2017 - Tech Breakouts

###

[McCool] OCF interoperability

<kaz> scribenick: kaz

mm: shows the draft charter for the OCF/WoT Liaison TF
... will merge the latest pull requests
... scope
... Enabling the use of web technologies enabled by the W3C WoT recommendations to OCF devices
... OCF has its own data model based on RAML
... (put proposals on the whiteboard)
... Next plugfest:
... OCF
... -> convert RAML data models to TDs
... -> generate interfaces
... -> based on T.S. WoT-node interface

mk: what kind of interface?

mm: (draws a diagram on the whiteboard)

<img />

mk: description using TD for OCF devices?

mm: may have multiple RAML files for one TD

sk: mapping TD to RAML as well?

mm: (adds another direction from TD to RAML)
... conversion from RAML to TD and then go back to TD from RAML, and get the same content

zk: so the TD can be converted to RAML and work for the OCF devices using REST/CoAP protocols

(discussion on action and operation)

dsr: naming convention?

zk: you need to generate OIC request

mm: (adds test cases to the interface conversion portion)
... round trip tests

dsr: what about IoTivity?

mm: bunch of physical devices
... we can have a simulator
... how do we create that?

zk: we could use real devices
... do we have RAML Things?

mk: this is all scratch and handling both the areas (WoT and OCF)

mm: we should accumulate our efforts

dsr: could you please gather TDs from PlugFests?

sk: we can upload all the TDs

jh: good to have some specific repo for that purpose

mk: do we want just TDs or including background information as well?

zk: good to have background information as well

dsr: collecting ideas is valuable

mm: we need more structured approach for testing

dsr: you can start with TDs
... but need some more data, e.g., JSON, to generate tests

kaz: who would lead this work?
... part of this OCF/WoT liaison?

mm: right

[Yongjing] oneM2M interoperability

yz: (shares his screen)
... Initial Discussion on WoT-oneM2M Interworking
... Content: Interworking Scenarios, Information Model Mapping
... (Interworking Scenarios (1))
... exposing oneM2M interfaces to WoT systems
... (Interworking Scenarios (2))
... transparent interworking
... encapsulate the whole WoT data model into oneM2M containers/flexContainers
... sensors expose interface using WoT I/F
... application entity (AE) as inter-working proxy encapsulates TD
... another AE uses the TD
... not the best solution, though
... (Interworking Scenarios (3))
... direct resource mapping with TD (like SDT/HAIM mapping or AllJoyn Interworking)
... fine granularity but still some limitation
... (Interworking Scenarios (4))
... semantic interworking (using generic interworking framework and base ontology mapping)
... semantic interoperability and automated
... limitation: ontology mapping may not be fully compatible
... those are potential scenarios
... (Information model mapping (1))

mm: what is the priority?
... what to start with?

yz: scenario 1 would be the best
... other scenarios would let oneM2M to consume TD

mm: oneM2M might have more flexible mechanism than OCF
... automated test for oneM2M situation?

yz: don't have clear view yet
... need some solution
... would ask oneM2M guys for ideas

dsr: would like to continue collaboration for next plugfest

mm: generating TD (for WoT) and RAML (for OCF)
... how do we arrange testing?

dsr: oneM2M model is XML-based
... maybe we could generate TD based on that

mm: who does what?

dsr: need more volunteers

yz: maybe somebody from the oneM2M side as well

dsr: node.js for accessing oneM2M module?
... maybe we can look into that
... should be able to create one with your help

mk: there is a oneM2M module

mm: we need to have something opensource-based

dsr: any companies for volunteers?

yz: would like to check within oneM2M

mm: is anybody here in the meeting room actively involved in oneM2M?

(no...)

mm: we should get some representation from oneM2M

dsr: we could invite external experts to PlugFest as well

mk: question on scenario 4
... have you identified the mapping issue?
... we might want to have a narrow base ontology
... for atomic use cases

yz: conflict from one domain to another

kaz: question about how to coordinate

mm: discussion on testing

kaz: maybe at some point we might want to have a dedicated testing tf

mm: make sense
... any volunteers?

mk: raises his hand :)
... already done some work
... can give some guidance as well

mm: you might want to generate a charter for that

yz: continues his slides
... (Information model mapping (2))
... oneM2M Base Ontology

Yongjing's slides

yz: note that oneM2M doesn't model 'event'
... base ontology deines upper layer semantics for human understanding
... (Information model mapping (3))
... (Information model mapping (1)) again
... WoT TD also describes interface while SDT doesn't
... instantiation as HAIM
... (Information model mapping (3))
... semanticDescriptor
... oneM2M SD (semanticDescriptor) supports semantic discovery/query while WoT TD doesn't yet
... oneM2M SD is more distributed to resource level while WoT TD is more at the "thing" level
... oneM2M SD is using RDF/XML while WoT TD uses JSON-LD
... (Information model mapping (4))
... there are a lot of more metadata points
... WoT metadata/data is stored in more centralized way in TD while oneM2M metadata/data is more scattered into different resource types

mm: questions?

mkoster: driving use cases?
... two way bridging from one to another

dsr: use cases which the current TD don't cover

mm: event model difference is generic
... should have concrete use cases

zy: basic mapping rules then concrete use cases, maybe

mm: you're using ER diagram and RDF diagram
... we need information for TD model
... discussion yesterday as well
... what's the right way for information model regardless of serializations

zy: don't have any specific preference
... maybe RDF?

mm: zoltan, can you mark observable within OCF?
... any way to distinguish property within oneM2M?

s/zonlatn, can you/can we/

sk: would like to see this oneM2M ontology within our PlugFest
... nice to include it

mm: compatibility between oneM2M ontology and TD?

zy: mapping or annotation link?

mm: another point is modularity

zy: note it's difficult for oneM2M people to understand different data model like TD

mm: thanks, coffee break now

mk: after break, there will be scripting workshop at Santa Clara
... and semantics/connection to RDF at Board room

[ morning break ]

<dsr> The IRC channel for the Linked data and semantic processing break out is #wot-ld

[Johannes] Workshop Scripting: conclude upon Promises / callbacks, CRUDN/Things to provide a conseted spec for implementation and further evolution

[ remote: Daniel, Darko ]

(nimura-san is preparing for his presentation)

[Nimura] ScriptingAPI: Understanding the architecture slides

kn: (Scripting API)
... scripting API provides means for discovery, provisioning and control of Things
... programmers don't have to care about protocols
... (1. ExposedThing)
... provisioning: development and setup
... exposeThing generate a TD and expose the server API
... 1. developer writes an app script using exposedThing with callback accessing a Thing
... (Runtime: Control of Thing)
... (Runtime provisioning: add Thing)
... (ExposedThing can be used in any layers)
... omitting consumedThing intentionally
... (ExposeTHing in various layers and combinations)
... (2. ConsumedThing)
... Provisioning: search a device initiates a discovery and setup a thing API to use
... 1. discover device
... 2. download TD
... 3. parse TD
... 4. expose client API
... (Runtime: Control of Thing)
... (Runtime provisioning: search and use another Thing)
... (ConsumedTHing can be used in any layers)
... layered mechanism
... client, cloud, gateway, device
... (ConsumedThing in various layers and ...)
... (Example: WoT Server/WoT Client)
... electronic applicance with WoT server is controlled by a remote controller with WoT client
... (3. WoT Servient (Consumed/Exposed Thing))
... the server on the right side exposes "Thing"

jh: device side on the server and application side on the client?

kn: yes

jh: same app script for various setup, e.g., direct connection or remote?

kn: right

mk: the light should be connected with the server side, shouldn't it?
... script for device control is for low-level hard ware control

zk: TD repository includes TD instance?

jh: we need to describe interaction model first

mk: what is the expectation for TD template?
... use case behind template?

jh: possibly we could have one declarative template
... or generate it programmatically
... keep it open for the both way

mk: TD is generated on-the-fly
... what is the right time to put that to the TD repository?

jh: maybe not all the runtime support on-the-fly generation
... we don't have any method to communicate with the TD repository so far
... there is a TF for discovery discussion

zk: we could have a property and interpretation by some ontology
... OCF has some meta property
... including if the Thing is discoverable
... ontology for that could be standardized

kn: we don't have that kind of ontology now
... comments from the telco includes
... consistency with TD format of the Santa Clara version
... semantic expressions as an optional parameter to the addXYZ methotds of ExposedThing
... also ConsumedThing/Discovery does provide semantic part already by "discovery filter"

jh: we don't need to change those methods if the ontology changes

zk: implementations need to know what is provided

mk: this is application level

zk: what my binding needs to do?
... how to generate some concrete OCF binding?

jh: I see your point
... we could offer an API for semantic annotation

zk: assuming applications can get information transparently?

jh: yes

mk: we don't have a model in which property can be observed

jh: so far all the interaction is request/response

zk: need a separate request about observable or not?

jh: let's take another example for this discussion
... what is needed for the Thing level or the interaction level

mk: question on Scripting API
... page 1
... "using scripting API..."
... need addition, e.g., to tell what the vocabulary and annotation is like

zk: how to do that in a generic manner
... giving an example would be helpful

jh: let's go through Nimura-san's slides and then have discussion later

kn: p14
... (Example: Voting)

kaz: question about the "client" and "server" inside the servient
... maybe it's misleading to have them within a servient

mk: we should fix the diagram and have discussion during lunch, etc.
... this diagram is a good starting point

kaz: ok

kn: (Comments from telco)
... how to deal with installing apps
... exposeThing is less important because Things are already there
... but not the case for gateway/edge, etc.
... inspection model of TD
... consistence with TD format of Santa Clara version

jh: tx
... many discussions on exposeThings and consumedThings
... (shares his screen on WebEx)
... Open Issues on the W3C Web of Things Scripting API
... session tomorrow
... had discussion on ConsumedThing

mk: had added some comments here

jh: consumedThing API
... getDescriptin() call

Open Issues

[[

interface ConsumedThing {

readonly attribute DOMString name;

Promise<any> invokeAction(DOMString actionName, any parameter);

Promise<any> setProperty(DOMString propertyName, any newValue);

Promise<any> getProperty(DOMString propertyName);

ConsumedThing addListener(DOMString eventName, ThingEventListener listener);

ConsumedThing removeListener(DOMString eventName,

ThingEventListener listener);

ConsumedThing removeAllListeners(DOMString eventName);

object getDescription();

};

jh: do we need method to get property?

zk: why the consumed side does discovery?
... not sure why we need getDescription here

mk: how to access the semantic description?
... more specific access through API for semantic description?

jh: properties that belong to the representation vs meta-properties that belong the ConsumedThing

[[

interface ExposedThing {

readonly attribute DOMString name;

Promise<any> invokeAction(DOMString actionName, any parameter);

Promise<any> setProperty(DOMString propertyName, any newValue);

Promise<any> getProperty(DOMString propertyName);

Promise<any> emitEvent(DOMString eventName, any payload);

ExposedThing addEvent(DOMString eventName, object payloadType);

ExposedThing addAction(DOMString actionName,

object inputType,

object outputType);

ExposedThing addProperty(DOMString propertyName, object contentType);

ExposedThing onInvokeAction(DOMString actionName, ActionHandler callback);

ExposedThing onUpdateProperty(DOMString propertyName,

PropertyChangeListener callback);

ExposedThing addListener(DOMString eventName, ThingEventListener listener);

ExposedThing removeListener(DOMString eventName,

ThingEventListener listener);

ExposedThing removeAllListeners(DOMString eventName);

object getDescription();

};

]]

jh: what invokeAction returns
... might be a simple type or an object

[McCool] Semantics and connection to RDF

[Dave] Linked Data and Semantic Processing Task Force

scribenick: mjkoster

<dsr> The draft slide is at https://github.com/w3c/wot/blob/master/TF-LD_charter.md

External standards to look at: echonet lite, OPC/UA

discussion of how the connectivity protocols relate to data model standards

(dsr) we should engage people around these protocols

(dsr) focus on the information model more than serializations

(dsr) example of linked data grammar graph based on RDF shape constraints

shape rules

(sk) does this define a standalone vocab or is it mapping to another ns?

(vc) there is some similar work using owl to constrain instances

(dsr) this focuses on validation vs. inferencing

discussion on data type rules on slide 9

does this constrain syntax or semsntics?

This is toward constraining semantics

this should define a higher level of semantics on top of JSON schema type definitions

discussion on composability

Discussion on core data types

(dsr) need to coordinate these definitions across across different organizations

(dsr) need to coordinate units definitions across different orgs

discussion of IoT platform as a defined RDF concept which can include metadata for

discussion on how to use ontology

(sk) question on working mode; where there seems to be a lot of overlap with other work being done in the IG/WG

discussion of modeling context and environment

(dsr) communities to get together to create application vocabularies

(mccool) review charter and deliverables and discuss the time frame, etc

(sk) start with a prior art review

<scribe> new topic: charter review

(victor) should we identify platforms to inform use cases

(mccool) identify priorities

(koster) need to identify items to constrain scope to some specifics

AI foa all to review the charter on github and make issues, PRs

(mccool) could this be a good way to define an information model for TD? THis could be a deliverable

(sk) there is already an RDF model for TD, the WoT Ontology

<victor> Out-of-scope: Dave, one of your slides mention SHRL (shape rule language). Is that your own terminology or does it have a spec somewhere?

(sk) what can we deliver into plugtests?

(victor) identify vocabs that we could already use

(mccool) another example, we could look at normalizing semantics fopr units

(sk) should focus on the gaps, on what is missing from our current approach

(mccool) we should distinguish between IG wotk and WG work

(mccool) suggest making this a TF of the IG that can also have impact on the spec

(dsr) what is the time scale?

(mccool) firm draft by EOY, this should impact in about 6 months for first deliverables

(mccool) first task could be the information model

discussion on how to generate use cases and requirements

actions today: review slides and charter, make github issues, start discussion on schedule

actions: get needs from other groups in WoT

discussion of structure, dsr will be th einitial point of contact

<Sebastian> Victor and Darko are interested to be involved in this TF

use the mailing list and use [tf-td] in subject

<Sebastian> Darko is interested to be the chair of this group

who are volunteers? where is the roadmap maintained, etc.

(taki) hsould define goals so people can decide their participation level

goals: define the technology intersection and identify value add points

<kaz> [ Lunch until 2:30pm ]

[Michael Koster] Linking

<scribe> scribenick: dsr

Michael Koster introduces the session: linking in respect to related Interactions, sub-Things, groups, collections

or "WoT Linking and Collections"

Let's talk about when you have a collection of things, e.g. buttons, or a refrigerator with a freezer compartment and a cooler compartment.

Let's start with a row of buttons. This could be modeled as an array or a collection or ...

Dave: can you identify a button with a number in an ordered collection, or perhaps a name in an unordered collection.

Another consideration is hierarchical compositions of re-usable sub-things or capabilities.

We want to describe the things that we want to compose.

The properties of the items may be different, e.g. a switch on the left or a switch on the right.

How do you cater for indexing or grouping.

The collections and compositions could be dynamic

Dave: I found vectors convenient for some of the use cases where the items were named and had the same model.

e.g. x, y and z coordinates

How do you dynamically create, update or delete items in a collection/composition?

What are the set of verbs for operating on a collection/composition?

Dave summarizes his model of collections and compositions which is formally described in terms of linked data and graph unification.

Michael: I would like to understand how you do this for thing descriptions, what story do we tell to app programmers?

Johannes: you could have linked from one TD to another.

(Dave indeed, things as named properties, or import relationships)

What is the impact of collections on security?

Michael: access control lists need to be able to handle collections and items.

Sebastian: you can use contexts to reference the metadata terms.

Dave: with a property whose value is a thing, you need to link to the thing's model

Michael: we could introduce "link" as a peer of "property", "action" and "event".

We need to enable the IoT platform's support for multicasting to a collection of things, e.g. OCF batch collections.

The links between collections and items could be traversed in either direction, e.g. a light that knows the room it is in, and the room that knows the lights in that room.

If you want to invoke an action on a specific item in a collection, it can be convenient to model the item as a thing.

If you want to invoke an action on the collection you define the action on the thing with that collection.

Zoltan: when you have things that have things as properties, when do you instantiate them?

Dave: my Node servient does this automatically when the referring thing is created.

Zoltan: how do you refer to sub things, e.g. for discovery?

Dave: via a path expression as in JavaScript a.b.c[2].

You can update the thing model directly via the thing API as the model is exposed as a property of the thing.

Michael: we could also look at a declarative means to update thing descriptions.

[Matsukura] Synchronization of WoT Servient update

Present
Matsukura, Ohura, Yamada, Matthias, Kaz, Nimura

scribenick: kaz

rm: (Background).
... synchronization is necessary for some conditions
... WoT servient have Things corresponding to devices
... WoT servient on a gateway tied with devices
... application can control the device (=original device) through another WoT servient on cloud
... (Use case 1: Smart home)
... application can't control the device directly
... (Use case 2: Smart factory)
... WoT client on cloud collects data from WoT servients that arae connected to factory devices.
... Services analyze the data and users monitor the status from a browser
... all the devices and network facilities are connected within some factory
... and sometimes the internal network is split into sub networks
... (SYnchronize WoT Servients)
... a legacy device is connected to a Servient on a gateway
... this is the original device
... notifies the device's capability to the cloud side based on the TD
... the servient on the cloud side has a shadow device
... (Control actual device from App script)
... if the app script changes the property of the shadow...
... (Handle event from actual device)
... when the legacy device generates an event, the original devices synchronize it to the shadow
... synchronization between the gateway side and the cloud side
... (Sample implementation on this PlugFest)
... some devices connected to their gateways with legacy protocols
... server and gateways synchronize with WoT APIs
... (How it works?)
... local device is discovered by the local gateway
... i.e., a local servient
... gateway notifies those devices to the server, and then both of the WoT servients start synchronization
... (What are the issues?)
... we should specify:
... how to search original devices on gateway from cloud?
... how to expose Things to other servients and consume them?
... how to synchronize device resources between WoT servients?
... set and get operations are supported by WoT API but how to communicate ia firewall between the gateway and the cloud?
... we should also consider:
... how to handle time critical devices from the cloud?
... process on local gateway first, and then notify the results to the shadow device
... requires edge-computing capability
... would like to start discussion about this within the IG/WG

mk: part of the architecture discussion in general
... property/action/event
... depending the implementers
... Siemens has something looks a bit different
... maybe same vocabulary but different work flow
... the second alternative is really standardize something
... those are the 2 options
... more flexible or standardization (or half way solution)
... context for cloud mirroring
... or replication
... implementers can make their choice

rm: who manages the whole description?
... universal repository?
... within our implementation, all the information was on the server side
... the architecture document specifies the basic mechanism
... expose/consumed Thing within the servient

mk: we should start with flexible use cases
... cloud mirroring
... we don't need to standardize anything other than the vocabulary
... both the use cases (smart home and smart factory) are quite similar
... Johannes has been doing something similar
... please go back to the schema thing

rm: go back to (SYnchronize WoT Servients)

mk: light-weight oneM2M architecture
... what you expose the Things
... there is a Siemens internal project
... OCF also goes in this direction
... Samsung, etc.

rm: our implementation uses HTTP
... would like to implement protocol binding for MQTT, etc.

mk: so does the "app script" provide HTTP interface?

rm: yes

mk: proxy or shadow on the cloud side
... this can be implemented just using scripting API
... and then we can compare with the existing approach
... you can put your ideas on the discovery document
... we need local discovery
... where the "legacy" stuff would fit?

rm: many standards include discovery capability

mk: we can present in detail in Ohsaka
... so need to finish by the end of April
... Nimura-san also made presentation
... also how to manage the certificate?

rm: would like to create functional use cases

mk: the transitions are mandated?

rm: would try several devices

mk: gateways are already registered with the cloud

rm: any other comments?

ohura: no specific comments

mk: activating the shadow is starting the Thing
... could you share the slides?

rm: yes
... will send them

kaz: this topic will be handled within the main call rather than a separate TF. right?

mk: this topics should not take too long time

kn: @@@

mk: there is a hook missing
... topic to consider
... the topic on time-sensitiveness
... the application may move the logic to the gateway
... think that's possible
... but how to associate local things?

rm: application running on the gateway side
... in this condition with time critical devices
... not collaborating actually
... should we discuss this within the group?

mk: need to make sure APIs and possibility

kaz: maybe implies global time stamp within TD?
... not only time stamp but time management mechanism based on time stamp within TD
... further discussion should be held within the group
... but if we want to handle time-critical devices, we need some kind of time management mechanism

[ afternoon break ]

[Johannes] Subscriptions / data streams / events

-> https://www.w3.org/WoT/IG/wiki/images/8/8b/Subscriptions-sc.pdf Johannes' slides

jh: (Proposal for Events and "streaming data" use cases)
... (Separate subscription management from actual data flow)
... Source <-> Sink
... Source<-Subcribe-Client-Publish->Sink
... (Proposal)
... establish resource-based management for subscription
... subscription managemetn separated from the actual data flow
... define interaction types for W3C WoT model
... DataSource / (EventSource)
... semantic type, output type, links
... DataSink
... (Datastreams Thing model extension: Thing description view)
... DataSource example and DataSink example
... (Datastreams Thing model extension: Scripting API view)
... (Datastreams Thing model extension: Protocol binding view)
... (Next steps)
... discuss proposals/feedback
... write down proposa to current practices
... trial in running code

mm: interested in demo with video streaming

mkoster: edge computing things are good

mm: OpenVX is good to see
... good to have edge-based video camera

mk: note we should concentrate on IoT side

jh: might want to have video streaming during the next PlugFest

zk: need to put some use cases

mk: event going along with video stream

mkoster: possibly HTTP plus MQTT (which covers what HTTP doesn't handle)
... data source could be a video camera

mk: can we collect what people really would like to do?

jh: my point is this protocol binding part
... shows (Datastreams Thing model extension: Protocol binding view)

mm: think we need additional property

zk: where to connect
... a sensor to be connected to one specific device?
... provide data to outside?

mk: would like to collect concrete ideas

jh: everybody can elaborate their use cases

kaz: would like to see the relationship between this discussion and (1) TV group's Cloud Browser discussion and (2) VW's VIWI proposal which uses combination of HTTP and WebSocket

jh: shows: http://resthooks.org/docs/

mk: we already have very specialized protocols
... REST hooks may actually handles them
... we need to implement protocols
... started some notes

zk: would like to talk about the possible API structure with Johannes

mk: would clarify the next steps
... REST hooks for Johannes
... exposing data source, etc. for Zoltan
... using OCF? BLE?

zk: doesn't matter
... thinking about the TD part

mk: what would be the data source for the streaming?

zk: at this point not interesting in protocols
... rather interested in default resources

mkoster: IoT REST API server

zk: right

mm: HTTP, WebSocket, TCP

mk: panasonic using WebSocket?

naka: we have local devices using legacy protocols

mk: JSON object?

naka: events

jh: JSON document?

mk: you might want to try converting to this model

jh: TD stuff

mk: anyone else?

(none)

mk: good starting point

kaz: at the moment, we're not interested in adaptive streaming but would start with simple streaming. right?

mk: yes

[Dave] WoT Contract

Present
Sebastien, Dave, Andrew

scribenick: dsr

Sebastien describes the role of contracts in Big-IoT EU project.

This has an app store with suppliers and consumers, and

One question is around the dependencies on a consumer to be

Sebastian explains how in BigIoT a provider registers a TD

The provider registers a large TD, but the client is a

We discuss an example in the current practices document

This is provided to enable a SPARQL query so that the

Dave notes that by using a URI to identify the IoT platform,

It is up to the platform to indicate what metadata it

Note that the platform URI identifies the kind of IoT

[ brief break ]

[Naka] TD Lifecycle update

-> https://github.com/w3c/wot/blob/master/proposals/td-lifecycle/TD_Lifecycle_Syntax_on_JSON-LD.pptx Kajimoto-san's proposal

naka: (TD Template and Lifecycle Eco System)
... TD template
... (The relationship example of organizations and TD)

<inserted> W3C/WoT-WG

naka: organization of each vertical industry
... mas production manufacturer
... platform provider
... service provider
... ("include" example)
... left-hand example is TD template
... right-hand example is TD for a Panasonic air conditioner
... we can refer to the template from the TD for the specific Panasonic air conditioner usint "@include"
... can include part of the template by specifying "air-conditioner:actions"

dsr: thinking about oneM2M case
... module itself could be a URI

mm: assuming section could be optional

scribenick: kaz_

mk: if the purpose is linking template from instance TD, we could use RDF-like model for that purpose

naka: some more use cases
... adding features
... or removing part of features

henry: we also thought about that kind operation using $add, etc.
... within JSON Schema

mk: the requirement is clear here
... good to know about what you need
... but we don't need to reinvent this kind of new notation

mk: JSON patch may be used for this purpose

naka: tx

mk: btw, do you want to avoid RDF extension capability?
... probably need to ask Kajimoto-san

<kaz_> [ Day 3 ends ]


Day 4, 09 Feb 2017 - Administration

Automotive Report from Kaz

<kaz> https://www.w3.org/2014/automotive/charter-2016.html

<kaz> https://github.com/GENIVI/vehicle_signal_specification

<scribe> scribenick: dsr

<kaz2> www.w3.org/Submissionj/2016/01/

Kaz introduces the Automotive Working Group charter which

Kaz explains the work on using Web Sockets to connect web

The car is modelled as a hierarchy, e.g.

The use of Web Sockets to connect the server to the client

The object hierarchy is defined by GENIVI.

<mjkoster> browsavle GENIVI model in JSON

Last October, Volkswagen submitted a proposal for the

This makes use of HTTP for access to resources and Web

Kaz would like to see continued discussion between the auto

MichaelMc: I think in this group we need to work on

Dave: just to check my understanding, you want this group to

Michael: not necessarily.

Matthias boldy asserts that Web Sockets isn't a protocol as

Kaz: ideally, the auto WG would re-use an existing protocol

Dave: one alternative to Web Sockets for eventing is W3C's

The Volkswagen proposal uses standard web security

Dave asks what more we should be doing in respect to

Kaz: they have their own security task force, and I am

Scripting API continued

Johannes: we would like to continue working through the

See:

Johannes encourages people to contribute to the issue list.

Matthias: we need to be careful as the WG has taken over the

Johannes talks about how to formally specify the scripting

MichaelMc: I think should pick some target languages to

Johannes: I agree in principle, specifying the IDL for a

s/strong/strongly/

Zoltan: WebIDL is frequently used as an alternative to just

Matthias: perhaps the W3C staff contacts could check if

Johannes: Typescript is used by Microsoft, Google and other

If we want to specify a portable API we should avoid a

Kaz: this also came up in the Auto WG who found that WebIDL

Johannes: how does ECMA handle this?

Zoltan: prose based descriptions

Johannes: perhaps the W3C staff could ask W3M if it is okay

There are tools for mapping TypeScript to specific

Matthias: I propose we use both WebIDL and TypeScript for now

General agreement with this.

Dave: perhaps we could make a tool to map between WebIDL and

Michael: perhaps we should state one of them as the

Johannes switches topic to promises versus callbacks versus observables.

He gives some explanation of how the three approaches relate

Zoltan: promises for a single result or error, otherwise

Dave: what do the various programming language communities

Johannes: promises are being added to a good range of

A minimum requirement for supporting promises is function

Michael: some environment do not support function pointers,

Zoltan: Observables are nice for cancellable promises

Johannes asks Zoltan to propose a detailed solution.

Zoltan: I will submit a pull request that documents the

Johannes: we should investigate the use of Observables when

Dave: we just need to be sensitive to the cultural norms of

Johannes changes topic to the issue of a root API object.

Zoltan: either the object needs to be present or it needs to

<yongjing> yes, but i'm in another meeting in the same time, so

Zoltan: for Node, right now we use a Node require statement

MichaelMc: this doesn't need to be part of the standard.

Matthias: what Michael suggested is very Node centric, and

We want to enable portability

Johannes: for our spec we just define the interfaces exposed

We could include some informative recommendations on how to

Johannes: let's now talk about the client API

Johannes talks through several alternatives for using

Zoltan: for broadcast protocols, you typically can't cancel

If you want a sequence of objects, I would recommend a call

Johannes agrees

Johannes: is there a convenient means for the client to stop

Zoltan: if the discovery call returns a handle, it can be

Matthias describes how Observables applies to this.

Michael: if we're planning on using Observables in our

Matthias: so one outcome is for us to reach out to ECMA for

Some discussion on how to support deleting things

scribe: discussion wanders a bit ...

Johannes sums up.

<scribe> scribenick: kaz

[co-chairs] Extraction & setup of WG out of IG

mk: WoT IG and WG Next Steps
... GitHub repos for each group
... Chairs/Editors/Staff have write permission
... others use pullrequests
... (WoT Task Forces)
... WG:
... Architecture, Thing Description, Scripting API, Security, Hypermedia, Type System
... IG:
... Linked Data and Semantic Processing, Testing, Synchronization of Servients
... hypermedia for actions and error handling
... type system for JSON Schema

mm: protocol binding?

mk: don't really have a TF for that
... that's informative work
... TF means a dedicated call
... would get feedback

jh: maybe linked to hypermedia discussion?

mkoster: concrete method
... wondering about the same thing

mk: liaison work is also important for binding
... (adds "prepare binding template" to hypermedia tf)
... we should have somebody as the Editor
... and regarding the IG side
... Dave has started LD and semantic processing work
... and Testing
... then Synchronization
... anything else?

(none)

mm: scripting api might be misleading?

mkoster: how to handle semantic discussion?

mk: let's move forward to the detail
... (WG Architecture TF)
... WG deliverable
... need Editors
... one of them would be Kajimoto-san
... Frank as well?

dsr: architecture layers

mk: taxonomy?

dsr: e.g., application layer, protocol layer, ...

mk: we already have application layer, interaction model, protocol binding, ...

(some discussion on possible layering of the architecture)

mk: (updates the "Topics" for architecture)
... Topics:
... overall architecture
... how to combine building blocks, what do they give you
... servient architecture (layer model?)
... (TD TF)
... WG deliverable
... Editors:
... Sebastian already

sebastian: maybe Taki?

taki: ok

mk: (adds Taki)
... Topics:
... overall model (prototype -> graphical -> RDF -> ...)
... type system
... (Scripting TF)
... WG deliverable
... Editors: Johannes, Zoltan
... Topics:
... related to architecture work
... language-independent definition
... implementable in embedded environments and Web browsers
... part of the test suite
... informational document on rationale
... (Security TF)
... need to support other deliverables
... Lead: still searching for candidates
... Topics:
... outreach with good TF Charter
... reach out to IETF security area through I-Ds
... work with liaisons for platform security models

kaz: mccool, are you willing to act as a tentative lead for this work until we find actual lead?

mm: as one of the co-Chairs maybe

mk: (Hypermedia TF)
... subteam to help TD
... Lead: Matthias
... Topics:
... define model for complex actions
... define error handling model
... align with binding template
... McCool, ok with acting as a tentative lead?

mm: searching for a permanent lead. maybe McAfee?

mk: adds "please give suggestion"
... (go back to "Hypermedia")
... Henry was interested
... (IG Linked Data and Semantic Processing TF)
... Lead: Dave?

dsr: ok with being the initial contact

mm: timeline and input for WG?

[ lunch ]

<img alt="group photo" />

Comm TF

kaz: need to update conf/liaison pages

mk: there are monthly calls

Liaisons

mk: (OCF Liaison)
... joint meeting with OCF and T2TRG

mm: OCF meeting in Amsterdam on March 6-10 + 11
... McCool will join MKoster won't

mk: March 11 will be T2T

mm: TF Charter available

mk: goals until the next f2f
... demonstrate (OIC) interoperability at PlugFest (OIC spec if OCF spec is not published in time)

(some discussion on OCF's standard work)

mkoster: OCF specs are not yet published

mk: compile input fro TD TF
... (oneM2M Liaison)

<inserted> (OPC Foundation Liaison)

mk: presentation at OPC March meeting
... 20-23 March 2017
... can pitch during the meeting
... what's the public things we can do?
... manufacturing automation factories
... there is knowledge about that there
... possible horizontal liaison
... goals until next f2f
... agree on strategy
... get access to example UA models
... roadmap for PlugFest contributions (e.g., I4.0 demo)

-> https://github.com/mmccool/wot/blob/a9e934e52b2296a1088a82eb25ac27c1ca33864b/proposals/liaison-ocf/charter.md OCF Liaison TF Charter

scribe: (IETF/T2TRG Liaison)
... next joint meeting: f2f July 2017, Duesseldolf
... goals until next f2f
... see joint meeting

mm: joint meeting with T2T?

mk: during the Duesseldolf meeting
... also plugfest during breakout day?
... request full-day room for PlugFest

kaz: preparation on Sunday?

mk: maybe 4 slots on Wednesday for PlugFest?
... at least 3 hours on Wednesday

kaz: so 1-day or half-day prep on Sunday
... 2-day meeting
... plus 4 or 3 hours on Wednesday for PlugFest

mk: updates the slides
... PlugFest prep: open space or room on Sunday (wired Etherenet uplink, power strips)
... Plan observers/groups (inbound + outbound)
... further plan?

mm: joint meeting with security guys?

mk: (F2F Meeting March 2018?)
... co-located with security conference
... todos:
... organize academic conference workshop
... TPAC is in November and then we'll have Christmas

mm: IEEE security in May
... in California

-> http://www.ieee-security.org/TC/SP2017/ IEEE Symposium on Security and Privacy

mk: mccool, did you do any outreach?

mm: not yet

-> https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017?gclid=Cj0KEQiAw_DEBRChnYiQ_562gsEBEiQA4Lcssv0CQ7OoLsJyYygkBZCPd_FieUUJGPErVpgAmimK8-AaAgtI8P8HAQ NDSS Symposium of ISoc

barry: both NDSS and IEEE are good

mk: updates (F2F Meeting Feb? 2018)
... co-located with security conf?
... http://www.ieee-security.org/TC/SP2017/

barry: maybe could join only the workshop

mk: note all these security conferences occur in California
... need to invite experts from Asia and Europe as well
... (another F2F Meeting Feb? 2018)
... co-located with security conf?
... https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017

Roadmap

Matthias' slides on the WoT IG/WG Next Sgeps - TF definition, Editor assignments, Liaison work, F2F planning, WG deliverable roadmap

kaz: before ending the meeting, please remember that we need to care about the W3C Patent Policy for the work on the WG deliverables.

<kaz_> [ f2f ends ]