- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 05 May 2020 03:17:43 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/04/23-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Farshid!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Architecture
23 Apr 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Call 1: Kaz_Ashimura, Kunihiko_Toumura, Michael_Lagally,
Tomoaki_Mizushima
Call 2: Kaz_Ashimura, Farshid_Tavakolizadeh,
Michael_Lagally, Michael_McCool, Tomoaki_Mizushima,
Zoltan_Kis, Elena_Reshetova, Shreekantha_Devasya
Regrets
Chair
McCool
Scribe
Kaz, Farshid
Contents
* [3]Topics
1. [4]Call 1
1. [5]Agenda
2. [6]Prev minuts
3. [7]Issue 480
4. [8]Issue 460
5. [9]Issue 481
6. [10]Issue 473
7. [11]Issue 461
8. [12]PR 483
9. [13]PR 482
10. [14]PR 468
11. [15]PR 470
12. [16]Summarization
2. [17]Call 2
1. [18]Agenda
2. [19]Previous minutes
3. [20]Issues
4. [21]Pull requests
5. [22]Thing life cycle
* [23]Summary of Action Items
* [24]Summary of Resolutions
__________________________________________________________
Call 1
<kaz> scribenick: kaz
Agenda
Lagally: (goes through the agenda for today)
Prev minuts
[25]Apr-9 minutes
[25] https://www.w3.org/2020/04/09-wot-arch-minutes.html
Lagally: typo with the link for Pullrequest 478
Kaz: just fixed
Lagally: excellent
... would suggest we approve the minutes
(no objections)
Lagally: approved
Issue 480
[26]Issue 480
[26] https://github.com/w3c/wot-architecture/issues/480
Lagally: TV use case proposed by NHK
<mlagally> [27]https://github.com/w3c/wot-architecture/pull/484
[27] https://github.com/w3c/wot-architecture/pull/484
Lagally: created a Pullrequest for that
[28]Pullrequest 484
[28] https://github.com/w3c/wot-architecture/pull/484
Lagally: (goes through the changes)
[29]changes
[29] https://github.com/w3c/wot-architecture/pull/484/files
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
[30]basic diagram
[30] https://github.com/w3c/wot-architecture/blob/ab27ef5162583a2e41c67dc18eb26144ac91ad54/USE-CASES/images/scenario_nhk.png?raw=true
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)
[31]Issue 480
[31] https://github.com/w3c/wot-architecture/issues/480
Issue 460
[32]Issue 460
[32] https://github.com/w3c/wot-architecture/issues/460
Lagally: let's defer this one
Issue 481
[33]Issue 481
[33] https://github.com/w3c/wot-architecture/issues/481
Lagally: assign to McCool
Issue 473
[34]Issue 473
[34] https://github.com/w3c/wot-architecture/issues/473
Lagally: would discuss with Zoltan
Issue 461
[35]Issue 461
[35] https://github.com/w3c/wot-architecture/issues/461
Lagally: can close this
PR 483
[36]Pullrequest 483
[36] https://github.com/w3c/wot-architecture/pull/483
Lagally: removing obsolete diagrams
... we have updated diagrams already
... would propose we merge this
... will look into the conflicts
PR 482
[37]Pullrequest 482
[37] https://github.com/w3c/wot-architecture/pull/482
Lagally: we can close this without merging
PR 468
[38]Pullrequest 468
[38] https://github.com/w3c/wot-architecture/pull/468
Lagally: (go through the changes)
[39]changes
[39] https://github.com/w3c/wot-architecture/pull/468/files
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
... Motivation, Expected devices, Expected data, ...
* 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
... 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
[40]Pullrequest 482
[40] https://github.com/w3c/wot-architecture/pull/482/files
Lagally: would propose we merge this Pullrequest 468
... let's ask him to incorporate gaps from Pullrequest 482 as
well
Kaz: when I mentioned there were two separate proposals on
geolocation information, he also mentioned we need to think
about that
Lagally: ok
... they're not contradictory with each other
Kaz: this use case is very interesting because the "Target
users" actually include various players
... so I think we should clarify all the related players within
the "Target users" section :)
Lagally: agree
... (and adds a comment about that point to Pullrequest 468)
... how to handle this then?
Kaz: we can merge Pullrequest 468 itself
... and then think about how to elaborate the "Target users"
Lagally: right
... (then goes through the "health monitoring" part)
... Gaps
* 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
... 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
Lagally: ok
... is everybody ok with merging this Pullrequest?
(no objections)
Lagally: merged
PR 470
[41]Pullrequest 470
[41] https://github.com/w3c/wot-architecture/pull/470
Lagally: we have a use case on transportation
... 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 this
Summarization
Lagally: (goes through what we did today)
... 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?
(none)
Lagally: let's close the call then
... would see the remaining Pullrequests
... please review them
<mlagally> [42]https://github.com/w3c/wot-architecture/pull/478
[42] https://github.com/w3c/wot-architecture/pull/478
Lagally: including above
... please take a look
... also please join the second call if possible
... aob?
(none)
[call 1 adjourned]
__________________________________________________________
Call 2
<scribe> scribenick: kaz
Agenda
Lagally: goes through the agenda and the discussion during the
call 1
McCool: did you resolve my PR?
Lagally: gives clarification
McCool: ok
Previous minutes
[43]Apr-9 minutes
[43] https://www.w3.org/2020/04/09-wot-arch-minutes.html
Lagally: is everybody happy with the minutes?
(no objections)
Lagally: approved then
Issues
<scribe> scribenick: FarshidT_
Lagally: two new issues
<kaz> [44]NHK's issue
[44] https://github.com/w3c/wot-architecture/issues/480
Lagally: one relate to energy efficiency, to be discussed in
next discovery call
<mlagally> [45]McCool's Issue on LinkSmart
[45] https://github.com/w3c/wot-architecture/issues/481
McCool: will create one liner issues once github starts
responding properly
Pull requests
<kaz> [46]PR 485
[46] https://github.com/w3c/wot-architecture/pull/485
Lagally: geolocation pending merge
... smart city use-case with large number of reviewers
... merged geolocation PR, no objections
Thing life cycle
<kaz> [47]PR 478
[47] https://github.com/w3c/wot-architecture/pull/478
Zoltan: wanted to have corresponding state in each protocol
(lifecycle proposal PR)
... native protocol refers to the underlying protocol (e.g.
mqtt)
Lagally: suggests instead a set of protocols
McCool: three operational states
... base-line operational, protocol op., wot op.
... operational term in ambiguous
Lagally: what is the transition betw. protocol and wot
operational?
Zoltan: the 3 operational states are shown in the diagram
... "previous state" indicates the flow of states
... preceding state when looking forward, previous state when
looking backwards
[48]https://github.com/w3c/wot-architecture/blob/master/proposa
ls/WoT%20lifecycle%20diagram-WoT%20new%20lifecycle.svg
[48] https://github.com/w3c/wot-architecture/blob/master/proposals/WoT lifecycle diagram-WoT new lifecycle.svg
Lagally: going through the states
Zoltan: some states have two names e.g.
bootstrapped/onboarding, which refer to the same thing
... bootstrap usually involved the identity management only
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
... distinction btw operational and non-operatinal maintenance
... rename maintenance to update?
McCool: agrees to call it update
Zoltan: operational means the device is reachable over the
network
... the main concern is wot-operational and less about
protocol-operational
<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
... decommissioned and manufactured are different
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
... will create a layered diagram trying to avoid additional
complexity
Lagally: going into details (e.g. ACL) will make it difficult
to understand
...
[49]https://github.com/w3c/wot-architecture/blob/master/proposa
ls/unified%20device%20lifecycle.svg
... a different view of how devices are used
... suggests improving the state names, and then to improve
second diagram
[49] https://github.com/w3c/wot-architecture/blob/master/proposals/unified device lifecycle.svg
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
... need to work on the authentication flows
... need to answer checklists e.g. to answer who needs to be
authenticated. Next week
Lagally: todos for next week: answering security questions,
revised versions of diagrams
... closing
<kaz> [call 2 adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [50]scribe.perl version
1.152 ([51]CVS log)
$Date: 2020/05/04 18:07:49 $
[50] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[51] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 4 May 2020 18:17:25 UTC