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

[wot-architecture] minutes - 6 August 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 31 Aug 2020 16:47:57 +0900
Message-ID: <87imcz2r4i.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/08/06-wot-arch-minutes.html

also as text below.

Thanks a lot for taking the minutes, Daniel and McCool!

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                            WoT Architecture

06 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,
          Daniel_Peintner, Tomoaki_Mizushima, Sebastian_Kaebisch,
          Ryuichi_Matsukura, David_Ezell, Michael_Koster

   Regrets

   Chair
          Lagally

   Scribe
          Daniel, McCool

Contents

     * [3]Topics
         1. [4]Past Minutes Approval
         2. [5]Profiles
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

   <dape> scribe: dape

Past Minutes Approval

   [8]July-30

      [8] https://www.w3.org/2020/07/30-wot-arch-minutes.html

   Lagally: we had 2 Calls
   ... no objections -> minutes approved

Profiles

   Lagally: 2 open PRs and 15 issues

   McCool: Several issues seem to overlap
   ... consolidate/close?

   Lagally: Agree
   ... should look into
   ... Let's talk about co-editors first
   ... we have Lagally, McCool, Mizushima
   ... Matsukura-san and Sebastian
   ... 5 co-editors

   <kaz> [9]Issue 21

      [9] https://github.com/w3c/wot-profile/issues/21

   Lagally: Issue 21
   ... Mix of "scope" and "name" discussions

   McCool: would be wise to start with scope first
   ... proposal: "core" does not even contain protocol

   Lagally: Agree, should first talk about data model

   McCool: In that case "core" makes sense
   ... insisting on a specific protocol in the core profile we run
   into problems
   ... with data model only we do not guarantee interop

   Lagally: relating to digital twin discussion: with core data
   model we could have interop... even across protocols

   Kaz: Agree. Starting with minimum set of features.
   ... we should define this set

   Lagally: First set of features w.r.t. data model
   ... suggest splitting
   ... 1. constraints on data model
   ... 2. protocols and constraints
   ... 3. naming

   McCool: some constraints are covered by JSON schema minLength
   etc
   ... related to strings is which encoding
   ... is there anything besides data models?

   Lagally: interaction model... but I see it as part of the data
   model

   McCool: ID formats? restrictions?

   Sebastian: I agree we should avoid the naming discussion
   ... future profiles may pop up
   ... "core" assumes it is always part of of it
   ... I also agree splitting the constraints
   ... one profile with multiple constraints... security, . et
   cetera
   ... one profile might not always work for all interested
   parties
   ... e.g., HTTP and JSON is fine but needs "more" on the data
   model side

   Lagally: Then you can extend the profile
   ... once you go beyond there is no guarantee that you will not
   blow other implementations
   ... conformant to profile means one has a guarantee

   Sebastian: example: client with core and restrictions
   ... what do you do with strings longer than the expectation

   Lagally: Cut string?

   Sebastian: What is the difference with today's situation?

   McCool: IF device says it satisfies profile.. it should satisfy
   the constraints
   ... if intentions of "core" is being part of any profile.. than
   name is fine
   ... out-of-box interop means I need to know whether it
   satisfies the constraints

   Lagally: One can also validate the constraints

   Sebastian: We have to differentiate OOB interop and interop?
   ... benefit: change is high that others implement the same

   Lagally: should not talk about changes but guarantees

   <Zakim> kaz, you wanted to say if we really need to avoid using
   "core" I'm ok with "vanilla", "plain", "minimum", "tiny" or
   anything.
   ... personally "core" is OK for the minimum set of the
   features, though

   Kaz: need for defining what we expect
   ... "core" term might be ok, but terminology should come later
   ... let's defer naming discussions
   ... and start with use-cases and requirements

   <McCool> another possible name would be "common" if we mean the
   "intersection of all constraints needed for interop"
   ... although I think "core" means that, too

   Lagally: We are defining a common ground
   ... should get more concrete

   McCool: 2 comments
   ... 1. should not use interop but OOB
   ... 2. leave name for now OR pick another name (fix it later)
   ... "common" instead of "core"

   Sebastian: suggest naming it OOB also
   ... there are use-cases that do not need profile
   ... Modbus does not need it
   ... very easy protocol
   ... simple datatypes et cetera
   ... there you have already OOB interop

   Lagally: Do you think Modbus constraints are good candidate for
   the data model constraints

   Sebastian: Would recommend it. Very simple. Based on simple
   types...

   McCool: back to discussion that "core" does not contain
   protocol
   ... Modbus is more restrictive than "core"
   ... but that is OK

   Lagally: No-one needs to use maximum constraints

   Koster: oob interop for CoAP and HTTP could be
   ... currently no core that works everywhere

   <McCool> by the way description of "core" in section 1.3 does
   not really match the proposal of not requiring a protocol in
   the "core" profile; you would need the "core" plus at least one
   protocol binding, and the bindings would have to match, to get
   OOBI

   Koster: we should call restrictions WoT-###

   Lagally: main use case
   ... cloud use case
   ... multiple manufactures connect to same cloud
   ... with current flexibility in TD we can implement many
   different variations
   ... generic cloud service is not implementable
   ... without limitations it is not possible

   Koster: Once you make choices it is not anymore broad consensus
   ... we look at the framing
   ... need to agree what the goals are
   ... unsure about the efforts... we are trying device
   specification
   ... like certifications
   ... maybe multiple profiles depending on domain

   McCool: a device clarifies profile... it just works

   Kaz: discussion during this call is great, because we're
   clarifying people's expectations for "profile" from various
   viewpoints
   ... we should clarify our expectation as a whole before diving
   into the details of this initial document
   ... which features, which data models, which technology areas
   and application domains we want
   ... because different parties have different ideas

   Lagally: We agreed on horizontal profile
   ... common ground

   Kaz: like we've been working on the use cases from the
   viewpoint of "horizontal vs vertical", we can think about
   profiles from the viewpoint of "horizontal and vertical"
   ... vertical part could be extension based on industry
   applications while horizontal part could be McCool's mentioning
   "core profile"

   Lagally: let's try to do everything in horizontal

   Kaz: we're not stuck with the name of "core profile" itself,
   but could use another name, e.g., "common", "vanilla", "plain",
   "minimum" or "tiny", for this draft document if needed. right?

   McCool: suggest keep it for now and change later
   ... documentation requirements
   ... developer use case
   ... requirement for templates
   ... do not wanna burden small devices
   ... 1. specification of templates
   ... could contain documentation
   ... let's table "documentation topic"
   ... have it or link to it

   Lagally: let's create issue for it, see Issue#27

   Sebastian: similar discussion in templates.... how much should
   a TD be self-contained

   McCool: developer needs documentation
   ... with tooling it should just work, no human readable
   documentation needed

   McCool/ML: building UI is 3rd use case

   McCool: Offline UI is the 4th use case

   <kaz> [10]Issue 27 - Human readable documentation

     [10] https://github.com/w3c/wot-profile/issues/27

   <McCool> scribenick: McCool

   looking at issue #25

   <kaz> [11]Issue 25 - Comments on "core" profile and scope of
   constraints

     [11] https://github.com/w3c/wot-profile/issues/25

   Ben Francis' comments about applicability of "web" if not using
   URIs, the internet, etc; for instance, Modbus

   Sebastian: modbus does have OOBI though; just need TD
   ... but its constraints are fairly tight
   ... OOBI not so easy for HTTP is since it is much more open
   with many more options
   ... so constraining those options with a profile makes more
   sense

   Lagally: mjk did we cover your points?

   Koster: I think so
   ... but some use cases would help at this point
   ... need some horizontal guidance for people building systems
   from scratch
   ... even across domains
   ... and also for constrained devices, eg limit resources
   ... calling out the protocols that are constrained would be
   useful
   ... see a lot of systems where it would be useful to...
   ... td is part of what helps protocols being interchangeable
   ... but we don't necessarily want to do this for one particular
   use case

   Lagally: let's take this step by step
   ... maybe find common ground for data model
   ... protocols are a different angle, may distract from other
   things, like data models

   Koster: are you talking about payload formats, content
   encodings, or information models
   ... the definition of this varies and may or may not include
   all these things
   ... the power of a TD is that we can standardize/define the
   data model and to separate out and interfchange the protocols
   ... so maybe we are talking about the same thing
   ... what is your thinking about what should be standardized in
   the data model

   Lagally: I think we should not go down into standardizing
   names, etc. but to put some constraints

   Koster: so, for instance, a property can't be arbitrarily
   complex

   Lagally: exactly
   ... certainly many things to debate in the strawman
   ... but there are some suggested constraints on data models
   there

   Sebastian: feedback on that... worried about id field again
   ... had long discussion about id field
   ... second point is security is already mandatory in TD

   Lagally: might be a mistake based on a basis in an old version

   McCool: dates are actually formally defined, in a different
   category than free-form descriptions
   ... there is also room for negotiation around id; the issue was
   really having a central issuing authority
   ... we can allow sessions, randomly generated, DID, UUID, etc.
   maybe we should specific types of ids
   ... maybe "support" should always be an email

   Kaz: regarding "id", we should clarify what kind of ID is
   needed in what kind of cases for what purposes, e.g., "globally
   unique" mentioned here is one possibility but "session-wide
   unique", "application-wide unique", etc., would be also to be
   considered based on the use cases and requirements.

   Lagally: yes, that's related to the lifecycle discussion as
   well.
   ... and then additional field names with meanings, etc.

   McCool: I think we need to handle a certain finite set of
   context extensions, and only those
   ... especially for things with formal meanings, eg data types

   Sebastian: worried that we are extending scope and vocabulary
   too much
   ... my proposal would be to discuss these terms in the TD task
   force to see if they should be included in the core model
   ... would avoid for now bringing these up here
   ... already set up a PR to move these to an issue on the TD

   McCool: I concur; I think we should trim down this strawman as
   much as possible to what we agree on

   Lagally: what kind of timeline are we talking about?

   Sebastian: it will probably take a while

   McCool: propose we use an extension for now, and simply allow
   it in the profile for now
   ... then in the long run, eg TD 2.0, it might move into the
   core vocab

   <mlagally_> [12]https://github.com/w3c/wot-profile/pull/26

     [12] https://github.com/w3c/wot-profile/pull/26

   McCool: I am a little concerned about making this core vocab
   for 1.1 for compatibility reasons

   Sebastian: mention geosparql in pr

   McCool: please note I've listed a bunch in the geolocation use
   case, we should add this, and also consider compatibilty with
   the web API (defined by DAS)
   ... we will have to evaluate and look at dependencies, etc

   Sebastian: I think we have to check and pick an ontology that
   makes
   ... we can decide in the TD model

   <kaz> [13]wot-thing-description issue 941

     [13] https://github.com/w3c/wot-thing-description/issues/941

   Lagally: if someone want to build an OOBI device that uses
   geolocation, what should they do?
   ... let's say october

   McCool: I think if it's october, even TD1.1 will not be out
   yet, so you will have to use an extension
   ... this is fine, to get OOBI we just need to get people to use
   the same extension and allow it in the profile (for backward
   compat)
   ... I think we can agree we don't have consensus, and probably
   we should not be defining new vocab in the profile
   ... we should create an issue and discuss various proposals for
   solving this problem

   Lagally: right now there is chance that people will use
   divergent terms...

   Sebastian: we should be discussing use cases, etc. first

   Lagally: there is a use case for this... it was one of the
   first ones

   Sebastian: but when did we discuss that it should be in the
   profile?

   Kaz: charter says "profiles" are subsets of TDs for
   interoperabilty purposes
   ... so I think we should define requirements for "profiles" as
   subsets of TDs, and then collaboratively discuss what should be
   the subsets of TDs with the TD TF

   Lagally: would not have seen the definition of a pragmatic
   keyword
   ... as being a problem

   Kaz: my point is not whether these keywords or features make
   sense or not
   ... but that we've been discussing requirements, and should
   discuss how to deal with the requirements for subsets of TDs
   with the TD TF

   Lagally: right, that's the main point
   ... ultimately, what I want is these keywords available as soon
   as possible

   Kaz: my assumption is that Sebastian should be OK if we just
   make a proposal to figure out where they should be implemented

   McCool: our Charter says profile should be a subset. If we
   define new terms, it is a superset

   Lagally: ok, agree we should not divergence

   McCool: agree that geolocation is important, but we should
   follow the process and put them in the right place

   Lagally: would it be possible to prioritize geolocation?

   Sebastian: more important than serial numbers, etc.?

   Lagally: together would be nice, but can be decoupling is ok

   McCool: would like to point out this is also needed for
   geospatial queries in directories

   Lagally: would be nice to get into 1.1 for September in the
   FPWD

   Sebastian: will put on the table next Wed
   ... McCool, can you comment on the issue and link in other
   discussion?

   Kaz: btw, we should look at the updated specs about
   geolocation/geospatial terms

   McCool: and maybe a joint meeting with appropriate groups at
   TPAC, eg. DAS, etc.

   Kaz: will talk with plh and ivan about that

   Lagally: ok, agree to merge PR to delete these from strawman
   ... time to adjourn...

   <kaz> fyi, meeting cancellation plans in August
   August 13 - Architecture
   August 11 - PoC
   August 18 - PoC
   August 19 - TD
   August 20 - Use Case and Architecture
   August 26 - TD may be cancelled; will discuss in main call on
   August 25

   [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [14]scribe.perl version ([15]CVS log)
    $Date: 2020/08/10 07:54:09 $

     [14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [15] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 31 August 2020 07:48:03 UTC

This archive was generated by hypermail 2.4.0 : Monday, 31 August 2020 07:48:04 UTC