- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 02 Mar 2020 09:50:16 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/02/20-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Ege!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Architecture
20 Feb 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Call 1: Kaz_Ashimura, Michael_Lagally, Kunihiko_Toumura,
Zoltan_Kis
Call 2: Kaz_Ashimura, Ege_Korkan, Michael_Lagally,
Michael_McCool
Regrets
Chair
Lagally
Scribe
kaz, ege
Contents
* [3]Topics
1. [4]Call 1
1. [5]Agenda
2. [6]Issue 437
3. [7]Pullrequest 431
4. [8]Use cases
2. [9]Call 2
1. [10]Approval of last week's minutes
2. [11]Call 1 discussion
3. [12]DID presentation from McCool
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: kaz
Call 1
Agenda
Lagally: (goes through the agenda)
[15]Issue 440
[15] https://github.com/w3c/wot-architecture/issues/440
Lagally: we can close Issue 426 since we discussed it last week
[16]Issue 426
[16] https://github.com/w3c/wot-architecture/issues/426
Issue 437
[17]Issue 437
[17] https://github.com/w3c/wot-architecture/issues/437
Lagally: Matsukura-san pointed out editorial problems like
duplicated paragraphs
... "Monitoring of operation status ..." in 4.1.13
... also spelling of "Smart Home Gateway" is not consistent in
4.2.4
... and subsections 4.1.13.1 and 4.1.2.1
... are only subsection of the parent section
... would like to see a pullrequest to fix the errors
[18]PR 439
[18] https://github.com/w3c/wot-architecture/pull/439
Lagally: PR for Matsukura-san's point #1 and #2
... would not fix #3
... would like to merge PR 439
... also Kaz should apply it to the expected static HTML for
REC publication
Kaz: ok
RESOLUTION: merge MR 439 to address minor editorial issues
(Note that Lagally would like to suggest we use "MR" for
"pullrequest" to avoid possible confusion with "Proposed
Recommendations", etc.)
Pullrequest 431
[19]PR 431
[19] https://github.com/w3c/wot-architecture/pull/431
Lagally: would like to keep this open
Use cases
Lagally: would like to use the same terminology for all the
expected use cases
<mlagally>
[20]https://github.com/w3c/wot-architecture/blob/master/proposa
ls/WoT%20Architecture%20Lifecycle.pptx
[20] https://github.com/w3c/wot-architecture/blob/master/proposals/WoT Architecture Lifecycle.pptx
Lagally: (slides on "Actors and Roles")
[21]USE-CASES/README.md
[21] https://github.com/w3c/wot-architecture/blob/master/USE-CASES/README.md
Lagally: and README.md
... (adds descriptions to the README.md file)
... we should see what kind of terminology is used so far
... (updates the description for "Stakeholders, actors and
roles")
... device owners, clod provider
... device manufacture, gateway manufacturer, clout provider
... (look at the lifecycle diagram as well)
... network provider
... what about "identity provider"?
Zoltan: would be too generic to have a section for
"stakeholders" again?
Lagally: maybe can remove the subsection later
... (updates the structure of "stakeholders, actors and roles")
... would remove the extra "stakeholders" subsection
Zoltan: please don't remove it at the moment
... and let's have some more discussion during the second call
Kaz: would suggest we look into the related specs like
Verifiable Credentials and DID about stakeholders/actors/roles
[22]vc data model spec
[22] https://www.w3.org/TR/2019/REC-vc-data-model-20191119/
[23]vc use cases
[23] https://www.w3.org/TR/2019/NOTE-vc-use-cases-20190924/
Lagally: ok, but we don't have enough time to see them today.
so let's record the resources and revisit them later.
Toumura: currently we gather use cases in a flat structure
... but some of the stakeholders/roles are at a bit different
levels from the others
... so I think we need some mechanism/policy to classify all
the stakeholders
... for example, there would be some lower-level actors for
discovery
... so would be better to classify the stakeholders/roles based
on the phases within the lifecycle
... also there are different viewpoints, e.g., business
viewpoint
Lagally: ok
... agree we need to classify the stakeholders and use cases at
some point
... (and adds a comment)
... please avoid domain-specific terminology, e.g., MNO, telco,
rather use network operator
Kaz: btw, can we add a note to the README.md about
Toumura-san's point?
... or would it be better to ask Toumura-san to create a GitHub
issue?
Lagally: Toumura-san, could you create an Issue?
Toumura: actually, I've already added a comment to Issue 438
for my point
[24]Toumura-san's comment on Issue 438
[24] https://github.com/w3c/wot-architecture/issues/438#issuecomment-588644714
Toumura: IIC's definition for the viewpoints is just an
example, though
Lagally: ok
... please note that we already have sections on category and
class within the use case template
Toumura: don't think the viewpoints, e.g., business, usage,
functional, implementation, are part of the use case
description itself
Lagally: so it (e.g., IIC's example) has a bit different
structure
Toumura: right
[25]Old WoT use cases
[25] https://cdn.statically.io/gh/w3c/wot/aa90b2b8/ucr-doc/index.html
Lagally: note that the old WoT use cases (above)) should be
checked
... to see which is covered by what we already have
... would be great to have somebody to try detailed review
... maybe we could ask the authors of the use case document
Kaz: and/or we could split the use cases and ask people to take
one for each
Lagally: based on the section structure?
Kaz: yes
Lagally: might be a good idea
... Toumura-san and Zontan, can you take one?
Zoltan: probably
Toumura: can take the "Domain: other" section
Lagally: tx
... (adds a note to Issue 438)
... we agreed to split the work on a domain-basis
... "Domain: Other" - Toumura-san
... "Domain: Transportation" - Zoltan
Zoltan: let's ask McCool if he's interested in Smart City
Lagally: ok
... myself also will pick one
... "Domain: Manufacturing" - Lagally
Zoltan: note that smart city topic is big, so maybe we should
split it into small pieces
Lagally: ok
... let's talk about that as well during the second call
[call 1 adjourned]
__________________________________________________________
Second call
<scribe> scribenick: ege
Approval of last week's minutes
(ml goes through the last week's minutes)
<kaz> [26]Feb-13 minutes
[26] https://www.w3.org/2020/02/13-wot-arch-minutes.html
any objections?
Lagally: approved
Call 1 discussion
Lagally: (goes over the minutes of this morning)
McCool: what about considering basic use cases, like
documenting API interfaces of IoT devices
Kaz: I thought you proposed we use "MR" for "Pullrequest"
instead of "PR". So we should talk about that again.
Lagally: because we have PR as proposed recommendation and pull
request at the same time
McCool: what about one becomes PropRec?
Kaz+Lagally+McCool: we will talk about this in the main call as
well
Lagally: (shows issue #440 quickly)
... in issue #437, it is indicated that there are
capitilization problems
McCool: maybe including more than smart factory for industrial
case
Lagally: PR #439 fixes the capitilization problem
... merging it
McCool: it is also editorial
Lagally: there is this document from Johannes Hund from 2018
McCool: these are 5 use cases that can be put under industrial
use case
Lagally: we left the most interesting use cases for the second
call
McCool: smart grids were of interest for Fujitsu?
Lagally: (puts in the list) It would be also interesting for
Siemens I think
... (listing volunteers for different use cases)
Ege: christian might be able to contribute to the smart grid
use case since he had built the demonstrator for the last TPAC
Lagally: a reviewer must answer the question of whether this is
covered by existing specs (architecture or td).
DID presentation from McCool
McCool: DID has the scheme
... it resolves it into a JSON-LD document
... the existing ID schemes were not good enough in different
criterias
... (slide 4 contains the requirements for DID)
... the identifiers are still unique but are not issued by a
centralized authority
... does not have the same detail for methods, so we need to
find the connection to TD
... there is another document that lists the possible methods
... there are also service endpoints. For us it would be
interesting since the endpoint could be a TD
... you cannot delete it but deactivate it. You can also update
the key but keep the did same
... a right to delete is not possible
... I have taken one use case that I find related to IoT
... they should be more explicit with the IoT use case
... (explains the URI scheme)
... could not find examples of path or query
... ids must be unique as that there is not any collision but
an entity can have more than one entity
Lagally: what does the spec define
McCool: core spec define s url format, did document format
... did document is mostly JSON-LD 1.0 with a single feature
that relies on 1.1
... we can use publickey semantics of DID in td in a publickey
scheme
... service endpoint can have a JSON-LD fragment
Lagally: I have questions but we ran out of time
... I don't see why distributed ledgers solve the privacy issue
McCool: maybe we should discuss in the main call
... I will put into architecture
<kaz> [Call2 adjourned]
Summary of Action Items
Summary of Resolutions
1. [27]merge MR 439 to address minor editorial issues
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [28]scribe.perl version 1.154 ([29]CVS log)
$Date: 2020/03/02 00:47:38 $
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 2 March 2020 00:50:23 UTC