- 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