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

[TD-TF] minutes - 12 August 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 07 Sep 2020 17:58:26 +0900
Message-ID: <87h7saklot.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/08/12-wot-td-minutes.html

also as text below.

Thanks a lot for takin the minutes, Taki!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                             WoT-WG - TD-TF

12 Aug 2020

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#August_12.2C_2020

Attendees

   Present
          Kaz_Ashimura, Cristiano_Aguzzi, Sebastian_Kaebisch,
          Taki_Kamiya, Daniel_Peintner, Michael_McCool,
          Tomoaki_Mizushima, Michael_Koster

   Regrets

   Chair
          Sebastian

   Scribe
          TK

Contents

     * [3]Topics
         1. [4]Meeting schedule
         2. [5]Issue #941
         3. [6]PR #896.
         4. [7]PR #938 about TDT
         5. [8]PR #943.
         6. [9]PR #945
         7. [10]PR #944
         8. [11]Issue #930
         9. [12]PR #927 on OAuth2
        10. [13]Meeting plan
     * [14]Summary of Action Items
     * [15]Summary of Resolutions
     __________________________________________________________

   <taki> scribeNick: taki

Meeting schedule

   Sebastian: Next week, there is no TD call. on August 19, there
   might be one.
   ... Sept 3rd, we are going to have one.

Issue #941

   <inserted> [16]Issue 941

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

   Sebastian: There are terms in Profile that not covered by TD
   models.
   ... we have to clarify use case, and which terms need to be in
   TD.
   ... not sure about serial number and revisions.

   McCool: there is a geo-location use case.
   ... we should adopt existing standards.

   McCool mentions a couple of standards...

   McCool: accuracy etc. are discussed in use case.
   ... Consistency with Web API is important.
   ... wrt. installation location and data of returned value.
   ... note datatype issue string vs. number.

   McCool points us to use case URL...

   <McCool__>
   [17]https://github.com/w3c/wot-usecases/blob/master/USE-CASES/s
   martcity-geolocation.md

     [17] https://github.com/w3c/wot-usecases/blob/master/USE-CASES/smartcity-geolocation.md

   McCool: "smartcity-geolocation.md" is the file name.

   McCool browses the use case.

   McCool: there are standards mentioned.
   ... Basic Geo Vocabulary, WGS84, etc.
   ... This document needs to be updated with regards to
   GeolocationSensor interface based on the Generic Sensor API.

   McCool explains Geo-location API...

   Sebastian: how about height and depth?

   McCool: it is synonym with altitude.
   ... altitude is relative to sea level, which may be complicate.

   Sebastian: Does it depend on stadards?
   ... ISO standard.

   McCool: sparql also should be added to geo-location use case.

   <kaz> [18]Geolocation Sensor API based on Generic Sensor
   approach

     [18] https://w3c.github.io/geolocation-sensor/#geolocationsensor-interface

   McCool: any ontology we adopt needs to be consistent with
   geo-location API.

   Kaz: As I mentioned the other day, this is a good topic to
   discuss with Devices and Sensors WG and Spatial Data on the Web
   IG.

   McCool: should we specify ontology or reference external one?

   Sebastian: We can make a container at the top level.

   McCool: we probably should not allow partial geolocation

   Cristiano: geo-location is important to agriculture.
   ... altitude is from sea-level. Depth is from terrain.

   McCool: height is useful, then. In addition to altitude.
   ... We can say "dig down 6 feet".

   Cristiano: Local values are useful in reality.

   McCool: In addition, we need o define units.

   Sebastian added a comment in issue #941 to summarize the
   discussion.

   McCool: geo-location API is not in RDF form yet.
   ... Singapore people use the geo-location API.

   Sebastian: serialNumber is in schema.org.

   McCool: We should split issue #941 into two.
   ... serialNumber depends on manufacturer.
   ... The issue has privacy implication.
   ... we can make it optional. People may want to put into
   database, however.
   ... "link" field. We can have "ref" and "url" type for that.
   ... Manufacturer also needs to be defined.
   ... Note there can also be "tracking number".

   <kaz> [19]new issue 946 on serialNumber

     [19] https://github.com/w3c/wot-thing-description/issues/946

   Sebastian: HW/SW revision numbers. We already have VersionInfo.

   McCool: version of TD vs HW/SW.
   ... We can put them in VersionInfo.
   ... We should create an issue for this.
   ... We need to be careful about fingerprinting based on HW/SW
   versions.

   <kaz> [20]TD spec - 5.3.1.6 VersionInfo

     [20] https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/#versioninfo

   Sebastian: also related to security?

   McCool: Yes. If you know version, you can exploit that.
   ... and there is a tracking risk.
   ... You can filter out information when TD goes out of
   directory.
   ... and they should be optional.

   <kaz> [21]new issue 947 on hardwareRevision and
   softwareRevision

     [21] https://github.com/w3c/wot-thing-description/issues/947

   Sebastian summarizes #941 discussion...

   <mjk__> [22]https://schema.org/GeoCoordinates

     [22] https://schema.org/GeoCoordinates

   Koster: How does it look like when you talk about container?

   Sebastian: It is JSON container like securityDefinition.

   Koster: It is a component of TD, as a stanza.

   <kaz> [23]TD spec - 6.3.3 version

     [23] https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/#version-serialization-json

   Koster: About the thing, not about TD such as manufacturer.

   McCool: we can make geo-location optional by using container.

   Koster: Location, manufacturer, etc. In Zigbee, there is
   cluster. TD is missing those component-oriented mechanism.
   ... I am concerned about bloating TD too much.

   <kaz> [24]geolocation information on schema.org

     [24] https://schema.org/docs/search_results.html?q=geolocation

   McCool: There are two use cases. Installation location and data
   annotation. I mentioned earlier.
   ... I agree with component issue.

   Koster: We can plugin at data model level.
   ... Where should we discuss this issue?

   Sebastian: We are not inventing new geo-location.
   ... Where is the source that we can evaluate and use? We should
   not introduce something others are doing in other ways.
   ... Has it been discussed in One Data Model?

   Koster: Yes. OCF, OMA, etc. We have been in the process of
   converging them.

   McCool: RDF mapping may be a good start, given that there are
   several well defined standards.

   Sebastian: Do you have a reference to One Data Model
   discussion?

   <McCool__> McCool: specifically, the WGS standard and the ISO
   standard based on it; although we may have to add things like
   "height"

   Koster: I agree that a good RDF base reference is needed if we
   can provide it for others to use also and coordinate it with
   the other groups

   <mjk__> [25]https://schema.org/GeoCoordinates

     [25] https://schema.org/GeoCoordinates

   Kaz: Schema.org may be a good place to start with.

   McCool: I will update the use case.

   Koster: there needs to be a basic RDF ontology that One data
   model can make a reference to for geo-location, temperature,
   etc.

   <inserted> scribenick: kaz

   mjk: if some data type is super interesting like geolocation
   data, it should be useful to the others as well

   mm: right. not only for us

   <inserted> scribenick: taki

   Koster: we can define a profile, where we can define these for
   interoperability.

   McCool: We can define preferred extension there.

   Koster: We need extension point defined.

   Sebastian shows GeoLocation in schema.org, and check "geo"
   container.

   <kaz> [26]GeoCoordinates page (click "JSON-LD" tab within
   Example 2)

     [26] https://schema.org/GeoCoordinates

   Cristiano: We can define extension for geo-location on top of
   core.
   ... I saw that pattern in NGSI-LD.

   McCool noted a comment from Ben.

   <Zakim> kaz, you wanted to time check

   McCool: Ben thinks it should not be in core.

PR #896.

   <kaz> [27]PR 896

     [27] https://github.com/w3c/wot-thing-description/pull/896

   Sebastian: contentMediaType and contentEncoding were added.
   ... Cristiano, please check.

   Cristiano: I will.

PR #938 about TDT

   <inserted> [28]PR 938

     [28] https://github.com/w3c/wot-thing-description/pull/938

   Sebastian: I started to formalize TDT in #938.
   ... In definition section, I introduce TDT to reflect
   discussion in architecture meeting.
   ... I added some examples to show TDT does not have some
   fields.
   ... I also introduced placeholder concept.
   ... with an example.

   McCool: "may not include" means "must not". We can clean up
   normative statements.
   ... OAuth does not necessarily define URL. We want to say "may
   not contain".
   ... we can simply say "may contain" in positive form.

   Sebastian: OK.
   ... I will add McCool as a reviewer.
   ... Rendering tool still does not work correctly. Victor and
   Daniel are working on this.

   <mjk__> [29]https://tools.ietf.org/html/rfc2119

     [29] https://tools.ietf.org/html/rfc2119

   McCool: I will review.

   Sebastian: Please everyone review #938.

PR #943.

   McCool: we may need to wait till TD 2.0.
   ... Should we use extension point, or include in core TD?
   ... Hash function of content of TD, to avoid attacks.
   ... getting into version 1.1 would be great.
   ... I could not find in respec.
   ... for an entry for LD-proof.
   ... version 1,0 TD, people need to explicitly define extension
   vocab for this.
   ... set vs array. Serialization needs to preserve order for
   this to work.
   ... Set can be serialized into array.
   ... We should clearly separate set vs. array.
   ... This is still in WIP.
   ... For 1.1 FPWD, we may not ready to include this.
   ... We are going to discuss in Security TF first.

   Sebastian: Let's discuss in September again.

PR #945

   <inserted> [30]PR 945

     [30] https://github.com/w3c/wot-thing-description/pull/945

   McCool: Right now security is array of strings.
   ... We need compact form simple use case.
   ... we can allow inline security definition.
   ... Ege and Ben think this is good idea.
   ... Parsing may become a bit more complex.

   Sebastian: Security definition becomes optional.

   McCool: We can have one line with nosec.
   ... It does not have to be FPWD.

PR #944

   <inserted> [31]PR 944

     [31] https://github.com/w3c/wot-thing-description/pull/944

   McCool: "and" in WoT, "or" in OpenAPI when multiple security
   schemes.
   ... "and" is consistent with our purpose.
   ... We need "or" method.
   ... we can use "oneOf".
   ... I have not created ontology yet.
   ... We are going to review in Security TF first.

   Sebastian: no impact on ontology.

   McCool: It does.
   ... rendering script may need to be updated.
   ... type field is a string or security scheme, or array of
   security schema.
   ... I do not know how to do that in ontology.
   ... and the script needs to interpret this.

Issue #930

   <kaz> [32]Issue 930

     [32] https://github.com/w3c/wot-thing-description/issues/930

   McCool: In Digital Twin, "model" is used. "template" sounds
   hacky.
   ... TDTD for directory of TDT?

   Sebastian: Thing Model Description.

   McCool: We can drop "description" for model.

   <inserted> Kaz: yeah, and that ("Thing Model") implies it's an
   abstract version of "Thing Description"

   Sebastian: We use "Thing Description Template" in version 1.0.

   Kaz: We can add a note saying we used to call it "Thing
   Description Template" in TD ver. 1 and have renamed it to
   "Thing Model".

   Sebastian summarized discussion in issue #930.

   Koster: "Model" makes sense.

   McCool: Lagally saw other use cases for "template", and
   proposed to change "model".

   Koster: Thing fragments, etc. there are lots of templates.
   ... Model can define constraints description at model level.

   <McCool__> mccool: probably each use case should be given a
   distinct name: Thing Query Fragment, Partial Thing Description,
   etc.; for future work, avoid reusing TDT to avoid confusion

   Sebastian: In version 1.1, we are going to use this name. TDT
   (i.e. model) is more important in 1.1. Any objectons?

   McCool: Lagally would agree to this.

   <sebastian> proposal: we will rename "Thing Description
   Template" to "Thing Model" for the TD 1.1

   RESOLUTION: we will rename "Thing Description Template" to
   "Thing Model" for the TD 1.1

PR #927 on OAuth2

   <inserted> [33]PR 927

     [33] https://github.com/w3c/wot-thing-description/pull/927

   McCool: PR #927.
   ... we have reviewed in Security TF.
   ... I propose to go ahead to merge.
   ... We can fix cosmetic problems later.
   ... password flow should use extension.
   ... there is an editor's note.
   ... I will create another issue addressing remaining small
   issues after merging this PR.

   Sebastian: It has been reviwed in security TF.

   Sebastian merged #927.

   Sebastian created issue #948.

   <kaz> [34]Issue 948

     [34] https://github.com/w3c/wot-thing-description/issues/948

   Sebastian created issue #949 for vocabularies for implicit and
   password flows.

   <kaz> [35]Issue 949

     [35] https://github.com/w3c/wot-thing-description/issues/949

   Sebastian: We are done with today's agenda.
   ... something else?

Meeting plan

   Sebastian: TK will decide about a meeting in 2 weeks.
   ... I will be back in September.

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

    1. [36]we will rename "Thing Description Template" to "Thing
       Model" for the TD 1.1

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [37]scribe.perl version ([38]CVS log)
    $Date: 2020/08/17 08:07:36 $

     [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [38] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 7 September 2020 08:58:31 UTC

This archive was generated by hypermail 2.4.0 : Monday, 7 September 2020 08:58:31 UTC