# IRTF T2TRG/W3C WoT work meeting

Workshop originally planned for Helsinki, FI, June 2020
https://github.com/t2trg/2020-06-helsinki

## Attendees:

1. Ari Keränen
2. Carsten Bormann
3. Cristiano Aguzzi
4. Michael McCool
5. Michael Lagally
6. Jennifer Lin
7. Andrea Cimmino
8. Farshid Tavakolizadeh
9. Jie Yang
10. Jim Schaad
11. Klaus Hartke
12. Kaz Ashimura
13. Kunihiko Toumura
14. Matthias Kovatsch
15. Michael Koster
16. Niklas Widell
17. Oliver Pfaff
18. Pardis Emami-Naeini
19. Peter Yee
20. Russ Housley
21. Tomoaki Mizushima
22. Colin Perkins
23. Francesca Palombini
24. Ken Ogiso
25. Zoltan Kis
26. Marie-José Montpetit
27. [e-mail]
28.

## Draft agenda:

| Time (UTC) | Subject | Who |
|------------|-----------------------------------|-------------------------------------|
| 1200Z | Welcome, Logistics | Chairs |
| 1210Z | WoT Update | |
| 1220Z | Use Case Process and Overview | Michael Lagally |
| | Lifecycle | Michael Lagally |
| | Discussion | |
| 1250Z | WoT Discovery | Michael McCool |
| | Discussion | |
| 1320Z | --- Break --- | |
| 1340Z | WoT PoC Progress | |
| | Retail | Michael McCool/David Ezell |
| | Smart City | Michael McCool/Jennifer Lin |
| 1400Z | [OneDM/TD Integration][4] | Michael Koster |
| | TD Templates; Modularity | |
| | Discussion | |
| 1430Z | [Hypermedia Controls][1] [in][2] [TDs][3] and beyond (+ impact on [RESTful design][RESTfulD]) | Victor Charpenay/Ege Korkan |
| | Actions and Events, Handling URLs | |
| | Discussion | |
| 1500Z | Wrapup, end of meeting | Chairs |

[1]: https://github.com/w3c/wot-thing-description/tree/master/proposals/hypermedia-control
[2]: https://github.com/w3c/wot-thing-description/pull/907
[3]: https://github.com/w3c/wot-thing-description/issues/302
[4]: https://github.com/w3c/wot-thing-description/issues/903
[RESTfulD]: https://tools.ietf.org/html/draft-irtf-t2trg-rest-iot-05#section-5

# Notes

Time stamps relative to the official meeting start time.

## Welcome, Logistics (Chairs)

Slides: https://github.com/t2trg/2020-06-helsinki/blob/master/slides/00-T2TRG-2020-06-helsinki-chair-slides.pdf

\[0:04]
Ari gave T2TRG intro. In the notes will list main discussion items and timestamps so you can look for details in the recording.

## WoT Update

\[0:10]
Michael McCool (MM) gave WoT intro.

MM: Descriptive approach for integrating IoT systems. Main components: architecture and Thing Description (TD).

\[0:17]
MM: Orchestration with NodeRED, NodeJS implementation Node-WoT. Some new work items: observe with HTTP, link relations, templates (multiple use cases), decentralized IDs, etc.

### Use Case Process and Overview (Michael Lagally) \[0:24]

Slides: https://github.com/t2trg/2020-06-helsinki/blob/master/slides/WoT-T2TRG.pdf

\[0:28]
ML: collecting use cases;  ~20 in the pipeline from several domains.

Marie-Jose Montpetit (MJM): manufacturing and agriculture use cases? Was actually in the next slide

\[0:35]
ML: Shortlisting some use cases -- focus on advantage WoT spec brings to adopters

Welcome everyone to contribute. Weekly calls. Output will be IG document.
Have reference to use cases repo in the slide deck.

## Lifecycle (Michael Lagally)

\[0:41]
Describing operational lifecycle across standards.

\[0:47]
CB: summary on where had to deviate from the T2TRG RFC8576?
ML: idea was to not deviate or re-invent stuff.
MM: layered keys was tricky to capture -- several provisioning steps

\[0:52]
MM: discovery needed also during onboarding -- discover the devices you are onboarding with

\[0:54]
ML: WoT profiles to handle variety of TD features and different devices. Early strawman available and needs significant discussion and more work.

AK: thank you for doing the use case work in public and collaborative; very useful for different standards & research work in this area
MM: still lots of input that needs to be prioritized but more input always good
ML: if anyone has additional use cases please let us know

## WoT Discovery (Michael McCool)

\[1:03]
MM: Intent to create a doc to describe discovery process. But not to re-invent the wheel. Generalized problem to find TDs. How to support semantic queries without too much burden for simple devices. Privacy aspects and alignment with existing standards important. Inferencing problems -- "no PII" is not sufficient, as there can be correlation/fingerprinting.

\[1:09]
Bootstrap phase should not have metadata about devices to preserve privacy. Need "first contact" protocol supporting multiple mechanisms for introduction.

\[1:14]
Use directory as a repository of information that needs authorization (with strong authentication) to access. Rotation of identifiers needed to avoid malicious user with cached TDs to know what devices are in question for new TDs.

\[1:25]
Experimenting with XPath and JSONPath query interface. Also signing TDs for security.

More information in the Github repo and links in the "resources" slide.

10 minute break

(back 1340Z)

\[1:40]
MM: will defer the discussion for the discovery on the next WISHI call June 30th: https://github.com/t2trg/wishi/wiki/Agenda-items#wishi-online-meeting

## WoT PoC Progress

### Smart City (Michael McCool/Jennifer Lin)

\[1:42]
Jennifer Lin (JL): different use cases Singapore GovTech is looking to solve with WoT. Smart thermosensor going to production. Low cost thermo sensor detecting high temperature in crowds. Could find areas with potential fever hot spots.

MM: general smart city use cases that apply beyond Singapore

### Retail (Michael McCool/David Ezell)

\[1:44]
MM: Connexxus working with grocery stores and gas stations in US. Integrating WoT to EdgeX Foundry. NodeRED for orchestration. Use case of buying ice cream.

\[1:50]
CB: how the results of experiments are documented?
MM: for plugfests trying to more formally capture experiments. Will walk through the PoCs. Will be in our repos, probably use cases or testing. Thinking if should have questionnaires.

Taylor Bentley (via chat): have Sidewalks labs reached out. They had a signage team that was vairly advanced
MM: not yet; but interested to talk. Let's take over email.

TB (via chat): bascially, I just wanted to flag: https://www.sidewalklabs.com/dtpr/
but now that the project is not being pursued in Toronto, I don't know if they'll progress to a PoC somewhere else (SDL is based in Manhattan)

## OneDM/TD Integration (Michael Koster)

\[1:55]
MK: summarizing where we are with OneDM. Getting ready to go live. Have published I-D and playground Github repo with comprehensive set of models.

CB: there's a [20 minute tutorial of SDF](https://www.youtube.com/watch?v=sTrqa5jYVKo) from our previous meeting. Provides high level interaction description for certain kind of thing.

\[1:58]
MK showed OneDM annotated WoT TD example of a Switch. The @type field of TD use to point to OneDM definitions. No linked data behind the URLs, so some further work for that needed in iotschema.
SDF definitions don't have protocol bindings or representation details but describing common definitions for broad classes. TD describes instances of things and has protocol bindings.

### TD Templates; Modularity

\[2:03]
MK: TDs are required to be complete. But often need TD-like entities that are not complete. For example don't have full protocol binding with URLs. OneDM models provide a vocabulary reference.

MK showed https://github.com/w3c/wot-thing-description/issues/903 wot-thing-description repo - PR 903

\[2:05]
MK: in WoT TD work looking at how OneDM definitions and TD templates could work together. Could we use TD templates like we use SDF in OneDM? The uses cases and potential overlap. The [PR 903](https://github.com/w3c/wot-thing-description/issues/903) shows what could it look if you translate SDF model into TD template.

\[2:08]
ML: how does anybody know string "on" has defined semantics?
MK: SDF enum in development; provides URI reference for each term/choice enum offers and have its own set of contraints and descriptions. Currently only providing human-readable description. But different ways to extend, e.g., state machine language.
MM: semantics are the link; still need to have precise definitions in human-readable format. Could be e.g. negative logic. Persistent link to definition are in the end the semantics -- can use @type to refer to it.
ML: if omit description, current definition does not convey behaviour
MK: have examples pointing to Wikipedia definitions for example. In SmartThings need i18n; this system of enums enables that.
CB: falling back a little from what we alredy established. On/off simple, but e.g., cheese firmness not that familiar for people. Need source of definition. Language doesn't currently provide that, SDF 1.0 does not have yet sdfEnum, but that is a next step.
Kaz Ashimura (KA): personally think it would be appropriate/easier to use a combination of state transition language (like [W3C scxml](https://www.w3.org/TR/scxml/)) and payload data model (like [W3C emma](https://www.w3.org/TR/emma/)) separately. Could use TD/ODM as the JSON-LD based data model.

\[2:17]
MM: one part semantics, but also how we make progress here? WoT TD for instances. SDF for high level descriptions of descriptions of devices. Path forward? several ways to use together? Formally cite SDF in the new SDF spec? What recommend people to do. SDF object to figure out how maps to TD.
MK: can use the OneDM models in TD plugfests. Bigger question about Templates. SDF is for device specifiers and makers. And folks who want to use the developer tools to make models in JSON. For example, SunSpec (making solar energy models) and Zigbee energy interested having broadly applicable models. We could make TD really easy to use. Main question is whether we take the OneDM definitions and translate them to TD templates and provide anchor URIs in TD namespace or make templates that link back to OneDM models. Pros/cons in both. Need to think what happens when OneDM model changes. Probably want to link instead of copy. Could add in TD the detailed constraints beyond SDF models. TD templates could have specific bindings and use profiles.
MM: when define TD templates do it with eye on interop with SDF. Modularity for TD templates should map to SDF Objects, for example. Set of activities for spec alignment. Third class: tooling. Can automatically generate TD templates mapping to SDF models. Could run with CI.
MK: could be base TD template that does not have anything beyond SDF; just maps to TD and linked data world. Could be driven through CI. Should think of work flows.
ML: can I express thins in SDF that I can't express in TD, and vice versa?
MK: e.g., full set of constraints in SDF, but not many things. Mainly composition and modularity. Layering of things and objects does not exist in TD. But TD is for instances.
CB: lots of things in TD that can't do in SDF. Like protocol bindings. One of the points in SDF is to make easy to map existing models to SDF and preferably back. Focus here on model interop. Very different from what TD had. That's why result looks different. But next step to make sure we have model interop on that level.
ML: OCF models or something else?
CB: and LwM2M, Bluetooth, etc. Each org has hundreds of models already. Want to find a way to translate to common language and back. Leads to compromises in compatibility. More in the process of accessing all ecosystems now.
MK: some ecosystem folks are looking at SDF and thinking of extending their ecosystem with it.
CB: way forward; going to be lots of discussion of this in the next few WISHI calls. Maybe the best place for people who are interested making these work together. Now have SDF 1.0 published last Friday. Next step is 1.1 and not drop in kitchen sink but to put the features we need to widen applicability to Bluetooth, Zigbee, etc.
MK: and will start working in the WoT plugfest immediately. Also Semantic Proxy project.
AK: also non W3C WoT members invited to Plugfests?
MM: Yes, drop me email and I can send invite to Webex.

CB: good communication channels open now. Will continue to drive convergence.

## Hypermedia Controls in TDs and beyond (+ impact on RESTful design) (Victor Charpenay/Ege Korkan)

(Actions and Events, Handling URLs)

\[2:34]

Ege Korkan (EK): introducing hypermedia proposals in the TD repository:

https://github.com/w3c/wot-thing-description/tree/master/proposals/hypermedia-control Victor's proposal
https://github.com/w3c/wot-thing-description/tree/master/proposals/hypermedia-control-2 Ege's proposal

EK: (starts with the first proposal above) in TD mostly focusing on actions that are started by client. Want to describe hypermedia in TDs. First request OK by standard, the subsequent ones are not easily described. What methods are available for example. Don't want to overload TD with all possible future interactions.

MM: multiple issues 1) developer has information of what code has to deal with? 2) dynamic TDs would have all complications with directories, signing, etc.

Victor Charpenay (VC): essential idea to reuse hypermedia vocabulary in TD. For every new affordance a new form in the TD. Would not need to add much to TD model to allow for this but only need new operation types for cancel or update of action. Different possibilities for exposing new forms.

Ege showed rest of the Victor's example

\[2:48]

Ege showed second example.
https://github.com/w3c/wot-thing-description/tree/master/proposals/hypermedia-control-2

EK: using dynamic hrefs with URI templates. Not clear how to get IDs; can ignore if static. But not clear how response payload for different operations should be.

\[2:54]
MM: issue with URI templates. Input/output data schemas would be natural here. Need data schemas per transaction.

EK: query acton schema described in the end of the example

MM: if have ID in response to POST ...

EK: entire href could be variable. HTTP standard says in 201 could be in header or body of response. Looking for feedback on the proposal for mapping the ID. `const: {id}`

Zoltan Kis (ZK): three standard actions; would prefer to have events and actions for cancelling. Would return a thing -- easier to model this way? Could be called something else than Thing since abstract.

VC: for ID mapping should define where URL variable points to?

EK: can this be also used like this? Don't know.

VC: ID may not be URI. Could be input to further action. Have to say the ID is a control; part of form to perform more actions. There was proposal to use OpenAPI. This suggestion is rewriting OpenAPI. But that does not solve this issue either.

CB: interesting discussion since running into problems where established mechanisms like OpenAPI can't solve this. I'd love to propose how to solve this in SDF, quite obvious, but will continue the discussion in next WISHI call

MM: API definition conference coming up. Contemplating making a submission. Might be interesting for WISHI people to participate too. Being discussed in WoT Github issue https://github.com/w3c/wot-marketing/issues/66

(running out of meeting time)

## Wrapup, end of meeting (Chairs)

\[3:04]

AK: good discussions to continue in the upcoming WISHI calls, next one on June 30th: https://github.com/t2trg/wishi/wiki/Agenda-items