<kaz> scribenick: kaz
kaz, daniel and sebastian
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?
Lagally: discussion with the Pub BG
Chair for the joint meeting
... FPWD publications, OneDM/Thing Model, ...
... any objections for publishing the minutes?
(none)
Lagally: approved
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
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
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"
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
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
<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]
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
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]
<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
https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2020
McCool: IRC available
http://irc.w3.org/?channels=#wot
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
https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Cancellations
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
... JSON-LD
... 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
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)
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?
(none)
<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
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
<kaz> scribenick: kaz
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: next PR 44
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
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?
(none)
(merged)
McCool: at the very least, supporting brownfield devices can be under "secondary goals" (and OOTBI is still primary!)
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
[[
EDITOR'S NOTE
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]
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
[slides]
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
<mlagally> https://github.com/w3c/wot-usecases
Lagally: use cases repo above
Lagally: Mizushima-san has been
working on clean-up
... there are still issues on the document, though
Lagally: merged
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
<mlagally> scribenick: mlagally
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
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
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
<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
[adjourned]
<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
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
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
<inserted> Issue 988
Victor: json schema round trip
<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
<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
<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
<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
<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
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.?
ack
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
[adjourned]
<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
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]
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_
<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
<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
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
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]
<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
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
<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
<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 ]
<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
https://swagger.io/docs/specification/using-ref/
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]
<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
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
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]
<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
https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Cancellations
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
https://www.w3.org/2020/10/TPAC/breakout-schedule.html
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
<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
+1
<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
<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 :)
<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
McCool: no presentation slides for
this
... would like to gather materials from people
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
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
McCool: Issue on discovery
... Toumura-san, any resources?
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
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
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
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)
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
McCool: will have prep discussion
during the Discovery slot on Monday, Oct 26
... will send an invite
Lagally: cancelled today
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]