<scribe> scribenick: kaz
<mlagally_> https://github.com/w3c/wot-architecture/blob/master/proposals/Architecture%201.1%20FPWD.pdf
(the above URL for the slides has been added to the Aug-27 minutes)
McCool: note that "Edge Computing" is a horizontal category of use case
Matsukura: use case are usually vertical
ones
... maybe "horizontal" is rather a requirement, isn't it?
McCool: had same discussion already
<mlagally_> https://github.com/w3c/wot-architecture/pull/532
Lagally: there is a merge request (532)
Kaz: as McCool mentioned we had
related discussions already, and I'm OK with putting
"horizontal/vertical" kind of labels to the existing use cases
as the basis of further discussion
... we can reorganize the use case description and the
requirements description later during the second round
... from my viewpoint, a bigger question at the moment is how
to deal with the possible requirements descriptions
... usually requirements are included in "Use Cases and
Requirements" documents which are usually group Notes
McCool: yeah, usually requirements are also informative. right?
Kaz: yeah
Lagally: (look into MR 532)
Kaz: ok
... let's approve the minutes themselves first, and then look
into the detail about that point later
("Zontan" fixed as "Zoltan")
Lagally: let's approve the minutes then
(no objections and approved)
<McCool> https://github.com/w3c/wot-security/issues/169
<McCool> review of lifecycle by Oliver Pfaff
McCool: who owns the data?
... also who is the actor?
... service provider role, user role, etc.
(Sebastian joins)
Lagally: we were talking about the new
section of the Architecture
... skeleton of the new lifecycle section
PR 532 Preview diff - 8.4 Lifecycle
Lagally: System lifecycle, Thing lifecycle and Information lifecycle
Kaz: btw, what about the security issue 169 itself?
Lagally: need further detailed
review
... and it's related to MR 532
Kaz: ok
Lagally: and let me clarify the
relationship
... (create a new issue)
Issue 533 which links wot-security issue 169 and Lifecycle discussion
Lagally: (goes back to MR 532)
Sebastian: note that I've updated the TD spec with the new terms
Lagally: very good
... (creates a new issue on terminology)
Lagally: (then goes back to MR 532)
Lagally: "Application Domains" would
be good
... (and then shows the preview diff)
Lagally: (goes through the new section "4. Application Domains (Verticals)" and "5. System Topologies (Horizontals)"
McCool: "Edge Devices" might be
confusing
... related to the horizontal use case of "Edge
Computing"
... maybe better to call it "Edge Computing"
Lagally: ok
... please take a look
... (then goes through "6. System Integration")
... (and "7. Requirements")
... ("8. Abstract WoT System Architecture")
... ("8.2 Affordances")
... ("8.4 Lifecycle")
Kaz: what about the diagrams for Lifecycle?
Lagally: would include them at some
point, but would have improved ones
... maybe Toumura-san could help us again about this as
well
Sebastian: I've been working on Thing
Model pullrequest
... it's quite important and to be aligned with the
Architecture document
... will take care of that
McCool: also discovery section as well
("9.2 Thing Model" and "9.3 Discovery")
Lagally: only one question
... about the title of the document
... should we say "WoT Architecture 1.1"?
Sebastian: important to identify the spec
Kaz: we can say "Web of Things (WoT) Architecture Version 1.1" like SSML 1.1 above
Lagally: let's go for it
... now can we merge this MR 532?
(no objections and merged)
Lagally: connected buildings
Lagally: wondering about Farshid's availability
McCool: on vacation now
Lagally: we should look into this next week then
Matsukura: have some problem with this MR
<ryuichi> https://github.com/mryuichi/wot-architecture/blob/master/REQUIREMENTS/agriculture.md
Matsukura: MR from my own
repository
... this requirement is common and horizontal
... e.g., gateway
... virtual devices
... unit
Lagally: this "related standard" is
very specific and from Genivi
... similar discussion on unit last time
Lagally: (mentions Genivi's resource within the issue as well)
McCool: people on Automotive may use
that kind of standard on units
... it's a tricky issue
Kaz: my impression is that the
agriculture requirements here (=gateway, virtual devices and unit) are too generalized as the requirements at this stage
... maybe we could think about some more agriculture-specific requirements first
... and we could identify some more agriculture-specific resources on units, etc., based on those agriculture-specific requirements
Sebastian: unit ontology depends on which domain you're working on
Kaz: right
Sebastian: would be misleading ot choose only one ontology at this stage
McCool: issue basically arise with special units depending on each domain
Lagally: another issue about the notation, e.g., KB and KIB
McCool: differences between fields as
well
... core vocabulary vs selected one based on the need
... could take two approaches here
Lagally: what would require the least effort?
McCool: could define possible
extensions for each profile
... the main point here is having some finite set
Lagally: (adds comments based on the
discussion)
... finite set of unit extensions and a standardized prefix to
unambiguously identify the unit
... also require a way to specify a version and a fixed context
string that can be statically parsed
Lagally: regarding the original MR 505, please regenerate a fixed MR
Matsukura: ok
... note that I can't update MR 505 itself
Lagally: do you want to close MR 505?
Matsukura: yes
Lagally: (closes MR 505)
McCool: we recently had discussion on timestamp vs time series
McCool: would create a separate issue
on time series for longer discussion
... should be collaborative with OneDM, etc.
McCool: for time series, should be targeting some concrete API, etc.
Kaz: I also mentioned some points
during the Use Cases call
... joint discussion with the MEIG during TPAC would be
helpful
McCool: API and/or data model
Lagally: maybe we should quickly talk about series of time
<sebastian> sorry, I have to go
Lagally: specific type to handle time
series?
... what if we have some device which generates time series of
data?
McCool: we should boil down the descriptions
Kaz: we should think about some concrete use cases for further discussion
McCool: maybe a good topic for the
MEIG joint meeting
... likewise
... geolocation as well
... lifecycle might be also
Lagally: there has been discussion on second screen synchronization as well
McCool: media control on different channels was the original topic
McCool: good topic for the joint meeting with PING
Issue 530 on discovery terminology
Lagally: to be handled by McCool
McCool: definitely need review by PING
Lagally: what about TAG?
McCool: for security in general?
Kaz: yeah, also basic
architecture design in general
... we can ask Wendy and Sam for help as well
Lagally: we need volunteers for the
remaining issues
... what about issue 522?
McCool: 3 more components to be
defined
... Directory, Discovery and Gateway
... Gateway translates protocols
... Discovery finds devices
... want to define time series database, etc.
Lagally: anything for standardization?
McCool: pretty common things there
Lagally: there is "Intermediary" as well
McCool: not really a servient par
se
... definitely there is a thing which is not a "Thing" (as part
of WoT)
Lagally: (adds comments to Issue
522)
... "Gateway" as defined by ITU-T?
... what would be the impact?
Matsukura: I had generated a standard at ITU-T about gateway
<ryuichi> https://www.itu.int/rec/T-REC-Y.2070-201501-I/en
Matsukura: concrete pattern on gateways
Lagally: what can we learn from
this?
... can you talk about this next time?
Matsukura: yes
Kaz: I'm still wondering whether
"Gateway" itself should be a requirement for WoT or not,
because I think WoT's target is the application layer rather
than the network layer.
... maybe the functionality of "conversion of protocols and IP
addresses" might be the requirement for WoT
McCool: we should be careful how to
define "Gateway"
... for example, we can look into ITU-T standards and see if
their definition fits us
Kaz: yeah
Lagally: let's add that to the agenda for the next week
Lagally: we have issues on several
diagrams as well
... some of them will go into the Lifecycle section
McCool: maybe the details should go
to the Discovery document
... and the Architecture document should keep being
abstract
Kaz: yeah
... technically, we could have a best practices or an
implementation guideline document and put the detailed sequence
diagrams into it
Lagally: right
... on the other hand, abstract diagrams could be included in
the Architecture
McCool: yeah
... high-level ones are possible
Lagally: something like my drawn sequence diagram about lifecycle state transition
Kaz: yeah, that kind of high-level one should be ok
McCool: would be better to split each diagram into separate SVG file
Lagally: right
... this kind of diagram (on lifecycle state transition) is
useful to clarify the terminology definition as well
Kaz: right
Lagally: note that we still have many
issues lacking owners...
... please consider to take some of them
... AOB?
(none)
Lagally: for the next week, we've
already put some agenda items
... we didn't talk about profile this week
... but would talk about that as well
[adjourned]