<kaz> scribenick: kaz
Lagally: (goes through the agenda)
Lagally: we can close Issue 426 since we discussed it last week
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
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.)
Lagally: would like to keep this open
Lagally: would like to use the same terminology for all the expected use cases
<mlagally> https://github.com/w3c/wot-architecture/blob/master/proposals/WoT%20Architecture%20Lifecycle.pptx
Lagally: (slides on "Actors and Roles")
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
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
Toumura-san's comment on Issue 438
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
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]
<scribe> scribenick: ege
(ml goes through the last week's minutes)
<kaz> Feb-13 minutes
any objections?
Lagally: approved
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).
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]