<scribe> scribenick: kaz

Logistics

Lagally: think we might want to change the time of the WoT Architecture call to get wider attendance
... opt1: 1 or 2 hours later
... opt2: merge with the 2nd call

Kaz: can create a doodle poll

Lagally: tx

Prev minutes

July-9

Lagally: talked about profile
... would talk about it today as well
... will put the information on the summary slides to the MD files as well
... btw, Matsukura-san, we were discussing how to manage the Architecture call slot
... we'll create a doodle poll to see people's availability

- Reschedule 1st architecture call (1-2 hours later)

- Merge 1st call into 2nd one

Matsukura: 1-2 hours later is OK but midnight would be too late...

Lagally: ok
... go back to the minutes review
... any concerns?

(none)

approved

vF2F minutes

vF2F minutes

Lagally: (goes through the minutes)
... discussed profiles during the previous call as well
... was also nice to have Ben there during the vF2F
... had discussion use case importance and contributors
... any concerns?

(none)

Kaz: so we've confirmed the vF2F minutes are OK :)

MRs

MR 505

changes

Matsukura: requirements for the agriculture use case

[[

Enable to respond to the requests from consumers instead of the original corresponding to the virtual device and being offline

]]

Matsukura: same content with the actual device with a different IP address
... the idea is a shadow device

Lagally: having the same property?

Matsukura: right

Lagally: what is the expected behavior?

Matsukura: this function would be useful for sensor
... the proxy always responds to the users for the actual sensors
... since the actual devices might be suspended sometimes

Lagally: ok
... so this is related to digital twin idea

Matsukura: yes

Kaz: maybe we should add notes on related ideas (like digital twin and device shadow) and basic need for energy consumption saving so that we can identify this use case is related to which category (horizontal use cases and vertical use cases)

Lagally: ok
... and we should think about security portion as well

Kaz: right

Lagally: (adds comments on that)
... next states for things

Matsukura: proxy has the information on the "actual state"

Lagally: digital twin to handle the state automatically for the edge devices

Matsukura: yes

Kaz: based on the discussion so far, I think all these requirements assume a proxy who manages all the edge devices, sensors and actuators
... so we should mention that assumption here as well

Lagally: ok
... (adds a comment on that)

Matsukura: "intermediary" is defined in the WoT Architecture
... and that point (=proxy manager) would describe the concrete function for that

Kaz: yeah, for the spec we intentionally used the abstract term "intermediary"
... and "proxy device which manages multiple edge devices" is a good use case for that
... regarding the definition on units
... the Automotive WG used to refer to the GENIVI resource
... but they're looking at new ontology definition
... also McCool was working on surveys about unit definitions

Lagally: (adds comments)

Profiles

MR 16

Lagally: would like to have volunteers :)

preview

Lagally: section 4 (section 4.2 specifically) needs further discussion
... but would like to make the draft an initial starting point

Kaz: yes, we always need something as the basis of the discussion :)

<mlagally_> proposal: Use the current strawman document as the baseline for the Profile specification

Lagally: any concerns?

(none)

all: agree

RESOLUTION: Use the current strawman document as the baseline for the Profile specification

requirements for profiles

<mlagally_> proposal: Accepting the following requirements for the FPWD: Interoperability, Limit and reduce complexity, Eliminate ambiguities, Limit resource consumption, finite set of features and capabilities, follow security and privacy best practices subject to group feedback

Kaz: do you mean we'll include the requirements description into the index.html?

Lagally: no

Kaz: so we'd like to consider the requirements.md as the basis of the index.html?

Lagally: restricted topics within requirements.md to be the basis

Kaz: ok
... so we'll consider the restricted list of requirements as the basis of the FPWD of the WoT Profiles document

Lagally: right

Matsukura: the WoT Profiles document would be very useful for PlugFest, etc.

Lagally: ok with the proposal?

all: ok

RESOLUTION: Accepting the following requirements for the FPWD: Interoperability, Limit and reduce complexity, Eliminate ambiguities, Limit resource consumption, finite set of features and capabilities, follow security and privacy best practices subject to group feedback

Lagally: will check with people during the 2nd call as well
... (shows wot-profile/issues)
... please review the issues

wot-profile/issues

Lagally: aob?

(none)

Lagally: btw, wondering about the progress of the use case description conversion

Kaz: all the MD files of the use cases are already converted into HTML
... so we can review the resulted HTMLs during the use case call next week

Lagally: ok

[call 1 adjourned]

---

Call 2

Lagally: initial description on the abstract system architecture
... including system components, lifecycle and thing templates

Kaz: will you create a MD file based on the description?

Lagally: actually, planning to generate an HTML file instead :)
... also would like to move the information on the summary table of use cases/volunteers to MD
... btw, regarding this call itself, let's adjourn it due to small participation today

[adjourned]