WoT-IG/WG vF2F Meeting

05-22 Oct 2020


Summary of Action Items

  1. [NEW] ACTION: kaz to ask PLH about the latest *trend*

Summary of Resolutions

  1. we'll go for Oct 13, 10m EDT for the JSON-LD joint meeting
  2. Accept the current editor's draft as the FPWD version with the fixes discussed in the call on Oct 7th. and including the editorial fixes marked with fpwd and editorial in the issue tracker.
  3. we'll continue the profile discussion during the Architecture on Oct 15
  4. proceed with FPWD of the TD 1.1 editor's draft after merging PR 993, with short name wot-thing-description11
  5. publish the FPWD of the WoT Discovery editor's draft, with short name wot-discovery
  6. publish the FPWD of the WoT Architecture 1.1 editor's draft, with short name wot-architecture11
  7. publish the FPWD of the WoT Profile editor's draft, with short name wot-profile
  8. publish the current editor's draft of the WoT Scripting API as an updated note

Day 1 - 5 Oct 2020


Kaz_Ashimura, Michael_McCool, Hiroshi_Ota, Kunihiko_Toumura, Michael_Lagally, Takio_Yamaoka, Sebastian_Kaebisch, Jeff_Jaffe, Daniel_Peintner, Ryuichi_Matsukura, Ege_Korkan, Cristiano_Aguzzi, David_Ezell, Ken_Ogiso, Tomoaki_Mizushima
McCool, Sebastian
Kaz, Daniel, Sebastian

<kaz> scribenick: kaz


kaz, daniel and sebastian


vF2F wiki

McCool: call logistics above
... several guests for today
... IRC channels is #wot
... resources on GitHub
... schedule
... PlugFest done last week, Sep 28-Oct 2
... today Architecture/Profiles
... Oct 7: Use cases, requirements and liaisons
... Oct 13: joint meetings with DID and PUB
... Oct 14: joint meeting with APA
... Oct 15: joint meeting: with WN
... Oct 20: Discovery
... Oct 21: TD and Thing Model
... Oct 22: Scripting, Security, etc.


Lagally: holding 2-hour call every week
... version to be published as a FPWD now
... clean up a bit, e.g., for ReSpec
... topics: FPWD review - go over the draft
... then requirements
... trying to identify requirements for standardization
... terminology as well
... then two presentations
... Sebastian on Thing Model requirements, Koster on OneDM compatibility
... anything else for today?

Prev minutes


Lagally: discussion with the Pub BG Chair for the joint meeting
... FPWD publications, OneDM/Thing Model, ...
... any objections for publishing the minutes?


Lagally: approved

Architecture draft

latest draft

Lagally: no ReSpec errors now
... would like to identify owners of unassigned sections after the FPWD publication
... this is the FPWD version, and the Architecture TF is OK with publishing the draft
... (goes through the sections of the draft )
... Introduction, Conformance, Terminology, Application Domains, System Topologies
... not perfect yet
... short section on System Integration
... then Requirements
... we'll detailed discussion later
... then Abstract WoT System Architecture
... WoT Building Blocks which talks about the related WoT specs
... Thing Model, Core Profile and Discovery have been added
... then Abstract Servient Architecture
... would like to go through the newly added sections
... and see go or no-go for the FPWD publication

Kaz: (as I mentioned the other day) we need to add the diffs from the v1 version within Appendix A "Recent Changes"

Sebastian: right. it would be helpful.
... Taki is working for TD spec too

Lagally: ok
... created an issue on that

Issue 545

Lagally: had a conversation with Matthias
... he's not active anymore and to be moved to the Acknowledgement section
... some more as well
... also would like to get some more new
... created another issue on that

Issue 542

Lagally: Terminology
... definition for "Thing Model", etc.

Sebastian: I have a definition within the TD draft

McCool: would be more convenient to have the definition within the Architecture spec so that we can refer to the document for terminology

Lagally: Sebastian, please make a Pullrequest to transition the definition from TD to Architecture

Sebastian: ok

Issue 547 on terminology for Thing odel

Lagally: goes through the use cases (Application Domains/ System Topologies)
... Editor's note for "5.5 Edge Devices"
... "TODO: (McCool) Check if the current text still fits with recent edge computing activities."

McCool: nothing incorrect here
... should say "expand" instead of "check"

Lagally: ok

McCool: expand to capture the recent activities

Lagally: ok
... probably need a proof read as well
... new issue on "align languages use case vs application domains"

Issue 548

Lagally: then "7. Requirements"
... Editor's note saying "TODO: New requirements from new use cases need to be added here."

McCool: links to the requirements on the GitHub would suffice

Lagally: ok
... creates a new issue for that

Issue 549

Lagally: section 7.2 also has the same note
... then "8.1 System Components"
... "TODO: Create introductory text that introduces the concepts from the succeeding chapters."
... also "8.1.2 Thing Models"
... "TODO: Create section."

Sebastian: there is a PR

Lagally: 8.1.4 Intermediaries
... "TODO: add reference."
... then "8.4 Lifecycle"
... need references

McCool: any resources the other W3C groups?

Kaz: what about IETF ACE, etc.?

McCool: that is rather related to device lifecycle and would like to see application lifecycle

Kaz: in that case, we might want to see the multimodal lifecycle note

<jeff> [/jeff needs to drop off.]

McCool: might make sense though that's kind of old

Issue 552 on lifecycle intro text

s/application lifecyle/information lifecycle/

McCool: note that we have PRs not yet merged on LD proof, etc.
... and related discussion on how directory is managed for discovery
... think LD proof should has enough features

Lagally: what about "information lifecycle"?

McCool: need to have discussion on information in a device and metadata like TD
... put together the obvious things and then non-obvious things

Lagally: what is the difference?

McCool: examples of obvious things are cameras to take photos
... to be moved to the other devices
... sometimes you might want to include personal data
... so it's not "TODO or Not-TODO" question

Lagally: the requirements depend on the scenarios

McCool: two large categories here
... 1. data management
... 2. metadata management
... probably separate lifecyle for both
... data management should be discussed with the Privacy group

Lagally: let me capture the points within an issue

Kaz: Michael McCool should be able to work on that but people are encouraged to provide use case scenarios for this

McCool: yeah

Lagally: can assign this issue to you, McCool?

McCool: yeah
... please put labels for discovery, past FPWD and security

Lagally: done
... creates two more issues for lifecycle

Issue 554

Issue 555

<scribe> scribenick: dape

Lagally: old editors note right before 8.7

<inserted> 8.7 Protocol Bindings

Lagally: Question to Sebastian: additional oepration types coming?

Sebastian: None planned
... default operation for unsubsribe event planned
... current text is fine as is

Lagally: Building block sections
... 9.2. Thing Model is new
... 9.3. Core Profile is new
... 9.4. Discovery is new

Sebastian: working on intro text for 9.2. Thing Model

Lagally: Introduction text for 9.3. and 9.4. is planned for past FPWD

McCool: Can expand editors text for 9.4. but actual update is planned for later

Lagally+McCool: cross-referencing between Architecture and the other docs like Discovery and TD to be handled by Kaz

Lagally: Sections 10+ do not contain 1.1. changes
... need changes sections for 1.1
... 9 issues left for FPWD (Architecture)

<inserted> Issue 558

Daniel: FYI: JSONLD has a former editors list in the top of the spec

Lagally: Talked with M. Kovatsch but he perefered to move it to appendix

Zoltan: Seems to be common to have editors kept together

Lagally: no strong opinion
... suggest keep it as it is

Kaz: we can also check commit history. please note the Editors list was imported from the WoT Architecture 1.0 version, so we need to clarify who would be the active contributors.

McCool: Suggest leaving it as is
... suggest moving it out to improve citation

Kaz: Will check with Panasonic, but publishing the FPWD with the current Editors list is fine.

Lagally: Issue#546, marked as "past FPWD"
... Would like to ask Sebastian to take over
... 8 minutes break before ThingModel topic starts

<kaz> [8min break]

Thing Model

Sebastian: Would like to start with requirement document for thing model
... see https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-models.md
... many use cases for thing models
... - digital twin use case
... - mass production use case
... - simulation use case
... essentially use cases where we don't need actual TD instances
... Requirements:
... - defining common elements
... - minimum requirements

<Mizushima> --> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-models.md thing model

Sebastian: - possible to define partial (or template based) security definitions

<inserted> 10. Thing Model from the TD draft

Sebastian: At the moment section "10. Thing Model" is in TD
... content comes from Annex C
... previous name was "Thing Description Template"
... still discussing content type requirement
... We are trying for formalize the chapter right now
... also work on text about differences between "TD" and "Thing Model"
... object oriented programming paradigm: class vs instance
... Thing Model defines model for a thing: common metadata, no/partial security, no protocol or template

Lagally: Figures contains term "template". Is thera definition?

Sebastian: Not yet

McCool: coming from URI template

Lagally: Need to explain how missing data is completed

McCool: 2 options
... 1. omit
... 2. named values
... problems like name collisions may arise

Sebastian: Chapter 10 is still under construction
... The TD follows the ThingModel and includes missing data/portions
... instance specific data

McCool: for security it is good to know the type of security
... but the authorization server does not need to be known in advance

Sebastian: Links make more sense in instances

McCool: depends on link relation types
... some kind of links may be in Thing Model

Lagally: Good point
... brings multiple inheritance back
... how can a TD be implementing 2 Thing Models
... eg. switch and a lamp

Sebastian: extension feature will be addressed
... technical solution is not decided yet
... re-use what we have?
... JSON schema, JSON-LD, ...
... need technical evaluation

McCool: Closeley related to modularity
... maybe avoiding certain conflicts
... aligning with oneDM structure

Ege: w.r.t. multiple inheritance: prefer using "one" ThingModel but add support merging 2 thing models into one

Lagally: Makes sense

Sebastian: Agree also
... should clarify the approach

Cristiano: there is not only inheritance but also composition
... need to clarify when to use what

Lagally: Agree, we will see both types

<McCool> McCool: agree with idea of doing composition of thing models (ideally still with modules) and then single inheritance ("implements" relation from TD to TM)

Lagally: how do we put things together

Sebastian: Please have a look at new section 10 in TD document
... there are new assertions
... introduces also @type "ThingModel"
... there is also a new "placeholder identifier"

Lagally: Issue how to escape double brackets

Sebastian: We have an issue with that regard

<McCool> McCool: think we should follow existing systems in that regard (example is "mustache")

Sebastian: Note: TD document contains Thing Model definition already

<inserted> PR 540

Sebastian: I prepared PR#540 for architecture
... added 2 paras explaining Thing Model

Lagally: Any comments/questions?
... propose merging
... no objections --> approved
... need to resolve conflict first
... PR#539
... comes from Zoltan

Zoltan: Made more changes
... scope is device lifecycle
... please let me know if there is something more or missing

Lagally: Suggest to take what we have and improve later (if necessary)
... suggest resolving merge conflicts and merging
... Need "owners" for FPWD issues

Sebastian: BTW, resloved merge conflict

Lagally: Okay, then let's merge PR 540

<inserted> PR 540

Lagally: back to "owners" for issues
... I will take some

McCool: can take issue#549

<kaz> Issue 549

Zoltan: Note: huge merge conflicts but can solve them

Lagally: Time check? Agenda check
... carry over to architecture call on Wednesday

<kaz> Updated agenda for today

Lagally: 5 minutes break

<kaz> [5min break]

<kaz> scribenick: sebastian

WoT Profile

Lagally: Specification is in early stage
... it has many editors note
... many details are missing

<Mizushima> --> https://w3c.github.io/wot-profile/ wot-profile draft

Lagally: however, good base for discussion
... we need active contributions, implementations, etc.
... which features should be adopted, which are common ground, etc.
... we need some feedback, how the current assumptions work

McCool: there are different use cases such as out of the box interoperability. are there more missing?

Lagally: first concentrate on OTB interop.

<Ege> https://github.com/w3c/wot-profile/issues/37

McCool: we need also discussion about extensions like geo location in the TD
... however, we should limit the extensions

Ege: I provided a review as an issue
... there are two concerns

<kaz> 5.1.22 Recommended practice

Ege: one is about events
... web sockets are very open
... other comments about small feadbacks

Lagally: many details, we should go over in detail

issue https://github.com/w3c/wot-profile/issues/37

Ege: What makes the enum special?

Lagally: is type safety and based on simple types

Chris: A concrete example could help with the enums

Ege: "format" is not supported anymore in JSON Schema

Sebastian: use a different term?

Ege: No, its a different mechanism
... Type is a must, but what is about photos?
... there needs better explaination when JSON is used as content type

Lagally: However, we just describe Thing Model Data Types there
... Should there be an assertion saying terms not in TD are not allowed for DataSchema, i.e. anyOf

Ege will provide a specific issue

Ege: misstake about the input of actions. It allows objects

Lagally: We running out of time. Cont. in the next call

Ege: Regarding security, shall all scopes be supported?

McCool: We should follow the security guidelines.

Lagally creates an issue about the different OAuth2 options

Lagally: continue on Wed. about the inputs from Ege

Ege: Current draft of WoT Profile is not ready for FPWD, especially the Event part

Lagally: Will be more feedback expected?

Daniel: I will read the current status

Cristiano: I will also review

McCool wraps up

Kaz: How should be the title name of the Arch 1.1?
... something like "wot-architecture11"?

Sebastian: dot or without?

McCool: I think "wot-architecture-1-1" is better
... what did the JSON-LD spec do?
... is there a convention?

<kaz> JSON-LD uses https://www.w3.org/TR/json-ld11/ for their 1.1 version
... and different groups use various notations
... TTWG uses https://www.w3.org/TR/ttml-imsc1.1/ for IMSC 1.1
... ARIA WG useshttps://www.w3.org/TR/accname-1.1/ for "Accessible Name and Description Computation 1.1"

[Day 1 adjourned]

Day 2 - 7 Oct 2020


Kaz_Ashimura, Hiroki_Endo, Gyu_Myoung_Lee, Takuya_Handa, Takuji_Kiura, Shinya_Abe, Michael_McCool, Michael_Lagally, Takio_Yamaoka, Kunihiko_Toumura, Ege_Korkan, Tomoaki_Mizushima, Rob_Smith, Hiroshi_Fujisawa, Zoltan_Kis, Dave_Raggett, Ryuichi_Matsukura, Daniel_Peintner, David_Ezell, Hiroshi_Ota, Ken_Ogiso, Sebastian_Kaebisch
McCool, Sebastian
kaz, McCool, mlagally

<McCool> presentations will be here, including opening decks: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-online-f2f

<inserted> scribenick: kaz


<kaz> McCool, Kaz, Lagally


McCool: logistics
... call agenda


McCool: IRC available


McCool: Guests?

Kaz: Gyu Myoung from ITU-T again

Gyu_Myoung: I'm aware of the W3C Patent Policy

McCool: the other guests from W3C Membership?

Kaz: please confirm all the other observers are also aware of the W3C Patent Policy :)

all: OK

McCool: Schedule
... Oct 7: use cases, requirements, liaisons
... Oct 13: joint with DID and PUB
... Oct 14: joint with APA
... etc.
... Cancellations of the group calls
... see the main wot wiki


McCool: would like to confirm the rest
... architecture on Oct 8?

Lagally: cancelled

McCool: scripting on Oct 12?

Daniel: planning to have it

McCool: security on Oct 12
... cancelled
... discovery on Oct 12
... will be held
... TD on Oct 14
... cancelled
... architecture on Oct 15?

Lagally: should have the call
... though could be shorter

McCool: main call on Oct 14
... will be held
... mainly logistics and organizations
... Joint calls
... 3 possible slots
... Oct 12, 9am EDT
... Oct 13, 9am EDT
... Oct 13, 10am EDT
... my 2 cents is 10am would be better
... any thoughts?

Sebastian: sounds good

RESOLUTION: we'll go for Oct 13, 10m EDT for the JSON-LD joint meeting

Sebastian: will let them know

McCool: Sebastian to confirm with the JSON-LD WG; McCool to handle the GitHub issue agenda and outlook invite
... APA
... Oct 14, 9am EDT
... agenda updated and Zoom allocated
... Other meetings: DID, PUB, Web&Networks

WoT vF2F meeting table

Ege: what would be the agenda for PUB?

McCool: media in general as well as published media

Agenda for the PUB joint meeting

Kaz: please see the agenda issue above

McCool: yes
... and we need session managers for those meetings
... (shows the agenda issues on wot repo)

agenda issues

McCool: will record all the session organizers to the issues above
... any volunteers?
... e.g., who is interested in the APA meeting
... anything else on logistics?


Agenda for today

agenda for Oct 7

Arch TF part 2

<scribe> scribenick: McCool

Lagally: behind schedule, full agenda; overflow from monday to deal with to close FPWD
... for both Arch and Profile
... may need to modify parts of later agenda to make time

Gyu_Myoung: I may have to leave before the end of the meeting

Lagally: ok, may have to shift things around

Gyu_Myoung: correction: need to leave, will be back in 1.5h

* Issues and PRs

Lagally: review issues, tagged some with "FPWD" label in wot-architecture repo
... some PRs that deal with some of these
... PR 539
... add device lifecycle section
... see you were having some rebase problems, marked as WIP

<kaz> PR 539

Lagally: is it valid to say we can merge even though imperfect, as a baseline?

Zoltan: tried many ways to resolve conflicts... had to rebuild
... PR shows long information, but merge should be fine

McCool: may break other PRs, but...

Lagally: well, let's merge anyway, and then deal with it as necessary
... (merged PR 539)

<inserted> PR 559

Lagally: next, PR 559, TM definition
... no merge conflicts
... now takes comments and discussion into account

<inserted> PR 560

Lagally: next, PR 560
... no merge conflicts
... suggest merging; any objections?
... no objections, merging
... no let's look at issues

<inserted> Issue 547

Lagally: closes issue 547, TM
... also issue 476, lifecycle; related to device

<inserted> Issue 476

McCool: think we should look through this closed issue and create smaller ones for things that are not addressed
... need smaller, more specific issues

Lagally: there are some editorial issues

McCool: maybe could label the editorial issues with a github label...

<Ege> I will be back in ~10 minutes

Lagally: issue 548, cleanup of usage of "Use Case" term

<kaz> Issue 548

Lagally: (marked as editorial)

<kaz> Issue 551

Lagally: issue 551, need a few lines to open section and summarize
... there are a few other places that are missing opening sections

McCool: I think these are not technically required, and unless we write the text right now there is no way to review in time

Lagally: right, so let's just accept it as it is, then deal with these sections after FPWD

Zoltan: do think we need to discuss whether we want three separate lifecycles or one
... and the introductory text should state the plan

McCool: suggest we just say in the ednote that "reorganization is under discussion" and maybe link to the issue
... detailed discussion can then take place in the issue

Lagally: sure

Zoltan: sure

Lagally: (does a direct edit...)
... need to create an issue, zk can you do so?

<kaz> Issue 561

<zkis> https://github.com/w3c/wot-architecture/issues/561

Gyu_Myoung: will be back in an hour

<mlagally> proposal: Accept the current editor's draft as the FPWD version with the fixes discussed in the call on Oct 7th. and including the editorial fixes marked with fpwd in the issue tracker.

<mlagally> proposal: Accept the current editor's draft as the FPWD version with the fixes discussed in the call on Oct 7th. and including the editorial fixes marked with fpwd and editorial in the issue tracker.

RESOLUTION: Accept the current editor's draft as the FPWD version with the fixes discussed in the call on Oct 7th. and including the editorial fixes marked with fpwd and editorial in the issue tracker.

Lagally: 5 min break

<kaz> [5min break]

McCool: seems there is still a lot of feedback we should take into account, perhaps we should defer FPWD?

Lagally: let's look at some PRs I developed first and then discuss

* Profile

<kaz> scribenick: kaz

Issue 42

Lagally: current events section is too loose
... Ege mentions "No experience at all with both of them from the plugfests."
... and that's true

McCool: Mozilla was working on WebSocket
... but WebSocket itself is not a complete spec yet

Ege: client/server bind

McCool: let's say longpoll at the moment
... need one mechanism for event handling

Ege: advantages and disadvantages with each approach
... would be over engineering unless we have protocols over it
... this may cause with high speed eventing

McCool: we could align with Mozilla's work later but at the moment need to live with one method which is already available

Zoltan: given this discussion, wondering if we should explore the WoT WebSocket protocols work

Lagally: should be out of scope

<McCool> mm: note also that primary goal of profiles is OOTBI, secondary (future) objective could be supporting performance (in which case, yes, WS makes sense... but we need more constraints to get OOTBI)\

Lagally's comment added

PR 44

Lagally: next PR 44

5.1.6 Event Affordances

Lagally: Editors not on event handling there

McCool: ok with accept this asis
... assuming change to longpolling and SSE
... we can defer protocol-specific reorg, really this comment should be in HTTP-specific section
... consistently for all affordances

https://github.com/w3c/wot-profile/issues/43 Issue 43

Lagally: tx for feedback
... (goes through the comments)

Daniel: data schema should be defined

PR 46

Lagally: (goes through the changes)

McCool: we need to look into use cases to see if it's reasonable

Kaz: +1

Lagally: let's address use cases which are relevant

McCool: ok

Lagally: hope this change will improve what we have so far

<McCool> mm: although if we are targetting new devices vs brownfield devices this is not as much of an issue

Lagally: should we merge this PR?

Kaz: should we add an Editor's note on relevant use cases?

McCool: let's assume pre-scriptive cases here

Lagally: objections for merging PR 46?



McCool: at the very least, supporting brownfield devices can be under "secondary goals" (and OOTBI is still primary!)

PR 47

Lagally: Sebastian's comment

Sebastian: we've been holding discussions about this point

Lagally: I have some ideas

Kaz: would suggest we defer this PR and discuss it after FPWD publication

Sebastian: would like to discuss this before FPWD...

Lagally: let's see if there could be some compromise
... Editor's Note within the Abstract section

The name WoT Core Profile is still under discussion in the group and is used as a working title. It is subject to change after the profile specification has reached a certain level of maturity.

Sebastian: Core profile would have impacts to all the other profiles...

McCool: "Core" is common
... would suggest we stick to "Core" at the moment with an Editor's Note

Lagally: at least the Note addresses the concern

Sebastian: saying "Core" implies it's already there

McCool: need to understand what Sebastian expects for Profiles

Kaz: unfortunately, it seems to me that we still need further discussion to get the conclusion
... so we should defer the discussion on this point and move ahead for the use cases discussion today

Lagally: would not like to defer the publication of Profiles...

Kaz: in that case we should have a dedicated additional Profiles call
... but we should have discussion on use cases as planned during this call
... given we have many invited guests for that purpose

Lagally: Sebastian, could you raise any concrete alternative proposal?

Sebastian: share the same goal with Lagally for the publication itself
... would like to provide clarifications

Kaz: in that case, we need to have an additional call for Profiles. right?

Lagally: let's have an additional discussion during the Architecture call on 15th

Kaz: need not to have that tomorrow?

Lagally: since can't make it tomorrow
... we can close PR 47 itself, and then continue the discussion

RESOLUTION: we'll continue the profile discussion during the Architecture on Oct 15

[5min break; then Use Cases]

Use cases

Lagally: various guests for the discussion
... would like to skip the detailed discussion on requirements
... and would start with the ITU-T collaboration
... then new use cases the WoT TFs
... and then Agriculture, Media & Entertainment

* WoT IG Use Case TF


Lagally: objectives
... identify and describe new relevant use cases
... collect use cases from the other W3C groups and also the other relevant stakeholders
... publication of "WoT Use Cases" document
... work split
... architecture vs use case work
... use cases are handled by the WoT IG's Use Cases TF at wot-usecases repo
... process
... use cases => shortlisting => requirements => spec work by the other TFs
... requirements analysis
... requirements draft

* PRs for the latest draft

<mlagally> https://github.com/w3c/wot-usecases

Lagally: use cases repo above

rendered draft

Lagally: Mizushima-san has been working on clean-up
... there are still issues on the document, though

PR 60

Lagally: merged

PR 60

Lagally: ITU-T summary
... Gyu Myoung will give updates
... there will be ITU-T meeting in Nov
... we've started to look into their work
... hope we could work collaboratively

(Gyu Myoung joins again)

OLS - DRAFT.md Proposed liaison statement

Lagally: should add references to the published specs
... align terminology to avoid fragmentation
... would like to establish open conversation channel
... as a starting point, we should provide our use case document to them

Kaz: given we need some more time to finalize this proposal, probably we should work on this during the use cases call next week :)
... we should think about the scope like reviewing the specs with each other
... providing use cases with each other, etc.

Lagally: right
... we should continue the discussion during the use cases calls
... also we should clarify the expectations from the ITU-T side
... Gyu Myoung, please let us know about your need too

Gyu_Myoung: maybe starting with simply exchange share our current work?
... to see what the other side has been doing
... something related to energy environment management, etc.
... ITU-T work on use cases and then architecture
... then provide ideas to related SDOs working on protocols, etc.
... if we have clear views between ITU-T and W3C WoT, could work on certain document

Lagally: ok
... McCool, could you help us generate some text for that?

McCool: we're interested in ongoing work

Lagally: note this is a liaison letter to be sent to ITU-T SG20

McCool: ok
... we should include alignment of standards
... terminology alignment would be helpful
... should not define different terminology for the same idea
... opportunity to align our work efforts, e.g., jointly developing common documents
... would say "seek to align"

Lagally: ok
... this could be an initial draft

Kaz: we need to copy to team-liaisons when we send this to ITU-T
... also should talk with them beforehand as well

Lagally: ok
... commit the proposal as an initial draft

Collaboration with other W3C groups

<mlagally> scribenick: mlagally

Agriculture - Kiura-san


Kiura Takuji - presentation - Agriculture CG

Rural hybridization

Since 2020 Prototype of Agricultural WoT?

Early warning system, monitoring glacial lake in Himalaya

Physical Hybridization in Rural Area, Open field smart agriculture use case is closely related

Technologies include: AR, AI, Cloud/Edge Computing, High performance networks, 5G and beyond

Various use cases

Discussion at APAN50

COVID-19 reveals vulnerabilities in rural area

scribenick: kaz

<kaz> Use Case Template

Kaz: would like to suggest Kiura-san generate a concrete use case description using the template above. "Rural hybridization" is a big use case which could cover many topics.

Lagally: interested in mitigation of natural disaster

McCool: would like to see a general use case which covers possible issues
... power management, etc., as well
... decentralized management using solar, etc.
... a lot of interesting stuff here
... agriculture is part of this but many other topics too

<McCool> sorry for taking extra time. I would like to mention the following link as being relevant to "rural hybridization": https://www.newyorker.com/tech/annals-of-technology/the-one-traffic-light-town-with-some-of-the-fastest-internet-in-the-us

NHK - Endo-san

scribenick: mlagally


demo is implemented using open source code available on github

In plugfest we connected TV to 4 devices from other WoT members

WoT enabled TV will enable new use cases by integrating with other devices

scribenick: kaz

<kaz> NHK's original use case

Kaz: related to the use case above
... please extend the one or provide an additional one for this work
... also this demo should be included in the demo during the breakouts later Oct

Sebastian: context?
... your own ontology?
... can the video be shared?

Kaz: let's continue the discussion based on the updated use case description from NHK :)

Sebastian: ok

* AR use cases - Rob Smith

slides tbd@@@

Rob: WebVMT overview
... open web format for location sync with video
... sharing, indexing, map presentation
... W3C editor's draft by the CG available
... roadmap
... use cases
... golden tutorial use case: AR demo, proof of action, data capture format for AR debugging
... virtual guide: AR/VR guide, e.g., historic site, medical, control in general

<McCool> (aside: closely related to geospatial use cases we can cover on Friday in the plugfest wrapup)

Rob: visualize events and structures + narrative
... sync with annotated map or virtual space

Kaz: we've generated initial draft use case descriptions as PRs

<kaz> PR 61 by Kaz

<kaz> PR 62 by Rob

Wrap-up for today

<McCool> (I think we should determine, quickly another time for Rob to join us)

Lagally: thanks a lot for contributions!

Sebastian: and thanks a lot for your hard work, Lagally!

Lagally: will continue discussion in next use case call (next week)

<McCool> (I will note then that the Use Case call next week is NOT cancelled as well in the wiki, etc)

McCool: note that there will be the WoT Use Case call on Oct 15th at 7am EDT


Joint meeting with JSON-LD WG - 13 Oct 2020


Kaz_Ashimura, Hazel_Kuok, Michael_McCool, Pierre-Antoine_Champin, Victor_Charpenay, Ivan_Herman, David_Lehn, Sebastian_Kaebisch, Dave_Longley, Kunihiko_Toumura, ivan, pchampin, Tomoaki_Mizushima, Christian_Glomb, Daniel_Peintner, Ogiso, dlongley, Benjamin_Young, Erich_Bremer, Cristiano_Aguzzi, Michael_Lagally, Harold_Solbrig
Sebastian, McCool


<kaz> Agenda for JSON-LD joint meeting

<kaz> scribenick: McCool


Sebastian: two major topics, related to TD and related to Discovery
... will start with TD
... going to go straight into issues and assume attendees know what WoT is
... but would like to know the current status of JSON-LD maintenance situation

JSON-LD WG status

Beny: maintenance mode is lightweight working group
... to keep an eye on JSON-LD iterate them if there are emerging needs or minor issues
... but not currently pushing for a major update at this point
... but group is willing to consider new work items, but nothing pressing at the moment
... we just published the 1.1 document, now the rest period after that

Ivan: there isn't another working group; JSON-LD CG does exist
... but don't currently have formal meetings, etc.
... but incubation can happen in CG
... and if the CG comes with new proposals, then formal work would happen in WG
... by having the WG, we can keep the IPR framework in place

(yvon -> Ivan Herman)

Sebastian: thank you for the clarification
... few words on our status; we have released our first docs, specifically TD 1.0
... now working on next version, and various other new work items

<inserted> WoT Thing Description Recommendation

Sebastian: let's start with TD

McCool: sure, but please reserve at least 20m for discovery

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

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

Victor: I see two new issues that did not get labelled with the JSON-LD label

Sebastian: are these urgent?

Victor: well, I think we should ask the JSON-LD editors for advice

Sebastian: issue 932, versioning
... would like some advice on how to best identify versions

<kaz> Issue 932

Sebastian: probably going to have a new ontology context with a new URL, victor is that right

Victor: yes

Sebastian: my question is how to distinguish JSON-LD 1.0 and JSON-LD 1.1

Beny: can trigger 1.1 processing in context file; forward-pointing API
... or rather, there is a way to specify it is a 1.0 document

Sebastian: question pattern of context URL... same pattern, just change the year?
... were looking at other standards to see how they did it, eg XML Schema

Daniel: but for some reason XML Schema did NOT change the namespace

Beny: I think they wanted an update-in-place

<kaz> JSON-LD 1.1 Recommendation - processing mode

Daniel: well, they added new types, so potentially breaking change...

Ivan: JSON-LD spec is silent on these issues
... I know the VC group or DID group may have some strong feelings about this
... because there are probably security implications
... one thing we did look at but postponed was adding a hash to context URL
... this is still an open issue, flagged for future work

<victor> ack

Sebastian: ok, let's bring up with DID

DaveL: from security perspective, reason to have a year is an additional signal
... to consider how old the spec is
... what other groups have tended to do is to increment a single number
... in other words, consider it always a major change
... also, consider it "fixed", and publish a hash
... so that processors can embed it in their applications (and don't have to download it dynamically)

Sebastian: ok, conclusion is we will talk with other groups, but it sounds like we should use the same pattern and just change the year
... but will have to follow up

Issue 643

Sebastian: base direction considerations
... note there are new terms for base direction
... but we also have a balancing act in that we also want to be compliant with JSON Schema
... and they already have some terms defined
... there are also some multiple language options, not allowed to define a container for title, etc.

<kaz> i|baes direction|Issue 643|

Sebastian: which is why we also defined the map "titles" that can give multiple string values tagged by language
... then define default language in context block
... use case is TD might be used to generate a UI, user might want to pick a different display language
... so would like to harmonize, align with JSON-LD, but conflict with JSON Schema is a problem
... probably can't fix in TD 1.1, but we would like to discuss what to do for TD 2.0

Beny: what is the JSON Schema limitation?
... I actually like the title/titles approach

Sebastian: JSON-LD approach seems to be to keep the title, but make it array value
... but "title" is special in JSON Schema
... and a TD is also a JSON Schema...

Beny: Multilanguage string is actually an object in JSON-LD...
... so also includes direction for each language

Ivan: we have language maps, but you can't add direction to them
... remember we had this problem
... it was a long and hard to solve problem

Beny: the margin of error is high and the value is low
... there is a verbose solution, but is it worth it?

Ivan: what we are doing here is actually a hack...
... in fact this is a problem in the RDF specification itself
... really the direction should be incorporated alongside language in the RDF string model
... but it would cause problems with already-deployed SW, etc.
... we could not really solve the direction issue in a completely satisfactorily manner
... we knew in advance this was coming, and geninely tried to solve in it collaboration with the internationalization community, but
... as another option, rather than using a plain literal in titles
... instead of using a plain literal, use stripped-down HTML markup
... allowing only a very small number of tags
... shied away from it, complicates things like search and editing, not ideal, but an option

Issue 988

<inserted> Issue 988

Victor: json schema round trip

Issue 967

<inserted> Issue 967

issue with "type" property

Victor: problem with "compacting" property affordance
... fails to round-trip
... type in particular does not pick up the right definition
... something in the particulars of the syntax is causing a problem
... is this an expected behaviour, or a software bug?
... expectation is that when compacted again we just get "type", not a URL

DaveL: when you are doing this round-tripping, noticed
... that you defined terms so they are expected to be URLs
... so I'm wondering if you have defined a base URL

Victor: context file has bases defined, so it should be interpreting that as a term

<kaz> i|devel:|Context file|

DaveL: there is an inline context also... will have to look at this in more detail

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

Victor: the other round-tripping issue is of the same kind
... issue 933
... hard to find answer, so your help would be appreciated


<kaz> mm: (explains what wot discovery is like)


<inserted> PR 943

Ivan: can't give an answer on when the WG will be created...
... we are in the process of creating the minimum requirements, davel and I
... at this point, two algorithms known to sign linked data
... goal is to create a working group with two inputs, and reconcile
... core problem is normalization, and since security, has to be carefully checked
... one of the proposal is just mathematical
... other proposal is the other way around, there is an implementation, but math needs to be checked
... right now we are waiting for reviews

<victor> could you put links to these pubs here?

Ivan: if we have some proofs of correctness, THEN we can do a proposal for a WG

DaveL: I think we are close to getting some report from the mathematicians very soon
... so certainly can't refer to it in a normative fashion right now...
... and others have done that

Ivan: chartering process may not be a smooth ride... expect some objections

<inserted> [kaz: also agree we should be able to add a reference at least informatively]

Lagally: what about existing work, eg. JSON web signature?

Ivan: JSON web signature is JSON specific
... but they don't define normalization
... JSON-LD is more fluid, and the missing normalization is a problem

DaveL: that is a very long discussion... JOSE went in an opposite direction from JSON-LD, avoid normalization completely

Quick summary of other issues

<kaz> JSON-LD related issues for wot-discovery

McCool: main one in discovery are queries that can return partial results
... are these JSON-LD or not?


Sebastian: let's use the issue tracker, maybe follow up in Nov in a TD meeting

Joint meeting with the Web&Networks IG - 15 Oct 2020



Kaz_Ashimura, Michael_McCool, Li_Lin, Geun-Hyung_Kim, Hiroshi_Ota, Philippe_Le_Hegaret, Sudeep_Divakaran, Kunihiko_Toumur, Dominique_Hazael-Massieux, Piers_O'Hanlon, Jon_Devlin, Dan_Druta, Louay_Bassbouss, Daniel_Peintner, Jack_Dickinson, GeunHyung_Kim, Martin_Alvarez, Song_Xu, Cristiano_Aguzzi, Zoltan_Kis, Tomoaki_Mizushima, dezell, Kazumasa_Okabe

<McCool_> presentation at https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-joint-wot-wn

<scribe> Agenda: https://github.com/w3c/wot/issues/934


McCool: goes through the agenda topics on https://github.com/w3c/wot/issues/934

<scribe> scribenick: kaz


kaz for first part


WoT summary

<dom> https://www.w3.org/2020/10/TPAC/wot-update.html#talk

McCool: Goal and Use Cases
... work with the existing mechanisms
... shows the diagram of the WoT building blocks
... Current Work Items
... we're on the 2nd Charter
... updates and new topics
... discovery: how to get metadata for IoT purposes
... defined to be global, so not just for the local networks
... part of this includes directory service
... Thing Description
... based on JSON-LD
... work with external orgs like oneDM
... TD defines abstract data model
... New Work Items
... Discovery: 2-phase architecture
... define how TDs are distributed
... Other Activities
... implementation experience
... and Resources

<dom> Web&Networks intro

Sudeep: reusing the lightning talk video content
... introducing the Chairs
... three Chairs there
... Our Charter
... Mission: explore to leverage network capabilities
... ideas around application hints
... both wireless/wired segments included
... also want to focus on tools
... what kind of metrics to be used
... Our Tasks
... identify opportunities and use cases for network and application collaborations
... want to see any standardization effort could bridge the gaps
... for 3G, 4G, 5G networks
... incubation of new work
... and share the latest developments in networking SDOs
... wiki: https://www.w3.org/wiki/Networks
... Progress so far
... (diagram on the group's history)
... 2 work streams
... edge computing and net quality monitoring/prediction
... dig a bit more through the following slides
... Two Workstreams
... network quality monitoring and prediction
... our goal is predict network information from network infrastructure and operators
... roundtrip time, etc.
... and edge computing
... lot of new use cases there
... offloarding of devices
... a lot of factors to be considered
... regarding when to offloard, etc.
... discovery of edge devices and their capability
... Topics
... network quality monitoring
... network quality prediction
... offload to edge
... trace based network emulation in browser developer tools
... peer-to-peer eCDN &video cloud service
... Demos
... have a few demos here

<dom> https://www.w3.org/2020/10/TPAC/group-updates.html#webnetworks

Sudeep: Principles for Web & Networks solutions
... guarantee integrity of the data
... need to keep in mind
... guiding principles
... When something is such a creating medium as the web, the limits to it are our imagination.
... (by Tim)
... That's it from our side

Edge computing

McCool's slides

<dom> Subtopic: Compute Utilities

McCool: Problem: Limited Clients, Sensitive Data
... Trends and Pain points
... privacy and latency are the key problems
... edge computing is counter proposal for that
... would like to combine offload computing
... and also system orchestration
... Use Case Domains: Private
... Home vs Office
... think about private use cases
... robot which has computer vision
... offload to my own PC
... office has similar requirements
... private cloud and offloading
... Use Case Domains: Public
... Retail vs City
... access some service
... IoT devices to be connected
... payment data to be handled
... Smart City services include multi-vendor services
... important to handle privacy constraints
... Edge Compute/Web Hybrids Discussed in W&N
... edge worker
... extend Web Worker to offload work from browser to edge computer (Intel)
... extend Service Worker to execute computations in the CDN (CloudFlare)
... distributed browsers
... and mobile worker
... all need "another computer" to offload to
... common requirements for those approaches
... when to offload?
... Edge Worker
... task definition
... moving the task to another environment
... but looks the same
... workload definition onto something
... need to define some utility
... and do the offload to move the work load from one to another
... the other mechanism of mobile worker has similar ideas
... Key Issues for Standardization
... discovery of "compute utility"
... common service API for network too
... performance of the network and the utility is important
... metadata for the performance
... to make decision on offloading is worth doing
... Packaging/Runtime Choices
... container images
... containers allow GPU access
... Relationship to WoT
... discovery of "compute utility" o compute services
... can use WoT Discovery
... semantic/syntactic query available
... should satisfy the need
... but have to have network API
... can describe with WoT Thing Description
... however, still need metadata and metrics
... hard problem is defining the computing performance
... technically we could write it using JSON-based mechanisms
... Metadata
... metadata about capabilities, performance and resources
... also about network
... to determine QoS
... relationship between the client the node
... we could query the performance once we could have the offload mechanism
... need feasibility requirements as well
... challenge for the decide part
... application script on the client side
... want some automated rules
... parameterize the rules
... final issue on identifying whether trustworthy or not
... Metadata
... workload: network QoS, compute QoS
... compute utility
... network (LPP)
... need to have acceleration mechanism like Web GPU
... tricky part is performance
... I have some client and how to handle the offloading?
... compute utility handles memory size, accelerator technology, performance, etc.
... Offload Decision Rule
... feasible options exist
... users may or may not want offloading
... so would be useful to mention offloading would cost what
... prbably need some metric for workload
... Summary
... all proposals for edge computing so far need...
... a target to offload to with "good" properties relative to client
... need to decide whether or not offload would be beneficial
... decision requires metrics on performance, connectivity, etc.
... compute utility could be defined that...
... is discoverable
... has standardized network interface
... has standardized workload packaging
... next thing is discussion

Song: what about another short presentation on DNN?

McCool: maybe 5mins?

Kaz: please let us know about the URL of the resource too

Song: will do
... Overview of executing DNNs on the Mobile Web
... deep neural networks (DNNs)
... DNN execution schemes on the Web
... heavy model vs lightweight model
... Enabling Distributed DNNs for the Mobile Web Over Cloud, Edge and End Devices

McCool: compute utilities could handle DNNs
... some particular algorithm there
... could be advertised in some way
... you have some particular performance in mind
... there are lots of benefit there
... maybe DNN today but might be another workload possibly in the future

Song: I see

McCool: predefined workload also would be aligned
... but we're more interested in WoT Thing Description to be applied general purposes

Song: I see

McCool: maybe we need contract kind of mechanism
... how to best execute the job
... based on the legal requirements as well
... depending on the countries/states

Song: this idea was brought by BUBG

McCool: we can figure out the common elements from this proposal too

Sudeep: in the current context, the bigger problem is probably discovery and Thing Description for edge computing here
... let's discuss that point

McCool: yes
... let me go through the WoT Discovery quickly

wot discovery draft

specifically "4. Architecture"

McCool: compute utility can run other workload
... one of the possible mechanisms for discovery is extending DNS
... 3 options here
... JSONPath, XPath and SPARQL
... looking at syntactic search mainly and semantic search optionally
... JSONPath can search for content
... you can have some template for the search
... let's say your workload is some kind of FFT

Dan: your zero-trust assumption
... everything you're looking for could be public
... we need to make clear distinction
... things which the user owns
... vs not owns
... it should address the ability to state what the Thing is
... what is the incentive?
... use cases with local on my PC, that's fine
... for enterprise, would be similar
... but why we need to accept offloading dynamically/globally?
... how to accept?
... may be out of the scope but we should have better description

McCool: 3 cases here
... offload to your own thing
... or something managed by the ISP
... or random case
... for example, I have some account managed by OAuth
... give a token to compute
... the third case would be difficult to handle
... so would start with the first one and the second one

Dan: yeah
... but even the thing you own should require authentication

McCool: right
... authentication is definitely a requirement
... general problem with edge computing is how to trust the destination of offloading
... in long term, there would be some solution
... to guarantee privacy as well

Dan: tx

McCool: different level of trust would be needed here

Zoltan: is there any work on vocabulary for orchestration, etc.?


McCool: benchmarks have some examples
... prototypes for offloading

Zoltan: there is dependency for Thing Description

McCool: there is no perfect solution yet

Zoltan: would start with the existing solutions

McCool: we can look into what they do
... monitoring shutdown, etc.
... need PoC

Zoltan: minimal solution would be good

McCool: benefit for offloading should be significant

Zoltan: tx

Sudeep: quick comment
... when we talk about metadata
... is the metadata for compute utility static or dynamic?

McCool: we WoT also have a problem with geolocation information
... static metadata is easy
... maybe you can query the static metadata first
... and then query the diff for the dynamic data
... geolocation data changes from time to time
... probably you want to update the data periodically

Zoltan: you have support for dynamic range with multiple metrics

Sudeep: ok
... the decision on offloading could be handled by the application
... minimal thing to have

McCool: subscribe what to see

Sudeep: network api on changes there
... something similar would be useful

McCool: should think about what would be essential
... how to implement offload rules
... for discovery we have an implementation by Fraunhofer based on LinkSmart

Kaz: probably we should think about concrete use cases for edge computing including the viewpoint of how to deal with offloading

<McCool_> https://github.com/w3c/wot-usecases/pull/31

Kaz: I think how to subscribe data and how to manage history of data stream should be also considered there

McCool: right
... would like to explain how to deal with use case proposals
... GitHub repo and raise proposals using Pullrequests

Kaz: yeah
... probably we should continue the joint discussion with the WNIG guys
... probably during the WoT Use Cases calls

McCool: right
... that call occurs on Thursday at 7am US Eastern
... would schedule a followup call
... let's continue the discussion by email

Sudeep: ok
... we have to talk about metadata for computing too
... if you could provide the detail on the WoT Use Cases call, we could joint it

McCool: ok
... will provide information to you

Sudeep: sounds good


Day 3 - 20 Oct 2020



Andrea_Cimmino, Christian_Glomb, Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Farshid_Tavakolizadeh, Hazel_Kuok, Josh_O_Connor, Kaz_Ashimura, Kazuhiro_Hoya, Ken_Ogiso, Kunihiko_Toumura, Lynn_Li, Michael_Koster, Michael_Lagally, Michael_McCool, Takio_Yamaoka, Tetsushi_Matsuda, Tomoaki_Mizushima, Zoltan_Kis
McCool, Sebastian
mlagally, cris_, kaz


<kaz> Lagally, Cristiano, Kaz

<kaz> scribenick: mlagally


McCool: non members should be aware of the patent policy
... we have updated the agenda, will decide FPWD today.

<kaz> (Hoya-san from JBA, Yun_Li from Tencent , Yamaoka-san from Yahoo and Josh from W3C Team)

McCool: tomorrow's main call is cancelled

Joint call report

Kaz: discussion in MEIG and WebRTC group about testing environment created by ... project
... it would be nice to collaborate with them

McCool: please add to agenda of a future testing call
... probably first week of November
... We did other joint calls, follow-ups are in issue trackers
... for example APA follow-up, planning a meeting for Dec 9th.
... probably other follow up actions as well

<inserted> [Kaz has just added an entry for the future PlugFest/Testing call]

FPWD resolutions

McCool: there's a moratorium for publication starting tomorrow. We either decide today, or it will be pushed out to November

<kaz> Publication moratorium (Member-only)


Sebastian: We have 3 PRs, let's review
... issue 986 gets merged
... MR 989:
... I fixed a bug in example 8
... some other typos and formatting changes

<kaz> PR 989

Sebastian: MR was merged

<kaz> PR 993

Sebastian: MR: 993
... we need a tentative namespace until we have allocated a new one
... some discussions about the tentative namespace

<McCool> proposal: proceed with FPWD of the TD 1.1 editor's draft after merging PR 993

<McCool> proposal: proceed with FPWD of the TD 1.1 editor's draft after merging PR 993, with short name wot-thing-description11

RESOLUTION: proceed with FPWD of the TD 1.1 editor's draft after merging PR 993, with short name wot-thing-description11

<McCool> proposal: proceed with FPWD of the WoT Discovery editor's draft, with short name wot-discovery

<McCool> proposal: publish the FPWD of the WoT Discovery editor's draft, with short name wot-discovery

RESOLUTION: publish the FPWD of the WoT Discovery editor's draft, with short name wot-discovery

<McCool> proposal: publish the FPWD of the WoT Architecture 1.1 editor's draft, with short name wot-architecture11

RESOLUTION: publish the FPWD of the WoT Architecture 1.1 editor's draft, with short name wot-architecture11

<kaz> https://github.com/w3c/wot-profile

<McCool> proposal: publish the FPWD of the WoT Profile editor's draft, with short name wot-profile

RESOLUTION: publish the FPWD of the WoT Profile editor's draft, with short name wot-profile

Sebastian: we are good to go

Kaz: let's send out the transition request today


McCool: we have four presentations, let me do the overview

<inserted> Discovery overview slides

McCool: the draft of the discovery architecture is still very rough, please create issues or provide feedback in this session
... we are *prescribing* a new system
... this is like late binding
... support search based on content, geospatial search
... local and global context, not limited to local network, also peer to peer
... directories are special kind of things
... we have a two-phase concept, we don't want to ignore existing protocols but some have privacy/security issues
... we have a protected exploration mechanism
... first phase is "introduction", "exploration" is 2nd
... we want to make sure not to leak any information and protect data
... <mmc explains the diagram on slide 3>
... we look at various mechanisms to return URLs for introduction
... sometimes the link is typed, sometimes we don't know if the link points to a directory or to a thing

Lagally: difference between a TD and a directory?

Cristiano: we will look into standard ways to connect with directories with other protocols

McCool: please create an issue in the discovery TF repo

Zoltan: we standardize discovery because of security and privacy, otherwise it could be just an application

McCool: yes, it also belongs into architecture, since it is prescriptive
... we have some open issues, specifically wrt. geospatial data
... JSONPath is not a standard yet
... Federation, chained queries
... Lifecycle - we need to clarify / create diagrams
... registration needs some additional work

Sebastian: is geospatial query also considered in semantic search?

McCool: you could include geospatial info in TD and write a SPARQL query, which requires a full SPARQL impl.
... we want to support a simple filter implementation and not require full SPARQL
... need to discuss with other groups
... want to make it implementable by lower end impl.

Zoltan: How to handle multicast queries

McCool: directory would not respond to mDNS query ...

Zoltan: want to map to existing scripting API

McCool: in scripting you have some options to do dicovery
... the actual fetch is in the 2nd process
... we have to make sure to include privacy controls

Zoltan: we have provisioning for multicast discovery, need to do some mappings here

McCool: we never return a TD directly, always authenticate via a URL first

<7 mins break>

<kaz> scribenick: cris_

Introduction mechanisms

<kaz> WoT Discovery Introduction Mechanisms

Toumura: (shows outline)
... list of different introduction mechanisms: direct, well-known, DNS, CoRE and DID
... finally a discussion about security/privacy
... an introduction mechanism is to find an URL which points to a Thing Description or a Thing Directory
... accessing TD should be authenticated
... this mechanism does not define new protocols but uses the existing ones
... the content type of the resource pointed by the URL should be td json

McCool: there might have some cases where the authentication is not required, like public TDs. That's why it is not a MUST but a SHOULD
... well-known is used when you have to guess the real url, e.g., from an ip address

Sebastian: in the first part you are saying that you're looking for URL but then you require that the content-type should be a td-json
... are you looking for URL or TDs

McCool: first you looking for URL and then you have to a GET in this URL to retrieve a TD

Lagally: we could you TDDs to publish Thing Models, have you explore this possibility?

McCool: we have been considering it but it is not in the current draft

Toumura: so let's start with the first introduction mechanism. Direct method is really simple is every time you get URL. Like from QRs or Bluetooth
... beacon
... Well-known URI on the other hand is based on RFC 8615.
... the next one is DNS service discovery. We can use multicast DNS to discovery Things or TDDs
... we have defined DNS-SD service instance name in
... the format <instance>.<service>.<domain>
... currently we prescribe that service MUST be _wot._tcp or _wot._upd for things
... and _directory._sub._wot._tcp for TDDs
... when consumer resolve the service it can inspect the type field to know if it is a TDD or Thing
... another method is CoRe-RD which is a draft specification of IETF
... we have defined two endpoints type there.
... finally the last method is DID
... DID define a service where you could retrive a TD or access TDD
... about security some introduction mechanisms must be used in trusted environments. For example use private networks (i.e. VPNs etc.).
... Also TDs should be protected for example using OAuth

McCool: we can't trust introduction mechanisms
... we should recommend people not include any sensitive information
... i.e. use opaque URLs (i.e. not my.domain/this-is-my-wallet)
... in the end introduction methods are not safe

Kaz: do we need some encryption and/or abstraction mechanism for URLs and TDs, e.g., not directly using myHome/Living/AirConditioner as the URL

McCool: I have to do research on the topic
... for example tiny url is a pretty famous option
... another thing is that DNS have extra fields for metadata. I'd like to discourage to use them...
... like for example the type of a device
... we could even leave off the distinction between td or tdd, because we could later inspect the TD to know if it's a TDDs
... however knowing beforehand that it is a TDD could spare some time.

<hazel> left to join TPAC

Cristiano: in M-DNS does a TDDs answer the query with all the contained TDs?

McCool: just its Thing Description

Sebastian: another topic can we trust the received TDs from a discovery step?

McCool: we can always use mutual authentication
... or we could use signed TDs. We've been discussing that with LD-proof
... group
... however there're some technical challenges there.

Toumura: what about Verifiable Credentials?

McCool: we could use certificates in DID

Kaz: I think extending TD with a way of signing on would make sense given Verifiable Credential is data model with encryption for users' credential management and TD is a data model to handle Thing information.

Zoltan: is discovery meant for operational stage?

McCool: we need to include more discussion on use duing other staeges about the document. Right now we are describing more the operational stage
... another thing is the concept of a process able to discover Web Things and register things on a TDDs
... onboarding is more about giving the keys for registration than the actual registration process

Lagally: should the device be active when it is registered?

McCool: I think yes, because people would aspect to talk with the device when its discovered.

Lagally: I think it is just one use case but whole picture could be different

McCool: it is an open issue

Lagally: I am thinking of scenarios where the device is registered but not active
... we should not make assumption about the status of a device.

McCool: operational it means that it can talk to the network.

Farshid: we could also have different TDDs
... each one specialized to a specific status of a device (operational or not)

McCool: it is equivalent to have metadata on the TD

Lagally: what do you do when you have contradicting responses from different TDDs?

McCool: it should never happen if they are trusted directories.

Farshid: the consumer could already know which has operational TDs
... probably we are overthinking it.

Kaz: It sounds to me that we might want to add trustability, response time, etc., as possible evaluation features of TDDs for advanced directory services.

McCool: yeah great point please open an issue about this.
... time check, farshid should present Directory API

WoT Directory API

<inserted> WoT Directory API

Farshid: the api is composed by a set of sub api: registration, notification, search, and managment
... management is a wip.
... the api is described as a Thing Description
... (shows the TD in the discovery document)

McCool: technically this is a thing model

Farshid: right
... please try this thing model and provide feedback
... back to the API. basically is a typical RESTful API.
... a simple POST to /td creates an anonymous Thing Description record
... however you could do a PUT /td/{id} to create a TD with a specific id
... with PATCH you could use partial TDs to update the database record
... a GET operation on /td endpoint returns a list of all TDs. However, it requires further discussion. Big TDs are challenging... and probably will require pagination/streaming
... another solution is return just links, but it is too heavy to GET every one of them later
... we could also prevent the creation of big TDs
... another topic that needs to be discussed is streaming

Sebastian: I have several questions: on slide 4 do you have already in mind the payload type of the id returned in the POST ?

Farshid: it is returned in one specific header

Sebastian: what do you mean by streaming? is it a subscription on TD events?

Farshid: no it is about sending a big list of TDs

McCool: On slide 5, it is a pretty rare use case to ask for all the TDs.
... I do agree that big TDs are problematic, one simple solution is to limit TD size and return an error
... another problem is encode TD is small udp payloads

Farshid: regarding listing all TDs I think it is pretty usefull... like in UIs
... we have to look to json-line which is a protocol that let you read json line by line

McCool: HTTP/3 and QUIC are other interesting protocols

Ege: HTTP/3 is already a reality

Ege: 2.9% of internet traffic is already on HTTP/3

<kaz> Web Transport WG

Kaz: there's a proposed WG that would work on APIs for QUIC on QUIC

<kaz> W3C API

<McCool> ... also W3C Team provides API to access the W3C DB, and that includes pagination, for instance

Kaz: my third point is about the PATCH command within the proposed Registration API. how to deal with TD fragments is a little bit complicated, also PATCH is challenging
... how to extract the fragment is still under discussion right?

Farshid: we'll talk about that later
... partial TDs is just a part of TD

<McCool> (comment: diff format for changes could also be used for patching... needed anyway to delete things in PATCH...)

Farshid: in TDDs you can also subscribe for different events.

McCool: the diff could be also used to partial deletion of part of a TD
... about id, we have a local identifier different form the TD id

Sebastian: what kind of subprotocol do you have in mind for notifications?

Farshid: we are using SSE, but we have to add some feature on top of this
... for example old libraries did not support authorization

Daniel: slide 8 there's naming inconsistency, could you harmonize it?

Farshid: yeah there's a mistake
... finally, we have defined error responses. For now they are omitted because they need more discussion on the TD task
... there are still some open issues, for example usage of OAuth socpes for fine grained access control, Anonymous TD deduplication etc.

McCool: time check, we have 40 minutes left. let's do a short break (5 minutes) and start again.

<kaz> [5min break till 10:23 EDT ]

<FarshidT_> I just checked, it wasn't a mistake. "updated_td" is the event type. "td_updates" is the field inside the event object that is set to the td diff. We can try to harmonize if it is unclear.

<kaz> scribenick: kaz

Syntactic Queries

Syntactic Queries

Andrea: Discovery in a nutshell
... JSONPath syntactic discovery API example
... sample TD on the left side
... app-TDD sequence diagram on the right side
... query from application
... and answer from the TDD
... XPath syntactic discovery API example
... this time the query is XPath
... and the answer is array of strings
... including TD fragments
... Example syntactic discovery queries
... JSONPath vs XPath
... Pros and Cons
... Pros
... both JSON Path and XPath are short and expressive
... passed as URL query parameters
... XPath is a standard

McCool: comparison between JSONPath and XPath
... JSONPath is more directly fits JavaScript

Cristiano: yeah
... Conclusion
... JSONPath must, XPath should
... array of TDs and array of TD fragments
... privacy & security

Andrea: could we use combination of conditions?

Cristiano: yes, like this (on p12)
... combination of title and created date

Andrea: what about searching for all the gateways?

Farshid: maybe using created dates?
... but we need to wait until JSONPath becomes a standard

<FarshidT_> slides: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-online-f2f

<Zakim> dape, you wanted to fallback if JSONPath never becomes a standard?

<FarshidT_> jsonpath draft: https://tools.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html (S. Gössner is the original author)


<McCool> ... ah yeah, the month is wrong ;)

<McCool> ... will have to fix that

<dape> https://www.w3.org/TR/xpath-functions-31/#json

<FarshidT_> Let's talk about IETF standardization of JSONPath: https://github.com/cburgmer/json-path-comparison/issues/70

Sebastian: what about the standardization for JSONPath within W3C?

Kaz: I thought Ivan mentioned there was a plan for standardization during the joint meeting the other day
... so we need to wait for that (for the normative reference)
... meanwhile we can add a reference as an informative reference

<FarshidT_> @kaz I don't get it. The slides are here: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-online-f2f Where did you get that URL?

<McCool> ... right, but the day should be 20, not 07, so it sorts correctly...

<McCool> ... I will fix

McCool: note that we do need a normative reference based on a concrete specification at some point

Semantic Discovery Search


Andrea: TDD and discovery
... SPARQL semantic discovery API

@@@syntactic/semantic queries are presented by Andrea

Andrea: SPARQL semantic discovery API exmple
... SPARQL queries examples: SELECT
... SPARQL queries examples: ASK
... SPARQL queries examples: DESCRIBE
... SPARQL queries examples: CONSTRUCT

McCool: one possible use cases is having multiple lights
... analysis of content needed

Andrea: that can be handled
... then Advanced SPARQL queries
... more interesting part :)
... SPARQL allows query federation
... TDD forwards the query to other TDDs
... former TDD returns a unified query answer
... Pros: allow extending discovery criterion to other TDDs easily and extends the discovery scope
... Cons: TDDs addresses must be know beforehand, also brute force forwarding
... example
... assuming 100 TDD services here
... put under "VALUES ?tdd" section
... Pros and Cons of SPARQL
... Pros: expressive and it originally has query capability, also a W3C standard
... Cons: possibly verbose than JSONPath/Xpath, consumes more resources, also complex (than JSONPath/XPath)

McCool: given we just have 2 more mins, the details to be discussed during the discovery calls
... federation definitely needs some more discussion
... note that there will be no Discovery call next week on Oct 26
... please create GitHub issues for the discussion

Sebastian: are there any implementations other than LinkSmart?
... e.g., SPARQL-based one?

Andrea: planning to release one

McCool: having a SPARQL end point would be great
... btw, does LinkSmart have semantic query capability?

Farshid: no

McCool: need a second implementation then
... also we need some converter from semantic query to DNS-based discovery services


McCool: tomorrow we'll talk about TD

[Day 3 adjourned]

Day 4 - 21 Oct 2020



Kaz_Ashimura, Michael_Koster, Sebastian_Kaebisch, Taki_Kamiya, Takio_Yamaoka, plh, Geun-Hyung_Kim, Kazuhiro_Hoya, Philippe_Le_Hegaret, Daniel_Peintner, Kunihiko_Toumura, Cristiano_Aguzzi, Geunhyung_Kim, Zoltan_Kis, Tomoaki_Mizushima, Ege_Korkan, Ken_Ogiso, Li_Lin, Michael_Lagally, Michael_McCool, Tetsushi_Matsuda, David_Ezell, Kevin_Olotu, Rachel_Yager, Lynn_Li, Jack_Dickinson, Ryuichi_Matsukura
Sebastian, McCool
kaz, zkis, Ege, cris

<inserted> scribenick: kaz


Philippe_Le_Hegaret from W3C Team, Geun-Hyung_Kim from Gooroomee, Li_Lin from China Mobile and Takio_Yamaoka from Yahoo Japan

Sebastian: please be aware of the W3C Patent Policy


1. Zoltan

2. Ege

<zkis> scribenick: zkis

<kaz> 3. Cristiano


Sebastian: editors, please check the documents, ReSpec errors, links, references
... please point to the new drafts that are going to be released
... deadline: this week


Sebastian: some web meetings were cancelled, please check the wiki
... next week we have the breakout session

McCool: usually we also keep a break after F2F

Thing Description Session

Sebastian: overview of the day
... what is new in TD 1.1
... then Daniel gives a summary on dynamic TD
... then, the Thing Model is one of the major topics today
... then, Component approach for TD, by Taki
... Finally, System Description by Ege

What's new in TD 1.1

<inserted> slides

Sebastian: we use some new terms in TD and TD model
... we now have the 'multipleOf' term, coming from JSON Schema
... IntegerSchema and StringSchema extended
... DataSchema also has new terms, for encoding and media type
... also, SecurityScheme was improved
... so why having contentMediaType and contentEncoding: if we have some JSON doc and also some image files as JSON elements
... to point out that, we could use the new keywords (represented in base64 for JSON)
... then, mapping of DataSchema to content types has been improved
... the list is just a direct overview, but TD does not restrict other content types
... The new ComboSecurityScheme

McCool: currently we can combine schemes with AND, while OpenAPI does that with OR, so this Combo was needed to support both AND and OR.
... also, avoids redundancy of having to repeat schemes

Sebastian: 2 more OAuth flows are supported

McCool: discussed tomorrow

Sebastian: location based annotations also supported
... see 7.1.3 Example in the spec
... we can define position as object property, based on geo base context, long/lat/elevation
... also other geo ontologies can be used
... also new is that we moved the Thing Model (TD Template formerly) to the main body
... with explanation about the differences
... we will discuss that later
... we have "at type" i.e. @type: "ThingModel"

<mjk> Is the "ThingModel" value a URI or is it a plain string?

Sebastian: So that's been a quick overview.

Kaz: will you upload the pres?

Sebastian: yes, as usual

Dynamic TD discussion, by Daniel

<inserted> slides

Daniel: a short overview in 2 slides
... not only about dynamic TDs, but also on how to manage dynamic resources
... we have an issue that discusses this

<inserted> wot-thing-description Issue 899

Daniel: check TD issue#899 [link]
... we want to be able to query the state of the interaction
... currently the TD has no mechanism to describe this
... TDs could change, and one can track or cancel with an action
... another approach would be to have a static TD, i.e. remains the same but defines all resources
... for instance, to append to an action, you need to do this or that
... we investigated during the last plugfest and turned out to be complex
... a lot of security issues as well, breaking hashing and signing
... also, the TD can be hosted not only on the Thing
... this would break with dynamic TDs
... also, clients need to update TDs regularly, the consumer should always track the TD changes etc
... we found out we didn't feel comfortable with either dynamic or static TD solutions
... so far the process seems to be stalled
... this is an ongoing discussion
... we will continue the discussion in the issue

Lagally: were these approaches implying new vocabularies?

Daniel: yes
... we need to express that one resource is meant for canceling another, etc

<mjk> q

Lagally: if we take the TD as today, is there a guideline or design pattern we could use for solving these use cases?

Daniel: we didn't decide yet which way to go
... it is a new area, it is complex, there was work done, also on IETF side, Matthias was opposing since out of scope

Ege: Matthias' proposal was to prescribe how to do this, since no standards can be used
... we would not exclude anyone by prescribing this

Lagally: this has relevance to profiles

Ege: in a profile we could constrain how a TD should look like, so we count describe this
... profiles are meant to be prescriptive, so this would be possible

Daniel: we should talk to Klaus Hartke for advice

Lagally: we should take it on the Profile discussion's agenda and get the relevant people in the discussion

Sebastian: would it make sense to consider this as a sub-protocol?
... since it's hard to describe with one TD
... both client and server are involved, so it's a protocol

<mjk> +1 sub-protocol approach

Lagally: I'd think it's not a protocol, but a semantic behavior of certain operations
... that depends on the model of the actions

<mjk> hypermedia is a sub-protocol

<taki> +q

Daniel: if we want a solution, it's more likely to be a static one, because the security implications

<mjk> several schemes to support hypermedia controls need to be supported

Lagally: agree with that

Ege: there was some value in dynamic TD's to take parts of the TD, send back a part as response
... so we don't need to register that small part anywhere
... it could be used in a sub-protocol if we prescribed that payloads would look like that
... like the response is a JSON object
... status is "time left" etc

<mjk> +1 zkis yes as a hyperemedia sub-protocol

Ege: then this starts to become sub-protocol

<mjk> CoAP has a way to do it, http has a way to do it, and it can be mapped to others

Lagally: should we talk about sub-protocols? not sure if it's the right way

McCool: we could use templates with static definition
... we could check how OpenAPI does it

Sebastian: they don't have it

<mjk> yes openAPI doesn't support hypermedia controls

Ege: they do have solutions

Daniel: today's discussion is similar to what happened in the issue
... we cannot really agree yet

McCool: we should have a set of well defined proposals and then decide

Daniel: we do have proposals, linked from the issue
... Victor, Ege, mixes
... but this is not concluded yet

Kaz: we should clarify the actual use cases and use case scenarios for the needs of dynamic TDs
... this point is related to discovery as well
... both should be tied to use cases

Sebastian: we have 2 use cases, one from Oracle, another from Mozilla WebThings

Kaz: those are implementation examples, but I mean we should clarify concrete description on use cases and requirements (possible based on those implementations, though), with what data, how to distributed, etc

KOSTER: I agree with that.
... we might look at it from a different angle. Neither OpenApi nor TD support hypermedia
... HTTP and CoAP use query parameters, a kind of hypermedia system
... what's missing from hypermedia systems is good semantic affordance
... we should consider supporting hypermedia patterns in the TD
... this may qualify us as sub-protocol
... the underlying system needs to support a hypermedia state machine
... as Sebastian also told

Ege: there are patterns, but no standards people agree on

KOSTER: that's what we try to do
... we should spec a static TD that could also handle a dynamic interaction

Daniel: we have worked out the hypermedia proposal and also the other one

Taki: the dynamic TD means complexity
... we should not create very complex TDs
... we should create some note on how to avoid making it complex

Daniel: good points, the 2 proposals say we are shifting complexity from server to client, or vice versa

Cristiano: the hybrid approach seems more promising (static TD with dynamic parts)

<mjk> client complexity as needed - argues for the hypermedia sub-protocol approach

Cristiano: why don't we return a TD that represents a virtual temporary action?
... also from Scripting pov clients just consume whatever is returned

Daniel: agree

McCool: this is similar to a previous discussion about ongoing actions
... we have a privacy issue: if someone can observe TD changes
... extra care falls on directories to track who can know what
... it becomes very hard to maintain privacy

<mjk> whether to include the TD element as a part of the static TD vs. emit it each time is a design question

Daniel: this was another level of complexity

McCool: it could be a token based design

Daniel: I'd disagree, e.g. in a factory, tokens should not be bound to persons, but roles

McCool: we could adapt the mechanism
... then, we already have a mechanism to support TD updates in Thing Directory

<mjk> whether the generated address/thing is private or public is a design choice

McCool: complexity also manifests in the extra load on the network
... every subscription adds complexity

<Ege> summary for hypermedia in OpenAPI: https://github.com/OAI/OpenAPI-Specification/issues/577

McCool: I strongly prefer the static approach.

<mjk> depends on the use case and underlying system, e.g. we could map to a dynamically created public MQTT topic as a particular sub-protocol

Sebastian: the next steps are a bit fuzzy
... ML mentioned this could be further discussed in the Profiles call?

Lagally: yes, it could belong there if we could make a solution

<mjk> profile is definitely a good place due to lack of a universal pattern

<mjk> e.g. special support is needed

Ege: if we want a TD for Thing Directory, we must solve this problem

<mjk> +1 this is also a discovery issue

Ege: we could reuse an ID to query
... this is what hypermedia tries to do

<Ege> https://swagger.io/docs/specification/links/

<kaz> (yeah, that's why I mentioned this topic is related to Discovery and we need to clarify the use case scenario including that viewpoint as well)

Ege: also in OpenAPI

McCool: we don't want to update the Thing Directory TD
... so we prefer the static approach

Lagally: what could be the starting use case?

Sebastian: let's postpone this discussion.
... let's continue in the Profile call.

<mjk> The use case is a static TD for the Thing Directory that supports hypermedia controls

Lagally: makes sense.

Sebastian: 7 mins break

<kaz> (and use case call collaboratively, I'd suggest)

<kaz> [ reconvene in 7 mins; 5 mins past the hour ]

Thing Model

<Ege> ack

<kaz> scribenick: Ege

Sebastian: Thing Model was called TD Templates in TD1.0
... what is TM needed for in the first place?
... We can onboard models into a system, we can simulate Things before developing them
... to reuse parts of models so that you don't define it again
... another way to look at it is to instantiate TD instances from TM
... this is relevant for deployment scenarios
... you can write the affordances, put string templates and then replace them with instance information during deployment
... now I will talk about how we can combine different models
... we should use existing solutions, examples are from JSON Schema, JSON-LD and SDF

<mjk> $ref uses json-pointer

Sebastian: we can also use the ids for TMs to use as import mechanism
... JSON Schema has the name clash problem

<mjk> it's "sdfRef" for references

Koster: we use JSON Pointers as the value of the reference and we use sdfRef instead of $ref

<mjk> the way we use json-pointer avoids name conflicts in oneDM

McCool: the components discussion is coming up, we can maybe define a mechanism with the components and also use it here

<mjk> in SDF, every reference is a unique URI consisting of a namespace and a unique json-pointer

<kaz> kaz: would agree with McCool basically, and suggest we start with JSON-LD approach as the basic one given TD is a kind of JSON-LD, and we can think about the other approaches like JSON Schema and JSON Pointer. And for that purpose, we should elaborate concrete use cases for the two basic categories, (1) standalone usage and (2) template usage based on people's need and interest. For example, in which case and time/location, we need which capability and notation for what kind of devices, etc.

<McCool> (also my main point was that @context used inside an object overrides definitions in enclosing object... which I think is what we want, especially if "components" are handled in sub-objects)

Cristiano: Using $ref would give the impression that TD is a JSON Schema

Sebastian: sort of, we would just use the vocabulary but not the mechanism entirely

<mjk> we decided to create sdfRef as a way to avoid confusion about the side effects, etc.

<mjk> json-pointer can be used to point to a part of a TD

Sebastian: the problem with @context is that you don't know what is used from the context, maybe nothing is used, maybe it is inserted accidentally

<mjk> +1 what sebastian just said

<mjk> we can point to what we need in a TD


Ege: OpenAPI also uses the $ref and not only for schemas

Sebastian: so now let's see an example for combining

Ege: what about a processing the models and letting the processor handle name clashes

Sebastian: so you mean that the processor would deal with this on its own

Lagally: we should think of the data model first, this diagram is a bit complex

<mjk> we need some structure in the composed thing ...

Lagally: I don't know if we have the requirement of handling combinations of thing models into a new model

<mjk> in SDF and iotschema, there are separate "capabilities"/"objects" that keep the conflicting names in separate paths

Kaz: I agree with ml. Do we have this requirement for a concrete use case?

<mjk> +1 sebastian we can review current art in the industry including zigbee/CHIP, OCF, OMA and others which are all composed models

<inserted> kaz: seems to me a bit too complicated to have this inheritance capability. would see concrete use case for this if we really need this capability

Cristiano: I agree with kaz
... Also problematic when we think of template strings in a TM, what if there are name clashes there?

McCool: We should define the use cases and make sure that simple cases are simple and focus on those

Koster: I agree. You can do components in a TD, put the models in there and then handle the name clashes via paths which will be different

<McCool> (I also said I feel strongly we should solve this as part of dealing with components, and resolve conflicts (if there are any) by having a clear priority order (so you always know which import overrides other imports))

Sebastian: So I will note this. Most seem to be interested in the simple case
... It would be nice to have more examples. Oracle and Eclipse Vorto?

kevin: Yes I can bring generic models for the discussion

<kaz> [5min break]

Thing Description components

<inserted> scribenick: cris

<inserted> scribenick: cris

Taki: recently, in the TD we discussed about how to define components. This is related to the previous topic about Thing Model
... I have a couple of slides to discuss
... but if somebody else wants to show something please feel free

Ege: I have some slides about the topic

Taki: mccool do you want to show something?

McCool: I don't have any, but I think that oneDM is a good candidate for this task

Taki: I just want to give a context about this issue
... everything starts from our charter document
... for example link relation types are mentioned in the document

<Mizushima> --> https://www.w3.org/WoT/IG/wiki/images/6/6f/2020-10-21_TD_mechanisms_for_components.pdf thing description components

Taki: composition is a relationship type that should be discussed. Another one is the "controlBy" relationship
... we discussed a lot about how to define relationships between TDs
... slide two gives a little summary about what we are discussing.
... we can use UML Associations as a staring point
... I think we should start from UML composition when talking about TD components
... in Munich Benjamin described a car represented with different TD. Using only one TD would be really messy (i.e. the TD will be huge)

<kaz> wot-thing-description Issue 168

Taki: issue 168 is relevant to the composition discussion. It offers an use case and an example about how to do composition using inheritance

<Ege> https://swagger.io/docs/specification/components/ is also related maybe?

Taki: issue 958 is more recent and talks about components

Ege: I am not sure if the components are separated files or just declarations inside TDs

Taki: the proposal in 958 seems to have all the definition inside one single file. I think we could discuss where components are defined later. It depends also from the use case

McCool: I think the main issue is to spit big api definitions in smaller components
... the car may not be the best example for components use case.

Taki: about WoT Directory is more to categorize apis in sub parts.

<mjk> q

McCool: we need an hericacl way to access different APIs. Scripting could leverage on that. Probably, component word is misleading ... module would be better
... I'd like to have still one single thing but divided in sub parts
... namespaces would avoid name clashes. I think OneDM do the same

Koster: exactly

McCool: anyway I think the example shown in slide 5 satisfy the use-case from WoT Thing Directory
... I think model implementation is orthogonal to this issue

Kaz: we are talking about two issues: in 168 should be handled in the TM discussion. The 958 this is reminded me speech interface. However this approach failed. w3c used another approach in the end, e.g., Multimodal Architecture, to integrate multiple devices and applications and SCXML is the key spec to control the state machine for multiple components

McCool: I agree that inheritance is another issue

Kaz: right

Koster: in OneDM we have semantic bread-crumbs

Taki: are flat models similar to semantic bread-crumbs?

Koster: it is similar to what you are showing in slide 5
... sdfRef is exactly the link to the Television TD Model
... client can use the component knowing that it is a Television easly.
... we also use this feature at orchestration level.

McCool: this implies that the scripting api should know about this model

Koster: they just need to expose it to applications

McCool: scripts could align this component model too

Taki: time check. we can switch to Ege's presentation

Ege: ok for me

System descriptions

Ege: we are focusing on mashups and how to represent them
... we started from a simple use case. Consume different things and then expose them as an a new aggregate thing
... we could do this in different ways. Scripting api is the more natural way
... node-red is a visual apprach
... mash ups are not really portable as node scripts
... code and node-red flow might be complex to read and understand
... also we can't formally verify and visualize the behavior
... however in industrial automations we have formal ways to describe behaviors
... like sequence diagrams
... so we started from sequence diagrams to describe WoT systems
... than we evolved it to a specilize thing description format
... it is called System Description
... from a SD you can generate code
... this work has been published recently
... (shows an example of WoT sequence diagram)
... from this sequence diagram we can generate a SD
... we have defined JSONLD context and the ontology as well
... (shows a SD example)
... we this simple SD we could describe the whole logic of a mashup
... In the paper we explained a scenario taken from one of our PlugFest
... the most interesting is about smart home scenario
... we defined also more a complex scenario. Like controlling a robot arm and different sensors

Lagally: this is really interesting application. I really liked it. How do you handle the parallel execution described in slide 10?

Ege: so this means that you can execute the block in any order

Lagally: it think this could raise some problems due to non-deterministic behavior
... the system description could be used to implement simulations. Did you think about it?

Ege: yes we are working on it. We also working on how to verify that the system is behaving as described

<taki> +q

<kaz> MMI Interoperability Test Report

<McCool> (comment: par just reflects the reality that these things *might* be running on different processes(ers), so it may be unavoidable)

Kaz: thank you really much. 8 years ago w3c was working on the same topic. I just linked an implementation report document
... might be interesting

Ege: I used it sometime ago. it is pretty similar to what we have done

Kaz: thinking about concrete requirements should be in this context

Taki: I'd like to know more on this topic. also about the component part

Sebastian: thank you everybody

<Zakim> kaz, you wanted to ask about scripting note publication

<kaz> kaz: given we're out of time, let's talk about that tomorrow :)

<kaz> [adjourned]

Day 5 - 22 Oct 2020



Kaz_Ashimura, Michael_McCool, Cristiano_Aguzzi, Daniel_Peintner, Kunihiko_Toumura, Li_Lin, Michael_Koster, Michael_Lagally, Sebastian_Kaebisch, Takio_Yamaoka, Ege_Korkan, Tomoaki_Mizushima, Ken_Ogiso, Zoltan_Kis, Kazuhiro_Hoya, Ryuichi_Matsukura, David_Ezel, David_Ezell, Akira_Kikuchi
McCool, Sebastian
sebastian, dape, kaz


<kaz> 1. Sebastian

<kaz> 2. Daniel

<kaz> 3. Kaz


<inserted> scribenick: sebastian

MM shows agenda for today


<inserted> Oct-22 Agenda

McCool: about cancellations of TF meetings next week

Daniel: not sure about Scriting call on Monday. I will ask Zoltan.

McCool: all cancelled calls are listed at the main wiki page


there is no Scripting call!

no architecture

no TD


<McCool> https://www.w3.org/2020/10/TPAC/breakout-schedule.html

McCool: lets talk about the break session next week
... overview is given here


MM gives an overview which are interesting like GeoSpatial, Connected Vehicle Interface, etc.

McCool: we need to request the slot for Tuesday, 22:00 UTC (=15:00 PDT, 18:00 EDT, 19:00 ADT, 23:00 CET, 07:00+1d JST)
... please let me know if you like to join
... as well if you have a presentation
... we use same slot as discovery TF call. We can use the same logistics

WoT Scripting

<inserted> Slides

<inserted> Scripting API draft

Zoltan: we have updated ReSpec
... we discontinued writeAllProperties()
... solved the issue with DataSchema with TD TF
... support for formIndex
... introduction of InteractionData
... improve some algorithms
... about DataSchema vs Form: script can select a Form by providing the formIndexing.
... however, if this fails, the communication fails

<Zakim> kaz, you wanted to mention actually EU summer time ends this weekend and the time will be *one hour earlier* in Europe

<kaz> @@to be moved

Kaz: Note: Next week there will be a time shift.

Zoltan: <shows current API>
... we have arrayBuffer, check data schema algorithm
... there is an explanation about InteractionInput and InteractionOutput
... we have also error handling
... we have improved the event handling
... <shows example about ExposedThing, Example 6 in API Spec>
... <shows the feature of expose() method>
... like to show about the status of the Discovery API

McCool: We have a constrain here regarding privacy

Zoltan: this is a face two API

<kaz> present David_Ezel

Zoltan: Promise can be fetchable and streamable
... as next we like to talk about script management, provisioning, and runtime
... we are going to creat a Note and continue the work

Cristiano: I have a comment about the docker container. I did this for RasPi and works good

McCool: what happen when we pass semantic filtering, however, semanitc search is optional?

<kaz> 9. The ThingDiscovery interface

Cristiano: Maybe we need a script manifest

McCool: We need also privacy consideration

Zoltan: we should consider that we are in IoT environment which needs provision for some actions
... have not discussed yet, if wot can run in a shared worker

Sebastian: wondering if we should discover Thing Models

McCool: question about if there is a link that says that the Thing have implemented a TM
... second question is if I have to check what is implemented of the model
... we need to save TM also in thing directory

Zoltan: I can also search for a model and result fill out the placeholder

<inserted> kaz: technically, TD and TM are different features and there should be some different requirements on how to handle them, so we should clarify what is needed for which with concrete sequence description based on some concrete use case.

McCool: we should explain use cases about this

Daniel: how about the semantic API. Is this done on the top of the current API?

McCool: Can we do a sparql seach yet?

Koster: I did some experience on this few years ago. Mainly you need JSON pointer for this.

<Zakim> kaz, you wanted to ask about the resolution for Scripting API Note publication

Kaz: shall we do resoultion today?

Zoltan: yes

<cris> just want to say that I think 90% of the time devs will use TM models at dev time not at a runtime. I agree that first we need to clarify better runtime use cases.

<McCool> proposal: publish the current editor's draft of the WoT Scripting API as an updated note

RESOLUTION: publish the current editor's draft of the WoT Scripting API as an updated note


<Mizushima> +1

Zoltan: thanks to Cris
... note I'll have less time in the future..


<cris> thank you everybody for the opportunity :)

<kaz> [10min break]

<dape> scribeNick: dape

Security - Overview

<inserted> Slides

McCool: Session going over "smallish" things
... merged & deferred PRs
... Subtopic 1: Combo scheme
... marked as "at risk" feature
... use-case: "OR" combinations
... avoids repeated notations by using AND and OR
... nesting of AND and OR is also possible
... 2 level nesting sufficient?
... AND -> allOf combinations
... OR -> oneOf combination
... Subtopic 2: Simplifying inline security definitions were deferred
... PR exists that allows string or inline security definition
... breaks validation -> Deffered to 2.0 version
... Subtopic 3: Signing TDs and LD-PROOFS
... needs canonical form of TD
... no formal definition exists yet
... JSON-LD is working on it
... in the phase of checking the proofs
... DID also waits for this feature
... plain JWS signing works in most cases but fails for RDF-based directory service
... hence we will wait for it

Kaz: Q: How to handle order/preference of combo scheme?

McCool: no preference for allOf
... oneOf has choice
... first form order preference?
... consumer can pick though

<inserted> kaz: if there is some expectation/assumption, we should describe that within the spec

Cristiano: In scripting we added formIndex... we might add securityIndex also

McCool: agree
... preference for "highest" security might be another solution

<Ege> I will be muting the incoming audio since I need to listen to another meeting. Please ping me here if I am needed :)

Security - OAuth2

<Zakim> kaz, you wanted to ask about the order/preference for combo setting

<kaz> Slides

Cristiano: OAuth 2.0
... authorization protocol
... based on HTTPS
... 4 different entries: client, auth server, resource server, resource owner
... (a) auth request -> (b) auth request -> ...
... OAuth 2.0 scopes: limits application access to user account
... scopes are simple string identifiers
... e.g., consent screen
... is OAuth2 nice fit for WoT?
... I think so
... 4 flows: code, implicit. resource owner, client credentials, and extension flows
... "implicit" and "resource owner" flow are no longer recommended
... 3 flows left
... Code flow
... resource owner -> client -> user agent -> auth serveer -> user agent -> owner approves -> client
... client -> auth server -> access resource
... Example: dashboard application accessing washing machine
... Another Example: dashboard application accessing TD directory

McCool: another use case is smart city

Cristiano: Device flow
... basically code flow with limited input devices
... if device is not able to prompt

<Ege> false alarm, I will be here all the time :)

Cristiano: client -> auth server -> request code & url -> code displayed to owner (open how this is done) ->
... cient polls for access token -> owner adds code to user agent
... "clicked" OK --> client get access token
... with token it can access resource
... Example: Smart radio and WoT speakers
... Client flow
... no resource owner or user agent (outside)
... client > id -> auth server -> access token
... Scenario: Application talking to washing machine
... Scenario: City opening sensor access to people
... Open points
... * provide examples how to use deprecated flows
... * multiple Oauth 2.0 flows in security definitions: issue#929 (@@@add URL)
... * address implementations variability (MS service access token in header/url), issue#923
... * node-wot implementation supports 2 flows only. Code and device flow is missing. see issue#325

McCool: we need 2 implementations. Directory might be 2nd implementation

Cristiano/McCool: humans in the loop are difficult to handle

Cristiano: * WoT scripts handle OAuth 2.0 code gracefully, scripting issue#214

Kaz: concrete settings would be nice when talking about code flow device flow

Cristiano: thing directory work might be useful here

McCool: OAuth use case is written up also

Kaz: Concrete settings might lower the barriers for other people

Cristiano: PDF is uploaded

Kaz: slides url is added to minutes also

<kaz> [8min break till 5min past the hour]

<kaz> scribenick: kaz

PlugFest report out

McCool: no presentation slides for this
... would like to gather materials from people

outcome issues

McCool: would ask people for resources and have discussion during the usual Discovery slot on Monday, Oct 26
... anyway let's go through the outcome issues
... various things marked with "Plugfest Outcome" label
... would collect materials like presentations and video for each outcome issue

Issue 92

McCool: got Cristiano's materials
... and would get NHK's one as well
... 3-5 mins for each
... Cristiano's one is related to "Farm/TUM mashup: display sprinkler status"
... would have three more listed there
... e.g., collaboration between coffee machine and TV

Issue 64

McCool: Issue on discovery
... Toumura-san, any resources?

Toumura-san's slides

Toumura: how to integrate Things and Node-RED

McCool: cool
... can download the PPTX version as well
... it's nice this can integrate Node-RED with catalogue service
... (shows the animation embedded in the PPTX on Node-RED programming)
... this is related to the use cases for retails proposed by David Ezell
... great result
... then next issue

<cris> really cool indeed

Issue 76

McCool: visualization in maps
... the prototype doesn't work now

Geolocation of WoT Things proto

Kaz: why don't we ask Daniel for help?

Daniel: some security issue there
... but can provide some screenshot

McCool: ok
... (shows Intel's location example)


McCool: device is installed at some geolocation
... a couple of scenario to handle it


McCool: (shows the 2nd example)
... position by longitude, latitude, accuracy and accuracyUnit
... also timestamp
... yet another system


McCool: (shows another example of camera)
... and then NHK

NHK's example

McCool: interesting mash-up including TV
... this is an accessibility use case

Kaz: NHK is not here, so I'll ask them about their video and also ask them to join the Monday call for prep

McCool: yeah, let's follow them up by email
... we can discuss the detail on Monday
... all, please provide links for your materials for Issue 92

Issue 92


Draft WoT Welcome page

Daniel: want to show you the recent updates
... easily identify the three groups: WG, IG, CG
... some more links to be added
... got comments from Lagally

(and Kaz :)

Daniel: recent proposal to add TF information
... but maybe would be better to add a section/page on "WoT activities" including all the TFs
... developer tools page lists information related to implementations
... would not stop the improvement though there are several remaining issues
... existing issues from Ege, Kaz, etc.

McCool: agree we should not block the improvement
... would be nicer to make the TFs more visible
... TFs belong to WG or IG
... so would be nicer to make the activities more visible

Kaz: agree
... probably having 2 directions, top-down and bottom-up, would make sense
... meaning (1) the current page which describes 3 groups which have various TFs and (2) activity page which describes all the TFs which belong to 3 groups

Lagally: this page is for alignment of the activity
... for people to see what W3C WoT is doing
... showing top level work and also actual activity would be important

Daniel: will generate a PR for improvement

Lagally: btw, how to handle the PlugFest work?

McCool: PlugFest should be put under the activity

Kaz: and describing which activity is handled by which TF would be useful

Lagally: what is described in the WG page, for example?

Daniel: currently quite simple
... but we can add contents

McCool: note that there are several joint TFs

Cristiano: agree we need to focus on the activities more
... just wondering about the WoT log

Daniel: we can generate a new one if needed

<McCool> proposal: accepted inverted colors as an official version of the WoT logo

<McCool> proposal: accept inverted colors as an official version of the WoT logo (e.g. for a menu bar)

<McCool> proposal: accept inverted colors as an official version of the WoT logo (e.g. for a menu or title bar)

slides Including a WoT logo

Kaz: I'm ok with any improvement with the WoT log, but we need to add the W3C logo on the left side of this WoT logo

<inserted> kaz: that point is included in my issue 84 https://github.com/w3c/wot-marketing/issues/84

<McCool> I was suggesting in the upper right corner, on the white, but below the title bar; note there is no inverted form of the W3C logo, either...

Sebastian: possibly an animation version of the logo?

<cris> http://arces143100.arces.unibo.it/

<cris> https://twitter.com/relucri/status/1319278759627739136/photo/1

Kaz: I'm personally ok with any versions, but we should check with the Accessibility guys and the MarComm Team if we want to use another version of the WoT logo

McCool: next, I'd like to show you the draft animation video
... (shows the animation video)
... some voice over available

Breakout planning

McCool: will have prep discussion during the Discovery slot on Monday, Oct 26
... will send an invite

Architecture call?

Lagally: cancelled today

Spec checks

Sebastian: yesterday, I asked all the Editors to check the ReSpec issues, etc.
... please double check your documents
... the deadline is tomorrow, Oct 23

McCool: anything else?

<Ege> https://stackoverflow.com/questions/64173335/do-w3c-thing-description-forms-require-an-op-key

<Ege> was going to say the same :D

Cristiano: some time ago, got a comment from Philipp Blum @@

<McCool> https://github.com/w3c/wot-marketing/pull/87

McCool: maybe we can add a link to the plugfest/breakout outcome? any volunteer?

<McCool> WoT Breakout session

Kaz: to make sure, McCool, you'll send a request for the 2nd WoT breakout session to Dom. right?

McCool: yes, I will

[WoT vF2F adjourned]

"http://dev.w3.org/cvsweb/2002/scribe/">CVS log)
$Date: 2020/12/16 12:15:10 $