WoT-IG/WG Joint F2F in Princeton - 28 January 2019-2 February 2019

group photo from the OpenDay on 30 January 2019

Group photo from the OpenDay on 30 January 2019

group photo from the WoT F2F on 31 Jan 2019

Group photo from the WoT F2F meeting on 31 January 2019

(Some more photos are available online :)


Summary of Action Items

  1. [NEW] ACTION: Ege to create an issue on "Vocabulary term"
  2. [NEW] ACTION: kaz to include Zoltan and Daniel into the discussion thread with PLH and Yves
  3. [NEW] ACTION: sebastian to create an issue on how to handle security (building block or not) within the architecture spec
  4. [NEW] ACTION: lagally to remove gray box of home
  5. [NEW] ACTION: sebastian to generate updated figures and text for smart factory
  6. [NEW] ACTION: mccool to generate additional use cases on mobile users
  7. [NEW] ACTION: mccool to generate text on security at the beginning of section 5 building blocks
  8. [NEW] ACTION: lagally to generate some text on digital twin idea around 5.1 overview
  9. [NEW] ACTION: kaz to talk with the W3C Comm Team about the WoT landing page
  10. [NEW] ACTION: kaz to talk with W3M about possible liaison with the One Data Model group after McCool/Koster/Lagally's outreaching them
  11. [NEW] ACTION: ege to create a PR on how to make the schema restrictive
  12. [NEW] ACTION: kaz to create an area to store presentations from f2f meetings

Summary of Resolutions

  1. We'll fix the README.md at wot repo, and think about further clarification during the WoT Architecture call later
  2. OK with not having "application scenarios" as a top-level section but possibly having that as a subsection of "Use Cases"

28 January 2019 - TestFest Day 1


Sebastian_Kaebisch, Michael_McCool, Ege_Korkan, Michael_Koster, Michael_Lagally, Tomoaki_Mizushima, Taki_Kamiya, Kunihiko_Toumura, Toru_Kawaguchi, Yousuke_Nakamura, Takeshi_Yamada, Ryuichi_Matsukura, Kaz_Ashimura
Kajimoto, Dave

Instructions for TestFest

Sebastian+Ege: gives instructions for today and tomorrow
... assertion test for today
... behavior test for tomorrow

expected deliveralbles from testfest

Expected deliverables from the TestFest

Let's work hard!

everybody working on testfest everybody working on testfest everybody working on testfest everybody working on testfest everybody working on testfest everybody working on testfest everybody working on testfest

Implementation summary

device servient implemenation summary

Device servient implementation summary

Updated instructions for tomorrow

Ege: all the implementors are encouraged to put all the CSV results (and TD as the source of those results) under the 2019-princeton directory of the GitHub repository

expected deliveralbles from testfest updated based on today's results

Expected deliverables from the TestFest updated based on today's results

[End of TestFest Day 1]

29 January 2019 - TestFest Day 2


Sebastian_Kaebisch, Michael_McCool, Ege_Korkan, Michael_Koster, Michael_Lagally, Tomoaki_Mizushima, Taki_Kamiya, Kunihiko_Toumura, Toru_Kawaguchi, Yousuke_Nakamura, Takeshi_Yamada, Ryuichi_Matsukura, Kaz_Ashimura
Kajimoto, Dave

McCool's update 1

where to install what

Where to install what on GitHub

McCool: goes through the report.html on his local pc

online report

McCool: Hitachi did interoperability part as well
... that is not priority for this time, though

staticaly rendered version report as of Jan 29

McCool: Ege has updated the assertion test tool

(note that Ege put a note on the whiteboard saying that 5 features have problem with the tool)

McCool: will revisit Ege's tool
... in hour or two, will explain the new setting
... should mention that features with underscore are not listed here in the main table within report.html
... service assertion separately described
... we have gaps there
... would add that later but we'll remove that part from the final implementation report
... make sure you check-in updated TDs and results

Ege: updated the playground/assertion tester

Kaz: by "updated" do you mean those 5 green features with problem yesterday also covered now?

Ege: updates the list of features with problems
... now there are 3 features
... td-action-names, td-property-names, td-event-names

McCool: talks about hangout setting

staticaly rendered version report

McCool's update 2

McCool: updated the results

Intel resources

McCool: TDs, CSV results...
... please put your results like this
... shows update.sh script


area for automatically generated results

McCool: sub directories under the company-specific directory will be ignored

Ege: explains the assertion tester's behavior for parent/children assertions

McCool: let's focus on the results here under the "inputs" area

inputs area

McCool's update 3

McCool: gives updates on automatically generated outputs

automatically generate outputs

McCool: don't edit this directory manually

[End of TestFest Day 2]

30 January 2019 - OpenDay


McCool, Sebastian, Ege, Koster, Lagally, Mizushima, Taki, Toumura, Kawaguchi, Yamada, Nakamura, Matsukura, Kaz, David_Hingos, Dong_Wei, Karl_Ludwig_Fetzer, Rahul_Kumar, Zoltan_Kis, Naveen, Kurt_Bettenhausen, GeorgePercivall, Tobias_Ahlgrim, many-people-from-siemens
Kajimoto, Dave

OpenDay starts

McCool: starts the OpenDay
... introduce Kurt
... also thank Siemens to host the meeting

Welcome to CT US@Princeton - Kurt Bettenhausen, Siemens

Kurt: compiles slides to introduce Simenes Corporate Technology
... there is a video as well
... [Milestones]
... [Facts&figures on R&D]
... 5.2 billion Euro for R&D; 40500 R&D employees
... 8100 employees and 5650 software developers at Corporate Technology
... [Corporate Technology at a glance]
... India, China, US, ...
... [Company Core Technologies]
... [CT RDA - Research & Development in Digitalization & Automation]
... [CT IP - Corporate Intelletual Property]
... [CT UR - University relations]
... [Charter of Trust]
... implement the technology accordingly
... video ready
... tx!
... enjoy your meeting!

Introduction to WoT - Sebastian Kaebisch, Siemens

Sebastian: W3C Web of Things - Getting Started
... glad to present WoT activity now
... giving some kind of introduction here
... WoT is a W3C standardization activity
... started with a workshop at Siemens in Berlin several years ago
... discussion on technology building blocks
... WG working on its deliverables
... 200 participants in WG/IG
... counter the fragmentation in the IoT world
... there are isolated activities
... to be consolidated
... exploration and liaison
... setting up deliverables, WoT Architecture, Thing Description, Scripting API and Binding Templates
... PlugFest effort for PoC
... close to submit a Candidate Rec for TD
... [PlugFests to Evaluate Current Working Assumptions]
... pictures
... [Why the Web - User- and Developer-friendly
... Internet of Things
... domain expertise, embedded developers, optimized protocols and formats
... silos with high integration costs
... hotel booking site as an example
... World Wide Web
... interoperability and usability
... very nice example of collaboration by different platforms
... integrating any applications
... much bigger than IoT domains
... based on the Web technology
... that's why switching to the Web technology
... [The WoT Thing Description]
... first building block
... bring a new thing
... first thing to know
... who are you?
... what kind of functions?
... what kind of data?
... how does the payload structure look like?
... how can I access?
... context information?
... protocols/serialization?
... security?
... relations to other Things?
... all the questions here are answered by the TD
... [W3C WoT Building Blocks]
... other building blocks
... independent from other formats
... work with other protocols
... done by the Binding Templates
... also Scripting API
... normalize the interface
... develop apps using standardized I/F
... also security to be taken care
... taking care of existing security settings
... [WoT Thing Description]
... an example here
... JSON-based document format
... thing metadata
... couple of metadata
... decide what to use
... security metadata
... then
... list of interactions with data schema
... common data definition like JSON Schema
... we don't introduce new data model
... simply use already defined data
... semantic annotatiaon
... JSON-LD format
... kind of like RDF
... existing terms for existing domains
... reuse domain knowledge
... and protocol binding knowledge
... also links
... [WoT Binding Templates]
... instantiated in TDs
... special usage of protocols
... e.g., application/ocf+cbor
... based on OCF
... [W3C WoT Integration Patterns]
... integrate legacy devices
... [W3C WoT Roadmap]
... here Jan 2019 now
... candidate rec to be published
... also working on implementations
... TD spec and Architecture spec
... ready to be published as W3C RECs this year
... also WoT workshop middle of this year
... hosted by Siemens in Munich
... to get feedback and new ideas
... newly generated CG for iot.shcema.org

Koster: recently created a W3C CG
... iot concept and ideas
... semantic modeling problem
... extensions for iot

McCool: various verticals
... e.g., smart city
... several different stakeholders
... smart city business group to be generated
... also looking at other things, e.g., liaisons
... bridging to othr SDOs

Sebastian: [W3C WoT summary]
... [W3C WoT Resources]
... links here
... implementations and tools
... WG participants here
... [Contact]
... questions?

George: api definition?
... how are you doing that?

Sebastian: there is a document
... API definition based on WebIDL

George: something like swagger?

Sebastian: abstract API design
... description of API
... very abstract

McCool: covers various web services and protocols

Kaz: give some more clarifications on scripting
... expose the device capability and consume it from the app side

McCool: for orchestration

George: implementations?

McCool: eclipse project for node-wot implementation
... thingweb, playground, node-red, etc.
... describe existing devices using TD

@@: what is the stance of orchestration?

McCool: node-wot is orchestration layer
... discover and consume
... run scripts on runtime

Kaz: mentions "orchestration" here means interconnection between various devices and applications using standardized Thing Description

McCool: mentions our demos expected later

Smart Agriculture - Ryuichi Matsukura, Fujitsu

Matsukura: [Smart Agriculture]
... computer-controlled agriculture
... plant factory
... Fujitsu's factory here
... completely controlled
... second one is greenhouse horticulture
... last one is agricuture cultivation
... reduce labor of human resources
... using drones, etc.
... [Greenhouse Horticulture]
... features
... ensure a stable supply
... regardless of weather conditions
... temperature, humidity, etc.
... enable stable year-round supply
... increasing product of tomatoes
... advanced technology
... growth is 3-4 times
... [Goals for the project]
... 3 goals
... collect environmental data
... provide services and facilities anyone can install/handle
... enable to use with no maintenance/no damages regardless of system troubles
... [Experimental fields]
... research greenhouses
... commercial greenhouses
... run by agriculture companies
... very big plants
... 4.0h in Shizuoka, 2.4ha in Miyagi and another in Ibaraki
... [System configuration]
... 100 sensors connected to the cloud
... 5 gateways
... each gw connected with 27 or 54 sensors
... the server aggregates the data

(break due to the network outage)

Matsukura: [Sensor units]
... 27 sensors installed in each fielded
... temperature, humidity, brightness, UV, air pressure, Co2
... also moisture, nutrient
... controller for BLE/LoRa
... extension cable connected with the sensors
... power supply methods: self contained, e.g., solar panel, battery, AC power
... monitoring every 1 min
... [Area network]
... [Gateway and server]
... local proxy and remote proxy
... WoT core here means runtime on Java
... connected with adapters
... for sensors/actuators
... [Operation management]
... treats network equipment as devices
... [Example of operation management]
... visualization of the actual network topology
... detects problems
... [Summary]
... smart agriculture project started in Oct 2018
... WoT-based system

McCool: questions?

Ege: protocols for various devices?

Matsukura: currently using proprietary devices and adapters
... some kinds of protocols are already supported

McCool: you mentioned ECHONET
... any relationship?

Matsukura: ECHONET has a lot of descriptions
... useful to generate new devices

Siemens demo video - Tobias

McCool: can we get the URL of the video?

Tobias: will check

Spatial Data - George Percivall, OGC

UNKNOWN_SPEAKER: [Geospatial and Sensors in WoT]
... [OTC topics for W3C WoT F2F]
... W3C/OGC Spatial Data
... [The OGC Mission]
... global forum of developers and users of spatial data
... [OGC Members]
... [800 implementations]
... [1000s of Services, 100Ks Datasets Worldwide Implement OGC Standards]
... [Spatial Data on the Web Interest Group]
... two standards bodies working together towards a Web of Spatial and (Linked) Data
... use cases and requirements, best practices, OWL Time ontology, SSN ontology
... fusion of semantic data
... [Spatial Data on the Web Best Practices]
... simple location elements
... [WFS 3.0 Core - Resources]
... [Time Ontology in OWL]
... [Allen Temporal Interval Algebra]
... [New Time-OWL]
... [Semantic Sensor Network Ontology]
... [Observations and Measurements]
... syntactic interoperability and semantic interoperability
... [Sensors and Observations]
... [OGC SensorThings]
... [OGC Standard-based Data Model]

McCool: extending vocabulary

George: [From Sensor to the Decision]
... [location...]
... [Next Generation First Responder IoT enabled Common Operation]
... [SensorThings harmonizes both in-situ and...]
... [SensorThings Example - Smart Cities]
... [OGC topics for W3C WoT F2F]
... W3C/OGC Spatial Data on the Web IG
... OGC SensorThings

Taki: the model is based on observation?
... foi, etc., different between verticals

George: not depending on verticals
... spec itself is generic
... units/measure is another question

Sebastian: we have very simple units
... and also referring to existing ones

McCool: vocabulary terms come from outside

George: similar approach
... can refer to the other units

Lagally: hot to validate devices?

George: compliant test framework
... executable test harness
... using scripted tests
... maintain official test site

Ege: what kind of test suite?

George: team engine

McCool: would be great to have resources on that

George: ok

Sebastian: say something more about test language?

WoT and Oracle IoT Cloud Applications - Michael Lagally, Oracle

Lagally: [W3C Web of Things + Oracle IoT Asset Monitoring]
... [W3C Web of Things]
... describe devices (things) in a common ways across device manufacturers and protocols
... multiple participants
... [Oracle IoT Applications]
... apps: asset monitoring, production monitoring, fleet monitoring, connected worker
... platform: IoT cloud services including digital twin simulator
... [Oracle device model and W3C Thing Description interworking]
... multiple instances
... DM2TD converter converts device model to TD
... property, action and events
... another converter for device level as well
... consume device and expose device
... node-wot bridge/gateway

[End of TestFest Day 2]

30 January 2019 - F2F Day 1


Sato, Fujiyoshi, Matsuda, Toumura, Koster, Kawaguchi, Yamada, Taki, Nakamura, Mizushima, Lagally, Ege, McCool, Kaz, Michael_McCool, Manu_Sporny, Zoltan_Kis
Daniel, Matthias
Kajimoto, Dave

<taki> Scribe: TK

<taki> ScribeNick: taki

McCool is explaining meeting tools...

McCool: schedule. Sebastian is not available for an hour from now.


McCool: Matthias has time constraint.
... Zoltan as well.
... Lagally suggested to split architecture session into two.
... one hour now.
... 9:30-10:30

<kaz> s

McCool: we do similar for TD.
... sebastian is available from 10:30-11:30
... zoltan is available after 12:30

Lagally: we can do another architecture session tomorrow.

McCool: 12:30, half an hour lunch.
... 90 minutes scripting session.
... security and privacy, we can drop today.
... binding templates for an hour.
... 3:30-4:25 security testing
... 4:35-4:30 WoT security best practices.

Kaz: I want to invite JSON-LD person in TD session.

McCool: we have TD session tomorrow as well.

Ege: I want to go through test results.

McCool: everybody needs to take a look at results.
... make sure test results are same as your expectation.
... for sanity check.

Nakamura: security meta data input, I would like to present.

McCool: meta data is TD. We can also discuss in security and privacy session.
... we go through the issue as part of TD session.
... maybe tomorrow is better for Nakamura-san's discussion.
... we have some time this afternoon as well.
... can newcomes introduce yourself

Kaz starts self introduction, others follow suite...

McCool, Ege, Lagally, Mizushima-san, Nakamura-san, Taki, Yamada-san, Kawaguchi-san, Koster, Toumura-san, Matsuda-san took turn to introduce themselves...

Sato-san and Fujiyoshi-san from Toshiba introduced themselves...

Daniel Peintner self-introduced...

<kaz> Chair+ Matthias

Matthias self-introduced... remotely participating...

McCool: Sebastian is not present now, but will join us later.

Lagally: let's start Architecture session.
... restructuing proposals
... one from Matsukura-san and another from Matthias
... after today's sesson, we need to do restructuring.

McCool: Zoltan is remotely participating as well.

Lagally is presenting architecture agenda...

Lagally: can matsukura-san explain your proposal?

Matsukura: straight forward agenda items.
... intriduction, terminology, use case
... then functional requirements, WoT servient architecture...
... I wrote whole description.
... I also uploaded deployment section.

<kaz> https://w3c.github.io/wot-architecture/#toc

Kaz: biggest change is restructuring building block and servient architecture section into one.

Matsukura: we discussed servient architecture and deployment in Bundang.

Matthias: reminder that we discussed in Lyon.
... It was forgotten.

Matthias is showing all the contribution in Github.

Matthias: technical requirements, I am not sure how to fit this.

Matthias is showing his comments list...

Matthias: termonology replacement look good.
... new functional requirements is ok.
... technical requirements. I think it is a bit too early.
... I propose this to section 11.
... WoT architecture by Matsukura-san. media type, interaction patterns, those are missing. I suggest to merge.
... WoT building block. we should explain what WoT deliverable documnets are.

Matthias is going through his proposal points...

Kaz: is this slide available?
... can you copy URL, Matthias?

<kaz> @@@ Matthias' slides tbd

<mkovatsc> https://github.com/w3c/wot-architecture/blob/working/proposals/W3C_WoT-Arch_Princeton-2019.pptx

Lagally: sequence flow is missing.

Matthias: it will belong to interaction model section.
... properties, actions will be described, and sequence diagram will be described too.

Lagally is showing introduction session...

Lagally: Matsukura-san suggests to keep this, and also terminology section.

Matsukura: application domains. currently we describe smart home, etc.
... description of combinations of IoT components follows.
... summary of use cases picture does not have detailed servient architecture.

Matthias: high level picture is a summary.
... cloud, gateway, device, etc.

Lagally: we can introduce property, action, events in introduction section.

Matthias: "process", "state", we should use those terms in introduction.

Koster: I agree.
... command-level details and block level descriptions are different.

<mkovatsc> Working branch proposal: https://cdn.staticaly.com/gh/w3c/wot-architecture/working/index.html

<mlagally> https://htmlpreview.github.io/?https://github.com/w3c/wot-architecture/blob/working/index.html

<mkovatsc> http://w3c.github.io/wot/architecture/

<mkovatsc> points to new repo

Lagally: there is some old stuff in WoT/architecture.
... Stale, non-maintained version.

Matthias: it came from IG.
... it was used for stating WG.
... IG Note never happened.

Kaz: we can explicitly mention in Readme.

Lagally: we can say it was a work of IG, and urge people to look at WG architecture.

Matthias: OK.

Kaz: we can update Readme.md.
... when we close a WG, we usually mention the closure of WG in HTML. We can follow this way as well if we want.

Kawaguchi: Let's focus on document content today. we can discuss this in editor's call.

Lagally: OK

RESOLUTION: We'll fix the README.md at wot repo, and think about further clarification during the WoT Architecture call later

Lagally: functional requirements.

Matsukura: we need to make clear functional requirements.
... I uploaded details in the document.
... component-level requirements.

Lagally: WoT servients architecture next

Matsukura: combination of application and device.
... proxy is a common architecture entity.
... in addition to application and device.
... configuration of servient. application and device srevients have common stuff.
... runtime is an abstract interface, and protocol binding provide concrere binding.
... this slide is about basic abstract structure.
... device interface adapter provides abstraction.
... proxy servient's runtime has two roles; i.e. both client and server.

Koster: "protocol binding". "protocol adaptation" may be better wording.

<inserted> Kaz: I'm not objecting, but if we changed the name of "Protocol binding" here to "Protocol adaption", that would imply we'd change the name of the building block as well

Koster: building block diagram, and this diagram. Style should look similar.

Lagally: why we can't say "Protocol Binding"?

Matsukura: some terms in building block diagram are obsolete.
... the diagram I provided is functional structure.

Koster: OK.

Matsukura: WoT servient architecture next.
... TD manager is about how to control runtime.
... servient generate exposed/consumed thing.
... who contrtols operation? It is TD manager.

Lagally: it should also include lifecycle management.
... such as onboarding.

Matsukura: servient is inside application. application receives TD, and makes ConsumedThing. TD manager takes care of this.

Lagally: where is Life-cycle management handled?
... we should consider to change terminology.

Koster: we can described all components first, then can talk about configuration...

Kaz: we need to described requirement in architecture section.
... Matsukura-san described requirements in requirements section.
... we need to link the two sections, architecture section and requirements section.

Matsukura: Deployment scenarios next
... simple deployment structures first.
... application control device in local network.
... and the second deployment is two WoT systems connected each other.

Lagally: PlugFest architecture

Matsukura: yes

McCool: security section. we need more general architecture security discussion.
... we can't fix broken devices, for example.
... I have not started this yet.

Lagally: When will you be able to do?

McCool: I will discuss with Elena next week.

Lagally: so we have two proposals, I summarized them.

Lagally is showing the two proposals...

Lagally is showing combined structure...

Lagally: we should have "application scenarios" separate from use cases.
... abstraction of all use cases.

Koster: we do not have to contain too many similar use cases.

Matsuda: application scenarios and deployments pattern how are they different?

Lagally: high level description is application scenarios.
... for owner of business, etc.

Matthias: we can describe application domain in use case section.

Lagally: we agree on intention now.
... we can name "application domain" or similar.

RESOLUTION: OK with not having "application scenarios" as a top-level section but possibly having that as a subsection of "Use Cases"

Koster: interaction should be mentioned earlier.

<mkovatsc> Feels like nobody remembers this: https://cdn.staticaly.com/gh/w3c/wot/gh-pages/wot-ucr.html

Lagally is showing detailed consolidated structure...

McCool: On Friday, we will read through after restructuring.
... short session on Friday, and another short session on Saturday.

Matsukura-san, Koster, Matthias: OK

Kaz: Example interaction patterns and references are already available within the Appendix section. and your point for them is that we still need to update those appendix subsections..

Kawaguchi: interaction pattern should be made a bit abstract.

Lagally is showing open issues...

Lagally: use cases for a thing directory, use case for semantic search are missing
... extension mechanism is not mentioned.

McCool: TD session next.

Sebastian: I need 5 minutes break.

McCool: 11:10am, we come back.

<kaz> (break)

<kaz> scribenick: kaz

(Ege is ok to take notes in pm1 for Lagally)

Kaz: before starting TD discussion
... group photo right after the TD discussion
... also dinner proposals by the end of lunch


McCool: 2 hours for today
... and 2 more hours tomorrow

Matthias: can make it

Sebastian: Matthias' slides include some of the TD portion
... Matthias, are you available in the afternoon EST?
... that's evening in Germany

Matthias: not really

Sebastian: in that case, let's start with Matthias
... will show the slides for Matthias

@@@ Matthias' slides on TD tbd

Matthias: summary noticed
... [Terminology]
... InteractionPattern (#282)
... comes from a different discussion than the TD elements
... maybe "Affordance"?
... this current term itself doesn't make sense
... offer possible interactions
... related to the issue 282 here

Koster: I also use affordance

Matthias: capability vs affordance
... if this is kind of problem
... combined hypermedia calls?

Koster: would be good
... Google API use "trade"
... no one uses "affordance" so far

Sebastian: pattern term for serialization

Matthias: kind of weird

Lagally: not really sure if it's clear enough
... "interaction" is clearer
... don't think "affordance" is the right term

Koster: "affordance" is used by the design guys
... element for interaction
... it means interaction
... if you talk with design engineers, they know about this

Lagally: why not "interaction"?

Matthias: it's design pattern

McCool: just change the class of name

Taki: potential impact to the Architecture?

Sebastian: possibly

McCool: probably we should read through the document

Sebastian: in 2 months we're done...

Matthias: let's think about this until tomorrow
... "InteractionPattern" is wrong anyway

Sebastian: may I ask you to create a new issue for further discussion?
... in addition to 282
... maybe we should add another issue for this discussion

Matthias: there is some additional discussions there already

Sebastian: ok

Matthias: next on "Vocabulary term"
... doesn't have a value or type
... just a term
... but we use it to mean RDF properties or class members or whatever we have now
... issue on the next slide
... logic broken after removing RDF/JSON-LD foundation
... people don't read the history

Ege: do you already have any issue about this?

Matthias: collected recently

Sebastian: Ege to create an issue

<scribe> ACTION: Ege to create an issue on "Vocabulary term"

<trackbot> Created ACTION-156 - Create an issue on "vocabulary term" [on Ege Korkan - due 2019-02-07].

Sebastian: related to the deletion of RDF/JSON-LD portion

Koster: just "term"?
... often used

Matthias: talked about this with vocabulary members

Sebastian: "element term"?

Matthias: there is a related issue on the next slide
... and also "Assumptions"
... overused throughout the spec
... next slide please
... [Information Model and Default Values]
... connected with "Vocabulary term"
... removing JSON-LD portion caused impacts
... what is actually our information model
... no formal grounding given
... @context, @type not included in the information model
... come back to show what all the model shows
... property graph, etc.

Sebastian: make sense

Matthias: have to find a way to mention what our information model is
... RDF/JSON-LD background
... label for property graph

Sebastian: specific keywords from JSON-LD there

Matthias: we defined equally defined members and elements

Koster: @type without semantic information?

Matthias: need to mention semantic annotation
... property graphs related to property labels

(Manu joins)

Manu: joins
... can provide some background
... have some specific question
... generalized discussion or data model serialization

Sebastian: maybe we should provide some more background from our side
... some issues here
... regarding the progress of JSON-LD 1.1
... complicated due to the difference of timeline
... want to look like JSON-LD but not refer to it
... still our RDF scenario/background
... so going for JSON-LD 1.0 serialization at the moment
... and making some additional stuff
... maybe TD 1.1 would be synchronized with JSON-LD 1.1 later

Manu: we have same problem with VC data model
... target is making sure people use only JSON-LD
... but difficulty with interoperability
... had to do refer to JSON-LD 1.0
... and make some restriction on JSON expression
... so that no changes would be required for 1.1 adaption
... for JSON processors, you have to ensure the context are provided some specific order
... we added some language for that purpose
... your JSON-LD processor must use something additional
... the spec can be normative in a right way
... does that approach helps?

Matthias: yes
... sounds quite similar
... exactly same
... more details on our issues?
... something if you could provide that "special language", that would be helpful

Manu: we have exact same problem
... we implement very soon
... the WoT context should come first
... the JSON-LD processor would throw error
... let me try to find the text
... same problem to be solved in the same way

Matthias: tx!

Manu: if you have issues with @context, @type
... we also had same issues several months ago

<manu> https://w3c.github.io/vc-data-model/#semantic-interoperability

Manu: 7.1.1 Semantic Interoperability from the VC data model draft

<mjkoster> here is the github issue discussion:

<mjkoster> https://github.com/w3c/json-ld-syntax/issues/20

Sebastian: cool

Manu: other question I had
... alias for @type?
... you can do this in the context

<manu> In the context, you can do this -- "@id": "id"

<manu> In the context, you can do this -- "@type": "type"

Manu: you can do the above
... the question is context information has alias or not

Matthias: for @type, basically people didn't want to introduce this complexity

Manu: can understand the motivation
... we had this discussion #20
... try to do is handling JSON version and JSON-LD version

<mjkoster> we wanted to keep the semantic annotation separate from the JSON type in the file

Manu: has anyone say they want to add objects that have no mapping?

Sebastian: should not the case

Manu: ok

Matthias: if you include other context
... you always have to maintain @type
... for semantic meanings
... the other part people just add their own types
... saw a lot of examples
... intend to do in the beginning

Manu: ok
... safely added to the context though not clean
... as the result

@@@ TD 6.3

Matthias: core vocabulary for TD

Manu: do you have a @vocab for mapping to some vocabulary?

Sebastian: no
... our idea is that @context is missing
... before processing JSON-LD, all the necessary information is added

Manu: ok
... the question of mine
... TD has @vocab or not

Matthias: if you could have a pointer, we could look into that
... you have to know about the additional vocabulary anyway
... must be context

Manu: make sense to me
... valid mapping
... people can use their own proprietary vocabulary
... only remaining question about @type
... any other questions around?

Kaz: would like to continue this collaborative discussion

manu: ok
... my question is generating a generalized data model?
... or serialized as JSON, CBOR, etc.?
... we've been doing serialization-agnostic approach

Kaz: quite similar policy :)

Manu: just wondering about test suite now
... anything else?

Matthias: some "central model" you mentioned?

Sebastian: do you want to show your slides, Matthias?
... would return to the slides

McCool: can continue the discussion by 20m
... and 90m for lunch

Matthias: sounds good
... (going back to his slides)
... [Information Model and Default Values]
... moved to the serializaton
... why it's there now?
... may be CBOR
... if there is information missing, should add that

Sebastian: people are confused with our mandatory terms
... give there explanations
... if you want to follow the default valuses...

McCool: any serializations

Sebastian: e.g., CBOR

McCool: clarify mandatory vs optional
... still mandatory but could have default value

Ege: optional/mandatory/default?

Sebastian: also have some slides on that point

McCool: we should keep default values
... to avoid confusion

Sebastian: still mandatory for serialization

McCool: information model is mandatory
... clearly identify what shouldn't change
... possibly have 2 separate tables?

<Zakim> manu, you wanted to note that this is a canonicalization problem, agree w/ putting it in information model, but problem comes in testing interop at the syntax layer.

Manu: in general +1 to moving it to information model
... if you make that decision, this is a canonicalization problem
... how to do that?
... needed to work on that problem
... JSON model to JSON-LD
... canonical syntax vs everything
... how the information canonicalize?
... data set normalization
... what is in the information model?
... fine to specify how to express it
... the number is expressed, for example
... and now we want to express digital signature, etc.
... can do it on the data model
... and different seriailzations
... there are 3 things to do
... values in the information model
... and different serializations would express that in different ways
... really think about canonicalization

McCool: regarding the issue on testing
... convenient to have canonicalized version
... standardized converter
... that's more media problem

Manu: that's reasonable
... forced to pack syntax
... one way is take the data and syntax converted on te end point

<sebastian> sorry

Manu: canonicalization mechanism
... JSON-based or CBOR-based
... and canonicalization in the spec
... ok to use the canonicalization

McCool: practical pov
... we're out of time to deal with that
... also switching to a different approach
... how to finish our test work
... have a standardized canonicalizer
... then we can use that for testing
... single assertion can specify what to test
... but we're going for manual way

Matthias: valid to have a tool for canonical form
... quite easy way to solve the issue
... default value must move back to the information model
... mandatory/not mandatory/default would be good
... we're using XML Schema for data modeling

Sebastian: maybe we should show an example

@@@ TD thing level, property (6.2.3)

scribe: to show you concrete example (ex. 7)
... this is actually map of property

Manu: afaik, not possible

Sebastian: 6.2.1 Thing
... we use XML Schema for any types
... e.g., "string"
... Property is actually a map for Property

Matthias: technically here is the type of array
... object notation to list

McCool: syntactically they're map

Matthias: maybe we can find map's

McCool: +1

Ege: from JSON Schema pov

McCool: only question
... implementations how to render them

<manu> Are you using -- https://w3c.github.io/json-ld-syntax/#node-identifier-indexing

Manu: are you using the above?
... JSON-LD WG may have some idea

McCool: we should go ahead and implement that

Matthias: cardinality here

McCool: syntactically not arrays
... but objects

Matthias: what our information model is like?

McCool: we're end of our time for morning

Matthias: let's go through the last slide
... [Serialization]
... there is no "JSON integer"
... serialization should be consistent
... unsignedInt must be serialized as JSON integer
... what about signed, or what about all others not listed?
... took out of the serialization section
... we have rule only for unsigned into

McCool: unsigned is wrong
... have to be numbers
... example is not normative, though

Lagally: problem with the table?

McCool: double type is also strange

Matthias: if you go 6.1, unsignedInt and double mentioned

Sebastian: got it

McCool: bug fix?
... may cause additional assertions
... should add some description on our using xsd type

Matthias: next
... some editorial thing
... names input and output rely on
... and the last point
... artificial constraint
... break the tool by @type
... string directly or array of strings?

Sebastian: can be both

McCool: the argument is inconsistent

Sebastian: "the @type MUST be serialized as JSON String or as JSON array of strings"

McCool: 2 questions
... must be serialized as array

Sebastian: why we should not simply use array?
... have to check the issue, though

McCool: maybe could not force people, though
... can we be flexible or strict?
... being flexible may cause problems

Sebastian: 5.3.2 ArraySchema


Sebastian: array or object?

Matthias: explains the behavior of array vs object
... shouldn't have artificial constraints

Manu: maybe mis-communicating...

Sebastian: item term here (5.3.2)
... trying to assign 2 data

Manu: something from JSON Schema?

McCool: we could have canonicalized version
... single or array

Matthias: we need one of the RDF experts

Manu: it can't have 2 different things at once

Matthias: we need to be consistent

Sebastian: we should have string and array of string for "op"?

McCool: time check
... 9mins for lunch
... Zoltan, scripting for 1:30pm

zk: fine

McCool: will update the f2f agenda

Ege: have generated an issue for this point

Matthias: there are 4 issues

<ege> https://github.com/w3c/wot-thing-description/issues

McCool: will update the agenda for Fri/Sat as well
... take a look and give comments

(Manu leaves)


Scripting API

# Zoltan's slides

<inserted> scribenick: ege

Zoltan: here is the agenda
... in last f2f, we discussed we might need alignment with web platform

various topics like webidl, use it?

scribe: not using observables
... it is not implementable for browsers
... we wanted to see how scripting api is understood in the group and did the questionnaire
... only 7 out of 20 people responded

McCool: did you mean browser only or browser+nodejs

Zoltan: not many are interested in browser implementations
... generally we implement for browsers, not the other way around
... polyfill would be enough
... having it in browser is a long and hard process
... we need one way to provision things, like adaptation interop testing
... does michael koster or matthias have comments on it

Matthias: like you said there is a choice of not needing a browser implementation
... I answered from my needs

Zoltan: do you have any comments on this

danielp: the poll represents what we have seen from previous calls
... there are not enough respondants
... so there is interest but the interest is very small

Zoltan: (presents issue 158)
... I have did this to make scripting API more browser compatible
... we will not go for a REC track, only a note
... if it is only a note, do we go for typescript or webidl
... I will show a gist about the proposal
... any comments

Daniel: no interest from browser
... what we have seems to work
... it worked well in testfest with node-wot
... we made step towards browser API but we wait for interest from them to go further

Zoltan: there these two options, slide 5
... option one, with fetch api. also change to typescript
... skipping slide 6. presents TAG tips to make scripting api more browser friendly
... we can explain how to create a js object from td
... slide 8. we see thing property, it implements observable
... in browser friendly api, we see onchange instead of observable

Kaz: I have comment regarding the discussion with philippe but can wait until you finish these slides

Daniel: to clarify, we just attach handlers at the moment, like described in TD. then you can get a TD by serializing.
... for browser you would need an algorithm to write a td like you do for read a td

Zoltan: right I don't even have that method here.
... there is an indirection here
... now ThingAction, it is similar. I need to update the comment
... now events, we have overused includes
... if you want to sub to an event, you just add an event listener
... now we come to consume and expose thing
... consumed thing inherits from thingfragment
... we also use observables for detecting TD changes
... browser doesn't use observable
... that is also more similar to browser implementations
... now exposed thing, small font but similar principles
... exposed thing extends consumed thing
... it has emit event, expose and destroy. we don't need getter setter since we inherit them from consumedThing
... the handlers are the same as before
... so only emitEvent has changed but not much
... now discovery
... discovery: has discover method and also has subscribe with three handlers
... browser friendly, now we just build js object
... we can attach event handlers and call start and stop
... now wot object
... in browser discovery is by constructing a discover() object
... it has fetchThingDescription instead of just fetch to avoid semantic overlap with the fetch api
... register and unregister for directory
... now back to slide 5
... daniel do you an opinion
... I don't have a strong opinion
... both are sensible since getting close to browser but not close enough is not worth

note from scribe: the previous two belong to daniel

McCool: I would go for an option 1.a to show that we are inclined for browser compatability
... we can vote now to see how it can look and then continue with email

[Voting: 5 for option 1 and 3-4 for option 2]

Matthias: I need more information to make a sound decision

Ege: agree on mk

McCool: it seems that this is a general problem
... what would you need

Matthias: examples?

Zoltan: browser compatible means it looks more like browser apis so more developers can understand
... it would be also consistent with node.js developers
... node is more liberal in event handling
... we need more work on asking more people

Ege: do you have cases (non-wot) that have a browser a non browser version?

Zoltan: we can do that

McCool: there is generic sensor api that has this case that responds to ege's question

Zoltan: we won't go for a rec, it will be a defacto api
... *** was ok for polyfill

Matthias: I am not sure if I understand with what me mean by provisining
... what does provisioning add

Zoltan: it brings discovery

Matthias: why not call it discovery then?

Ege: students ask for tutorial

McCool: this is more of a marketing outreach problem

Zoltan: will there be an online device that people can use ?

no comments

Ege: but a tutorial is not an example, it starts small and builds up

McCool: it is more of a tutorial
... sorry more a workflow

Zoltan: this should be a task for the architecture
... but happy to contribute

McCool: one would land at the landing page and then read the architecture and then the tutorial

Kaz: discussion with philipp

Zoltan: if we move away from webidl we change a lot
... then it becomes a documentation for node-wot

Kaz: i wanted to invite them to the discussion but I couldn't

McCool: if it is a browser api we can leverage from the test suite they have

Zoltan: thank you, we can finish scripting pai

Kaz: we can include you to the email thread

Zoltan: please include daniel as well

<kaz> ACTION: kaz to include Zoltan and Daniel into the discussion thread with PLH and Yves

<trackbot> Created ACTION-157 - Include zoltan and daniel into the discussion thread with plh and yves [on Kazuyuki Ashimura - due 2019-02-07].

---- binding templates

Binding Templates

<inserted> @@@ "mk:" within this section to be converted to "mjk:"

Koster: we stopped working on the binding templates once we fixed the vocabulary
... the goal is to release it as a note
... it was released sync with prague td
... the current format of the document is appopriate
... it explains how they work
... there is some architecture that shouldn't be in this document
... like having a security layer in between and so on
... so we should keep it simple
... enumeration of all the protocols we support
... what each term does
... it teaches a developer how to use protocol bindings but not to create new protocols

Sebastian: I tried explaining protocol bindings in the td documents
... I have said that you can find this form term in the protocol bindings document
... we should check for consistencyt
... for example you should do a get request
... I say: please follow the guideline found in the protocol binding document
... what is missing is ontology representation of http, coap, mqtt terms
... that's why I removed them from the spec
... e.g. I didn't use the retain flag since there is no ontology which defines that
... in mqtt you dont know the broker and topic from the href
... we should also do the media type registration in IANA

application/td-json or something like that

Koster: many can do that
... it is more for TD
... someone from eclipse foundation maybe? they use mqtt a lot

Sebastian: the default assumptions should be also in the protocol binding
... since we are a standard and protocol bindings are not how do we reference it

Koster: do you do make reference to sections

Sebastian: no just to the documenbt

Koster: I list the vocabularies but they should be separete documents
... these documents can be used outside of WoT as well
... no one says that they should be published soon
... we should at least have an internet draft for mqtt scheme

McCool: could be based on real devices
... we should test that before we put it
... so we should be testing more examples
... put it in an appendix maybe
... see the part that is relevant and then you can read the whole thing
... maybe you can do expanders like in TD
... a way to hide
... at least node-wot needs to be able to speak with an OCF device

Koster: but there is no reference OCF

Sebastian: we need clarification on how json document would look like

Koster: it is still not there
... now matthias is there

McCool: implementing how the payload looks like

Koster: maybe it can be only in node-wot

Sebastian: this was also a request from mozilla

McCool: is mozilla an implementation?

Koster: there is some new vocab like cancellation

Sebastian: we lack a good example for events
... there is someone from, I think, ietf who wants to see how events would be used

Koster: now there is a new thing called websub
... from w3c
... if we will use webhooks, we should work with websub
... kaz do you know that

Kaz: no but I can check

Koster: there are multiple ways to use http to do async

Sebastian: we have subprotocol term but there is only one value supported, longpoll

Koster: that is why there is websub

McCool: we should reserve the word for now

<kaz> fyi, WebSub is now a W3C REC

Koster: what about extension points in the vocabulary
... we don't have the idea of an extension point

McCool: how to make sure that people don't overwrite them

Ege: what do you mean by overwrite

McCool: we don't say that anywhere, meaning that something we already defined shouldn't be redefined

Kaz: websub is already a standard

Koster: that is easier then, we can implement

McCool: in two weeks please, :D

Koster: @@@ as I put above, WebSub is a webhooks from w3c

McCool: websockets from mozilla

Koster: we haven't figured out how to use websockets to make events

McCool: these strings are reserved
... there is a mozilla standard on how to handle eventing in websockets

Koster: fujitsu implemented websocket handling?

matsukura: yes

Koster: then we can use that
... there is nothing that is competing that I know of

McCool: we put what is already out there
... and then say that it is possible for user extensions since there are a lot of experimental stuff out there

Koster: is there anything about eventing that is missing overall?

McCool: a binding for opc/ua

Koster: does anyone have an implementation for it?

McCool: in the long it would be nice for it

Koster: just the idea of having xml in protocol bindings would be nice

Sebastian: there were some previous work by taki on how to map json schema to xml schema

Koster: so that would be nice

McCool: CORE shows up in the book by guinard
... we should have a generic http example
... there is some overlap between security metadata and forms/protocol bindings

Koster: is there security meatadata in forms

McCool: yes

Sebastian: in the coming sessions, in the TD spec it would be good to show different cases of TDs
... a rich example set

Lagally: we should mention opc/ua in the architecture document
... in addition to zigbee zwave etc.

Sebastian: we should have a rich set

McCool: but that would be putting something that we didn't tested
... maybe we can put in examples

Sebastian: maybe we can have a document about only examples

<inserted> kaz: wonders if Sebastian's mentioned "example document" is related to the "TD Best Practices document" proposed by Victor and Maxime. think the concept is different from that, though

McCool: that would go well with the tutorial
... adding more protocols for longpoll

Koster: sure I will create an issue for adding more to longpoll
... it is a more discussion issue right?

McCool: yeah

Koster: I don't know if we have more to discuss and to create issues

McCool: opc ua is a long term requirement
... eventually we should try to get that

TD media type

<Zakim> kaz, you wanted to ask sebastian for clarification on media type registration

Kaz: something to say about the iana registration

<kaz> media type registration procedure

Kaz: W3C is taking care of that
... registration form can be put in the td spec
... and we'll send an application email to IANA

McCool: also what about .td format

<kaz> like HTML 5.2

Sebastian: there is also one in coap, in content-format

Matthias: oh yes we can do that
... 65100 is the experimental range value

Sebastian: without this and without @context there is no way to identify a td

McCool: will we talk about cbor serialization?

Sebastian: not in this charter

Matthias: there is no advantage on doing batch registration

McCool: i worry that someone can steal the name
... we can register so save the name but not specify how it should be done
... standard encoding of cbor in json

coffee break

<kaz> scribenick: mjkoster

TD - revisited

<kaz> @@@ Sebastian's slides tbd

TD - mandatory terms and default values

McCool: we need to be able to check all terms

rename "Versioning" to "VersionInfo"

McCool: on previous topic, can we agree to optional, mandatory, default
... propose a separate section about how to canonicalize
... defaults may be serialization-dependent
... like content type
... but we can e.g. say JSON is the default
... ege: it is difficult to extract defaults from the specification
... we will add extra information into the document
... forward reference to the section where defaults are defined
... like a star with a reference
... if we canonicalize the file, we can express these defaults and other things like string vs. array
... we can also write tests against the canonical version to make assertions easier
... validators have a way to add defaults
... the canonicalizer would be a required processing step for TDs

The spec would have a special section to explain the non-canonical formatting options but in general use the canonical version for assertion extraction

Taki: does default always imply mandatory?

McCool: we should create a concrete proposal to evaluate tomorrow

"VersionInfo" term


language negotiation support

McCool: the server can always refuse and offer it's choices

Koster: you can't always get what you want

McCool: then the server can simplify responses

Toru: the negotiation uses only the title field?

Sebastian: yes

discussion of issue #161 on language negotiation and issue #359 about singular and plural terms which refers to #161 terms

<inserted> [kaz points out that issue 359's title is confusing if the main point is language negotiation]

scope at the interaction level

McCool: this is security scope which associates an interaction with a security scheme
... could remove it at the interaction level and put into a form
... for e.g. oauth and bearer token schemes
... this is issue 355

explanation of events is too rare

McCool: we need more examples

<kaz> Siemens example on periodic events

Sebastian: shows example of the 3-schema pattern for events

McCool: concern that this is different from how actions work
... there is no response schema from the subscribe operation

Koster: we need to try these against some subprotocols

McCool: what about longpoll?

discussion about subprotocols and how this pattern will fit

Sebastian: what is the outcome?

McCool: create an issue to add a response to the subscription operation
... for each subprotocol, build examples to validate the pattern and explain how to use
... make sequence diagrams

Sebastian: the seq. diagrams should go into the binding template document

items support for both object and array

Koster: need to support both of these and also contains

Ege: make an issue for contains
... what about adding "not"

Koster: "not" may not be useful for the use case of a client breaking items out of a packet but might be good for validation cases

McCool: let's add only what we know we need

<kaz> security test plan

security testing

McCool: the security testing plan is in the charter
... it is ambiguous how to test a standard as opposed to an implementation

<kaz> rendered version

McCool: so we will be testing implementations based on a framework

<kaz> Charter

McCool: to collect evidence that the standard support security
... and ensure that conforming implementations are tested
... functional test and adversarial test
... we wanted to enable different tools to be usable and not require any one particular tool

<kaz> toc

McCool: functional testing verifies that the server conforms to it's own TD
... e.g with proper authentication access is allowed, with improper auth, the access is denied

Lagally: what about things with known vulnerabilities?

McCool: these can't be passed as secure
... functional test would pass but pentest would fail
... adversarial testing simulates an attack
... we can use web service attacks but IoT devices may have new vulnerabilities, e.g. physical attacks
... we will only consider network based attacks and attacks in the operational state
... the stages are information gathering, discover vulnerabilities, try to exploit vulnerabilities
... the focus is on vuln. discovery
... static code analysis, can be done with source code or binaries
... dynamic analysis is more black box testing over the interface
... we have both network interfaces and scripting API
... fuzz testing tries to generate side effects to erroneous input to trigger vulns.
... it may create a huge array, or pass corner case values, numbers instead of strings, etc.
... e,g, trigger buffer overflows, etc
... tools for CoAP, HTTP, but not found for MQTT
... also over-the-air/wire protocol analysis can be done to find evidence of vulns.
... requires isolated networks due to network traffic generated
... there are tools that try to attack based on known vulnerabilities
... our framework will do static, dynamic tests and analyze the results

Kaz: we should have 2 or more passing implementations

McCool: we can start with node-wot and decide another implementation

Ege: there was a comment from an AC rep and another that they need to capture the test steps and show a test result in a formal fashion
... they use a well known language

Lagally: how are we going to implement the test plan? Will there be certification?

McCool: W3C doesn't certify things so it is the manufacturer's responsibility to run the tests

Lagally: how would we then make a recommendation for a particular device?

McCool: there will be published test results

Lagally: then it's self-certification
... we don't make any recommendations

McCool: we could sponsor hackathons to facilitate the testing
... we can run some tests against node-wot and the OCF bridge as a demonstration of two implementations

implementation report from testfest

McCool: the coverage is pretty good but many assertions are still untested

Ege: we need to cover the untested items before we can publish the CR

McCool: these could be easy to cover but someone needs to implement the missing assertions in a TD
... please focus on filling in the gaps and the manual assertions

Sebastian: can we review these gaps before tomorrow ?

McCool: created a "checked" directory where each org will create a subdirectory wcontaining ".impl" files for correction of the bad assertions
... add a column to the csv file to add a correction note for each bad assertion
... there is an example created in the checked directory
... tomorrow we can go over the list and assign people to add missing features to their TDs
... 20 minutes tomorrow to discuss additional security and validation issues
... everyone please go through your results and create the checked file entries within the next week

Kaz: we can prioritize the failure cases

Ege: we still need to cover false failures, unimplemented features, and manual assertions
... make a results-checked directory to copy results into
... look at the files and correct not implemented errors

Lagally: to do a good job this needs to be a very thorough line by line assertion check of all the files

McCool: will send out an email with instructions
... will try to schedule a mini-workshop for this tomorrow
... just go through the results and look for the incorrect assertions
... adjourned

[End of minutes]

1 February 2019 - F2F Day 2


Matsukura, Fujiyoshi, Sato, Matsuda, Toumura, Koster, Kawaguchi, Yamada, Taki, Nakamura, Sebastian, Mizushima, Lagally, Ege, McCool, Kaz, Zoltan_Kis, jeff, Kathy, Dan
Kajimoto, Dave

<kaz> remote+ Matthias_Kovatsch, Daniel_Peintner

TestFest results

<inserted> scribenick: kaz

Lagally: summarizes the results

TestFest summary by Lagally

TestFest summary by Lagally

People's interested industry areas

People's interested industry areas

Lagally: we should get prepared for the demo during the upcoming workshop based on the results

McCool: two main messages to convey: input for use cases and proof of interoperability

Lagally: stories: home, industrial, ...

McCool: matrix of application scenarios

Lagally: checks people's interest on home scenario and industrial scenario
... using the matrix on the whiteboard

McCool: need to think about more attractive demo scenarios

Lagally: adds smart cities, buildings

McCool: remote things are nice but would be even more attractive to bring actual devices to the venue

Lagally: let's continue to think about it
... what about agriculture?

matsu: part of industry

Sebastian: this is a wish list and I think we should think about something realistic as well
... also we should think about people to invite

Kaz: would suggest we put a note about "who to invite to the workshop" and "which topics to be handled during the workshop" at the bottom of the whiteboard
... rather than starting discussion about that now

McCool: +1

Lagally: puts a note
... and continues to check people's interest in possible future scenarios on smart cities and buildings
... Intel
... Oracle
... Fujitsu
... Siemens
... Panasonic: maybe difficult at the moment
... Hitachi: would also concentrate on industrial scenario

McCool: 2 issues: orchestration for multiple vendors, and concrete products

Koster: orchestration for conference room, etc.?

McCool: interested in Huawei's opinion as well

Lagally: asks Matthias about his opinion

Matthias: can't tell the detail at the moment
... but some work on oneM2M inter-connection

Kaz: thinks it might be easier for people here to express their interested technology points like orchestration and bridging in addition to those 4 categories (home, industrial, smart cities, buildings)

zk: some collaborative work on smart building with a university

Lagally: asks people about their interest in bridging with other SDOs

Sebastian: we should think about not only quantity but also quality
... also want to think about automotive industry as well
... mentions possible stakeholders to be involved
... BMW, VW, Mozilla, Everythng
... also would like to invite Automotive WG guys

Lagally: adds notes on those points to the whiteboard
... and continues to check people's interest in bridging
... and then wrap up the discussion

TestFest/Demo lessons learned

Ege: Testing Procedure
... [Current Testing Procedure]
... 1. implementation owner pushes TDs to "inputs" directory
... [Very Soon Future]
... need to see what is NOT implemented
... reverse direction: implementation report => results => imputs
... need correction
... got feedback from Panasonic
... [Testing Procedure]
... need feedback since this procedure will be applied remotely from later on

McCool: any feedback about the procedure itself?

Koster: tool itself seems easy to use
... we don't need to think about that
... but the tool is still buggy...

McCool: we don't have dynamic interface check yet
... just static syntax check now
... [My Feedback]
... the testing tools are automated but not in the lop of everyone's development cycle
... no one provided the manual assertions, so 20+ assertions are not marked even as "not implemented"
... github is not well suited for this fast paced changes when submitting TDs, results and report during the TestFest
... since someone needs to merge and pull the changes
... GitHub itself is version control system rather than data store
... there are many versions there too

Kaz: thinks we can simply use vendor-specific repositories to manage the data with appropriate permission

(or simply create an additional "wot-testfest-results" kind of repo and give write permission to all the TestFest participants)

Ege: TestFest results

McCool: shows the latest results
... the pink areas here shows features at risk

latest report

McCool: goes through the "Results" column
... pink means less implementation than 2
... yellow means 0

Ege: [Feedback from implementation owners]
... feedback from SmartThings and Panasonic

feedback from implementors

McCool: tool is useful but we need to check the results manually

Ege: [Non tested assertions]
... Some assertions (27) CANNOT be tested automatically. Thus, we

need manual input from implementation owners.

template for check

Ege: [Non tested assertions (Examples)]
... Td-serializiation-default-values: For JSON-based Thing Description
... serialization, if values are not given for certain mandatory fields, default values
... MUST be assumed.
... Td-form-protocolbindings: Syntax
... If required, forms MAY be supplemented
... with protocol-specific vocabulary terms identified with a prefix.
... And more related to behavior
... [Parent and Child Assertions - Discussion]
... how to handle a parent implementation if a child assertion about a non mandatory term is not implemented?
... Example:
... Td-action-names: Each optional vocabulary term as defined in the class Action and its superclass
... InteractionPattern MUST be serialized as a JSON name within an Action object.

Lagally: would like to check the purpose of testing effort again

Kaz: points out that there are 2 separate issues here
... check assertions to display implementation experience
... and tooling for that purpose
... but we don't have to generate a smart automatic tool if there is difficulty with that
... we can simply check the assertions manually if needed

McCool: the problem with manual assertion check is that TD spec is still changing and we need to check the assertions frequently

Kaz: in that case, we should fix the spec right away given the timeline

Ege: [At Risk Assertions]

features at risk

Ege: the above list still includes "not tested" ones

McCool: would like to walk through the report

Kaz: repeats his point@@@

McCool: so let's go back to the report.html and see the actual status
... starts with "client-data-schema"
... basically what we need is...
... top 3 are client behavior
... bottom 3 are server behavior
... we need 2 more server implementations and 1 more client implementation based on the results
... I can do the server part
... Koster, what about you?

Koster: can also do it

McCool: asks people about the assignment for manual check based on their implementation status
... regarding "td-action-arrays forms" and the following 2 assertions, maybe we can remove them given they're not implemented and we can have them at the top level
... continue to see volunteer checkers

@@@ McCool's check list tbd

[break till 12:15]

WoT Architecture - revisited

Lagally: give summary from the discussion yesterday
... and shows the updated draft (using Staticaly)

<mlagally> https://cdn.staticaly.com/gh/w3c/wot-architecture/restructure/index.html#introduction

Lagally: Abstract here

McCool: structure to be straighten out

Sebastian: security missing as a building block?

McCool: maybe as "cross-cutting security" rather than one of the building block?

Sebastian: will create an issue for wot-architecture for further discussion

<scribe> ACTION: sebastian to create an issue on how to handle security (building block or not) within the architecture spec

<trackbot> 'sebastian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sha, skbisch).

Matthias: we shouldn't discuss the details now
... there are many topics here

McCool: right
... some of them are related to each other

Lagally: Introduction

Matthias: did a review for the updated draft

Lagally: first we need to agree on the structure
... that's my plan

Matthias: ok, just wanted to make it sure

Lagally: toc here
... 3. Use Cases
... including Application domains and scenarios
... based on Oracle's input
... then two requirements sections
... functional requirements and technical requirments
... then WoT Servient architecture by Matsukura-san
... how to rework it?
... and then
... Deployment scenarios by Matsukura-san

McCool: having two similar sections is strange
... for Security and Privacy
... would like to merge 10 and 11

Lagally: ok. let's remove section 10 then
... we should now look into the use case section
... 3. Use Cases


scribe: there are too many sub titles

McCool: please scroll them a bit?

Lagally: do so

McCool: may be "Oil and Gas" as "energy"?
... energy as the top level which includes oil and gas?

Lagally: goes through the list
... connected car, agriculture, healthcare, smart cities, ...
... and then high-level topic like Environment Monitoring

Koster: maybe one big table to list the top topics?

Lagally: ok
... 3.2 Use Case Patterns


Lagally: no changes here

Koster: what does the gray fringe line mean?

McCool: fig. 2 has two gray boxes
... maybe security boundary?


McCool: let's kill the house from the figures

<scribe> ACTION: lagally to remove gray box of home

<trackbot> Created ACTION-158 - Remove gray box of home [on Michael Lagally - due 2019-02-08].

Lagally: how to handle security boundary like fig. 3?


Ege: here the gray box means different kind of network?

Koster: conceptual diagram or network details?

Matthias: these figures are for use case description

McCool: reasonable to say this is for use cases
... text here says the gateway manages electronic appliances inside house.

Lagally: Cloud-ready Devices
... how to explain Cloud Proxies, etc?

McCool: would move the section and describe different kind of proxies
... logically gateway settings should be sub sections of proxy

Lagally: Legacy Devices
... we need something here
... then Smart Factory
... should mention BACnet, etc.?

McCool: should mention more than one protocols
... diagram is fine
... but should use different color to describe different standards
... if include OPC-UA, should say oneM2M OPC-UA

Lagally: this is more or less bridging setting

Matthias: we should show different standards

McCool: would suggest we use different color to identify them
... industrial circumstances

Matthias: common use cases with different technologies

McCool: could put very similar pictures including different technologies
... monitoring smart building and others

Lagally: would be great to have some concrete figures and text

Sebastian: can volunteer

<scribe> ACTION: sebastian to generate updated figures and text for smart factory

<trackbot> 'sebastian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sha, skbisch).

McCool: managing many devices using common infrastructure
... that's the pattern applied to smart factory here
... let's call the common mechanism "institution management"
... which doesn't apply to smart home

Lagally: ok
... next Connected Car

McCool: car is just an example of interaction by multiple subsystems

Ege: robot is another example

McCool: users don't see the internal complexity

Lagally: maybe "Mobile Embedded System" as the main category?

McCool: fine

Lagally: then Cross-domain Collaboration

McCool: point-to-point interaction and cloud-based interaction

Koster: are those par of "Use Case Patterns"?
... they're rather use cases themselves

McCool: remote access is one use case
... and collaboration is another
... and interaction

tou: fine with moving cross-domain collaboration to Use Case Pattern

McCool: additional use cases on mobile users

<scribe> ACTION: mccool to generate additional use cases on mobile users

<trackbot> Created ACTION-159 - Generate additional use cases on mobile users [on Michael McCool - due 2019-02-08].

Lagally: goes to Requirements
... Common Princeples
... flexibility and compatibility
... and then unchanged sections
... Functional Requirements
... make sense to split "Functional Requirements" and "Technical Requirements"

Matthias: not sure about "Technical Requirements"
... maybe non-functional requirements?

Lagally: let's go to WoT Building Blocks
... no change here

McCool: maybe we can add "cross cutting building block"?
... e.g., for security?
... maybe should mention security briefly at the beginning of section 5

Lagally: could you generate concrete text?

McCool: will do

<scribe> ACTION: mccool to generate text on security at the beginning of section 5 building blocks

<trackbot> Created ACTION-160 - Generate text on security at the beginning of section 5 building blocks [on Michael McCool - due 2019-02-08].

Matthias: maybe you could do high-level review?

Lagally: ok
... we're reviewing this within 15 more mins
... 6. WoT Servient architecture
... please review this section in detail
... within section 9, there are several missing text marked as "t.b.d."
... would like to look into Matthias' PR as well

<mkovatsc> mkovatsc.github.io/wot-architecture/

Matthias: have a link for the rendered version
... basically fixing issues which we've already discussed
... did some renaming as well
... focus on OCF and more than just smart home
... also renamed common patterns
... what the use cases are here
... different locations from different networks
... put summary here (3.3)


Matthias: diagram from Matsukura-san's slides
... so far, so good?

Lagally: think so
... any other comments?

McCool: this is a better starting point

Matthias: thenrequirements

Lagally: would suggest we all review the proposals

Matthias: content-wise, there is no difference
... now we should review the content and get comments
... 5.2 Architectural Constraints
... started overview about the architecture first
... and detailed description by each subsection
... uniform interface, interaction model, ...

Lagally: you're planning to provide some text?

Matthias: yes
... also normative assertions as well

Lagally: great
... how to handle digital twin within figure 11?
... maybe not using this fig. 11 itself, though
... can do that

<scribe> ACTION: lagally to generate some text on digital twin idea around 5.1 overview

<trackbot> Created ACTION-161 - Generate some text on digital twin idea around 5.1 overview [on Michael Lagally - due 2019-02-08].

Matthias: fundamental things like how the TD was designed
... can be referenced by the TD document
... much overlap about 5.3 Building Blocks
... 5.3.3 is important to explain what the binding means

Lagally: wondering if "5.3.1 Web Thing" is one of the building blocks
... maybe belong to interaction model?
... we don't have "Web Thing"

Matthias: let's put it up there
... would help from somebody from semantic web
... under "5.4 Servient Implementation"
... servient architecture
... effects one of the building blocks, Scripting API

Lagally: we currently have two sections for Scripting API
... 5.3.4 vs
... Scripting is optional but still one of the building blocks

Matthias: question about "6. WoT Servient Implementation"
... text here to be moved to deployment?

Matsukura: servient architecture
... this section is very familiar with the requirements
... describes conceptual architecture

Lagally: how to rename it as "servient inter-working"?

Matthias: or could be simply the existing "WoT Deployment"?
... make sense to describe different roles of servients there

Lagally: would it make sense to use Matsukura-san's diagram instead of fig. 14?


Matthias: which figure by Matsukura-san?

Matsukura: Futjitsu don't use Scripting API but use another kind of scripting mechanism

Lagally: can we use fig. 19 instead of fig. 14?

Matthias: can't make decision yet


Matthias: question about section 6
... high-level architecutre, servient architecture to be moved to deployment
... refinement with servient internal design (fig 19) to be moved to section 5


Matthias: and SNIPPETS: (was WoT Deployment Scenarios and Guidelines)
... if there is something useful take it
... otherwise should remove this section
... because there is overlap with Matsukura-san's content
... how to deal with editors list?
... Kajimoto-san is not active any more, and Toru-san to be added?

Taki: will check with Kajimoto-san
... myself to be added, though

Matthias: will generate another PR and you can merge it

Lagally: ok

Nakamura-san's presentation on security

McCool: to be added under "Marketing and Outreach"

[lunch till 2pm]

<jeff> Hi, everyone.

<jeff> What are the coordinates?

2nd WoT Workshop

draft cfp (member-only)

second WoT workshop

<inserted> scribenick: mjkoster

Kaz: Introduces workshop web page
... questions?

jeff: in the context of 4 years work on WoT, the level of application/semantic interoperability general IoT space has improved but not as large an impact as expected

<kaz> wot architecture draft

jeff: we haven't gotten to the level of implementation
... would like to find the areas of greatest impact going forward
... Interoperability is still a huge challenge
... concerns that the workshop will play a sufficient role to result in a giant step toward consensus
... will the workshop as now planned be effective?
... the range of topics is very broad
... What do others think?

McCool: agreed, it is a matter of prioritization
... what is our next step of activities?

Kaz: agree, we can regenerate the topics

McCool: also we can look at the goals and identify gaps
... the contributions need to focus on achieving the goals

Lagally: we also need to drive toward adoption

kathy: we have a bridging system that works to put a smarthome system together
... produce a web thing that is not tied to cloud services or smarthomes

McCool: there are things in this implementation that could be standardized
... we may want to standardize runtime plugins

kathy: where we need to agree is on the schema
... the gap is the schema, how to describe the device and the API
... basically where are we with iot.schema.org?

McCool: one data model is working on a common information model

<Zakim> jeff, you wanted to comment on the range of use cases

Lagally: what should we take out and leave in?

jeff: for each of 35 sub-bullets there are 10 application domains
... an eexample of narrowness is the Mozilla smarthome implementation
... maybe we need to move toward 1/2 dozen narrow examples like the Mozilla system
... look at those and identify areas for standardization
... the current call looks so broad that we may not get consistent examples
... The Mozilla system is a good example of the narrow input that would result in cohesion

Kathy: the mission statement is great about countering fragmentation with a web based abstraction layer

McCool: we could reduce the number of topics and the application areas
... but maybe we shouldn't jump to smarthome

Kathy: the range of use cases is a good thing

McCool: can we get feedback on which topics are priority?

Ege: worry that the whole topic list will be considered to be Web of Things

Lagally: what is the actual problem we are solving?

jeff: too many topics, too little focus
... focus on future standardization opportunities that are associated with each contribution

Lagally: how do we align with the submission deadline?

jeff: the leadership team can take a convex hull of all the ideas
... for example, under the "Information models" and "use cases" bullets, there may be enough material to go on
... especially if there are not a lot of coherent submissions in other areas

Lagally: the committee can take up this process of prioritizing

jeff: that's a great idea, then you can go back to the introduction and tighten up the verbiage around determining the next generation of WoT work

Sebastian: how do we get a final OK that the workshop is taking place?

jeff: personally don't have approval rights, but can drive consensus at the W3M

Lagally: so we will get feedback from everyone here, narrow down the scope and range of topics, and present an update at the next Wednesday call

Kaz: we can have an updated draft by the end of Tuesday

Lagally: so we need all feedback by noon Tuesday CET
... is that enough time for people to provide feedback?

<zolkis> it should be enough

Kaz: continue this discussion online with the assumption that we will ask for feedback by Tuesday

<kaz-win> dan: "This workshop solicits papers touching on many varied areas that relate to the Web of Things initiative, but will prioritise submissions that focus clearly on the role, nature, maturity and integration of various standardization efforts."

jeff: anything else at this point?

everyone: Thanks, Jeff

McCool: we should narrow it down to five topics

interoperability testing

McCool: interop testing is not a priority for this testfest
... there are tools to process the interoperability and people can put the results in the same place with a slightly different csv file
... wot-thing-description/testing directory
... record the outcome of testing producer-consumer pairs
... for failures, provide detail
... P-C pairs can be listed more than once if there are different tests
... the tool collates all the results together and builds a matrix
... points off for no security
... the names in the table are defined in the impl.csv file
... and are also used in the implementation description

<kaz-win> https://github.com/mmccool/wot-thing-description/blob/updated-test-results/testing/inputs/impl.csv

<kaz-win> https://github.com/mmccool/wot-thing-description/blob/updated-test-results/testing/inputs/interop/interop-hitachi.csv

McCool: create PRs against the main repository
... will add dates later
... spend 1/2 hour to get organized

marketing and outreach

McCool: how do we get people to adopt and deploy ?
... and make it easy to use
... how do we track adoption?
... what targets can we focus on to drive adoption while maintaining balance and breadth

Lagally: the W3C landing page is very old

McCool: there is a draft of a new page but we haven't pushed it out yet

<kaz> https://www.w3.org/WoT/

McCool: landing page should point to the workshop
... we can start over with a simple landing page and maintain it
... can we meet with the W3C team about this?

Kaz: will make the contact with W3C team

McCool: also we will want to promote reference implementations like node-wot
... there are some simple implementations that people can also use

<kaz> ACTION: kaz to talk with the W3C Comm Team about the WoT landing page

<trackbot> Created ACTION-162 - Talk with the w3c comm team about the wot landing page [on Kazuyuki Ashimura - due 2019-02-08].

McCool: each company may have things they want to promote around WoT
... we don't have branding or logo
... W3C does have badges like the HTML5 shield and graph logo
... there should be some well known indication of compliance
... W3C published test results and a compatibility matrix on browsers
... there might be a similar thing for WoT
... self-certification or do we run the tests?
... we could make a compatibility list of features e.g. security schemes

Kaz: we could start by publishing notes with the plugfest results

McCool: we could put the matrix up front, linked from the landing page
... look at the current HTML material

<kaz> (sounds like something like "Can I use WoT?" site. fyi: https://caniuse.com/)

Sebastian: who is going to be responsible, who is the point of contact for this work?

McCool: we can do some basic items with shared responsibility
... we should get 1 or 2 volunteers

<kaz> (fyi, accessibility initiative has a WG on education and outreach: https://www.w3.org/WAI/about/groups/eowg/)

McCool: for the education task
... let's use the intro paragraph from the CFP about countering fragmentation as the intro to the interim landing page
... what about tutorials, who is interested in working on a tutorial

Ege: can I write it on medium?

McCool: we should get a couple of people together to discuss and bring a proposal back
... both examples of node-wot and ad-hoc implementations
... with security etc.
... proposing a task force to deliver tutorials

<kaz> https://www.w3.org/WoT/WG/

McCool: core tutorials on W3C site

<kaz> https://github.com/w3c/wotwg

<kaz> (we can put the actual content on GitHub and add forwarding configuration to the www.w3.org server)


Nakamura: will present security metadata examples
... worry that people will have difficulty understanding the 2 proxy configuration
... three patterns, direct servient-servient, one proxy, and two proxy
... proxies that use WoT exposed and consumed thing for communication

McCool: how does it work with firewalls, where are credentials needed

Nakamura: it is hard for the application to manage all of the credentials
... in the 2 proxy pattern

McCool: no way to carry header information across proxies
... but the inter-proxy API may not be public
... how does the application tunnel through the near proxy to authenticate to the far proxy
... also may be an issue of URI rewriting

Nakamura: the proxies can each authenticate locally to the next proxy
... pattern 3-2

McCool: could the reverse proxy be a forward security proxy
... and hide the proxy from the TD?
... also there is a pattern with multiple forms that have different entry points on different proxies with different security mechanisms
... the reverse proxy could delete the forms with local URIs
... with multiple forms there could be a way to help the client choose the best form
... there could be ordering rules, internal metadata, or external metadata
... only one base URL witih full URLs for the alternate entry points
... we need to work through how to secure local access i.e. LAN without CA based PKI
... and how to organize the selection

Nakamura: should show how to structure the security metadata for the configurations in the architecture document

Kaz: this may belong in the security document

McCool: the security best practices document is a good place
... next steps, we can take this up in the security meeting
... start with a list of configurations we care about
... it may be too late to add to the TD document

<kaz> f2f agenda

McCool: to summarize, we need to update the landing page by next week, and start an education task group

schedule for tomorrow

McCool: discuss TD and test assertions
... we have a 6 month extension so don't need urgent recharter resolution
... IG charter is a long list of topics

Kaz: there is approval for the IG extension but we need to make an announcement about this
... the workshop is barely ahead of the recharter deadline in June
... discuss tomorrow
... what else do we have to talk about

Lagally: event discussion
... TD events

McCool: respond to the event issue and discuss in the TD session tomorrow
... missing a payload definition for subscription response that may contain unsubscribe/cancellation information
... what if the response contains a URL?
... can we use the pattern of a returned TD fragment?

Kaz: we could discuss recharter now


McCool: what is the expected date for the IG charter?
... target end of March

<kaz> draft IG Charter

McCool: need to have an election for new chairs in March

<kaz> Ben's comment to issue 599

McCool: simple API, browser API, or other?
... have a general topic about application API standardization in the IG

discussion on the hypermedia driven API topic

discussion on profiles for applications and protocols

change to "additional Use cases and Requirements"

<kaz> kaz: also we need to convert "specification"s to "document"s

<taki> Scribe: TK

<taki> ScribeNick: taki

TD Issues

Sebastian: Camel Case for op values
... issue #179
... Proposal - use readProposal, writeProposal, observeProperty

McCool: for consistency

Koster: also consistency with IETF specs

McCool: also subprotocol, longpoll, webhooks, etc.

Koster: if we do not care about IETF rules...

<kaz> issue 179

Koster: Weblinking spec says terms rels should be lower-case.
... also good for round-tripping

Sebastian: this is nice to have.
... everyone ok as it is now?
... Let's keep as it is.

Ege is recording the decision in GitHub...

Koster is closing the issue...

Sebastian: meaning of op values

McCool: we need behaviour section.
... it does not say anything about behaviour.

Sebastian: Include JSON Schema "anyOf", "allOf" and "not"
... issue #298

<kaz> issue 298

McCool: no use case so far. it may help developers.

Sebastian: Full JSON Schema support
... we currently support a subset of JSON Shema
... we can have a note that semantic processing for such terms are not possible.

McCool: "oneOf" has an use case.

Sebastian: URI datatype? Introduce "format" term?
... #226

<kaz> issue 226

Sebastian: JSON Schema "format" term.

Koster: It is used for URI pattern, there are also other use cases.

McCool: there can be multiple context
... please keep this in mind.

Ege: does anyone support this?

McCool: this is mainly for validation.

Lagally is enumerating various formats...

Sebastian: format is about hint of the pattern of strings.

McCool: we need two volunteers immediately at this point.

Sebastian: JSON Schema "format" helps identify URI as URI.

Koster: example? href?

McCool: subscription's dataschema too

Sebastian is writing an example

Sebastian: "format": "uri-reference"

McCool: who volunteers implementing?

McCool assigned people to implement this feature...

<scribe> scribenick: taki1

McCool: I hope we can find a good reference we can point to.

Sebastian: Link also has a set of specifications.

McCool: it does not change validator.

Sebastian: right

Koster: namespace can help avoid name conflict

McCool agrees

Ege: property is readonly, but op=writeproperty. we have this kind of cases.

McCool: readonly/writeonly definitions are not present in TD spec.

Ege: are there dependency?

McCool: it just does not have effect.
... it is ok though it should be disallowed
... putting it into spec is very complicated

Koster: op is optional. when there are multiple, it is mandatory.
... default can depend on readonly/writeonly.
... it should be covered by default.
... we already have default for op

McCool: but not context dependent
... Canonicalizer can do that.
... we may want to stay with the current way.
... we should also check definition in JSON schema.
... it may allow to write those combinations.
... we need more precise definition
... current definition is self-referencing
... definition in JSON schema seems clearer

Ege: I discovered that href can be ""
... empty string

Koster: it is ok. perfectly fine.

Ege: we are aware of it right?

Koster: URI reference allows for that

Ege: I suggest to link vocabulary with examples.

McCool: forward link?

Ege: yes

Sebastian: we have to do it at the end.
... good idea.

McCool: extra column pointing to example?

Sebastian: maybe too much.

Ege: I created many new issues as the result of testfest.

Lagally: observable property.
... how to cancel?

Sebastian: unsubscribe to the same topic.

Lagally: this is not event

Koster: some protocol requires unsubscription
... what if application wants to unsubscribe?

Sebastian: we have "obserbeproperty"

Sebastian: why not have "unobserveproperty"?

McCool: naming should be consistent.
... unobserve is fine

Ege: vote?

McCool: "unobserve"

Koster: how about cancel action?
... I can provide an example.

McCool: do we need websub?

Koster: we need to take a closer look first.
... how about SSE?

McCool: eventsource, SSE, websub

Koster: we need to take a look at Fujitsu and Mozilla implentation for WebSocket.

McCool: webhooks has one implementation.

Koster: RESThook is an implementation name

Ege is adding a new issue for adding webhooks and event source...

Kawaguchi: Webhooks, we saw siemens example TD yesterday.
... is it possible to use it for observing properties?

Koster: it is more complicated.
... we want to keep property as simple as simple

Kawaguchi: it should be clearly described.

McCool: longpoll and event source. This is simpler.
... webhooks?

Koster: In CoAP, I can use webhook.

McCool: subprotocol is mostly for HTTP
... should we add those two?
... we can clearly describe WebHooks is not for property.
... for tomorrow, I am going to make a several PRs.

Sebastian: same room logistics procedure tomorrow as well.
... Until 12:00. No lunch. Coffee to be provided.
... We can still discuss TD tomorrow, but won't be that long.

McCool: dinner plan?

Kaz: Chinese restaurant next to Mexican restaurant yesterday.
... 7:30 @ Lobby

[End of minutes]

2 February 2019 - F2F Day 3


Sebastian, Matsuda, Toumura, Koster, Kawaguchi, Yamada, Taki, Nakamura, Mizushima, Lagally, Ege, McCool, Kaz, Zoltan_Kis
Kajimoto, Dave

Next F2F

McCool: next meeting collocated the upcoming workshop?
... maybe after the workshop?

Sebastian: would make sense

McCool: can you look into the possibility of Sat/Sun?

(workshop expected on 27-29 May)

TD timeline

Sebastian: need to ask TAG for review

McCool: let's get things cleaned up

Marketing, etc.

McCool: need to talk with W3C management
... e.g., possibility of publicly available WoT test site

Matsuda: certification of WoT?

McCool: validation of people's resources

Kaz: we need to clarify our expectation/requirements for that before talking with the W3C Management

McCool: hoping lighter mechanism to validate resources as a starting point rather than certification
... would think about some kind of branding as well, but that is another story
... validation about TD and device behavior

Sebastian: good topic for the IG side?

McCool: can take an action to put the ideas together

Smart Cities BG

McCool: kind of discussing possible collaboration with other smart city orgs


McCool: should invite people from the other SDOs, e.g., IIC, to our meeting, e.g., the workshop
... anybody going to IIC next week?

(McCool, Taki, Matsuda-san)

Sebastian: end of March, there will be an IETF meeting

McCool: Koster?

Koster: will be there
... discussion with WISHI guys

McCool: can go
... when will we have vocabulary extension?
... should discuss how to do that
... currently have difficulty with validation
... if I come, would like to talk about that

Sebastian: can you share the information about the meeting?

McCool: WISHI links
... will try to attend the online meeting
... talk about extension schema
... how to validate them

Koster: currently protocol binding service doesn't check the data

McCool: our first priority is getting REC but we should discuss validation as well

Workshop - revisited

McCool: btw, regarding the upcoming WoT workshop, who from us are planning to submit position papers?
... I myself will

Sebastian: W3C workshop is not an academic conference

<mjkoster> here is a link ti the T2TRG WISHI wiki pages

<mjkoster> https://github.com/t2trg/wishi

Sebastian: position paper could be just a one pager

Kaz: clarification on workshop expectation@@

McCool: maybe one pager is not enough

Kaz: the purpose of w3c workshops is getting new ideas and participants from the industry

Liaison - revisited

McCool: would work with IIC
... and ITU
... nice to bring them to the table
... and One Data Model
... when is the next OCF meeting?

Koster: OCF is sponsoring the One Data Model

One Data Model

@@@ slides tbd

Koster: [What is the OneDM Group? Who is involved?]
... a liaison group including mostly SDO members
... OCF, Zigbee, Thread, OMA
... data model interoperability is one of the topics
... what they decided to invite non-liaison people as well, e.g., W3C
... also include Bluetooth
... proposal for a subgroup to handle private information
... we have Google, Amazon, Comcast, Honeywell, Legrand, Philips Signify
... hosted on the OCF Enterprise Workspace (Kavi)

Lagally: any resources?

Koster: some presentations available
... high-level interoperability stack, etc.

Lagally: can access them?

Koster: probably you need to contact somebody from them
... we can join them as one of their members as well
... [What is the goal?]
... very similar to our goal
... define a common data model for high level interoperability between IoT devices and services
... interesting question about data model how tightly coupled with serialization
... [What is the process?]
... reviewing existing models in progress
... iot.schema.org/WoT, Google/Nest, OCF, Zigbee, OMA LWM2M, etc.
... some people are thinking about higher model
... focus on abstract model
... decoupled from serialization
... common meta model

Lagally: what about interaction?

Koster: we need some kind of commands
... event, action, property affordances are common features of most models

McCool: curious about IoT stakeholders involvement
... what about browser companies?
... other than Google

Kaz: do we want to establish a liaison with them?

Koster: if we want, maybe we can establish a liaison but their work include NDA portion

Lagally: possibly we can think about a liaison without NDA part

Koster: that's what I'm suggesting to IETF too

Kaz: if we want to establish a liaison with them from our side, I think I should talk with the W3C Management as well beforehand

<scribe> ACTION: kaz to talk with W3M about possible liaison with the One Data Model group after McCool/Koster/Lagally's outreaching them

<trackbot> Created ACTION-163 - Talk with w3m about possible liaison with the open data model group [on Kazuyuki Ashimura - due 2019-02-09].

Koster: having some presentation about our work on WoT to them would be interesting
... also would like to look into Zigbee, etc.

McCool: data model for Zigbee
... you (Koster) and should coordinate

Kaz: btw, we should invite these guys as well to our workshop. right?

Koster: right

McCool: remember that Oracle has data model translator

Matsuda: the scope of the one data model is specifying some concrete data model?
... or just thinking about metadata?

Koster: think both
... common data model is something like our TD
... at a high level
... that is definition of interaction model
... and different schemas to specify the value
... decided to work on high-level data model

(some more discussions)

McCool: what to do for the next step?
... 3 of us (Intel, Oracle, SmartThings) to look into their work?

Lagally: we should see what they're doing

McCool: want to present OCF work and WoT work to them too

Koster: put all the WoT work including Oracle, etc., into that WoT presentation?

Lagally: let's put our ideas together first

Koster: can contact them and ask about if we can get their information

McCool: our internal meeting next week?
... we'll have a Wed meeting (main call) and a Fri meeting (TD)
... and decision in 2 weeks
... any area for presentation?

Kaz: under the wot repo

Next week calls?

Kaz: btw, won't we have f2f recovery rest next week?

McCool: no
... we'll have calls next week

Kaz: so no call on Monday but all the expected calls on Wednesday?

McCool: right
... all the calls wed and fri will happen

Workshop sponsor?

Sebastian: wondering about the possible sponsors for the workshop

Kaz: we can think about sponsorship after getting approval for the workshop :)

[break till 10:35]

TD test update

McCool: regenerated the implementation report
... including the updates from Panasonic, Oracle
... still working on bug fix for the assertion tester tool
... looking through the results
... still have uncovered features
... by Wed, will create new directory for the data

TD spec - transformation to JSON-LD

Sebastian: regarding the spec, Victor is working on the section about transformation to JSON-LD
... possibly several additional assertions
... goes through the PR version TD
... about transformation to JSON-LD
... list of container, type, context
... have not reviewed this update completely yet
... would like to discuss this during the TD call on Friday

McCool: all this content informative?

Sebastian: we should discuss that

McCool: think this proposal is clear
... but may effect the assertions

Koster: I do use semantic information within my TDs

Lagally: wondering about the text from this proposal
... does this pushing RDF?

Kaz: would be better to send this to the group and ask the group to take a look before the review during the TD call on Friday

Sebastian: ok
... and let's discuss how to deal with this during the TD call

Lagally: what is the status of JSON Schema?
... already tight enough?
... need further iteration?
... there is an Editor's note
... "This schema is known to be too permissive."

McCool: we need to clarify how to do what is needed.
... we should tell people how they can make the schema restrictive

Kaz: who is expected to explain that?

McCool: Ege to generate a PR for that?

<scribe> ACTION: ege to create a PR on how to make the schema restrictive

<trackbot> Created ACTION-164 - Create a pr on how to make the schema restrictive [on Ege Korkan - due 2019-02-09].

McCool: this point raised an issue about checking all the remaining Editor's notes within the spec draft

Sebastian: searches for "Editor's Note"s
... (noticed fig. 2 is missing)

updated TD draft@@

TD publication schedule

Kaz: we should think about the updated timeline

McCool: we should aim the end March as the deadline
... also we need to get TAG review
... what about mid March?

Kaz: we need to list "features at risk" within the status section

McCool: can add some additional ID to identify features at risk

Kaz: note that we need to generate "explainer" for TAG review

McCool: any template?

Kaz: there are many examples on GitHub

McCool: will make updates for report.html by the TD call on Friday

Where to put presentations for the f2f meeting?

Kaz: would suggest we create a specific directory on GitHub so that we can search for them easily

<scribe> ACTION: kaz to create an area to store presentations from f2f meetings

<trackbot> Created ACTION-165 - Create an area to store presentations from f2f meetings [on Kazuyuki Ashimura - due 2019-02-09].


Taki: points out an issue

<taki> TK: Appendix B Thing Templates

issue 279

Sebastian: related to issue 279

<taki> TK: There is a paragraph that says it is Thing Description where some optional parts are not present... But example B.1.3 is a composite template.

<taki> TK: which appears to be different from what the description says.

Sebastian: put a proposal on the issue
... already working on that



Since a Thing Template is a subset of the Thing Description in which some optional and mandatory vocabulary terms does not exist, however, it can be serialized in the same way and in the same formats as a Thing Description. Note that Thing Template instances cannot be validated in the same way as Thing Description instances due to missing mandatory terms.


all: ok with that proposal

[f2f meeting adjourned]

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/02/11 13:08:47 $