Lagally: would approve the minutes
Lagally: went through the use
cases
... geolocation use caes and TD templates
... would go ahead and approve day 2 minutes as well
Lagally: any concerns?
(none)
Lagally: approved
Lagally: before the virtual f2f
... (goes through the minutes)
... any concerns?
(none)
Lagally: also approved
Lagally: this is the final version for
the publication
... (goes through the diffs)
... expect the draft will be published along with the press
release
... the specs will be used as the basis for actual
products
... would like to send official thanks to all after the
transition approval
Lagally: would like to look into issues
Lagally: will remove the example template
Lagally: updates for the use case template. any comments?
(none)
Lagally: we need some more time
Lagally: possibly inherit multiple
blocks
... might implement two interfaces for a blueprint
... cooler, heater vs air conditioner having both
capability
... Define an inheritance mechanism and corresponding handling
of namespaces to avoid naming conflicts, when things implement
more than one template.
... would add links for some more resources
Sebastian: different topics here
... TD template and relation types
... should have resources for them
Issue 465 on requirements for web linking and link relations
related standards:
https://tools.ietf.org/html/rfc8288
https://tools.ietf.org/html/rfc8631
https://tools.ietf.org/html/rfc6903
https://www.iana.org/assignments/link-relations/link-relations.xhtml
<mlagally> A Thing Description Template is a description for a class of Things. It describes the properties, actions, events and common metadata that are shared for an entire group of Things,
Lagally: need to define terms clearly
Lagally: possible term is "snippet" during the call
Sebastian: would have Zoltan as
well
... what is our minimum expectation for TD Template?
Sebastian: would like to see the analogy of Object-oriented programming approach as well
Lagally: Sebastian mentioned:
... Expose a Servient: Templates are used to define a WoT
producer such as for a WoT runtime implementations (e.g.,
node-wot)
... and Zoltan responded:
... That is not a TD template, but a partial TD (or TD
fragment) that may contain parts that cannot be part of a
TDT.
... (goes through the discussion on Issue 458)
... we need to keep things separately
... Zoltan mentions instance-specific data
Sebastian: my use case is
mass-production
... including 10000 things
... the data model can be taken over by some TD instance
... information within a TD template will be used by the
instance
... technically, a TD template could have some
instance-specific data
... but would like to have a concrete example for that use
case
Lagally: is there any additional
requirement?
... we need to have some term for partial TD, etc.
... let's keep the discussion clean
... and define "Thing Description Template"
Sebastian: A TDT does not contain enough information to identify or interact with a real Thing.
Lagally: (adds a comment to Issue
454)
... a TD Template is a description for a class of Things
... (adds some tweaks to the definition of "TD Template")
<ryuichi> (sorry, have to move another meeting. bye)
proposed definition for "Thing Description Template"
Lagally: let's wrap up the
discussion
... talk to you later at the second call!
[Call 1 adjourned]
Lagally: (goes through the minutes)
Lagally: (goes through the minutes)
McCool: sanity check for the use case
template
... we should go through the whole minutes and create create
actions and issues
Lagally: (creates an issue for security checklist)
Lagally: (creates another issue to update the lifcycle use case)
Lagally: (goes through the minutes)
[Zoltan joins]
Lagally: would take an action to clarify the Architecture call times
<scribe> ACTION: Lagally to clarify the Architecture call times
McCool: some typo there?
... peofiles => profiles
Lagally: other than that, would approve all the Virtual F2F minutes (Architecture part)
Lagally: (goes through the
minutes)
... would like to approve these minutes as well
... still need final decision for the Virtual F2F minutes
during the next main call, though
Lagally: (goes through the diff
file)
... this should be the final version for the V1 spec
(no problems within the HTML)
Lagally: there is an issue for the fleet management use cases
Zoltan: we can have separate use cases depending on the targets
Zoltan: transportation use case could be split into separate use cases depending on the vehicle
McCool: transportation should be a category
Lagally: (adds a comment to Issue 469 saying "see also #435")
Lagally: remove use-case-example.md
McCool: fine
Lagally: (merges #463)
Lagally: update
use-case-template.md
... (merges #464)
<McCool> mm: under dependencies it would be helpful to list work items, not just deliverables
<McCool> ... but can go ahead and merge this for now
Lagally: (updates use-case-template.md)
Lagally: update lifecycle diagram
Elena: latest change on commission state
Lagally: wondering if GitHub can hosts the online version of draw.io
Elena: (shares here screen showing
the online version diagram)
... actors on the arcs
... manufacturer, service provider, network provider, device
owner
... and others?
... (adds edits)
... Device Owner or Service Provider between "Manufacture /
Decommissioned" state and "Bootstrapped / Onboarded" state
(discussion on the Actors)
McCool: ownership doesn't usually
matter
... the point is whether having write permission or not
Kaz: btw, maybe this is kind of overkill at the moment, but at some point we might want to think about apartment buildings in addition to smart homes
McCool: right. apartment has mixture
inside
... roles of person
Lagally: everybody has different scenario
Zoltan: what is the main purpose of this diagram then?
Lagally: to clarify the common model
McCool: one role is missing
here
... state before manufacturing
Elena: an optional state?
McCool: basically this diagram is
drawn from the service provider's viewpoint
... precondition and postcondition
Lagally: would update the diagram to include all the points discussed today
McCool: would like to consider Oliver's summarized lifecycle descriptions on IETF Anima and OPC-UA
Elena: mapping between them and the states within this diagram?
McCool: maybe could add some vocabulary from them
Lagally: McCool, could you work on Oliver's diagram?
Zoltan: we should do a homework
now
... overview of concrete protocols, etc.
Lagally: make sense
<McCool> mm: I can review. Make an issue and assign it to me (if there isn't one already...)
<McCool> mm: basically I will look at Anima/Oliver's slides and see if they align
<McCool> ... also, never mind, I will add the issue myself right now
Lagally: there is an SVG version of the diagram on the wot-architecture GitHub repo
<McCool> mm: new issue to review Anima terminology: https://github.com/w3c/wot-architecture/issues/474
<inserted> ml: we should have an editable SVG version of the diagram on GitHub
Kaz: how to identify who created the updated SVG diagram when? maybe we need to use "YYYYMMDD-author-wot-lifecyle.svg" as the file name?
Zoltan: we can create a subdirectory?
[Elena leaves]
Lagally: would like to talk with the
media guys about the use cases
... any updates from your side, Chris?
Chris: no concrete updates so
far
... maybe need some more direct/individual approach to get
concrete feedback
... reaching out directly
... some of the possible use cases are related to the ones
generated by the MEIG (Web&TV IG) Home Network TF
... related to timing information
... kind of like Netflix experience
... watching a content from various environments
Lagally: ok
... but we should not preclude cloud-based approach
Chris: right
... maybe split into several use cases?
<McCool> mm: (sorry, I have to drop; ttyl)
<mlagally> tty
Kaz: maybe we might want to think
about combination of home network use cases and bullet
chatting
... massive number of users accessing same content at
once
... and share the users' feedback/comments as well as the basic
video content
Chris: may be an interesting combination
Lagally: anybody interested from the media side?
Chris: multi-room synchronized
playback, etc.?
... the scenario itself might be similar
(though media requirements have been covered by HTML5 extensions)
Chris: can share some resources
Lagally: companion screen for
additional information like audio commentary
... accessibility is a possible use case
Chris: also immersive purposes
using multiple cameras
... could share some links about research projects
... currently more research topics than products/services,
though
Lagally: we already have a template for use case description
[Zoltan leaves]
Lagally: so we can create a "bucket" for media use case description based on the template :)
(generates a bucket use case description)
Chris: we can include the information about NHK's proposal during the MEIG meeting at TPAC
MediaTimedEvents in Hybridcast
<mlagally> https://github.com/w3c/wot-architecture/edit/master/USE-CASES/media-information-references.md
Lagally: media-related bucket use case description above
<cpn> https://2immerse.eu/motogp-at-home/
Chris: some more possible use cases
(as R&D work) above
... we can show this bucket use case to the MEIG
... and ask them for feedback
Lagally: ok
... please let me add a disclaimer at the top
Chris: will share this with the MEIG guys
Lagally: tx!
[call 2 adjourned]
