[TD-TF] minutes - 16 December 2020

available at:
  https://www.w3.org/2020/12/16-wot-td-minutes.html

also as text below.

Thanks a lot for taking the minutes, Taki!

Kazuyuki

---
   [1]W3C

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

                             WoT-WG - TD-TF

16 Dec 2020

   [2]Agenda

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

Attendees

   Present
          Kaz_Ashimura, Sebastian_Kaebisch, Jack_Dickinson,
          Taki_Kamiya, Michael_Koster, Daniel_Peintner,
          Tomoaki_Mizushima, Victor_CHarpenay, Ryuichi_Matsukura

   Regrets
          Michael_McCool, Michael_Lagally

   Chair
          Sebastian

   Scribe
          Taki, Kaz

Contents

     * [3]Topics
         1. [4]Minutes
         2. [5]Issues with "Defer to TD 2.0" labels.
         3. [6]Technical Discussion
         4. [7]Issues
         5. [8]Issue #774. TD producer field in TD.
         6. [9]Issue 712
         7. [10]Issue 617
     * [11]Summary of Action Items
     * [12]Summary of Resolutions
     __________________________________________________________

   <taki> scribeNick: taki

Minutes

   <inserted> [13]Dec-9

     [13] https://www.w3.org/2020/12/09-wot-td-minutes.html

   Sebastian going through 2020-12-09 minutes...

   Sebastian: We will be making prototypes for bindings, to make
   separate documents for various protocols.
   ... #1007. We decided to keep it as it is.
   ... #800. We forgot to include those options before.
   ... Minutes were approved.

Issues with "Defer to TD 2.0" labels.

   Sebastian: We will consider them in new versions. They may have
   impact on compatibility.
   ... I plan to work more on this list. Please take a look at the
   current list, and make comments.

Technical Discussion

   Sebastian: There was a meeting with IETF SDF group this week.
   ... We did not have deep discussion. We want to dicuss on SDF
   and TD.
   ... We can consider OneDM as TD's model.
   ... I created an issue #903 a back while.
   ... Can Koster give us update on the latest discussion?

   Koster: Yes. I can go over use cases, refreshing everyone. IoT
   data models, Zigbee, TD, IoT Schema, Bluetooth, OMA, OCF, etc.
   We came up with common model.
   ... Common goals became clear among them including Mashup. TD
   and iotschema were candidates.
   ... There was a language requirements. RDF was considered but
   not selected.
   ... Reusability. Define once and use many times.
   ... It cannot be tied to specific data schema and
   representation.
   ... Realign with existing 13 practices.
   ... event/action/properties classes are common across.
   ... they seem to map well everywhere.
   ... You can bind them to protocols.
   ... "Mapping files" can specify additional constraints for
   protocols.
   ... As with TD, SDF is declarative.
   ... with semantic anchors (JSON pointer)
   ... SDF has a way to make consistent URI.
   ... SDF has required/optional events.
   ... similar to JSON schema, but be brought to higher level.
   ... We added enumeration in version 1.1

   Sebastian: Mapping file. Does it have its own format?

   Koster: I have an example. it is key-value pair using JSON
   pointer. each entry adds/modify existing entry.
   ... You can add Zigbee constant 8 in mapping file, for example.
   ... We can consider inline mapping file as well in the future.
   ... Mapping files can contain hints such as the way to map
   properties.
   ... That way you can separate general part from specific part.

   <Zakim> dape, you wanted to expressiveness

   Daniel: Expressiveness difference. SDF can contain several
   things. SDF can result in several multiple TDs. Is this on
   purpose?

   Koster: SDF has a few more classes that are not present in TD.
   Things that have multiple capability. We found them from
   existing models.
   ... TD does not have Object. Light valves, can have
   capabilities.
   ... TD can use annotations for this.
   ... We decided to have Objects in SDF instead.
   ... Thing could be a composition of other Things in TD.
   ... Zigbee light valve using TD, we will face this issue.

   Daniel: it makes sense.

   Koster: It is going to be an interesting exercise to see if
   there are issues such as conflicts.

   Sebastian: We also have linking concepts.

   Koster: Yes. In LwM2M, we use links for structure.

   Kaz: How to deal with externally defined vocabularies and how
   to refer to them?

   Koster: SDF allows to use namespace feature. Uri-prefix works.
   ... We need to make an external server to make dereferences
   into a single file.

   Kaz: In that case, intermediate format can be quite similar to
   TD.

   Koster: Light switch model. You can get SDF for that. And then
   convert to TD with annotation.

   Kaz: Thank you.

   Koster: SDF is very much like iotschema. We can convert SDF to
   iotschema very easily.
   ... iotschema can refer back to SDF with annotations.
   ... How to make a forward reference from SDF to iotschema is an
   issue.

   Sebastian: I will come back in 5 minutes or so.

   Koster: SDF object file can be a single a model. They can be
   composed into TD.
   ... SDF can be used as Semantic proxy between for example, OCF
   and TD.

   Sebastian: We have abstract definition of SDF, translating to
   TD with protocol binding. We need to clarify.

   Sebastian will come back shortly...

   Kaz: We can take a short break...

   Taki: "We need to use some examples to translate abstract
   definition of SDF into Thing Model, to obtain TD with protocol
   binding. "

   Daniel: I saw examples. The term changed?

   Koster: Yes. SDF objects with optionality can also be looked
   at.

   Sebastian is back...

   Koster: I proposed to create two Zigbee/Dotdot examples with
   optionality.

   <kaz> [14]wot-thing-description Issue 903

     [14] https://github.com/w3c/wot-thing-description/issues/903

   Sebastian: We can also use the workflow, and explain it. We can
   refer to SDF definition from examples.

   Koster: I will provide examples including On/Off light valve
   example.

   Sebastian: I would like to assign this task to Koster.

   Koster: We can consider a feature to import SDF into TD editor.

   Sebastian: Plugin feature can be considered in the editor.

   Koster: We can test mapping files in that effort.
   ... We can make a standard/customized mapping files based on a
   single SDF.

   Sebastian: I plan to provide a chapter on generation of TD from
   Thing Model with examples including a SDF example.

Issues

Issue #774. TD producer field in TD.

   Sebastian: Information on implementations of TD producers.

   <kaz> [15]Issue 774

     [15] https://github.com/w3c/wot-thing-description/issues/774

   Sebastian: Similar to server term in HTTP.

   Sebastian shows an example "Apache/1.3.27 (Unix)..."

   Sebastian: In the form of tdProducer: mode-wot/0.7.1 in TD.
   ... A use case. for debugging purpose.

   Koster: can be used forensic analysis.
   ... I do not see a strong need for this.

   Kaz: Not sure if it would really make sense in TD context.
   ... We should be careful.

   <kaz> scribenick: kaz

   Koster: there could be security issues too

   Sebastian: right
   ... (adds comments to issue 774)
   ... we should not add this feature now
   ... maybe for 2.0 version

   Kaz: possibly

   Sebastian: (assign @mmccool for the possible security concerns)

   [16]Sebastian's comments

     [16] https://github.com/w3c/wot-thing-description/issues/774#issuecomment-746593562

Issue 712

   [17]Issue 712

     [17] https://github.com/w3c/wot-thing-description/issues/712

   Sebastian: think this is already solved

   Daniel: yeah, it's very old

   Sebastian: (goes through the issue)

   Koster: prefer not using this parallel processing

   Kaz: +1

   Sebastian: (shows example 32)

   [18]Example from the TD 1.0 REC

     [18] https://www.w3.org/TR/wot-thing-description/#example-32

   Sebastian: we could allow this simpler expression:

   "forms": [{
     "op": ["readproperty", "writeproperty"],
     "href": "https://mylamp.example.com/status"
   }]

   Sebastian: to be converted to:

   "forms": [{
     "op": "readproperty",
     "href": "https://mylamp.example.com/status",
     "htv:methodName": "GET"
   },
   {
     "op": "writeproperty",
     "href": "https://mylamp.example.com/status",
     "htv:methodName": "PUT"
   }]

   Kaz: technically, human beings can convert that based on our
   own knowledge on HTTP methods
   ... however, it would require all the TD processors to know
   about any kind of protocol methods

   Sebastian: right
   ... (adds comments to Issue 712)
   ... there should be also procedure description how the
   transformation to the default representation
   ... I can provide a PR for that

   [19]Sebastian's comments

     [19] https://github.com/w3c/wot-thing-description/issues/712#issuecomment-746614965

Issue 617

   [20]Issue 617

     [20] https://github.com/w3c/wot-thing-description/issues/617

   Sebastian: array for response in the From class
   ... changing it to array of responses
   ... Farshid gave a comment

   [21]Farshid's comment

     [21] https://github.com/w3c/wot-thing-description/issues/617#issuecomment-665105127

   Kaz: do we have any concrete use case for this?
   ... and did we check that during our Plugfests?

   Sebastian: don't think so
   ... possible use case might be having multiple content types

   Kaz: sounds like a use case of fallback with some errors

   Koster: possibly switching servers based on those errors

   Sebastian: might be useful but would break backward
   compatibility...
   ... so wondering how this need is urgent
   ... possibly related to discovery too
   ... having multiple entries for "response"

   Kaz: yeah
   ... if the possible use case has urgent importance from some
   business viewpoint, we should think about this
   ... but if not, can be deferred

   Sebastian: (adds comments)
   ... we'll ha a backward compatibility issues
   ... should talk with the Discovery TF to clarify the need

   [22]Sebastian's comments

     [22] https://github.com/w3c/wot-thing-description/issues/617#issuecomment-746637603

   Sebastian: would close the call now :)
   ... thanks a lot for your hard work and great contributions!

   Kaz: the next TD call will be on 13 January 2021. right?

   Sebastian: exactly

   [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [23]scribe.perl version ([24]CVS log)
    $Date: 2021/01/27 09:42:30 $

     [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [24] http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 27 January 2021 09:42:47 UTC