W3C

WoT Open Day - Day 1

11 October 2021

Attendees

Present
Ai_Mizokawa, Christian_Glomb, Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Fady_Salama, Hiroki_Endo, Hiroshi_Fujisawa, Hiroshi_Ota, Junde_Yhi, Kaz_Ashimura, Kunihiko_Toumura, Marcus_Schmidt, Michael_Koster, Michael_Lagally, Michael_McCool, Mikkel_Brynildsen, Philipp_Blum, Ryuichi_Matsukura, Sebastian_Kaebisch, Takashi_Kasuya, Tetsushi_Matsuda, Tomoaki_Mizushima, Tomoya_Asai, Van_Cu_Pham, Walter_Bae, Youngmin_Ji
Regrets
-
Chair
McCool/Sebastian
Scribe
kaz, sebastian

Meeting minutes

Agenda

McCool: Today is a WoT Open Day
… Thursday as well
… Welcome
… Takenaka's presentation
… break
… plugfest report
… and wrapup

Scribe

McCool: Kaz and Sebastian

Patent Policy

McCool: this is a WoT WG/IG joint meeting
… and for the invited guests, Open Day is organized by the IG
… please be aware of the W3C Patent Policy

W3C Patent Policy 2017

McCool: please upload your presentation slides to the GitHub
… if not possible, please let us know about the link

Guests

Ota: Hiroshi Ota from Yahoo Japan

Mikkel: Mikkel Brynildsen from Grundfos

Kasuya: Takashi Kasuya from Takenaka

Asai: Tomoya Asai from WebDINO (former Mozilla Japan)

Walter: ...

Youngmin: Youngmin Ji from KETI

Mizokawa: ...

Logistics

McCool: wiki at https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2021
… presentation slides https://github.com/w3c/wot/tree/main/PRESENTATIONS/2021-10-online-f2f

Sebastian: please make sure you all join the IRC as well

Takenaka

Slides

Kasuya: will upload my slides later
… I'm from Takenaka Corporation
… slide 1
… Smart Building
… advanced energy-saving
… slide 2
… BACS: Building Automation and Control System
… multi-vendor systems consisting of HVAC, metering, etc.
… IoT and AI
… slide 3
… Software Defined BACS
… architecture here
… GW exchanges the data with the data platform outside on the cloud
… slide 4
… BIM: Building Information Modeling
… will be necessary for building management
… lifecycle of BIM here
… slide 5
… Issues for Smart Building Data Platform
… data modeling
… support for practical use cases that consider IoT and AI
… using Lambda architecture and WoT
… reduction of running costs
… slide 6
… Proposed Method: Data Modeling Automation
… spatial hierarchies from BIM
… slide 7
… Extract Geometry / Metadata from BIM (IFC)
… IFC is intermediate format
… extract geometry from the data
… slide 8
… visual graph
… site-> building-> story, ...
… using building ontology
… slide 9
… Requirement / Design for Smart Building Platform
… concepts, requirements and technologies
… slide 10
… Architecture: futaba
… realtime processing by Lambda architecture and WoT
… slide 11
… standards comparison
… slide 12
… Data model / Endpoint using WoT
… spatial data and point data merged
… and put into the buidling metadata registration tool
… slide 13
… Big data processing
… it takes time to process big data
… so processing on the backyard using Databricks by Azure
… slide 14
… Use case (1): EQ House
… very small house for experiment purpose
… 200 points of IoT devices
… Use Case : EQ House (2)
… visual graph including building/space, device and point
… slide 16
… Use Case: EQ House (3)
… remote control system using AI to improve confort
… slide 17
… Use case (2): Takanaka Research & Development Institute
… digital twin application
… slide 18
… API definition
… sorry but written in Japanese
… WoT features for HOT category, e.g., getting TD, property, etc.
… slide 19
… WoT API (1) Auhtentication
… crate ID
… request to issue / refresh an access token
… slide 20
… WoT API (3)
… WoT API (4)
… retrieve data

McCool: thank you very much
… wonderful stuff
… great proof of spec

Sebastian: thanks!
… very interesting
… which kind of TD are you using?
… genuine 1.0 or any addition?

Kasuya: using 1.0

ask se

Philipp: great presentation
… you wrote some JS code. right?
… not node-wot but your own implementation?

Kasuya: made SDK ourselves
… WoT API is basically REST-based
… so not very complicated
… if needed, maybe we can also provide our codes

McCool: capture any requirements
… e.g., security
… geolocation
… you're using graph-based topology
… that's something we should look into
… the last thing is slide 22
… number of events there
… API definition here
… what standard for event handling to be supoorted?
… discovery as well

Kasuya: we adapt to Open ID standard
… for ID management
… refresh token in one day
… that is the basic security mechanism to avoid attacks

McCool: using bearer token?

… maybe we should dive into the detail later

Kasuya: 2nd question was geolocation. right?
… our system target is inside of a building
… so we don't really handle "geolocation"
… we can identify the location by "position"

McCool: ok. I meant "location" and "positioning"
… want to have some mechanism to combine the location information and the position information

Kasuya: right
… that's a good point

McCool: we'll have collaborative discussion with SDW and OGC later this month

Kasuya: we've extended these APIs (p22)
… have implemented them over Azure platform
… we can use this kind of event bus for subscription
… get TD, get property, write property, invoke action
… subscribe event, get subscription status of event, unsubscribe event

McCool: cancelling actions for controlling robots could be a use case

Kaz: did you have any difficulty with binding between building management standards and WoT?

Kasuya: good question
… (p11)
… we have developed a GW for that purpose
… extend functions on-demand

Kaz: your input would be very useful for our Binding Templates spec

Kasuya: btw, this proposal was actually my Ph.D Thesis
… so you can refer to the details there
… can send resource later

Kaz: tx

Lagally: question about event API again

Kasuya: web hooks?
… retrieving big data from the Azure platform
… might take long
… to create clusters, etc.

<McCool> (so "cold" here refers to historical data?)

<McCool> (and "hot" to live data?)

Kasuya: so users can register Webhook to get notification

Kasuya: we can retrieve streaming data
… that's our event subscription system

Lagally: ok
… what about the payload?

Kasuya: standard JSON
… this example on p27 is a bit extended, though

<dynamis> thesis of Kasuya-san (in Japanese) http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/2021/IPSJ-JNL6203010.pdf

Lagally: thank you very much

Sebastian: what kind of protocols are you using?

Kasuya: currently, BACnet, MQTT, Modbus

Sebastian: possible discussion about BACnet some more
… if you're interested in generating official binding for BACnet, that would be very welcome :)

Kasuya: we don't develop the BACnet SDK ourselves
… third party developer developed it and we just use it

Sebastian: ok

Kasuya: (p14)
… even the BACnet object, we can encode it based on the schema
… our use case is remote control, etc.
… handling properties
… like this example

McCool: modularity is the question here

Kaz: regarding the next steps
… I'd suggest we ask Kasuya-san to participate in the WoT-JP CG to summarize the points first
… and then they can provide input for the WoT-WG for our spec work

McCool: sounds reasonable

McCool: also, if there is any publication in English, that would be helpful

Matsukura: glad to see you again
… thought Univ. Tokyo was using IEEE standards
… why did you change to WoT?

Kasuya: different functionality
… IEEE was used for storage purposes
… our new system has realtime part
… modern systems need to implement RESTful I/F as well
… that's why

McCool: thank you very much for your presentation!
… thanks for your time as well
… really helpful
… please work with Kaz for uploading your slides, etc.

Kaz: will help him :)

[break; resume at 10mins past]

Plugfest report

McCool: list of projects here
… NHK, Testbench, Siemens, Hitachi, Intel, TUM
… ECHONET report deferred to Thursday

McCool: going through over the project reports
… checking the issues that are labeld with "PlugFest 2021.09
… who like to present first?
… ok, I will go

Intel: Geolocation

<kaz> Project (2021-09 Plugfest): Geolocation - Intel #167

<kaz> Slides

McCool: show my presentation that I have prepeared
… concentrate on GeoLocation
… idea was to find out aboubt the GeoLocation requirements
… especially about geoloc data and queries
… there are results about data encoding and some use cases with examples
… next steps would be do get consensus in the community
… there is also the need to do joint discussion and alignment with WGS84, Spatial Data on the Web, Web Geolaction API, etc.

Ege: what happen with the BRICK Ontology group?

McCool: yes, should be also in the list

Siemens: TDD

Sebastian: Thing Directory by Christian and Thing Model by me

Project (2021-09 Plugfest): Siemens / Logilab TDD #168

Slides

Christian: showing the result from Siemens / Logilab TDD
… our implementation is mainly based on exploaration phase
… surprised that new problems have appeared compared to the last PlugFest
… (showing Architecture of the TDD implementation)
… issues: 1) values sometimes not present in TD since they are optional like @type and "id"
… 2) problems when "unit" term uses special chararacters like "%"
… 3) TD with different contexts
… 4) "securityDefinition" is not restored correctly

<Christian provides some feedback about implementation experience>

Ege: in the first version we had this placeholder context file, however, in the last testfest we changed to the 1.0 context file

<Zakim> kaz, you wanted to suggest we discuss that not now but during the TD session and/or the joint discussion with the JSON-LD guys :)

Kaz: suggest we discuss that not now but during the TD session and/or the joint discussion with the JSON-LD guys :)
… also please create GH issues based on this kind of findings from the Plugfest.

Sebastian: right. we should discuss this with Manu Sporny in two weeks
… there wil be joint discussion during the DID meeting

Siemens: TM

Project (2021-09 Plugfest): TM Composition #194

Slides

Sebastian: how to generate TD instances
… examples here

examples

Sebastian: use case of a production line
… how many bottles to be generated today, etc.
… whole bottle filing line
… including bottle filling, capping and sprayhead

<sebastian> https://github.com/w3c/wot-testing/issues/194

Kaz: any findings?

(Sebastian has trouble with unmuting himself)

NHK

Slides

Endo: WoT device simulator
… outline
… how it works
… background - future media use case verification
… to very UX, we need physical devices which provide media content
… however, hard to prepare physical devices
… so prototyping based on virtual devices
… that's why "WoT Device Emulator"
… examples of virtual WoT devices
… smart display
… smart cutting board
… demo (virtual device controlled by Node-RED)
… virtual device within Android
… actions to toggle the power
… the emulator can be handled from Node-RED
… brightness as well
… next
… present Web sites
… how a virtual device works as a WoT device
… user register the TD to the Android phone which includes the Emulator
… virtual device on a Webview
… the Emulator process automatically serves the Web APIs described in the TD
… Many thanks
… Toumura-san's support
… media use cases using the Emulator will be provided
… working on legal process within NHK to make the Emulator public.

McCool: presentation upload issue to be created
… making the Emulator public would be useful

Kaz: +1

Endo: thanks!
… agree with you

McCool: thanks!

TUM

Project (2021-09 Plugfest): Testbench #189

Slides

Marcus: Marcus from TUM
… Testbench: Main Goals
… Testbench
… diagram
… TD initiates operation, parameter, input, and output
… then sent to the Testing
… then Evaluation
… established by API testing
… note we rely on more than one protocol
… Test Report
… T1: operation coverage
… T2: parameter coverage
… T3: input coverage
… T4: output coverage
… Things I have interacted with during the Plugfest
… had problem with Intel and Fujitsu
… Fujitsu used local IP address which was not provided by the VPN
… regarding Siemens
… counter, eCar, SmartCoffee, SolarPower, TestThing
… eCar was not available
… Hitachi worked
… UNIBO Farm including CoAP test cases didn't work

McCool: problem with CoAP?

Cristiano: definitely need to look into it

Marcus: no problem with ECHONET :)
… lighting, air conditioner, light sensor, temp sensor
… What's next?
… Ege will give some more points

Ege: Motivation
… many cod repositories contain badges about the build status/test coverage
… TD "Badges"
… can we have badges within TD?
… gives confidence to the Consumers that every affordance can be uses
… TD "Badges": Example
… "testResult" section is added here
… to manage testSuite, totalTests and passedTests
… as an initial thought
… WoT-Testbench

Kaz: for W3C spec generation, "testing" is to clarify the implementability
… on the other hand, this work looks testing for implementations and products. right?

Marcus: yes

Kaz: in that case, we need to clarify that point first
… and then ask all the implementers for feedback about their testing experience

McCool: we should create an issue on possible impact for discovery, etc., as well
… around directory, for example

McCool: let's start with creating an issue
… we may need to refer to external schema
… having a standard way to fetch data would be useful
… Ege, will you create an issue?

Ege: for discovery?

McCool: under your project issue first
… then discovery

Cristiano: are you able to test events?

Ege: diagram about how things were tested

<Ege> https://github.com/tum-esi/testbench/blob/master/readme-images/eventTesting.svg

Ege: event testing flow above

Cristiano: ok
… another question on TM
… any work?

Ege: future work
… but some in the playground

Kaz: regarding the idea of including testing information within TD on p14
… would suggest we split the information from TD itsef
… and attach it with TD using link, etc.
… we need further discussion, though

McCool: let's create an issue about that as well

Hitachi

Project (2021-09 Plugfest): Node-RED integration (SPARQL query) #154

Slides

Toumura: Node-RED - WoT Discovery Integration

Toumura: implemented query this time
… updated query interface
… demo video available

(demo)

Toumura: you can easily handle the properties using Node-RED
… timestamp->counter-count->msg.payload
… Issues / Discussion / Lessons Learned
… round-tripping issues
… invalid securityDefinitions (w3c/wot-thing-description#1193)
… title and description are converted to titles and descriptions
… orchestrating Things using Node-RED
… thermostat and visual alert
… ECHONET air conditioner could be turned on
… NHK smart speaker could handle the lED light
… direct access to ECHONET Lite Web API
… for this Plugfest, we could access the ECHONET devices via the GW
… that's WoT-ECHONET intermediary
… GW removes an encapsulating object

Kaz: is it really a problem to use a GW?

Toumura: yes, given ECHONET Lite Web API also follows REST API, it would be nicer to allow direct connection

Matsuda: thanks, Toumura-san
… we'd like to talk about that point on Thursday

McCool: issue of languages here
… i.e., title and description
… maybe in the future we can look at it

Toumura: this is my first time to use SPARQL

McCool: yeah

<Mikkel> Have WoT looked into SHACL validation of TDs?

McCool: problem with JSONPath not being a standard yet

A separate question on validation

Mikkel: a question for WoT in general
… have you thought about SHACL or validation?

McCool: we did think about that
… interesting thing might be warning
… might want to do some more

UNIBO: Action model

Project (2021-09 Plugfest): Hypermedia protocol proposal 3 #187

Cristiano: Problem
… how to describe complex action interaction models of the IoT world?
… Problem diagram
… single action request vs queued actions
… Proposal: Leverage on Thing Models and Action Thing Descriptions
… example codes
… Thing Description on the left side and Thing Model on the right side
… Proposal: GreenField (core profile?)
… Thing Description on the left side vs Action Thing Description on the right side
… Pros
… no id needs to be tracked
… can statically describe Action Request operations
… Green Field Device Exposed TMs
… Results
… Green field device-consumer
… didn't add any changes to the node-wot implementation
… just add changes to the application side
… (shows an example code)
… Green field device-exposer
… Existing service / device TMs
… for existing devices, it's a bit more complicated
… Exposed Thing Model vs Action Description Model
… Existing service / device consumer
… What we need to standardize?
… common action model
… concept of Action Description
… TD keywords and semantics
… operation types for queues still needed

Ege: if you standardize the model, we need to show what to implement
… how to generate the description?

Cristiano: you mean we don't need this model mapping within the Exposed Thing Model?

Ege: right
… if we don't have an ID

Kaz: in addition to the TD examples, we should have description on the use case and scenario too
… what kind of devices are handled here
… what kind of actions are queued to handle them, etc.

Cristiano: yes, didn't have time to describe that part

McCool: looks basic powerful approach

Wrap-up

McCool: will create an issue for NHK
… ideally should have links for presentations
… next event is Open Day Day 2 on Thursday, Oct 14
… Netzo will join it. Right?

Sebastian: yes

Logistics

McCool: assuming we cancel all the calls other than the main call, the PlugFest call, the Editors call and the Chairs call
… no TD call or Architecture call this week
… thanks a lot, everybody
… Takenaka's presentation was fabulous
… thanks again!

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 147 (Thu Jun 24 22:21:39 2021 UTC).