Call 1

<kaz> scribenick: kaz

Agenda

Lagally: (goes through the agenda for today)

Prev minuts

Apr-9 minutes

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

Issue 480

Lagally: TV use case proposed by NHK

<mlagally> https://github.com/w3c/wot-architecture/pull/484

Lagally: created a Pullrequest for that

Pullrequest 484

Lagally: (goes through the changes)

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

basic diagram

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)

Issue 480

Issue 460

Issue 460

Lagally: let's defer this one

Issue 481

Issue 481

Lagally: assign to McCool

Issue 473

Issue 473

Lagally: would discuss with Zoltan

Issue 461

Issue 461

Lagally: can close this

PR 483

Pullrequest 483

Lagally: removing obsolete diagrams
... we have updated diagrams already
... would propose we merge this
... will look into the conflicts

PR 482

Pullrequest 482

Lagally: we can close this without merging

PR 468

Pullrequest 468

Lagally: (go through the changes)

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
... 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

Pullrequest 482

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

Pullrequest 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> 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

Apr-9 minutes

Lagally: is everybody happy with the minutes?

(no objections)

Lagally: approved then

Issues

<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

Pull requests

<kaz> PR 485

Lagally: geolocation pending merge
... smart city use-case with large number of reviewers
... merged geolocation PR, no objections

Thing life cycle

<kaz> PR 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

https://github.com/w3c/wot-architecture/blob/master/proposals/WoT%20lifecycle%20diagram-WoT%20new%20lifecycle.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
... 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

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]