- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 07 Sep 2020 20:53:31 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/08/27-wot-arch-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Architecture
27 Aug 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Michael_Lagally, Michael_McCool,
Ryuichi_Matsukura, Michael_Koster
Regrets
Chair
Lagally
Scribe
kaz
Contents
* [3]Topics
1. [4]Agenda
2. [5]Prev minutes
3. [6]Profiles
4. [7]Pull requests
5. [8]Architecture
6. [9]Lifecycle
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
Agenda
Lagally: two specs: Profiles and Architecture
... profiles has 2 MRs
... architecture needs spec drafting
... work split and contributions as well
Prev minutes
[12]Aug-6
[12] https://www.w3.org/2020/08/06-wot-arch-minutes.html
Lagally: kind of long discussion on wot-profile
McCool: we need to go back and think about the components
... required features possibly including communication protocol
should be the core profile
Lagally: would be good to define core data model as well
McCool: interoperability would be on the protocol level
Lagally: yes
... at least one protocol
McCool: yeah, if some device works with HTTP and another one
also works with HTTP, those two should work with together
Lagally: regarding the minutes themselves, any objections to
approve them?
(none)
Lagally: approved
Profiles
Lagally: wondering about compound multi-protocols
McCool: the structure of the Profile document is quite abstract
... get-out-of-box interoperability is important
... everything satisfies the core profile
... possibly have a HTTP Profile
Lagally: note that we should avoid data fragmentation
McCool: right
[13]WoT Profile draft
[13] https://w3c.github.io/wot-profile/
Lagally: (shows the ToC of the above draft)
McCool: Security is important and to be included in the core
Lagally: (then shows the TD spec's "5. TD Information Model")
[14]TD - 5. TD Information Model
[14] https://w3c.github.io/wot-thing-description/#sec-vocabulary-definition
Lagally: that is the datamodel
... for digital twin use cases, we don't have to think about
protocols
McCool: on the other hand, actual device interaction requires
protocol binding
... starting with HTTP
... then MQTT
... CoAP might be a bit difficult
Lagally: ok
... we have core data model as section 5 within WoT Profile
McCool: the Core Profile could assume HTTP
[15]wot-profile issue 2
[15] https://github.com/w3c/wot-profile/issues/2
Lagally: way to identify profiles
McCool: new version of @context could be used?
... like this format using "#" for the detail
... [["@context":
"[16]https://www.w3.org/2019/wot/td/v1#core"]]
... additional protocols could be specified like:
... [["@context":
"[17]https://www.w3.org/2019/wot/td/v1#http"]]
... [["@context":
"[18]https://www.w3.org/2019/wot/td/v1#coap"]]
[16] https://www.w3.org/2019/wot/td/v1#core
[17] https://www.w3.org/2019/wot/td/v1#http
[18] https://www.w3.org/2019/wot/td/v1#coap
Lagally: profileCompliance = core
... profileProtocol = http, coap, ...
... ?
McCool: yeah
... seems reasonable
Lagally: (adds a comment to issue 2 about that point)
... this could be addressed by two new keywords (vocabulary
terms): profileCompliance, profileProtocol
... profileProtocol can be an array
Koster: question about protocol binding constraints
... and data model part
... specifically, "core data model"
... out-of-box interoperability could be constraints?
... could define smarthome data model
... don't see super-tied use cases yet
Lagally: if you look into the current strawman draft...
... would like to identify some specific devices
... e.g., for geolocation use cases
Koster: common object to define locations and address
discovery, etc.
... you have to have some object for that purpose
... for out-of-box interoperability
Kaz: think I can understand the concept of switching profiles
using "@context"
... but would see how to do that based on concrete use cases
... maybe we can use the existing use cases as the basis
Lagally: we should be careful about how to deal with the data
model part and the protocol part
McCool: would agree with Kaz that we should think about use
cases
... some vocabulary could be involved like geolocation
vocabulary
... we don't have any concrete geolocation context file itself
yet, and that is frustrating, though
Lagally: we could define some mandatory features for actions,
properties, etc.
Kaz: if the geolocation use cases are important, we should
start with them and clarify what is included in the core
profile and what is extension
Lagally: yeah
McCool: think we can do that
Lagally: btw, what can we do for the FPWD publication until the
end of September?
McCool: we don't need to define the detail for the FPWD
Lagally: (shows the Editor's Note at the end of 5.1.2.2
Recommended practice)
It will be evaluated whether the profile also recommends some
new TD terms that may be introduced in TD 1.1. Currently the
following terms are discussed: serialNumber, hardwareRevision,
softwareRevision, loc_latitude, loc_longitude loc_altitude,
loc_height, and loc_depth. If these, or some of them, are
defined in the TD 1.1 model, they may be recommended here in
one of the next draft updates.
]]
McCool: we could walk through the spec and identify issues
Lagally: that's actually the plan
Koster: there are both "Interaction Affordance" and "Event
Affordance"
... probably "Interaction Affordance" should be "Action
Affordance"
-> [19]https://w3c.github.io/wot-thing-description/#dataschema
TD -
[20]https://w3c.github.io/wot-thing-description/#dataschema
[19] https://w3c.github.io/wot-thing-description/#dataschema
[20] https://w3c.github.io/wot-thing-description/#dataschema
(discussion on units)
Lagally: make units mandatory?
... (creates a new issue on wot-profile)
Koster: would suggest we align with OneDM which uses SenML
units
McCool: would say you must use SenML units if exists, otherwise
you must use QUDT
[21]QUDT Ontologies Overview
[21] http://www.qudt.org/pages/QUDToverviewPage.html
(discussion about the concrete description on how to deal with
units)
[22]SenML
[22] https://tools.ietf.org/html/rfc8428
[23]issue 29 - consolidated comments on how to deal with units
[23] https://github.com/w3c/wot-profile/issues/29
<mjk> [24]https://tools.ietf.org/html/rfc8428#section-12.1
[24] https://tools.ietf.org/html/rfc8428#section-12.1
McCool: also we should create another issue on if we allow only
a finite set of vocabulary extensions
Lagally: (generates another issue on that)
[25]Issue 30 - Allow only a finite set of vocabulary
extensions?
[25] https://github.com/w3c/wot-profile/issues/30
Lagally: (going back to Issue 2)
[26]Issue 2 - Way to identify profile(s)
[26] https://github.com/w3c/wot-profile/issues/2
(discussion about data annotation)
Lagally: (creates yet another issue)
[27]Issue 31 - Annotate the data model with common elements
[27] https://github.com/w3c/wot-profile/issues/31
(also discussion on how to indicate preference on annotation
scheme
[28]Issue 32 - Standardized way to indicate capabilites
[28] https://github.com/w3c/wot-profile/issues/32
Pull requests
[29]PR 23
[29] https://github.com/w3c/wot-profile/pull/23
Lagally: (merged PR 23)
[30]PR 28
[30] https://github.com/w3c/wot-profile/pull/28
Lagally: (merged PR 28)
[31]wot-architecture PR 505 - Create a new requirements from
agriculture
[31] https://github.com/w3c/wot-architecture/pull/505
rm: will work on that
Lagally: tx
[32]wot-architecture PR 531 - Define Discovery requirements
[32] https://github.com/w3c/wot-architecture/pull/531
McCool: need to link it with motivated use cases
... also other related verticals
... already ha sections on security, privacy, user needs and
accessibility
Lagally: good piece of work
... also looks good
... we can once merge this and then update it later
Kaz: sounds good
Lagally: (merged PR 531)
Architecture
[33]current draft
[33] https://w3c.github.io/wot-architecture/
[34]Slides
[34] https://github.com/w3c/wot-architecture/blob/master/proposals/Architecture 1.1 FPWD.pdf
Lagally: recollection of the structure
... current structure on the slide as well
... and proposed structure for 1.1
... 1. Introduction
... 2. Conformance
... 3. Terminology (+ delta for discovery, thing templates,
profiles, lifecycle)
... making "4.1 Application Domains" a level 1 chapter
... also making "4.2 Common Patterns" another level 1 chapter
McCool: what about edge computing?
Kaz: adding the edge computing use case itself would be nice,
but we should think about how to structure those three topics,
"application domains", "common patterns", and "edge computing"
McCool: yeah, we could say "verticals", "horizontal" instead?
Lagally: verticals, horizontals, and placeholder for the others
NOTE: Edge computing is a horizontal use case.
Kaz: how to deal with the content within the current "4.3
Summary"?
... maybe multiple system integration or something like that?
McCool: yeah
Lagally: "6. WoT Architecture" to be "Abstract System
Architecture"
... rework on the existing chapter 6 and improve the whole
structure
... "6.1 Overview" to be split into subchapters
... "6.5 Hypermedia Controls" to include "Semantic annotations"
and "Thing Model Concept" (Templates)?
McCool: would like to propose we go for incremental improvement
Lifecycle
Lagally: new subchapter under the "Abstract System
Architecture" section?
... including:
... * Introduction (Zoltan and Lagally)
... * System Lifecycle (Lagally)
(out of time)
Lagally: will upload these slides
Kaz: also it would be good to put the content on some MD
file(s) so that people can raise issues directly
McCool: like outline.md
Kaz: right
[adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [35]scribe.perl version
1.152 ([36]CVS log)
$Date: 2020/09/03 14:22:42 $
[35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[36] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 7 September 2020 11:53:36 UTC