W3C

- DRAFT -

WoT f2f in Prague

23-29 March 2017

group photo from OCF joint meeting

Group photo from the OCF/T2T/W3C joint meeting on March 23

group photo

Group photo from PlugFest March 24-25

group photo

Group photo from WoT F2F Meeting on March 26-19

(Some more photos are available online.)

Agenda

Contents

Summary of Action Items

  1. [NEW] ACTION: kaz to talk with PLH about rechartering
  2. [NEW] ACTION: kaz to talk with PLH about if TD can refer to JSON-LD 1.1 if it's a WD
  3. [NEW] ACTION: matthias to summarize the plan for publication and rechartering and send a message to the group list

Summary of Resolutions

  1. the next F2F will be held in Korea on June 30-July 5 (June 30-July 1 for PlugFest)
  2. both Panasonic diagram on the basic interaction and Fujitsu diagram including proxies can be included as part of the appendix (after some cleaning-up)
  3. we would like to go for the changes based on JSON-LD 1.1

Friday, March 23: OCF/T2TRG/W3C Joint Meeting

The Agenda and the Live Notes are available on the IRTF T2TRG's GitHub repository and Google Docs, respectively.

OCF/T2TRG/W3C Joing Meeting OCF/T2TRG/W3C Joing Meeting OCF/T2TRG/W3C Joing Meeting OCF/T2TRG/W3C Joing Meeting OCF/T2TRG/W3C Joing Meeting OCF/T2TRG/W3C Joing Meeting

Saturday, March 24: WoT PlugFest - Day 1

plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1 plugfest day1

Sunday, March 25: WoT PlugFest - Day 2

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

Monday, March 26: WoT WG/IG F2F Meeting - Open Day

Open Day Open Day

Attendees

Present
Kaz_Ashimura(W3C), Tetsushi_Matsuda(Mitsubishi_Electric), Matthias_Kovatsch(Siemens), Michael_Lagally(Oracle), Michael_Koster(SmartThings;W3C_Invited_Expert), Sebastian_Kaebisch(Siemens), Kazuio_Kajimoto(Panasonic), Ryo_Kajiwara(ACCESS), Michael_McCool(Intel), Kunihiko_Toumura(Hitachi), Milan_Milenkovic(Intel)_Barry_Leiba(Huawei), Darko_Anicic(Siemens), Taki_Kamiya(Fujitsu), Daniel_Peintner(Siemens), Dave_Raggett(W3C), Tomoaki_Mizushima(IRI), Zoltan_Kis(Intel), Takeshi_Yamada(Panasonic), Toru_Kawaguchi(Panasonic), Jose_Manuel_Cantera(FIWARE/ETSI_CIM;Invited_Guest), Ege_Korkan(Techinical_University_of_Munich;Invited_Guest), Victor_Charpenay(Siemens), Ari_Keranen(Ericsson), Ryuichi_Matsukura(Fujitsu), Takeshi_Sano(Fujitsu), Soumya_Kanti_Datta(Eurecom), Federico_Sismondi(INRIA), Johannes_Hund(EcoG;Invited_Guest), Kazuaki_Nimura(Fujitsu), Danh_Le_Phuoc(Technical_University_Berlin)
Regrets
Chair
Matthias, McCool, Kajimoto
Scribe
Kaz, Dave, Kajiwara, Daniel

<kaz> scribe for today: Kaz, Dave, Kajiwara, Daniel

<inserted> scribenick: kaz

Welcome

-> https://www.w3.org/WoT/IG/wiki/images/3/3e/2018_W3C_WoT_F2F_Prague_Welcome.pdf

<kaz> next f2f in korea 30 june - 5 july 2018

Towards simplified TD

<inserted> Matthias' Slides

Matthias: [Thing Description Sapporo 2015]
... (shows the TD 2015 version)
... [Thing Desription Montreal 2016]
... and then 2016 version
... domain-specific vocabulary, security metadata, property/action/event, array
... entry points for interaction
... sapporo version had a single entry point
... montreal version multiple points
... hrefs there
... [Thing Description Now (1/3)]
... TD validator available now
... security work ongoing
... single entry point for interaction again
... new thing is data schema here
... semantic data schema
... e.g., iot:BinarySwitch
... discussion tomorrow
... annotate semantic information as well as syntax
... the other part is protocol binding
... [Thing Description Now (2/3)]
... some default approach here
... basics to build the request using "form" with "href"
... if you use some additional invocation
... deviation from defaults
... e.g., vocabulary for CoAP
... basically coap and also some OCF/CBOR content format
... can be understood by OCF implementation
... invoke action, write action, etc.
... pick up information
... [Thing Description Now (3/3)
... link from one thing to another
... web linking support within TD
... target will be another TD resource
... "rel": "controlledBy"
... e.g., motion detector
... how things are related with each other
... commercial building automation

McCool: possibly orchestration in addition to point-to-point connection

Zoltan: OCF has support for containers
... wondering about relationship to that
... interaction would be different

Matthias: detailed discussion to be done during the tech days :)

(some more discussion)

Matthias: JSON representation for linking by IETF
... text version link converted to JSON

McCool: anybody working on this?
... IoT use cases

Johannes: target is thing or interaction

Matthias: [JSON-LD 1.1]
... proposed Charter for a WG
... successor of JSON 1.0 by CG
... AC review until 29 Apr 2018
... we should clarify what our requirements are
... JSON 1.1 does have merits
... but we should focus on the AC review
... to get proper review
... detail to be done tomorrow
... proposed period 1 June 2018-31 December 2019
... should be aware of the reference for CR
... features we need to be kept in
... we should have strict use cases
... mandate from our viewpoint:
... make JSON-LD even more like idiomatic JSON
... using keys not arrays
... [@context #103]
... issue on the TD repo
... discussion with Mozilla
... very active though not participating in the WG
... we need to think about how to simplify TD
... one example is issue 103

-> https://github.com/w3c/wot-thing-description/issues/103 issue 103

Matthias: semantic annotations fully optional
... we can easily handle this
... register TD-specific media type
... e.g., application/td+json
... preprocessing based on that
... how to convert TD to triples
... and also no restrictive conventions
... e.g., always arrays where possible

Sebastian: wondering about media type registration and versioning

Matthias: you can define td+json
... and then manage versions

Kaz: we should think about that
... there was version attribute in XML-based formats, though

Kajimoto: compatibility question
... currently using JSON-LD 1.0
... compatibility with the parser?

Kaz: how to use "@version"?
... to identify TD version?

Matthias: no, "@version" is to identify JSON-LD version

(some more discussion)

detail for tomorrow

Matthias: [Objects vs Arrays #111]

-> https://github.com/w3c/wot-thing-description/issues/111 issue 111

Matthias: triple representation inside
... [base #106]

-> https://github.com/w3c/wot-thing-description/issues/106 issue 106

Matthias: lack of interoperability
... need for base URL in addition to TD URL as the base
... [@id/id #105]

-> https://github.com/w3c/wot-thing-description/issues/105 issue 105

Matthias: need for additional urn
... @id mandatory?

<inserted> Matthias: important to match security metadata in runtime

Dave: core model of WoT by RDF

McCool: default URI and additional URI

Matthias: all the tooling is there in semantic web

Danh: you don't need referenceable ID everytime
... you can identify things using, e.g., Amazon id

Matthias: possibly from multiple networks
... [schema #107]

-> https://github.com/w3c/wot-thing-description/issues/107 issue 107

Matthias: JSON Schema syntax
... some of the things could be simplified
... e.g., recursive properties
... schema information directly here
... how the semantic annotation needed for this?

McCool: reusing the existing mechanism

Matthias: reusing the modeling work
... [@type #104]

-> https://github.com/w3c/wot-thing-description/issues/104 issue 104

Matthias: type: boolean
... a bit inline with what can be simplified

McCool: similar capability with OCF data model

Matthias: [link vs forms #88, #108]

-> https://github.com/w3c/wot-thing-description/issues/108 issue 108

Matthias: discussion during the OCF joint meeting as well
... relation from one resource to another

McCool: related to binary payload
... link is one way

Matthias: a bit different
... input data and output data
... could send binary image for action
... one of the concerns
... where is the convergence
... what are the properties?
... properties have links, actions have forms, event have what?
... a bit more costly
... what are the events or resources?
... [Scripting API]
... entity description within TD and sub entity description

<dsr> Referring back to the discussion on @id, I would advise people look at W3C’s Best Practices for Publishing Linked Data, see http://www.w3.org/TR/ld-bp/ and the section on the role of good URIs in particular

Matthias: (TD example on the left side; Scripting API example on the right side)
... thing.properties.on.get
... how to deal with TD

Zoltan: we already have an issue about that (on the scripting side)

Matthias: [SImplified Thing Description with JSON-LD 1.1]
... proposal (work in progress)

Simplified WoT Thing Description under the TD repo

EcoG: How Web of Things technology Helps Integrating EV Charging into Business Processes (Johannes Hund, EcoG)

Johannes: used to be active within the WoT WG
... established EcoG last year
... Electoric Mobility is coming and the pace is increasing
... [Fragmentation is the biggest challenges for a global interoperable Infrastructure]
... electric power charging is getting more and more important
... auto-OEBm charging HW manufacturer, shopping mall, charging operator, fleet, utility, ...
... API-enable approach for that purpose
... [EcoG brings the App Economy to Charging]
... [Inspired by Android]
... [The API for EV Charging]
... API for various charging providers
... [Builiding Blocks of the Hardware Agnostic EcoG Software Solution]
... SW-stack, OpenAPI, Platform
... EcoG: Bringing together the relavant Expertise&Experience
... 3 experts
... [We figured out how to monetize EV Charging]
... [Today EV Charging is just Power Transfer]
... e.g., just 2 dollars
... [The Paradigm SHift in E-Mobility: Every Business becomes a Filling Station]
... traditional gas station to EV filling station
... With the EcoG API every Business turns the Time to charge into Extra...]
... [Integrated Customer Journey]
... with an EcoG API enabled Charge and Mobiel Phone App
... charging structure with users
... [Unlocking NEW Revenue Streams with the EcoG API business integration]
... 2 dollars for each => 110 dollars for a super market, 80 dollars for a fleet operation, 12 dollars for a coffee shop
... [EcoG is moving the infrastructure business from boxes to services]
... [EcoG Traction covers Pilot Customers across different...]
... [EcoG API Business Architecture]
... ecosystem diagram
... integrating smartphones, smart wathces, etc.
... [Open IoT^h^h^h WoT API to integrate EV Charging]
... [Using Web Technologies for IoT & API Service Development]
... broaden developer base
... enable the "long tail" market
... maybe there could be some killer-app for the main 80%
... but interested in the 20% long-tail part
... [Using Web Technologies to Secure IoT & API Services]
... web-grade security
... simplified integration
... [Expected Developer Experience make EcoG eeasy to use]
... low entry barrier
... broad community
... rich tooling
... [Two EcoG Demonstrator Sites for testing and project implementations]
... EcoG Munich, GER
... EcoG Detroit, US
... based on WoT
... also proxy exposed for IoT
... bunch of customers
... Ford, Bosch, VW, ...
... very interested in feedback

Zoltan: reminded me of pysical web

Johannes: several stakeholders from business owners as well
... running station at supermarkets
... multi-stakeholders there
... we provide/maintain the runtime

Milan: question missed

Johannes: rental cars, family cars
... public charging depending on the charging network
... make it simple for people to use
... possibly free charge based on the car manufacturers

McCool: key area for Web payments as well

[morning break till 11am]

<dsr> scribenick: dsr

We resume after the coffee break …

Comparison of AWS, Azure, and Oracle Device Models

Matthias introduces Michael Lagally, Oracle

Michael works in the Oracle IoT group

I will review AWS, Azure, and Oracle (IoT Cloud service) in respect to the high level concepts, device descriptions, device models and so forth

Some definitions of terms for a common understanding …

Things, device descriptions, device models (device types/templates), properties, and events

First let’s look at Microsoft Azure IoT Hub

Shows a list of links for the background information

Device Twin is an abstraction of the device state. Actions and events are not part of the Microsoft model. Messages are lightweight. The device twin model does not support templates or aggregating multiple devices into a virtual device

Twins have tags and properties. There are 3 kinds of properties, desired, reported and device identity

Actions could be modelled in terms of posting a payload to a method endpoint

Actions can take arbitrary number of parameters

No dedicate event mechanism, but can be modelled as device to cloud messages.

Shows a slide with an example using JSON as a serialisation format.

Tags are metadata, e.g. the device location

Moving on to Amazon IoT Device Shadows.

Similar in creating cloud based representations of device state

Devices report their state using JSON messages over MQTT

Amazon device shadows have a version, a thing name, a thing type, and a set of attributes.

There is a registry to manage things. They have concepts for thing types and groups

Groups may include other groups

Attribute values are limited to 800 bytes in JSON, probably due to the MQTT protocol

The spec only offers simple types for attributes

However, you can use a rule engine that supports JSON arrays and objects

Actions are similar to Microsoft’s digital twins

Likewise for events.

Moving to Oracle’s IoT approach

Oracle IoT Cloud Service platform manages devices, messages and events

Device models are a blueprint for defining devices, and support simulations without the need for physical devices.

You can create virtual devices as aggregations of other devices.

A device instance is created by registering a device that implements one or more device models (registering with the IoT Cloud Service).

The IoT cloud service can be used to manage device models and device descriptions. We use JSON, but not Linked Data

A simple WoT TD to Oracle device models demo is available

Device models describe metadata, attributes, actions, formats and links

Devices are uniquely identifiable.

Attributes can have a range of types, excluding arrays and objects. Attributes can be read-only.

Our database analytics tools expect flat data, and don’t currently support compound data types

Oracle actions can only take a single parameter, if you need more, format them as a JSON string.

Binary data is a challenge for JSON based messages.

Formats define message payloads and are uniquely identifiable via URNs

Formats are classified as either data or alerts

Human readable descriptions are valuable

Names may include spaces, but that isn’t recommended

Shows an example of a device model in JSON

At the Plugfest, I showed a demo that provides a gateway between the Oracle IoT Cloud Service and the Web of Things Node-wot implementation.

IoT gateways provide a means to connect via MQTT, CoAP, etc.

Can support manual or automatic transformation between device models and WoT thing descriptions

The gateway can expose and consume things …

AWS and Azure only define a data model with no actions and events. The serialization formats are incompatible, none of the solutions define a protocol binding mechanism, this forces device manufacturers to create code for 3 different environments

A unified device model would simplify integration across different platforms and accelerate market adoption

Sebastian: are the plans to add support for compound data types to device models for Azure, AWS, Oracle?

Michael: don’t know about Microsoft and Amazon, but no customer demand for Oracle IoT Cloud Service

The resource limitations are relaxed for apps running on gateways as opposed to resource constrained IoT devices

Dave: can you say anything about Oracle’s support for graph databases, and processing for Linked Data for greater flexibility?

Michael: no

Darko: why haven’t manufacturers driven work on shared models?

Michael: I would say that everyone has developed their own approach independently

Dave: do you see the likelihood of convergence for Web protocols (gateway to cloud, cloud to cloud) as proposed by Mozilla and EVRYTHNG?

Michael: that is the likely evolution, yes

Johannes: what would motivate cloud platform providers to adopt the Web of things?

Michael: Platform providers will adopt what their industrial customers ask for

<Zakim> kaz, you wanted to ask if there are any specific requirements for TD

<kaz> ml: some idea but detail to be discussed later

Testing Semantic Interoperability between WoT Systems

<inserted> Soumya's slides

Presented by Soumya Kanti Datta, EURECOM

Soumya introduces Eurecom and F-Interop, and their work on testing for the IoT

Interoperability is key for achieving the full potential of the IoT

Semantic interoperability is a way to solve interoperability across heterogeneous data sources, formats and models

SemTest, an industrial extension of the H2020 F-Interop project for work on testing semantic interoperability

This covers lexical, syntactic and semantic checks on messages

Checks at the communication level, lexical/format checks, and data processing checks

SUT = system under test

Question: are there any examples of commercial systems that embody semantic interoperabilty?

Soumya: there are several EU projects that claim to do this

Dave: I want to mention the work by the AIOTI on white papers on semantic interoperability, with a paper from 2 years ago and a new one aimed at developers in preparation - contact me if you want to get involved

Soumya shows a diagram with two connected systems under test

Some discussion about semantic processing involving SPARQL queries

<scribe> New diagram with a Query server positioned in between the two communicating systems under test.

n.b. in regards to the previous talk - RDF Semantic Graph is a W3C standards-based, full-featured graph store in Oracle Database for Linked Data and Social Networks applications.

Soumya: the key is to demonstrate semantic interoperability through explicit semantic modelling

We’ve done some work with oneM2m (see slide 11)

MichaelKoster: applications can interoperate through using the same terms, or through adapting to differences between models

Dave: one approach is to use abstract upper ontologies to relate different models, but this is expensive due to mapping terms to abstract atomic terms, another is to map models at a peer level, this involves conditional rule based transformations

Souyma invites us to fill out his survey (see slide 15)

As of know we (Eurecom) are implementing the tests within the F-Interop platform

Dave: F-Interop is funding a relatively short term effort on testing for the Web of Things, and I would like to talk to people here at the Prague meeting for their ideas on how to proceed

<Ege> Can you repost the survey link

https://goo.gl/forms/h3wgsyOpztxA3lSG2

Matthias encourages work on testing

<inserted> [lunch till 2pm]

<kaz> Milan's slides

<inserted> scribenick: ryo-k

Semantic annotation - Milan

Session: Semantic Annotation and Handling of (meta)Data in IoT Information Models

<inserted> Milan Milenkovic gives his talk

examples to be shown are taken from actual examples

digital transformation is needed, but current IoT standards are inadequate

what and why, not how

Commercial buildings (having 10s of thousands of sensors)

multiple systems, but not interoperable / not reusable semantics

<inserted> scribenick: ryo-k_

Problems and IoT Solution?: pre-internet... error prone (up to 30% error rate!)

very cryptic, only very people know how it works

need/want: portable services, attribute-based searches

"you can't do searches on IoT without semantics"

semantic annotations provides how the thing links to another things, relations to others

[Sensor data and meta-data use]

Haystack notation example

dis stands for display

One thing to like about Haystack: tags are crowdsourced (in the building management community

list of available tags -> pick as many of them that are useful

Rich metadata allows to add new sensors and integrate it without rewriting script

"Enables" attribute-based search (you can't do without it

How to handle metadata?

[Some Learnings and Observations]

Some of the metadata are static, rarely changing

variable metadata key value pairs in info models / separate APIs/queries to fetch static metadata as overlay

Descriptive, not Prescriptive

Dave: This analysis may help to convince people of different domains to standardize metadata

Example app: Finding rogue zones (too hot or too cold)

BMSs generally do not install rogue zone detection

(algorithm) Get all zone IDs, get zone sensor for zone, get setpoint, if difference > threshold then it is a rogue zone

sometimes 10%-50% rogue zones are found (actual results in Berkeley

What do you need to have in Metadata schema? -> looked at published smart-building apps, classified them, find relationships among entities

User input is important

Some applications only use part of the relationship. the parts are different among types of apps

Uncertainty in the metadata

compared Haystack, IFC, Semantic

Semantic sensor networks: (+) Flexibility, (-) Completeness

Take actual applications, analyze them and find what is needed

Dave: There are things can't know in advance, but can we use AI (predictive) technology? -> works maybe for historical data

BIM describes the design intent

iotschema.org -- an Update

iot.schema.org

Motivation: many standardization organizations, many cloud providers with their own notation -> we need some sort of semantic interoperability

What needs to be built? -> well known formats to describe semantics

"capability"

= set of affordances needed to interact with a device

Feature of Interest pattern

IoT needs to interact with physical objects

FoI largely overlaps with schema.org

example: LightControl capability

iot: providesInteractionPattern

all interactions are optional (= not prescriptive)

Lagally: : Q: How do you describe relations between interaction patterns, eg. TurnOff should not be with SetColour? -> The schema does not forbid those settings, this is implementation dependent

Can put restrictions on top of this schema

These restrictions can go into thing description

<kaz> (discussion on "Example: LightControl Capability")

State machine to describe state -> can also be used to forbid certain actions. / but not part of iot.schema.org

@3: How many domains are targeted? -> few. tens, not hundreds

Can mix other capabilities into a capability

Example: SetDimmer Interaction

data level is optional too

thing descriptions mostly differ in data level

(eg: Air conditioners having different temperature range / units)

<kaz> Darko's slides

What's new

schema contains more terms, has more users

proposal of how to use shape constraints

Events are being specified

<kaz> (slides 11)

attributes "writable", "observable"

How you are supposed to use iot.schema.org: example: discovery

How to ask ThingDescription Directory to find "an" air conditioner, not a "specific" air conditioner?

If well-known term exists, then it can be used -> that's what iotschema tries to do

search a term on iotschema.org, find a capability

"Air conditioner Capability"

2nd use case: automatically generate TD Templates

Pick certain terms that our thing should implement (shape constraints for thing) -> generate TD

such tools already exist for schema.org -> let's make one for iotschema

Why shapes are needed? -> they allow us to create variations between things with same capability

Example: one smart light has only "SwitchStatus", other smart light has "CurrentDimmer" "TurnOn" etc.

Shape templates provides a "fill-in-the-blank"-like template

<kaz> [[

<kaz> http://www.w3.org/2018/03/wot-f2f/slides/2018-03-26-W3C-WoT-F2F-Prague-iotschema-v2.pdf

<kaz> Light-SmartThings-TDTemplate.jsonld

<kaz> ]]

3rd use: TD recipes

Recipes = semantic templates for mashup applications

also JSON-LD documents

they allow automatic discovery of thing descriptions, they allow script generation

All steps except implementing application logic is automated with a "recipe"

<kaz> Matthias: asks Darko for explanation on what the objective of the Reccipes, what it provides, etc.

[Demo: OverflowProtection] -> What is the recipe in this case?

Recipes are declarative

(the parts in yellow is the recipe; thing 1 and thing 2 has functions implemented; the discovery provides the "arrows" in the diagram)

<kaz> fyi, minutes from the Mar-16 LD call

<inserted> Kaz: I also asked you to clarify what the "Recipe" was like during the LD call on March 16, but today's main point is not recipe itself, so please move ahead and talk about the main point (semantic interoperability using iotschema.org)

Work plan:

restructuring of iotschema.org, online version of TD generator, demo of applicability in other models like IPSO smart objects/Amazon IoT/TD from Mozilla and EVRYTHNG etc

McCool: Similarities with OCF and Amazon IoT(Alexa skills) are interesting

Toru: : Applicability to ECHONET. how to participate in development?

Darko: We still need to clear process to contribute, but can start contributing on GitHub (github.com/iot-schema-collab)

<kaz> Kaz: as put on the wide sheet on the wall, some of the PlugFest participants already tried semantic annotation using iotschema.org, so you should work with them

Danh: How to add concept like in schema.org?

Darko: If existing concepts not working: find concepts in other specs like OCF, take their resource type/concepts

Feature of Interest may make things worse, they may be arbitrarily implemented/defined

ThingDescription is also influenced by other specs (like in iotschema.org

<kaz> Kaz: given the purpose of this work is semantic interoperability, we might want to think about one specific scenario including multiple vendors, one from OCF, another from oneM2M and yet another from ECHONET, and think about how to use semantic annotation by iot.schema.org for interoperability

(discussion on how to correspond concepts in OCF/iotschema/ECHONET/etc.

<kaz> ari: wonders about the threshold to add entries to iot.schema.org

example: Presence sensor: one uses motion, but others may not use motion, how to describe them?

short answer: make one

but still needs an abstract term ("occupancy"? that is independent of motion, etc)

<kaz> scribenick: kaz

Kaz: many people are interested in this topic (semantic interoperability), so how to continue the discussion?
... main call, LD call, PlugFest call?

darko: already discussion within the LD call but need to report back to the main group

Matthias: need some executive summary as well

milan: ask about the work within WoT WG

Matthias: explains the WoT Charter mentions the mechanism
... e.g., Schema.org

danh: we should have one "place" for the discussion

darko: we want to have definition of simple feature of interest with iotschema.org

[break till 4:30pm]

-> https://github.com/w3c/wot/tree/master/plugfest/2018-prague/PlugfestSlides PlugFest slides

<dape> scribe: dape

<scribe> scribenick: dape

ETSI ISG CIM's work on NGSI-LD API

<inserted> -> slides tbd@@@

Jose: work for FIWARE foundations
... ETSI API specification
... ETSI ISG has mandate to establish info exchange layer
... smart cities is main domain
... there are many mores
... IoT is very important but not only source of information
... Mission: link all data sources
... to make it easier for end users/databases/.. to exchange information
... idea is to create common API ... in "Context Information Management"
... does not mean that there is single instance
... extra metadata can be exchanged in different systems
... Example: multi-modal transport ... for example google maps
... there are other applications/formats
... how to enable such open systems (from different sources)
... goal: keep it simple and achieve:
... * API for developers
... * minimal complexity
... * breaking silos
... * enable data sharing
... Work on Information Model
... core concepts: Entities, relationships having properties
... also have query language
... example: Police report an accident
... car damages lamp
... involved are vehicle and LegalUnity
... ids for vehicle and legalEnitity (police)
... moreover, the damaged lamppost belongs to the municipal with additional information
... information are published, can be subscribed, consumed etc
... how are these elements represented?
... JSON-LD is used
... we defined context
... additional terms can be added
... 2 types of nodes
... type "Property" and "Relationship"

Lagally: Who manages IDs?

Jose: Should be managed by each entity (data owner)

Ari: How to discover those IDs?

Jose: query system at certain location.. et cetera
... Assumptions
... * API is agnostic
... * use URIs to identify
... Possible architectures: Centralised, Distributed, Federated
... Information model has 3 main concepts: Entity, Relationship, Property

Lagally: Question, where is clock?

Jose: time for "observedAt" is example provided by source of data
... Queries, why don't use SQL, SPARQL, ..?
... every database has different approach
... we have flexible subset of queries

Sebastian: Wonder why SQL for example does not suffice needs...

Jose: Do not want to be bound to SQL...
... want to be flexible
... there are some pre-defined queries (by id, by equality, ...)
... nice to have also queries by geo locations
... API also allows to so Subscription
... similar to query... get informed if a certain condition is met

Victor: is there RDF representation behind context? File does not seem to exist

Jose: Correct, is not there yet but can be retrieved from XXXX
... Also ask for formal feedback from working group
... plan to finalize API specification within this year
... work on API introduction for developers
... also tackle security and privacy

Kaz: There is already official relation between the 2 groups
... want to do a more concrete one between the 2 groups

<kaz> W3C Liaison table

Matthias: 2 things I see
... w.r.t. query I would like to know how powerful the language is
... e.g. pointer to thing directory, also used in OCF
... in IETF it is registering web things
... SPARQL could be one of this complex query languages

Dave: interested in graph model
... lead of data activity... includes looking at model
... can talk about this later

Matthias: Also you specify data that gets send around..
... could be good test for WoT

Daniel: Wonder whether there is practical exploration

Jose: There can be many issues, need to solve security issues
... also there is previous work..
... document database vs graph models

Matthias: Did you look into how to scale this solution?

Jose: we have research experience in distributed deployment
... no "real" experience...
... centralized approach can work but the goal is distributed approach

Lagally: Is the assumption to use GSM network?

Jose: no. it is network agnostic
... Next steps: 1. queries. 2. is time
... also resource directory pointer

Kaz: also possible to join PlugFest demonstration
... beginning of July Korea, October TPAC

Matthias/Kaz: will look into liaison

<kaz> [briefly mentions the procedure for liaison and actual collaboration]

Jose: collaboration would be desirable

Security Recap

McCool: would like to mention what we are doing for security
... Issue:
... * many different sec auth schemes
... * interactions may have multiple forms with different protocols
... Basic Example:
... have basic configuration section
... we also look at OCF, what standards do they use
... do we need all that is used there?

Milan: what is meant with "security" in TD?

McCool: security metadata
... put minimum we can

Matthias: Also telling you where to get auth token

McCool: Please look at .../wot-security/ directory

PlugFest Report

plugfest day2

Matsukura-san's Summary Slides

Matsukura: 5 demonstrations
... first of all thank you to all PlugFest participants and Oracle hosting PlugFest
... we had more than 20 peoples
... many servients (yellow: application servients, blue: device servients) [see slides]
... red boxes show support of iot schema
... please check also on github whether figure is correct
... various viewpoints:connect with remote/local proxy
... security, Scripting API
... device simulators

McCool: eventing is yet another thing we might want to add

Soumya's Slides

Soumya: Two connected cars
... accessibility scenario
... 2nd demo: smart home and connected car scenario
... <showing video>

Johannes: Servient running on car?

Soumya: external device...

Sano/Matsukura: servient in 3 locations: Cloud, Japan, Prague
... showed long polling and event handling
... NodeRED (application) controlled device in Japan

Nimura-san's slides

Nimura-san: Scripting API
... LED lamp has on/off only
... script adds capability fadeIn/fadeOut
... also worked with Siemens
... injecting scripts is possible

Kawaguchi-san's slides

Kawaguchi: smart house demo
... worked also with Fujitsu
... Echonet gateway

Matthias' slides

Matthias: Fest plant with small CoAP devices
... valve can be opened ... goes to tank ... there is also pump from lower to upper tank
... have sensors watching water levels
... in Munich we had proxy... connected to Oracle IoT Cloud

<Darko shows script talking to Oracle cloud and acting on Fest plant>

Lagally: <showing Oracle IoT simulators>
... created digital twin based on provided TDs

McCool: I had several things
... OCF smart home instances wired up
... gateway talks CoAP
... make generated TDs available on the fly
... OCF devices available as WoT devices
... also used web camera... with eventing... changing exposures
... binary data (images) was use case
... long polling was implemented
... voice service was implemented also (Amazon alexa)

<kaz> all the PlugFest slides on GitHub


Tuesday, March 27: WoT WG/IG F2F Meeting - Day 1

Day1 Day1

Attendees

Present
Barry_Leiba, Kaz_Ashimura, Matthias_Kovatsch, Michael_Lagally, Dave_Raggett, Sebastian_Kaebisch, Victor_Charpenay, Daniel_Peintner, Taki_Kamiya, Takeshi_Sano, Ryo_Kajiwara, Darko_Anicic, Dan_Brickley, Milan_Milenkovic, Michael_Koster, Paul_Changjin_Jeong, Kazuaki_Nimura, Soumya_Kanti_Datta, Ege_Korkan, Tetsushi_Matsuda, Ryuichi_Matsukura, Tomoaki_Mizushima, Zoltan_Kis, Kunihiko_Toumura, Toru_Kawaguchi, Takeshi_Yamada, Ari_Keranen, Michael_McCool, Kazuo_Kajimoto, Elena_Reshetova(remote), DarkoAnicic, Benjamin_Klotz(remote)
Regrets
Chair
Matthias, McCool, Kajimoto
Scribe
Taki, Ege, Kaz, Nimura

<inserted> scribenick: taki

Next F2F

<inserted> Matthias: Are there any conflict for June 30- July 5?

<kaz> (no objections)

<inserted> Matthias: Good.

RESOLUTION: the next F2F will be held in Korea on June 30-July 5 (June 30-July 1 for PlugFest)

Plugfest Security Postmortem

McCool: Let's plan for next PlugFest.
... In the afternoon, discuss security metadata.
... Outline. What we tried. What's issue...
... Intel: Two exposed Things.
... local https. Basic auth.
... Not used by anyone else.
... using metadata proposals.
... Siemens. Https + basic auth.

Mattias: and bearer tokens

Matthias: proxy support. forward proxy.
... and reverse proxies. (things only reachable through proxies)
... used oracle instance.
... disabled cert check using config flag.
... last plugfest, used bearer tokens with Fujitsu beacon light.

Soumya: I used https. TD was encypted.
... It was a plain encryption.
... securoty of Thing itself is under development.

Yamada: Https + bearer token (jwt)

Kawaguchi: Global endpoint.
... Let's encrypt. local http only.

Matsukura: Fujitsu used https.
... proxy supported https.
... locally http only.
... https supported locally, but turned off for plugfest.

McCool: I will put this up to Github. people can edit it later.
... and I will create a survey.

McCool recaps what we did in Plugfest...

McCool: Issues such as protocol error. Probably due to firewall etc.
... Worked in hotel but not at Oracle.
... network disconnection. self-signed certification. those were also issues.

Kajiwara: we try to enable local device. using local CA.
... It is a CG work.
... HTTPS Local CG.

McCool: only limited set of authentication schemes. Only basic auth and beaerer tokens (jwt).
... Incomplete metadata. Those were issues.

Kawaguchi: cross-site scripting issue.
... Browser prevented us from using cross-site scripting.

Matthias: Was that your own servient?

Kawaguchi: We allowed it. Proxies did not.
... I used Chrome.
... I had problem when I used TD.
... Advanced ACE.
... Node-Red did not have problem.

Matthias: Chrome behaved correctly.
... Copper under firefox was not working.

McCool: I also used curl.

Matthias: Scripting issue. therw was not an issue in fetching.

McCool is creating a slide on scripting API issues...

<kaz> -> McCool's slides tbd@@@

McCool: cross-site scripting issue specific to using WoT scripting API inside browser.
... "Dashboard" app trying to connect to Things that was at different location.
... any other issues?

Zoltan: ACL is implemented. Need to do provision manually.

McCool: Next plugfest plan. what do we wanna do?
... security metadata.

Matthias: 30 June and 1 July.

McCool: We need to be done by 1 June.
... We need to create a consistent security metadata set.
... by then.
... we need to try more authentication strategies.
... OAuth2, wider use of bearer tokens.

Matthias: Pop tokens (at least as a 1-1 prototype)

Elena: API keys

McCool: Basic auth

Barry: digest and basic auth. what's different?
... digest and local authentication should be used together.

McCool: OCF is based on ACE.
... metadata for ACE, and OCF. entry points, roles, etc.
... we also should try non-OCF implementation as well.

Matthias: I have implemetation in node.wot.
... It is work in progress.
... coap implentation in node is fragmented.

<ryo-k> fyi: web page for httpslocal cg is here https://www.w3.org/community/httpslocal/

McCool: First we define metadata, then need to implement.

Matthias: Can you share OCF ACE information?

McCool: authentication server, certification server. ACL.

Matthias: OCF tends to depend on IETF standards.

McCool: Discussion in IETF T2TRG is necessary.

Ari: Lightweight M2M.

McCool: We are gonna have lifecycle discussion.
... we have lifecycle diagram.
... it has implication on security.
... we have been focusing on operation phase.

Kajimoto: we need to analyze the gap between security document and the issues we now have.

McCool: we still need to do general discussion.
... Testing validation strategy is related too.

Kaz: We need to clarify requirements before analyzing the gap.

McCool: general discussion first, then concrete discussion.
... for now, practice first, then generalize.

Security Metadata

McCool presenting on Security metadata proposal...

McCool: Issues with current assumptions, goals and requirements. We need disucission.
... I present strawman proposal
... I generated concrete examples.
... issues.
... different authorization schemes in one Thing.
... different entry points, roles, management styles. etc
... RAML, OpenAPI have this. different authorization scheme in one thing.
... I made those assumptions.
... We need to discuss whether or not this is a requirement.
... security interaction patters

Matthias: TD says how to get authorization. role is in token.

McCool: I try to describe existing mechanism.
... We can validate assumptions llater.
... OpenAPI supports multiple strategies, multiple entry points.
... we do not want to replicate configuration definition.
... we give a name. and use it elsewhere.
... we can share configuration between interactions.

<kaz> security pullrequest 86

McCool: AND-OR combination scheme.

Elena: we need use cases.

Matthias: When proxy is there, we do not see OCF device behind it.

Elena: OCF is in local network, and has its own authentization mechansm.

Matthias: one thing, how can it possible to support multiple security systems?

McCool: coap and https.
... OCF device with coaps and https.
... We can use OR operation.

McCool showing examples...

McCool: Security is an array.
... each has @id and "scheme"
... each interaction has "security" field referencing id such as "ocf-config".
... Proxies.
... proxy configuration and endpoint configuration. we can define both in "security".
... OAuth is a bit complicated.

McCool showing OAuth metadata definition...

Matthias: we need to check what we really need.

McCool: We should not repeat information here if it is processed somewhere else.
... i tried to make metadata definition consistent with existing system such as OpenAPI.
... I will keep updating the proposal.
... There are open issues. compatibility with JSON-LD.
... list of supported security mechanisms. what's in and what's out.
... validation issues. combination of parameters.
... there can be invalid combinations.

<kaz> security metadata document

<inserted> Kaz: wondering about the proxy/gateway use cases. Do we want to think about server capability within TD as well?

Matthias: We need to be careful what we define for gateway use cases.

McCool: we first should focus on what we need.

McCool is showing detailed specification section...

McCool showing various examples...

McCool: presentation is just a summary.
... for now 5 schemes are listed.
... each scheme can specify relevant protocols.
... API key is a blob. Bearer tokens have structure.
... OpenID and inter-ledger are interesting.
... Please take a look at the proposal document, and provide comments.
... I created issues in Github.
... for open issues.
... such as versions for security schemes.

Kaz: Do we really want to use "OCF Security Model" as a categor?

McCool: it is scheme="ocf"
... It is work in progress.

Kaz: given other entry names are technology-based, maybe "ACL-based security" or "SDO-specific security" which includes this (=OCF Security Model) as an example

Sebastian: should we keep discussion separate from TD vocabulary discussion?

McCool: whether common or specific to schemes. It depends on this.

Matthias: extension points need to be defined in TD.

Sebastian: common part needs to be discussed in TD call.

Matthias: binding should be discussed in security call.

Dave: abstract model can be discussed in TD.
... we need a framework around TD.

<kaz> [break until 11:15am]

<ege> scribenick: ege

Interaction Patterns Sequence Illustration (Kajimoto/Kawaguchi)

Slides

Kawaguchi-san: this presentaiton will be about presenting examples of interaction sequences, not a new standard
... no clear description of end to end sequence and inconsistency among spec drafts, e.g., WoT Architecture, WoT Thing Description and WoT Scripting API
... I only have HTTP prepared so my example will be based on that.
... Describing an example of HTTP get request with scripting api (sending the request, getting a promise as a response)
... Similar example description with an HTTP PUT request
... Now some new stuff, especially for the plug fest: HTTP long polling
... Sending a get request and getting the answer once the server device detects a change and sensds a response

McCool: question on long polling

Matthias: What you asked is more about multi-XXXX and not actually long polling

McCool: ok. (to kawaguchi-san) what is a change , what is a previous state. What happens if you have a request during a change

Matthias: That would be more like a bad implementation

McCool: I would think of getting a previous state in order to understand if there is actually a change

Matthias: what is the actual problem

McCool: What if I have the value 0, it changes to 2, there I subscribe and then it changes to 1 and I get that value so I miss the change to 2

Matthias: If you implement it right there shouldnt be such problems

Zoltan: We are not interested in making precise time stamping problems etc.

Matthias: There is a way by using cookies. First get you store a cookie as a server and the second time it gets a GET request it blocks it
... I wanted to the client side of long polling in node-wot for long polling during the plugfest but didnt have time

McCool: I wanted to implement both server and client side with node wot (SAID BEFORE THE 11:37 Matthias)

Matthias: There is also another pattern where even if you dont have a change you send something saying that hey Im still here

Koster: We can all agree that observable properties is event type

Ari: http, using different resources

Matthias: If a device is already existing, you cannot impose to put a timestamp

Zoltan: what about putting timestamps in responses

switch the order of 11:42 and 11:43

Zoltan: but the scripting should expect behaviour

Matthias: CoAP has the observe clock

Kawaguchi-san: Now simple web socket that has been implemented by Siemens
... presented the slide

Matthias: this is simple websocket so you need to define the underlying protocols afterwards
... (After a question of McCool) we cannot think what is the application use case

Dave: What about if I want to send 10000 property update a second

Matthias: Then you should events

McCool: My thinking is that simple things should be simple

Dave: yes but complex things should not be impossible

Matthias: but you can already do that

Zoltan: (explained how you can do it)

<ryo-k> Series Transfer Pattern: https://tools.ietf.org/html/draft-bormann-t2trg-stp-00

Koster: There is an IETF draft by bormann that can help about it

Kaz: What is the difference between slide 4 and 5 from the slide design point of view? the difference between the possible event handling mechanisms (and important points) should be described in addition to the diagrams themselves

Panasonic's sequence diagram on observable/event and action

Kawaguchi-san: I have found this action pattern and I have found this invokeAction method

McCool: return codes of actions

Matthias: there is no current XXX about having Hypermedia control kind of stuff

Zoltan_and_Matthias: It should be such that you get status or TD or whatever and from the information you learn what you can do with it

McCool: Scripting API should be protocol independent

Matthias: It might be good to have something in the TD that says that I will do this action
... Then it proceeds on doing the action. In the meantime you can still access the server. In the example of a cleaner, the action could take 2 hours and then respond and all this time is sort of not used.
... you cannot have two different implementation of a request. You cannot have one where it tell you that it will do the action rightaway and another that starts doing the action and then responds. It is possible but way simpler to pick one

McCool: (before Matthias' answer he asked something about having two version described in the TD)

Matthias and Sebastian: (in response the Koster's question) this type of flow should make it easier to people to understand the difference of action and properties

Kawaguchi-san: Now event patterns
... There is a github issue on how to use property action event

McCool: We need to see how MQTT works, maybe Michael has something to do with that

Sebastian: I would like to see CoAP in the observe patterns
... I have a student working on MQTT for Web of Things, I can provide input later on about it

Kawaguchi-san: This is mostly to illustrate and to say that everyone is ok with the action patterns

Matthias: we dont do discussions on "architecture", we do specific topics, e.g. terminology is a part of architecture

Matsukura-san: (a question on what about proxies that we have introduced in plugfests)

Kawaguchi-san: I think we should do another slide where we merge proxy and basic intereactions

RESOLUTION: both Panasonic diagram on the basic interaction and Fujitsu diagram including proxies can be included as part of the appendix (after some cleaning-up)

[break until 11:15am]

Interaction Pattern Definitions (Matthias)

Matthias: Presenting property definition in the terminology. it is updated

Dave: What about the observable aspects, is it described somewhere

Ari: What about write only

Matthias: That would be modeled by actions

Barry: What if someone cant read it because of access rights

Matthias: That would come from the orthogonal security aspects, it shouldnt be mixed with property deifinition

Taki-san: What about previous states

Matthias: You can have it in the application layer and model it by an array
... I understand this might be needed, can you bring a use case to discuss

McCool: Or an action to get the history

Barry: or use blockchain!

Matthias: (After a question from Lagally) If you want to model something, start with property, if you cant model pass to action, if you cant model it, pass to events and only after that if you cannot model it then we can talk about having a 4th interaction pattern

McCool: What about state transitions ( EGE: didnt get the discussion about the state machine etc.)

<kaz> Kaz: wondering if all the "properties" (or rather members/fields of TD) need to be exposed, or only exposed ones are called "properties"

Dave: What about generating events in the client

McCool: You can do it with actions

Dave: yeah that is a workaround but what about the concept

McCool: an action with semantics

Dave: No that is a workaround. What if there is a usecase that we dont know that can be modeled only with a client raising an event. I am not saying that there is one and that we should add something but more like raising the a question

Matthias: You want a P2P network that you can do with things being servient
... the initial definition of action had the idea of doing a physical change

McCool: Maybe actions should be not only about internal state because maybe i dont care about the change of the internal state but the result of the action that is something about the physical world

Milan: I dont think you should call strong consistency in the event delivery. You should either say best effort or guaranteed delivery. Strong consistency is a bit ambigous

Public: people agree on what Milan says

Matthias: So what are the use cases of read only, writable and observable properties

<kaz> [lunch till 2pm]

Matthias: I didnt have time to explain the updates

<kaz> scribenick: kaz

TD Data Schema Now and with JSON-LD 1.1 (Victor)

<inserted> -> Victor's slides@@@

Victor: new features from JSON-LD 1.1
... for the sake of the following discussion by Sebastian and Matthias
... syntax, etc.
... [Objective]
... define the transformation
... to RDF
... using only standardized procedure
... 3 possible steps
... set WoT context if not present
... default values
... transformation to RDF
... [changes]
... default values
... getting rid of arrays
... couple of other changes
... key-indexed interactions
... JSON Schema syntax for Data Schema objects
... relax of the constraint on arrays
... for @context and @type
... for easier implementations
... [Default values]
... [Key-indexed interactions]
... we use "name" to identify interactions

Matthias: what does "framing" mean?

Victor: several possible representations
... compact one, nested one, etc.
... all the formats are expected to be equivalent
... based on the same RDF model
... TD is normalized format we're looking for
... framing algorithm for defaults
... second thing is key
... representing interaction
... where the key is the identifier

McCool: link to other places?

Victor: "name" here is not equivalent with the one from RDF
... still some open issues
... provided use cases

Soumya: app servient wants to parse it?

Victor: easier for an object to use arrays...

Matthias: parsing problem and accessing information
... software object identical with TD structure
... codes are iterating

Victor: this is what our JSON Schema is defined
... open api also uses that
... [JSON Schema syntax]
... "fields" before "name" and "schema"

McCool: "prop" could be name of some property

Taki: @@@ prohibited?

Victor: reusing JSON Schema
... properties come from TD properties
... separate question
... another proposal for that

Matthias: let's focus on what JSON-LD 1.1 is like

Dan: W3C itself should make decision which to use

Matthias: if we go down to the path (1.1), what is the requirements?
... complexity?
... key is nice applicable feature
... AC review for the proposed Charter
... JSON Schema is independent from JSON-LD

McCool: what are our use cases?

Victor: framing is the most important feature
... there is no easy way without that
... on the other hand, many people have started to use JSON-LD and found problems

Matthias: regarding dependency
... syntax and semantics
... discussion during TPAC2017
... adapt to new concept
... being clearer

Sebastian: like the change (e.g., framing)
... interested people could provide use cases

Matthias: we should go through the changes

Victor: [COnstraint on arrays]

<danbri> JSON-LD charter is before W3C AC for review (https://lists.w3.org/Archives/Member/w3c-ac-members/2018JanMar/0054.html - member only link). Draft charter is (public link), https://www.w3.org/2018/03/jsonld-wg-charter.html

Kaz: left side and right side?

Victor: possible usage here (not left as 1.0 and right as 1.1 here]

Matthias: TD directory should support this
... how to deal with this convention?

Zoltan: array for "@type"?

Matthias: you can do that
... the parser would handle it

Victor: if you use other JSON-LD convention, other could have string, etc.

McCool: restriction for small devices?

Matthias: kind of education needed
... could be an array

Victor: [Issues]
... a couple of issues
... identification
... WoT convention, JSON path, RDF normalization
... Base URI
... use of JSON-LD's "@base"
... use of TD identifier
... [Identification issue]
... in both JSON-LD and JSON Schema
... there are properties and actions
... using "id" is JSON-LD 1.1 convention
... having "uuid" for some id
... if there are 2 identifications, would have id conflicts

McCool: observe tag?

Victor: "id" is yet another URI

McCool: relative to where the TD is
... may or may not be same

Victor: possibly other kind of IDs
... #properties/example/schema/properties/id JSON Path
... not sure how they handle it
... this is not part of the JSON-LD spec itself
... 3rd alternative: hash://md5/9f86d081884c7d659a2feaa0 RDF normalization (randomly generated)
... common with temperature, etc.

Kaz: who handles the hash ID?
... possibly TD directory?

Victor: possible option
... also every agent may also expose the ID

Barry: new hash schema?

Victor: took from some proposal
... there are different ways there

Barry: talk about that later

Dan: RDF hash would make sense
... ":hash"

Barry: talk about later

Victor: [Base URI issue]
... how to declare TD
... how JSON-LD is defined here

<danbri> discussion of http://json-ld.github.io/normalization/spec/

Victor: just add "@base": "urn:wot:myThing"
... we could specify within the TD spec
... only has the space as the key
... in this case
... urn:wot:myThing/example WoT convention
... this is something we use
... might need access control
... submitted to the JSON-LD CG
... but pushed back

Matthias: why out of scope?

Victor: require some preprocessing
... we could continue to use option with JSON-LD 1.0

Matthias: discussion on the pre-processing stage?
... could also take the base id to fill the content

Victor: possible solution

Matthias: nice solution is
... this is TD-specific

Victor: this "@base" "urn:wot:myThing" would be put on the array if used for TD
... wanted to show this diagram...

McCool: we actually see them?
... or transformed results?

Victor: put into the TD as soon as the property is processed

McCool: how would a big ugly hash work?

Matthias: if you input extra document which is located somewhere
... you don't need the hash itself

McCool: possible human-readable id?
... in a form
... as alias

Kaz: possibly additional "display name" or "exposed name"?

McCool: within the document for the developer, the id should have a human-readable alias
... most users don't handle that

Victor: could be possible
... [diagram of DataSchema]

-> @@@url of Victor's DataSchema diagram tbd

Dave: extended diagram for DataSchema?
... used for multiple times?
... we can make it easy to use that so

Victor: all the data included in the DataSchema

Matthias: it's possible

Victor: we can reuse it once it's defined as part of DataSchema

Matthias: those are small extensions
... basic building blocks

McCool: some use case on binary data
... extend the Schema for that?
... media-type knows about that

Victor: anyway requires container

McCool: what if it's empty?
... leave it out?

Kaz: clarification on the colors

Victor: yellow upper nodes are JSON Schema
... green lower nodes are TD extensions
... [another diagram on SenML]
... binding templates spec
... interaction for properties here
... (goes through the diagram)
... abstract model regardless of the serialization

Sebastian: comment on the current TD ant this model
... for the future

Ari: just a future example?

Victor: yes
... [yet another example]
... provided by Matthias
... battery->schema->0.0.100.0
... we can input this into the doc
... I'm done

McCool: min/max?

Victor: wanted to explain that kind of detailed but couldn't due to network connection

Matthias: "rssi" property

Victor: (shows the TD draft)
... (rawgit version)

Matthias: (explains the example)
... example 2

Zoltan: multiple ranges?

Matthias: whatever complex types
... might want to talk with the JSON Schema guys

Dave: arrays in JS 1.1
... order or unorder
... maybe unordered one would be less costly

Victor: JSON-LD?
... already covered

McCool: 1.0 as well?

Victor: yes
... just RDF list is used regardless of whether ordered or not

Matthias: what JSON-LD 1.1 could bring to us?
... is this something we want?
... should follow 1.1 version?
... note that we could be delayed by using 1.1 version
... this could be raised within the AC Review for the proposed JSON-LD 1.1 WG

Dave: would be good to join that group as well

Matthias: will look into this

Dan: some awkward characteristics on JSON-LD
... you need @context
... a bit awkward
... not sure this group really should add anything to their work

Victor: this work should be standardized

McCool: 2 comments
... our schemes fixed??
... any applications
... larger scope for IoT

Dan: when the RDF model group had discussion
... still questionable for this group

Lagally: when the draft would be published?
... we want to wait until JSON-LD 1.1 becoming a REC?

Matthias: no
... the roadmap I imagine
... 1.1 version is based on what they have been working
... may start around June
... figure out what the features to be fixed
... still loose end
... we have initial strawman for the next f2f if we start our work for 1.1 now

Lagally: wondering about the risks

Matthias: it's a complicated situation
... my expectation is JSON-LD 1.1 based version (of WoT specs) could be stable

Lagally: wondering about actual product implementations...

Sebastian: wouldn't expect yet another big changes...

Lagally: should work with the stable version?

Matthias: you can new features if you want
... same mediatype definition anyway

McCool: various possible issues
... if early enough, we might be able to resolve them

Soumya: hear 2 directions
... wondering about what oneM2M is doing
... they're using 0.a version for standardization

Matthias: the model would not compatible...
... their style is spec first and then implementations
... on the other hand, we've been working on implementations simultaneously
... another point is
... the model of TD itself didn't change drastically
... we have property, schema node there
... property could directly have type

Victor: not the way we should use JSON Schema

Matthias: meant small changes about the underlining model

Victor: possible solution might be using RDF itself :)

Matthias: possibly we can use pre-processing

McCool: as our plan b

Lagally: when we could expect implementations?
... might be going to 2020
... note that I'm talking about device manufacturers

Kaz: wondering if we could think about the core of JSON-LD vs 1.0 profile and 1.1 profile
... and work on both
... and then once the 1.1 version is fixed mainly work on that

Matthias: would try a vote
... who would prefer 1.1?
... whould would do that?

McCool: what version would make sense?

Kaz: not the final decision but people's opinions at the moment

Kajimoto: difference between 1.0 and 1.1?
... if the changes are very small, we can assume 1.1

Matthias: the changes are stronger than the ones they made previously
... positive feedback from Mozilla and EVRYTHNG as well
... would go for one specific solution

Taki: Victor explains the changes

Sebastian: more data side

Matthias: let's see what the JSON-LD 1.1-based TD would be like

Simplified TD with JSON-LD 1.1 (Sebastian/Matthias)

-> slides tbd@@@

TD pullrequest 116

Sebastian: first change (example 4 from TD)
... possibly semantics may not be decided
... JSON-LD 1.1 requires @context
... but it should not be necessary
... still based on the RDF model
... concrete triple
... at @context
... we need kind of post-processing as well

Matthias: possibly 3 processings?

Sebastian: we have to integrate the context

Matthias: in that case 3 processes?

McCool: user's perspective
... what 1.0 and 1.1 are like
... side-by-side examples?

Matthias: what about example 1?

<danbri> maybe typo on screen: Propertis (I think, fuzzy eyes :)

McCool: maybe we can generate an example?

Matthias: would like to look for that

(more discussions)

Sebastian: one big change is...
... (going back to the slides)
... [Downside of Current Workin Assumption]
... interaction container
... by the usage of "@type"
... class, type of the interaction model
... we use many "@type"s withing TD
... kind of interaction pattern
... semantic information like "iot:BinarySwitch"
... also we have to use container with JSON-LD 1.0
... because not allowed to use keys
... no restriction for that any more
... mandatory notations like "writeable", "observable"
... mediatype as "application/json" need to be defined everytime?

Matthias: some more discussion on "form" vs "link"
... we can ignore if "writeable" or "observable" is False

Sebastian: [Develoer Perspective]
... list of points
... usually HTTP/JSON is used on the Web
... why do I always have to write that down explicitly?

Matthias: may specify the default as HTTP, CBOR, etc.

McCool: mainly use CoAP
... OCF devices are CoAP-based

Matthias: actual commercial deployments use CoAP

McCool: default values always the same?
... other values could be set?
... from security viewpoint, constant default would make sense

Sebastian: [JSON-LD 1.1]
... [Pre-processing with JSON-LD 1.1 ...]
... [@context #103]

Matthias: let's take break now

[break until 4:10pm]

<inserted> scribenick: nimura

Sebastian: explaining about TD - W3C editors draft

Example4: Experimental TD example

<inserted> -> TD Example 4 based on JSON-LD 1.0 and 1.1

Matthias shows different

1.0: LD+JSON need @context

1.1: TD+JSON, we can do pre-processing

we still have name fields

ignore semantic markup @JSON-LD1.1@@@

Valid URI/(URN) is used for identify the TD

Sebastian: we already have a years ago the JSON-LD but gone after that

Matthias: property has JSON-LD 1.1 object.

McCool: the property is nice, but action and event are confusing

Matthias: programming language like JS restricts: name is identifier

link was singular but currently plural

we want re-use @id?

an object has single key: @id

"level": "name" work, but ambiguous.

when we starts use schema, this is one of the risk because there's nothing yet.

few solutions there and risk there. 5% of the case?

taki: can we be the pre-processing optional?

that's we are trying to do.

Matthias: we do this changes.

"integer" resolve URI in local, so no collision.

we are going to consistent to JSON schema.

RESOLUTION: we would like to go for the changes based on JSON-LD 1.1

major topic in TD call is explain about the issues at github.

link vs forms: it's like json schema

more natural from scriptingAPI point of view.

issue #88, #108

<inserted> TD issue 88

<inserted> TD issue 108

Protocol binding: for example OCF, non-standard implement implementation

It introduce bit complexly for property, but people continue to implement

Conclusion: exposing web resource, link to web resource is sufficient for get/put, you know what to do.

Property become less powerful but concept becomes simpler.

What happens for observe property?

How to differ get end pint and observe end point?

If you need to read OCF, need to have header.

stick to form there.

link gives relation to resources.

form gives interaction, but that's weird.

forms in html world have specific meaning providing data

Mm: stick to form, not automatically processing

Non standards interaction, we need to cover.

pre-processing has defaults, some kind of suggestion is needed.

New TD Vocabulary (description, version, tags, etc.) (Matthias)

"name" term there, @is becomes handle and unique.

human readable expression is favorable that's helps developers

about name, is it optional?

it's still working.

for the reference of object @id is necessary.

that's central of mandatory.

agreed on make "name" optional.

but name always require make sense.

we don'have "name" in some examples.

level can be used for expressing international language definition.

level and name are different.

level does not necessary like name

Name: {"en"]:"My Thing", "de":"Mein Ding"}

do we really needed?

that's internationalizable solution.

descriptions should be optional.

inside description maybe common markup can be defined.

description can be internationalizable.

about tags,

popular model among developers.

We have label, so not necessary tags?

Do not include TD vocabulary to tags.

about version,

is it optional?

it is useful for all of the application.

if we introduce change on TD version, runtime could handle it.

no version for TD, but JSON-LD version?

OCF has spec version.

<victor> candidate terms from standard vocabularies: owl:versionInfo, owl:priorVersion (not ideal), dc:hasVersion, spdx:versionInfo (best)

maybe instance version can be introduced?

thing should work like web. what's the purpose of version?

<kaz> (MLagally shows some examples on Java)

TD must be self contained: fetch all required web resources.

about author,

author=manufacturer

URL+manufacturer

It's not author.

however TD can have author.

minimum thing is support URI for fetching.

about domain,

as seen in iotschema.org

do we want to separate into domain?

Synchronization topic by Matsukura-san

In the plugfest, many integrations are provided by companies, so share the info and update the architecture document.

device servients were located in two place.

oracle provides solution in Praque.

proxy servients coordinate application and devices.

these app from Oracle or so could access remote proxy.

role of proxy servient is manage TDs and coordinate connection between apps and devices.

how to use proxy servient?

device connects to local network that connected to local proxy servient.

then app can search the device from TD directory.

in the future, proxy servient supports binding template.

Zoltan: what discovery mechanism is used?

proxy servient contains Thing directory.

Zoltan: only devices underneath can be controllable?

remote proxy that connected multiple local proxy servients handles devices underneaths.

Zoltan: what is the request?

Fujitsu specific approach is taken.

McCool: how do the devices discover?

TD directory is the implementation of core directory.

McCool: what protocol uses, standard way?

victor: look up is different from Siemens one.

McCool: how security handles? how do I translate?

<kaz> Kaz: if needed, we should ask Sano-san from Fujitsu for clarification on detailed protocols for discovery/registration

app never see local address.

security metadata to TDs would be added

Is discovery supported like query?

Still simple approach by search name is taken.

Assumption is names are unique that's not good assumption.

next time Fujitsu might support iotschema approach.

SSE and long polling are supported.

nobody implemented SSE in plugfest, but Fujitsu check that.

compact WoT core is developping, and next time we will show the device.

thing directory, proxy and the variations can be reflected to architecture doc.

<kaz> Kaz: just wanted a clarification

<inserted> ... the first point here (slide 7) means updating the preparation/guideline.md for the next plugfest and the second point means updating the WoT Architecture document, e.g., the Appendix section like the one from Kawaguchi-san

showing scalability experience for example 1 million devices will be useful.

kawa: register things at one time is convenient.

<kaz> [ Day 1 adjourned ]


Wednesday, March 28: WoT WG/IG F2F Meeting - Day 2

Day2

Attendees

Present
Kaz_Ashimura, Matthias_Kovatsch, Michael_Lagally, Dave_Raggett, Taki_Kamiya, Takeshi_Sano, Ryo_Kajiwara, Daniel_Peintner, Darko_Anicic, Sebastian_Kaebisch, Barry_Leiba, Ege_Korkan, Michael_Koster, Kazuaki_Nimura, Ryuichi_Matsukura, Tomoaki_Mizushima, Victor_Charpenay, Tetsushi_Matsuda, Kunihiko_Toumura, Toru_Kawaguchi, Takeshi_Yamada, Zoltan_Kis, Michael_McCool, Kazuo_Kajimoto, Elena_Reshetov(remote), mlagally, Paul_Changjin_Jeong, Federico_Sismondi
Regrets
Chair
Matthias, McCool, Kajimoto
Scribe
Lagally, Dave, McCool

<kaz> scribenick: mlagally

lifecycle

Elena's slides

lifecycle section should live in the main document

McCool: we could not find a lifecycle - only IETF spec has an example. This is a strawman
... maintenance could be intentional or unintentional
... we intentionally assume in security group provisioning has already happened

<yamada> https://rawgit.com/w3c/wot-security/working/index.html#lifecycle-of-a-wot-device

Barry: are you aware of ietf security group? chartered in the last few weeks
... 2 groups: TEEP, SUIT
... SUIT = SW update for IoT
... TEEP = provisioning not limited to IoT
... you have trusted and untrusted parts

McCool: the entire device could be trusted

Dave: you might have trusted services
... our descriptions should cover this

<ryo-k> suit (Software Updates for Internet of Things) - https://datatracker.ietf.org/group/suit/about/

Dave: OMA has merged with IPSO to found OMA Spec Works

<ryo-k> teep (Trusted Execution Environment Provisioning) - https://datatracker.ietf.org/wg/teep/about/

Dave: we should take into account

McCool: we should also work with the IETF groups

<dsr> My point is that the lifecycle also needs to take into account the provisiong of services in gateways and cloud platforms, i.e. provisioning in depth, and not just IoT devices at the edge

<dsr> My second point was the need to encourage coordination on provisioning and management across the many IoT alliances and SDOs. Let’s hope the IETF work helps with that

Elena: presents lifecycle of scripts

<inserted> scribes for today: Lagally, Dave, McCool, Victor

Elena: we have to discuss if script lifecycle is in scope

McCool: 3 cases

wot device with wot runtime

scribe: ocf device with a wot gateway

Dave: this is multi stakeholder

McCool: existing device, where target device has own lifecycle and provisioning
... these are different configurations

Sebastian: same lifecycle for all things?

McCool: perhaps we need multiple models
... different for consumer and industrial
... in industrial, devices may install their own software stack
... having only one model is naive
... we assume only operational state - is this a valid assumption
... script may be installed before operational state

Zoltan: we have 3 lifecycles here (scripting runtime and TD)

McCool: scripting lifecycle is within operational state
... is scripting update in the operational state

Zoltan: this may be outside or may cause a cycle

Elena: we may have a small section on lifecycle

kajimoto: lifecycle diagram - we may need decomissioned state
... ... lifecycle sometimes defined in operational state
... security items may be added by manufacturer

McCool: another state could be "engineering"

Dave: purpose of the diagram? best practice?

McCool: we want to define states to clarify what state we are talking about
... where do the steps take place? depends on the situation

Zoltan: consequence of the diagram?

McCool: clarify scope of standard
... if we can refer to an external standard

Lagally: look at osgi
... look into oracle IOT client documentation for inspiration

Zoltan: OCF lifecycle has a purpose for certification

McCool: an OCF gateway still has to onboard - go through provisioning process - we may need liaison
... technical connection is possible - we may need a bridging at org level

Dave: this is also related to privacy: GDPR in Europe
... we are just defining interfaces
... we want to draw attention to the interfaces

Zoltan: we want to make these connections easy

Kawaguchi: state could be simplified from a SW stack perspective: device is accessible to wot servient, discoverable

Elena: this is just device lifecycle - last slide is about software lifecycle
... please define SW lifecycle

McCool: scripting TF should define this

Zoltan: will discuss later

matthias: this is interwoven with identity management
... we should look at Panasonic model - existing devices

McCool: we also have to worry about other authentication schemes

matthias: dan yesterday raised security question about JSON-LD

McCool: in NDSS we also looked into protecting access, securing against manipulation

Sebastian: how do we handle this topic? make it more convrete? Where do we discuss?

McCool: have not defined TD discovery in the standard
... you could go to a base url and get a TD

Sebastian: where do we discuss this - github issue, f2f?

McCool: we discuss in security TF, but thing directory should be discussed in TD TF

matthias: no additional call - online interim meetings on Architecture

Zoltan: scripting API will refer back to this - we need sth. to be referencable

McCool: identity mgmt. is a lifecycle issue

Zoltan: one or multiple identities of a thing?

McCool: multiple access paths

matthias: multiple TDs from different places, multiple network interfaces, different addresses

Zoltan: in OCF you get an id via ownership

Matthias: different ids from different systems

Zoltan: if you get ocf id and from somewhere else

matthias: WoT shoud have urn mechanism to map uuid, imei etc.

McCool: we need a concrete written proposal - one-pager
... decide in next group meeting where this is discussed

Dave: we should review against best practices for linked data
... group needs to be aware of that

<dsr> see https://www.w3.org/TR/ld-bp/

McCool: we should not just have a string

matthias: @id in TDs mandatory - there were name clashes during the plug fest
... should see how existing things are mapped into this - see Panasonic's plugfest demo

kaz: issues are common with all TFs

McCool: we need a proposal first

kaz: we should also restart architecture work
... lets start with a clear proposal

matthias: I'm updating architecture document anyway - will add a small section

McCool: security could be handled like this too

matthias: architecture needs full lifecycle
... no difference between small device and web server - perhaps just skip the commissioning step

McCool: there are various standards for services: cloud, open fog, ...

matthias: i write a markdown proposal - how to map for existing services
... will integrate initial lifecycle version into architecture document, generalize security TF model
... do longer calls on arch document - want to avoid just another call

Sebastian: would be useful to be more concrete

McCool: diagram needs to be generic enough
... use cases would be more concrete, e.g. consumer + industrial
... existing diagram is svg

Sebastian: Siemens can contribute on industrial use cases

<Discussion on where document can be found>

Barry: please change color of the slide, black on white

Terminology

Matthias: Let's talk about terminology
... could WebThing be an alternative to different terminology?
... corresponds to our abstraction in WoT

Barry: WoT server is an impelementation thing, not an abstraction

McCool: if we assume to get consensus with Mozilla/EVRYTHING, align terminology

Barry: pick something that's easy searchable
... IETF does that

matthias: servient vs. WoT host?

servient was not familar to TPAC participants

scribe: Is WoT host less confusing?
... servient is full SW stack

<brainstorming>

<strawman poll>

<pro's and con's of node vs. servient>

<inserted> [break until 11:10am]

<dsr> scribenick: dsr

Summary of Security Issues for the Scripting API

Elena presenting remotely

She talks us through the main assumptions e.g. security must be transparent for scripts as much as possible

Will we cover security errors? Yes

We assume that the security configuration is handled independently of the scripting API

Diagram for “Flow 1” - in which a script discovers a new device

The script uses network discovery to find a thing

The required security credentials are identifed from the thing description

These credentials are obtained if not already present

The credentials are passed with an action request - the action response returns a result or an error

if the error is due to security, the script can refresh the secutity credentials and retry the action. This may be appropriate when the error indicates that the credentials have expired

McCool: the user may need to do something as part of the process for obtaining the credentials

In one scenario, the credentials are requested when retrieving the thing description

The permissions may be fine grained, e.g. allowing a script to read the status, but not to update it

McCool: the permissions may depend on the user’s role

Daniel: the credentials can declare what a script is permitted to do

Zoltan: this is all encapsulated by the WoT run-time

Matthias: the server sending the thing description cannot always detemine what the client is allowed to do or not ….

The client may be able to identify that the credentials are missing

I like the lazy acquisition of security credentials

Zoltan: when we do discovery, we are doing TD discovery not OCF discovery

MCool: We may want to expose the user’s role as part of the discovery process

Dave: can’t we we indeed handle authentication and authorization as part of the process for fetching a thing description, e.g. returning a bearer token for subsequent use in invoking thing actions etc.

Matthias: if you already had the thing description, you need another means to get the security credentials

Dave: indeed, and you need a means to request the credentials when a security token has expired

Matthias: we should like at how this is handled in RESTful systems

Zoltan: so we need to ensure that the Scripting API is able to report some set of security errors

McCool: we should look for guidance at existing practice

Elena: the general principle is to avoid providing additional information when this isn’t needed

If the information is already present, it can be propagated, but let’s keep things simple

Diagram for “Flow 2” in which a script exposes a new thing

A WoT script wants to specify security restrictions on the thing’s actions and properties

How does the script define and pass the security policy to the run-time

This may involve some protocol specific details, e.g. user id and password for HTTP Basic

Matthias: I would avoid this being set in the script. The run-time knows what security to apply

McCool: the thing description could declare user roles for each property or action, and the run-time could then expose this to an authorization mechanism

Matthias: we want to avoid putting security details in the TD

Zoltan: so are you saying that security policies are handle by a thing?

Matthias: the person who configured a script for exposing a thing, can also set the security policies at the same time

McCool: we can explain this in relation to the lifecycle

Matthias: script author’s shouldn’t need to know about the details of security schemes, and instead just needs to describe his/her intent

Elena: do we agree that we need a way for scripts to pass the intent (e.g. via roles)

Zoltan: no, this could be handled externally as part of the application context

Matthias and Michael talk about the use of identifiers that the run-time can use to map to the specific security mechanisms for the protocols in use

Matthias cites the use of named roles as such identifiers

Zoltan: do we need to standardise these?

McCool: no, they can be passed as opaque strings

Matthias: we should support arrays to allow for multiple roles

Daniel: we would like scripts to be able to run on different platforms

Zoltan: we could use the management interface for managing security policies

Elena: yes, we can manage this out of band and not expose it as part of the scripting API

Matthias: we could support hints …

McCool: we have extensibility through the means to add metadata

The lifecycle is important in that we need to talk about when information is provided and who provides it

<McCool> McCool: summary, we need to work on scripting lifecycle to determine who and when security data is defined.

Scripting API Security Metadata

Zoltan presents …

<McCool> ... normally, private information needs to be provided out of band, and within a script we should (at most) define the policies or roles that particular interactions use.

<McCool> ... these policies or roles should be selected from a list configured by the entity that set up the scripting runtime

We’ve summarised scripting issues in Issue #95

<McCool> ... however, to get consistency, it would be useful if these roles were defined using a common vocabulary. It is suggested that we defined a few such terms but using an extensible mechanism.

<McCool> ... a complex subject, but we can start just with "user" and "admin" and go from there

<McCool> ... it is also noted that security errors *should* be returned by the scripting API, with as much information that is available on the network interface, but no more

<McCool> ... this is based on the observation that a malicious attacker can look at the network traffic anyhow so there's no point making honest users' lives difficult by hiding information

<McCool> ... however, we should define more generic error codes or categories simply for ease of use

Zoltan uses OCF as an example

<McCool> ... there is also the question of defaults... if no policy or role is given, a "default" should be used

<McCool> ... this concept of default may (or may not...) be reflected in the TD... likewise, a "role" may use a SET of security configurations, and this may require a refinement of the current proposal to represent

OCF defines a specific sequence of steps for provisioning with onboarding/ownership transfer, and provisioning of security metadata

<McCool> ... also discussed was how to handle security during discovery, providing different TDs to different users to assist with privacy, and dealing with authorization errors

The WoT run-time needs to comply with the OCF requirements when it comes to exposing WoT things

OCF ownership transfer involves specifying device and owner ids

<McCool> ... points to note: secure delivery of differentiated TDs can be handled in a hierarchical fashion, eg. having a discovery service that needs authentication before it returns a thing

<McCool> ... this may/may not be out of scope; part of the lifecycle discussion

OCF is still refining its provisioning process details

The security metadata is covered by Issue #91

<McCool> ... finally, the scripting API should deal with authentication lazily so that (a) it does not waste time trying to do authentication it does not need (b) it has to do it anyways for certain schemes, eg refreshing expired tokens. SOME things, however, can be checked at startup (eg do I have an appropriate username and password for basic auth) but the more general case requires lazy eval

A WoT client needs to discover the thing, figure out the provisioning service and device info.

The WoT run-time needs to undergo OCF certification

Zoltan: the main use case is to expose OCF devices as WoT things

a secondary use case is to expose WoT things as virtual OCF devices

For the main use case, an application can expose multiple OCF device resources as a WoT thing

Matthias: we could include the full security details in the TD, but probably don’t want to expose all of that to WoT clients

McCool: for gateways, we need liaison with OCF to discuss the details

Zoltan: OCF controlls access to device resources via ACLs

A thing may represent multiple OCF resources

The WoT run-time needs to encapsulate:

- OCF discovery

- Claiming OCF client role

- Requesting access permission + validity period

- Making OCF resource requests (CRUDN)

- Processing replies and requests

McCool: we should use reflection for the run-time to discover the details

Talks about an OCF gateway

Dave: is OCF certification per gateway or per OCF device? In other words would an application hub for the web of things need certification separately for each app that exposes OCF resources.

Matthias talks about OCF work on a bridge and perhaps we can convince them to work with the web of things to simplify that?

McCool: right now OCF is specifiying bridges for each mapping separately

Matthias: I would like to figure out who to talk to the OCF people about their work on bridges

MCool: we need to push them to make this happen

Matthias: OCF won’t certify apps/gateways that bridge OCF devices to other ecosystems

MKoster: at the end of the day, OCF is member driven …

Dave: perhaps we should focus on showing how security can be handled when bridging the web of things to other ecosystems.
... perhaps we (WoT IG/WG) ought to show we know how to address the complications of onboarding and transfer of ownership (e.g. when people move home)

Zoltan: can’t we get some of the Microsoft and other companies to engage with the WoT activities?

Matthias: these companies are putting all of their resources into OCF and claim they don’t have any resources available to also engage with the W3C WoT work

McCool: OCF is making a lot of use of IETF specs, which will help with the WoT security discussion

Zoltan: OCF had a bad experience when merging in AllJoyn

Dave: we need to show that the security challenges can be addressed effectively, even though we won’t be standardising everything - i.e. some aspects are left to WoT application gateway platform providers

<kaz> [lunch until 2pm]

<McCool> test

<kaz> scribenick: McCool

Scripting API Improvement with Simplified TD (Zoltan)

<inserted> Scripting issue 90

Zoltan: issue 90 about errors
... we already talked about security, but there are other categories
... Matthias has requested a list of errors
... depends on algorithm
... all methods can fail for security reasons
... this morning we figured we need a WoT-specific error
... that has more information than the basic Node.js Error object

Matthias: useful to have more information
... there are still arguments to keep it consisitent with normal errors

Zoltan: there is the issue of writing scripts that deal with errors specific to certain protocols
... then not portable
... we need a set of generic error codes
... suggest if you have a list, then add to issue

Matthias: agree don't want protocol-specific codes
... but let's look at RESTful concepts and define a set of generic errors

Dave: want a set of abstract errors

McCool: reporting information not a security issue (if available on the wire), but depending on how we do it, may be a portability issue

Dave: issue is avoiding information that is too specific to a platform

Matthias: for instance, token has expired, etc.

Dave: we can agree that scripts should be portable

McCool: we need a concrete proposal that we can evaluate

Zoltan: have some categories (see the issue) already
... TypeError, NetworkError, SyntaxError, etc.
... there is the issue of the "message"... displaying it or not is up to the application
... there is also a catch-all InternalError with a message

Matthias: should start with existing categories, see how far we get

Zoltan: should we have more than just a message for the SecurityError
... or a symbolic code?

McCool: want symbolic tokens so we can handle certain categories consistently

Matthias: user needs to know how to deal with the error, i.e. they should know when retrying is useful or pointless

Zoltan: suggest people try to capture their opinion on the issue

https://github.com/w3c/wot-scripting-api/issues/96

Zoltan: tryed to come up with webIDL to represent web API as a test
... came out a little bit different than the current API
... map-like DOM for instance
... can generate DOM that is consistent with (proposed new) TD

Matthias: after McCool's question, we can use this to build a DOM consistent with JSON-LD 1.1 TD

Zoltan: do we want to expose the security section or not?

Matthias: might be useful for introspection

McCool: what about ID?

Zoltan: will have... point is, will expose everything in the TD

Matthias: there will be an issue for things with @ in front... have to use ["@..."] not .@...
... there are restrictions on identifiers we will have to look into
... some we can map @context to context, but what about @type and type? causes a conflict
... so need to extend the mapping somehow
... don't need to break interactions down into Properties, etc. already broken up

McCool: also possible keyword conflicts

Matthias: but always have the fallback to [] notation

Zoltan: should the mapping be direct?
... can be awkward for scripting

Matthias: changing the names is a problem, 1:1 mapping clearer

McCool: I agree a 1:1 mapping is better

Zoltan: we could just add methods for @types

Matthias: but why? this works fine
... can access everything just with knowledge of the TD
... you just have to know that you have to use [] for @-types

Zoltan: then we should probably not separately define these in the API...

Matthias: if you say we don't specify this, then you just follow the TD implicitly
... we can just tell people what is happening

McCool: just tell people that if it's in the TD it will be in the DOM

Matthias: we can also autogenerate the scripting API DOM spec from the TD spec

Victor: we can take existing tools to generate the spec

Matthias: you said you don't want to track the TD spec...

Victor: can generate webIDL from ontology

Zoltan: could also generate JS object/implementation

Matthias: but we aren't talking about the implementation, but about the spec
... and we already generate a lot of that from a formal model
... so we can do the same thing for the Scripting API

Zoltan: but it's not really necessary since we can do introspection

Matthias: but we need to know where to attach handlers, etc.

McCool: we should distinguish goals and means... goal is scripting API and TD are consistent
... so just figure out how to get there efficiently
... I think that we can just give the rule and don't have to redundantly list everything redundantly

Zoltan: we don't need to specify the structure, already given by the TD

Matthias: but still need attachment points
... eg to add a property
... where do I call this?

Victor: so we should at least have the skeletons for each class?
... but agree it's necessary to add extra entry points

Matthias: we do have to specify skeleton so we can add entry points to it
... need context for function definition
... start doing it and you will hit the problem I'm talking about...

Daniel: I think we can also just try to prototype the generation of the WebIDL
... as a reader, I don't want to jump between two specs, SA and TD

Zoltan: but how do we deal with variable @type syntax

Victor: well, in other cases have similar issues, like $key in JSON-Schema
... so not an unusual problem

McCool: the issue is only that the webIDL generator needs to do the right thing

Matthias: issue is that you want to avoid the @type

Zoltan: can't define @type in webIDL

Matthias: so it's the webIDL spec that is the issue...

Victor: we also have methods like invokeAction...

Matthias: need to know where this goes in the class structure

Victor: the @ keys could be left out of the webIDL spec... and inferred from TD spec
... but we include the "main" classes in the webIDL

Matthias: then we "metadefine" the other things...

Zoltan: that will give bad feedback from the AC

Matthias: it works, so...

McCool: can make ["..."] the main definition, then say the . notation works for things whose identifiers satisfy certain rules

Victor: at least three representations of same JSON-LD object
... advantage of the webIDL is that it gives a canonical representation

Matthias: make this deal
... then we will do another pass that deals with the @types
... make an API, but ignore all @types

Zoltan: but we could infer some of the @type stuff?

Matthias: no... and the spec will be in flux due to the JSON-LD 1.1 transition

Daniel: will take the action to talk to webIDL people about this issue

Zoltan: moving on... examples, how to set a Temperature, etc
... showing use of the different notations

Matthias: note that properties now have get and set

Zoltan: and then there is the observers pattern

Matthias: example does not quite follow the pattern we discussed

Zoltan: in this case, interface implements observable
... alternative is there is an "on" method
... (refering to "temperaturechange" example in issue tracker)
... might need options to pass to subscription
... so using "on" would be nicer if we want to pass options to the subscription
... but we should stick to the known semantics
... also have "on" not only for events but also property change

Matthias: confusion of multiple paradigms

Zoltan: we should probably experiment with writing code with both
... Observable is an ECMAscript proposal, but may not fly
... often used for filtering infinite series, but we aren't doing that

Daniel: what if it does not fly?

Zoltan: then we would have a private definition
... OK... we have a few more issues
... but the intent is to get as close to the TD as possible
... we should track the TD
... starting point for updating the scripting API work

Matthias: if there is an example, we should check that it works

McCool: what about extension keywords?

Zoltan: consuming works, but exposing is a problem
... exposing is a security issues, need to check against known strings

McCool: I would hope it works if the extended key is in the context I include

Victor: this is why framing is important.. know in advance what object should look like
... will remove unknown keys, add prefixes if needed, etc.

Daniel: a good implementation would do that, but... can we enforce it

Zoltan: a risk of injection attacks

McCool: I suggest we break it up... what we can from the scripting API, then separately deal with security risk... and what checks we need to include to avoid problems

Matthias: agree separation of concerns approach is useful
... may have separate validation tools, etc.
... but generally we need to deal with extensions
... maybe have a .validate API call... but in general, we have to figure out how extension points work

Zoltan: ok. regarding other points, will talk to some stakeholders and Javascript purists what makes sense to them
... that all said... mostly we are talking about Consumed things in this spec, need to look at how it works with Exposed things
... also does not really discuss schemas

McCool: but may change anyways if we align with JSON-schema

Daniel: should be easy, simple recursive structure

Matthias: suggest for now do everything except @-types
... we will look into it, later on we will patch in such things
... should look at some other implementations to see how they deal with such exceptions

Kaz: if we have some difficulties with webIDL... can give feedback to Web group

Matthias: proposal is deal with basic things that work, then figure out how to add to the spec how to deal with exceptions
... Daniel will reach out to Toby to see if there already is a solution
... should coordinate with Kaz
... need to find the right person to talk to

Zoltan: Toby is only the latest guy to touch it

Daniel: one question: future
... what are our plans for other languages... is webIDL the right choice
... other languages can use our spec
... first ones that do a non-browser spec will need to do something else

McCool: so why do we bother with webIDL at all?

Matthias: for one thing, it makes adoption in a browser easier
... but we may want an informal guide for other languages

Zoltan: of course you can use the WoT and TDs without scripting at all...

Matthias: maybe move another topic up...
... is an issue about "what is the web"
... read between the lines there that there might be some misunderstanding
... for instance, we need at least some URI scheme
... and example there, we looked into MQTT, a counter-example Mozilla brought up
... of course we need a URI scheme; we know how to do this, but it should be pushed up to a standard
... another example that is counter-example, there are lots of other protocols that are linkable that we probably don't want to use, eg "file://"

Barry: don't even need an RFC
... URI schemes are defined by "expert review"
... so much easier process
... can also just use the Oasis spec

Matthias: also mediaTypes, etc.

Barry: so maybe what we should write is a definition of what protocols are useful with WoT
... and if necessary, guidelines for how to define a URI scheme
... what about Quic, etc.
... a google thing, follow-on to http that runs over UDP
... they will have a URI scheme for it, so that kind of thing should work
... in most cases bad for implementation to worry about protocol...

Matthias: one complication: coap over UDP vs. coap over TCP
... semantics are a little different

Koster: application probably won't have to deal with this...

Matthias: reminder that the URI is just an opaque string...

McCool: Barry, will you take the action to write up a definition of "what it means to be compatible with WoT"?

Barry: sure, I can take a stab at it

Matthias: we should look at the use cases to see what protocols are appropriate to use
... may have different requirements on northbound and southbound interfaces
... may also have proprietary interfaces in various places
... also specialized sub-protocols, eg. over websockets
... may be specialized protocols on both southbound and northbound interfaces
... (CoAP over UDP may or may not be a good example of that)

Koster: how about extensions, cross-exposure between ecosystems, etc

Matthias: may need specific bindings for "proprietary" protocols
... in that case though while it might be accessed from inside a servient, it would not be described with a TD
... could still use a TD...
... reusing mechanisms, but not direct access; feasible vs allowed

Koster: even for generic web interfaces, may want to have a protocol binding to give some details
... there is a question of what is the "natural" mapping
... still want to write it down

Matthias: if you start from the TD, even the defaults define a binding

McCool: what about security? Protcol Binding or TD spec?

Matthias there is also DataSchema

scribe: currently only defined as examples

Matthias: are there another other protocols we should include
... would be a good "check" with our list of requirements
... my understanding it was a proprietary binding
... will discuss tomorrow... but is http

McCool: regarding wot-security working vs master, I will create a PR tonight to get caught up, if the security TF members can be please review ASAP

[Day 2 adjourned]


Thursday, March 29: WoT WG/IG F2F Meeting - Day 3

Attendees

Present
Kaz, Matthias, Dave, Taki, Matsukura, Yamada, Sano, Daniel, Sebasitan, Federico, Koster, Nimura, Matsuda, Mizushima, Ege, Ryo, Toumura, Kawaguchi, McCool, Kajimoto, Zoltan_Kis, Michael_Lagally, Danh_Le_Phuoc, DanhLePhuoc
Regrets
Chair
Matthias, McCool, Kajimoto
Scribe
Mizushima, Kaz, Koster

<kaz> scribe for today: Mizushima, Koster, Kaz

<inserted> scribenick: Mizushima

Web of Testings Test and Validation

McCool: agenda is context
... thing description validation
... security validation
... Out of scope

Kaz: we need check list of plugfest

Dave: rechartering oppotuniity

McCool: and Test Suite Rewuirements
... Review of Specification and test suit design

<kaz> Web Platform Testing framework

Koster: i think we need recomennd.

<kaz> (McCool captures the discussion on his slides)

Kaz: We should integrated W3C test tools
... frameworks

McCool: I start about to do
... We need list of test case under plugfest
... we should update from 2016

[Plan for Testing]

ECHONET Update

Kawaguchi: ECHONET update
... I take about collaboration with ECONET
... ECONET is mutivender home networking

McCool: is ECHONET Lite IP-based?

Matsuda: no. any kind of transfer is applicable if you want

McCool: Machketing?

Kawaguchi: 4 milions shiping

<mjkoster> Matsuda: Echonet lite can use non-IP networks

<inserted> scribenick: kaz

McCool: what is the data payload? binary or some specific format?

Kawaguchi: binary
... [What is ECHONET Device Object?]
... ECHONET spec itself doesn't specify the devices' behavior
... it specifies just the data format

Kawaguchi: [Support for Legacy Protocols]
... shows concrete data format and frame payload

Dave: wondering about the performance
... you can choose multiple interface

Kawaguchi: baed on the manufacturer's preference
... but there is some guideline

McCool: 2 problems
... automatically generate the TD?

Kawaguchi: for each device?
... partially automatic generation

Koster: what kind of format to be used?
... any kind of XML?

Kawaguchi: shows the object model
... some 0x80, 0x81 kind of data
... property on=0x30, off=0x31

McCool: anybody working on web implementation for ECHONET?

Sebastian: the property names are standardized by ECHONET
... how to extend?

Kajimoto: vendors can set unique name within the vendor-specific area

Kawaguchi: [Ongoing status]
... intended to be used on the cloud server
... talking with ECHONET guys about collaboration
... not open to the public yet

Matthias: it would be worth to define semantics from WoT viewpoint

Kawaguchi: q: when will the WoT specs be ready for practical use?

McCool: depends on the requirements
... commercial purposes?
... stable enough for engineering?

Matthias: starting with the next plugfest in Korea, we should apply changes for JSON-LD 1.1

Lagally: what about the simplified TD proposals?
... starting from when?

Matthias: asap
... new editor's draft should cover it
... end of April for the updated drafts?
... think after 3 more plugfests, spec and implementation would be stable
... question about normative reference
... maybe JSON-LD 1.0 as a normative reference for a while

Lagally: any other significant changes?

McCool: don't think so

Lagally: what about Mozilla's proposal?

Matthias: getting consensus

Kawaguchi: (go backs to the slides)
... interaction patters
... what would be the suitable use cases?
... property read/action
... property observe/event
... sending query parameter?

Matthias: discussion on terminology
... clear understanding on property/action/event?
... examples are helpful
... why property should be suitable to which case, etc.
... [Initial feedbacks (2/2)]
... TD DataSchema
... what data types are actually allowed?
... Sebastian has already answered

Kawaguchi: can expect the TD spec will be updated
... JSON Schema terms are re-mapped from time to time

Matthias: addressed by the simplified TD
... top-level property and form field
... and sub property
... would fit lwM2M and IPSO, etc.
... hierarchical structure
... JSON hyperschema also would fit

Kawaguchi: recommended method for discovery?
... any guideline?
... for unique ID/URL and versioning?

Matthias: some work by IRTF T2T
... on device identifier
... not sure about your own method, though

Kawaguchi: when will iotschema.org ready?

Koster: already ok for practical uses

Matthias: community-driven work
... if something missing, you should edit it

McCool: should define use cases for your "practical use"

Kajimoto: at a starting point with them
... but many manufacturers support ECHONET standard
... so might make sense to invite some key people to the next f2f

McCool: wondering about vendors from outside Japan

[break till 11:40; next topic on rechartering]

next f2f

Matthias: have let the host know about hour preferred date and waiting for confirmation

<scribe> scribenick: mjkoster

recharter

Matthias: what are the building blocks?
... synchronization of servients
... life cycle - design phase, semantic composition
... simple JSON TD
... unified TD

McCool: proxy synchronization
... standardized directory

Dave: how to use the IG to grow the ecosystem

McCool: TD templates

Matthias: concept of templates has been around since the beginning and has been expected
... it's a TD without the instance information
... can be given the scripting API to create an exposed thing
... it's already in the charter

McCool: it's not in the charter
... TD types like templates
... with a unique identifier
... to argue about later
... new ontologies for things like name

Dave: maybe we could charter another group

McCool: new interaction types like screen
... hypermedia pattern when a thing returns a thing or a form or an action

Dave: can a thing be a data type?

Koster: communication patterns like webhooks and pubsub (protocol bindings and sub-protocols)

Matthias: to explain better, for examplee ws is only a transport; how do we use these for interactions?
... there is CoAP over WS, etc.
... Mozilla also working on sub-protocols over web sockets

Dave: do we want to try to converge on a default binding?

McCool: also multipart chunked SSE

Matthias: we have weblinking in the TD which can pull in external resources
... management things

McCool: security metadata and bindings, e.g. roles
... test modes

Matthias: system thing to represent the local runtime
... and things in the runtime to potentially expose
... has some internal URI scheme that can use I2C and other local interfaces, like GPIO on a raspberry pi
... there is a local discovery mode

McCool: security configuration data

Matthias: can provision a new runtime

McCool: maybe it's 2 different things for system e.g. runtime provisioning and local things in the runtime context

Matthias: could have a servient management thing for provisioning and installing scripts
... thing management vs. management things

McCool: gateways?

Dave: website using iotschema annotation with UI controls
... also discovery
... make it easy for ppl to discover and install services using web browsers

McCool: service things
... payments
... large can of worms

Matthias: this is exactly thing management

Dave: also make these things discoverable

McCool: basically a TD that describes the services

Matthias: there is a capability for a thing already defines

Dave: how do we orchestrate it end to end?

Matthias: script on the website can call or invoke interactions of the management thing
... which operates on the runtime

Dave: browser vendors may need to do special things

Matthias: if they implement the scripting API it can be done without special integration

Dave: security and privacy are important

Lagally: we don't have a way to describe how an API works like interdependencies between interactions

McCool: we can use ontologies to apply constraints

Dave: sequences of API calls

Koster: there is a schema.org activity on describing web service APIs

McCool: prioritize now

Matthias: bubble sort by walking through the list
... what can we identify that we already know we need

Dave: sort by WG vs. IG

Matthias: also some out of scope or later
... system thing exploration can be done in the IG on the management thing
... there is vocabulary, flow, and how to expose

McCool: suggestions for sorting items by venue IG vs. WG

Kaz: risk of doing some important standardization work within the IG side

Matthias: should team up with IETF on protocols and sub-protocols

Dave: is there any other work we want to collaborate with IETF on?

Matthias: mapping to web of things protocols, e.g. defining URI schemes
... people need to participate in the plugfests to incubate some of these ideas

McCool: well, actually

Dave: need to involve ppl not in the room, do more outreach
... rechartering means re-joining and creating opportunities for other companies to join

McCool: we could make it more attractive to browser vendors

Matthias: we need to be realistic about creating something worth marketing and something people can use

discussion about whether to use the charter to create interest and attract new members vs. using the charter to commit to delivering something useful

discussion about outreach

Dave: are there any thongs we should look at for outreach, e.g. cloud services, to get participation rather than competition

<inserted> scribenick: mjkoster_

Matthias: tool development and playground
... will clarify some things and make a strawman proposal for items for the new charter
... (walking through the list and making notes)

McCool: discussing class vs. template

Lagally: a place where we distinguish templates from instances

Matthias: there was a discussion IRTF about hard typing vs. flexibility in description

McCool: manufacturer has a template for a type of product

Matthias: hypermedia patterns; constructed action, events for alerts, entity description
... a running action is not a thing but needs a description in the TD
... management thing is low hanging fruit
... how do I manage a remote runtime or proxy
... WoT vocabularies are normative

McCool: security metadata also

Matthias: communication patterns go in IG
... but the created action can be developed in WG, it is already incubated
... who would build and specify a new sub-protocol over WS?

(dsr, mm, and expected to be Mozilla)

Matthias: this should be IG incubation

Dave: want to build a peer to peer protocol

Matthias: also the Panasonic WS sub-protocol
... system thing is a candidate for IG incubation
... is there anything someone can't live with?

McCool: split developer outreach into two categories
... liaisons and online events

Matthias: combine with plugfests

Sebastian: what about the WoT landing page?

[lunch till 1:30pm]

<kaz> scribenick: kaz

Next plans for WoT Task Forces

Scripting

Zoltan: publication prep ongoing
... new api style for simplified TD
... feasible we agreed
... @context
... action point for Daniel to check with WebIDL people about how to handle the changes
... PRs for simplified TD

Matthias: need to accelarate the work
... how the JSON-LD 1.1 version would look like
... WebIDL only includes normal stuff
... Daniel to follow up

Zoltan: we can modify later if needed

Matthias: can you do it now?

Zoltan: not now

Matthias: maybe you can ignore the semantic part for the moment
... and Daniel can handle it separately

Zoltan: we can add an Editor's note

Matthias: paper review next week
... can give you the 2nd week
... e.g., 13th
... scripting call on 15?

Zoltan: ok
... and make a PR
... start the work on the scripting spec for new version
... next plugfest will be end of June
... aim May for the iteration
... start algorithm discussion
... security consideration as well
... freezing date may be June 1

Matthias: in May iteration

Zoltan: main steps of the algorithm
... will discuss how to do during the next script call in 2 weeks
... April 9th
... that's it
... btw, thanks for the good meeting!

(zoltan leaves)

TD

Sebastian: restart our telco on April 6
... next f2f end of June
... around 13 weeks
... need stable version for plugfest
... by 10 weeks
... compile simplefied TD approach
... new vocabularies into TD deliverable
... ask for volunteers

McCool: will create PRs for security metadata for TD
... aiming PR by end of May

Matthias: special build procedure for TD spec

Sebastian: not very complicated

McCool: also need ontology work
... 4 weeks to do that

Sebastian: rocedure on the README.md
... ok to merge section 5 and 6?
... initial idea was only core model somewhere
... make sense to merge "5. vocabulary" and "6. JSON-LD Serialization"?

Lagally: not a good idea
... pure model should be kept separately

Matthias: simplified TD doesn't have to be a second one

McCool: clean separation would be good

Sebastian: maybe possibly provided as a separate note?

Dave: self-contain style would be good
... other serializations could be documented separately

Matthias: this will be fine
... media type can be registered
... maybe good to have a separate work with figures
... CBOR, etc., could be interesting
... depending on how much figures needed, though
... maybe would make sense to move out
... there is redundancy

Lagally: would like to keep it asis

Matthias: maybe clean-up is still needed

Lagally: right

Sebastian: done

Binding

Koster: still some work for publication
... next item is actual action pattern
... more functionality
... target wold be May for stable one
... major refactoring base on simplified TD

Matthias: not much adaptation

Koster: simplified version of form, etc.

Matthias: one point is
... action item Barry picked up
... guideline for WoT Binding, e.g., MQTT

Koster: happy to prepare for it
... stable version by May
... publish for plugfest
... binding mechanism

Matthias: similar issue to be documented for security part

McCool: lifecycle issue
... create instance, etc.

Koster: that's it

Matthias: when to publish the first draft?
... maybe end of April?

Kaz: provides the clarification that the originally expected publication date was last week and would suggest we publish it next week asap

Matthias: Binding to be published asap
... TD also to be published asap

Security

McCool: end of April
... security metadata for TD
... more imporatant thing is security review for scripting api
... lifecycle and expansion for security
... more abstract ersion of lifecycle
... timeline
... 6 weeks from now
... NDSS paper also to be finished
... for the security note
... industry use cases
... try to update by the next plugfest
... another point
... testing validation
... every tf also should look into it
... accessibility
... work with Graeme
... OCF liaison
... Koster has views?
... WoT bridging project
... involving OCF Members
... OCF metadata-WoT metadata bridging

Matthias: they might think OCF as a possible competiter to OCF
... but that's not true
... bridging vocabulary with OIC one, etc.
... should not feel WoT is a competeter

McCool: technical reviews for feasibility
... so would ask Koster's opinion as well
... with reference to more stable version specs
... we'll have more discussion on that

Matthias: some binding for WoT-OCF
... something does that UPnP
... knowledge about UPnP

McCool: ecosystem-ecosystem bridge
... bidirectional bridge

Matthias: WoT for bridging
... you don't have automatic mechanism
... but more formal way using WoT
... get less bridging issues

McCool: thinking about OCF bridging
... let's talk about that offline

wrap up

Matthias: thank you everyone for coming!
... quite good meeting
... simplified TD, etc.
... solves various issues
... fits better to existing ecosystems
... very good result from this meeting

McCool: rechartering timeline?
... 3 months extension enough?
... maybe actually 6 months

Kaz: will talk with PLH
... based on the results from this meeting

<scribe> ACTION: kaz to talk with PLH about rechartering

<trackbot> Created ACTION-130 - Talk with plh about rechartering [on Kazuyuki Ashimura - due 2018-04-05].

Matthias: 3 months for wrapping up the current work
... and 3 months for generating new Charter

Kaz: repeats the basic plan on the flipchart

publication plan and rechartering

Dave: what to be done within the upcoming a few months?

Matthias: publication/plugfest by the next f2f
... will summarize it by email

Kawaguchi: still not sure about the relationship

Matthias: explains

Kaz: this is similar case to HTML5 which depended on WebIDL

<scribe> ACTION: kaz to talk with PLH about if TD can refer to JSON-LD 1.1 if it's a WD

<trackbot> Created ACTION-131 - Talk with plh if td can refer to json-ld 1.1 if it's a wd [on Kazuyuki Ashimura - due 2018-04-05].

Matthias: will summarize the story and send it to the Membership

<scribe> ACTION: matthias to summarize the plan for publication and rechartering and send a message to the group list

Lagally: first and good meeting

Matthias: thank you, all!

[f2f meeting adjourned]

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/05/07 02:47:30 $