W3C home > Mailing lists > Public > public-wot-wg@w3.org > September 2020

[wot-architecture] minutes - 27 August 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 07 Sep 2020 20:53:31 +0900
Message-ID: <877dt5ls5g.wl-ashimura@w3.org>
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

This archive was generated by hypermail 2.4.0 : Monday, 7 September 2020 11:53:37 UTC