<kaz> scribenick: kaz
Lagally: (goes through the agenda for today)
Lagally: typo with the link for Pullrequest 478
Kaz: just fixed
Lagally: excellent
... would suggest we approve the minutes
(no objections)
Lagally: approved
Lagally: TV use case proposed by NHK
<mlagally> https://github.com/w3c/wot-architecture/pull/484
Lagally: created a Pullrequest for that
Lagally: (goes through the changes)
Lagally: expected devices
[[
- Hybridcast TV
- Hybridcast Connect application (in a smartdevice such as smartphone)
- Cleaning Robot
- Smart Light (such as Philips Hue)
- Smart Mirror
]]
Lagally: expected data
[[
The trigger value of the scene of the TV program.
Hybridcast connect application know the Thing Description of the devices in home. (Discovery?)
]]
Lagally: we need to understand the context
what "TV" here means
... description
[[
Home smart devices behave according to TV programs.
Hybridcast applications in TV emit information about TV programs for smart home devices.
(Hybridcast is a Japanese Integrated Broadcast-Broadband system. Hybridcast applications are HTML5 applications that work on Hybridcast TV.)
Hybridcast Contact application receives the information and controlls smart home devices.
]]
Lagally: in terms of "Gaps", we need to
put some information about how signaling is handled for this
purpose
... way to annotate deices, etc.
Kaz: looks like a good starting point
Lagally: agree
... let's look at the image as well
Lagally: hybridcast connect application
includes device controller hwich talks with the WoT devices via
node-wot and proxy
... any questions?
... happy to get this proposal from NHK
... would propose we incorporate this
<kaz> +1
Lagally: any objections?
(none)
Lagally: merged
... (goes back to the original issue 480, and adds a label)
Lagally: let's defer this one
Lagally: assign to McCool
Lagally: would discuss with Zoltan Lagally: can close this Lagally: removing obsolete diagrams Lagally: we can close this without
merging Lagally: (go through the changes) Lagally: Target users [[ A Smart City managing mobile devices and
sensors, including passively mobile sensor packs,
packages, vehicles, and autonomous robots, where their
location needs to be determined dynamically. ]] Lagally: fyi, there is some people
detection mechanism based on audio instead of video [[ * Sensor ID * Timestamp of last geolocation * 2D location * typically latitude and longitude * May also be semantic, i.e. room in a building,
exit ]] Lagally: and Optional data Lagally: would propose we merge this
Pullrequest 468 Kaz: when I mentioned there were two
separate proposals on geolocation information, he also mentioned we
need to think about that Lagally: ok Kaz: this use case is very
interesting because the "Target users" actually include various
players Lagally: agree Kaz: we can merge Pullrequest 468
itself Lagally: right [[ * Onboarding mechanism for rapidly deploying a
large number of devices * Standard vocabulary for geolocation
information * Implementations able to handle image payload
formats, possibly in combination with non-image data (eg images and
JSON in a single response) * Video streaming support (if we wish to serve
video stream from the camera instead of still images) * Standard ways to specify notification mechanisms
and data payloads for things like SMS and email (in addition to the
expected MQTT, CoAP, and HTTP event mechansisms) ]] Kaz: we should look into the existing
Web APIs for notification purposes Lagally: anything related? Kaz: e.g., geo fencing events Lagally: ok (no objections) Lagally: merged Lagally: we have a use case on
transportation Lagally: (goes through what we did
today) (none) Lagally: let's close the call then <mlagally> https://github.com/w3c/wot-architecture/pull/478 Lagally: including above (none) [call 1 adjourned] <scribe> scribenick: kaz Lagally: goes through the agenda and the
discussion during the call 1 McCool: did you resolve my PR? Lagally: gives clarification McCool: ok Lagally: is everybody happy with the
minutes? (no objections) Lagally: approved then <scribe> scribenick:
FarshidT_ Lagally: two new issues <kaz> NHK's
issue Lagally: one relate to energy efficiency,
to be discussed in next discovery call <mlagally> McCool's Issue
on LinkSmart McCool: will create one liner issues once
github starts responding properly <kaz> PR 485 Lagally: geolocation pending merge <kaz> PR 478 Zoltan: wanted to have corresponding
state in each protocol (lifecycle proposal PR) Lagally: suggests instead a set of
protocols McCool: three operational states Lagally: what is the transition betw.
protocol and wot operational? Zoltan: the 3 operational states are
shown in the diagram Lagally: going through the states Zoltan: some states have two names e.g.
bootstrapped/onboarding, which refer to the same thing McCool: suggests layered diagram for the
lifecycle <kaz> Kaz: would agree with
McCool and think that it would make sense to once clarify the three
layers here, i.e., hardware, network and WoT <kaz> Kaz: after that, probably
we could think about what terms would better fit, e.g., onboarding,
operational or ready Zoltan: operational is split to two.
Maintenance can happen in parallel to operation McCool: agrees to call it update Zoltan: operational means the device is
reachable over the network <kaz> Kaz: "WoT operational"
should be the main scope of the WoT standards Lagally: not happy with transition from
manufactured to destroyed Zoltan: how to describe a destroyed
device? Lagally: the device unique id can be
always blocked Zoltan: decommissioned is more service
related and can relate to the same manufactured device Lagally: consider decommissioned as a
separate state Zoltan: already discussed merging the
two <kaz> Kaz: if it's uncomfortable
to say "manufactured" as the starting point coupled with
"decommissioned", maybe we could rename "manufactured" here more
service-oriented name, and have another "manufactured" state as the
starting point separately Zoltan: suggests taking decommission away
and add it as a layer <inserted> Kaz: in that case, I'd
suggest we once go for clarifying 3 layers, service, network and
device, and then think about what would be included as the WoT
states on the service layer Zoltan: need to think about a way to add
the additional dimension in the diagram Lagally: going into details (e.g. ACL)
will make it difficult to understand Kaz: this diagram
(unified-device-lifecycle) itself is quite understandable and looks
like our everyday life :) on the other hand, we're improving the
first diagram (WoT-lifecycle-diagram-WoT-new-lifecycle) based the
three layers, and that would be useful to clarify the relationship
between those two diagrams Zoltan: why there is a directory? is this
a WoT specific use-case? McCool: should add descriptions for the
diagrams Lagally: todos for next week: answering
security questions, revised versions of diagrams <kaz> [call 2 adjourned]Issue 461
PR 483
... we have updated diagrams already
... would propose we merge this
... will look into the conflictsPR 482
PR 468
... Motivation, Expected devices, Expected data, ...
... we need to have something more than the location data
itself
... some more complex object
... Dependency on node-wot
... would look at PR 482 again
... let's ask him to incorporate gaps from Pullrequest 482 as
well
... they're not contradictory with each other
... so I think we should clarify all the related players within the
"Target users" section :)
... (and adds a comment about that point to Pullrequest 468)
... how to handle this then?
... and then think about how to elaborate the "Target users"
... (then goes through the "health monitoring" part)
... Gaps
... I think we should talk with the DAS WG
... and fyi, I'm suggesting to McCool and Sebastian that we should
have a joint meeting with the DAS WG during TPAC 2020
... will follow up that with them
... is everybody ok with merging this Pullrequest?PR 470
... let's defer this until we have more people
... there will be some specific requirements
... like transition from one network to another network
... e.g., a pc connected with a fixed line
... then with a wifi network
... and then with some mobile connection
... need to change the networks based on where you're
... need a mechanism to switch the network dynamically
... would ask people for help to review thisSummarization
... would work on the backlog topics when we're ready
... about profiles
... btw, during the main call yesterday, we had discussion on
having use case discussion separately
... Kaz will create a doodle to see people's availability
... aob?
... would see the remaining Pullrequests
... please review them
... please take a look
... also please join the second call if possible
... aob?
Call 2
Agenda
Previous minutes
Issues
Pull requests
... smart city use-case with large number of reviewers
... merged geolocation PR, no objectionsThing life cycle
... native protocol refers to the underlying protocol (e.g.
mqtt)
... base-line operational, protocol op., wot op.
... operational term in ambiguous
... "previous state" indicates the flow of states
... preceding state when looking forward, previous state when
looking backwards
... bootstrap usually involved the identity management only
... distinction btw operational and non-operatinal
maintenance
... rename maintenance to update?
... the main concern is wot-operational and less about
protocol-operational
... decommissioned and manufactured are different
... will create a layered diagram trying to avoid additional
complexity
...
https://github.com/w3c/wot-architecture/blob/master/proposals/unified%20device%20lifecycle.svg
... a different view of how devices are used
... suggests improving the state names, and then to improve second
diagram
... need to work on the authentication flows
... need to answer checklists e.g. to answer who needs to be
authenticated. Next week
... closing