[TD-TF] minutes - 20 January 2021

available at:
  https://www.w3.org/2021/01/20-wot-td-minutes.html

also as text below.

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

Kazuyuki

---
   [1]W3C

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

                             WoT-WG - TD-TF

20 January 2021

   [2]IRC log.

      [2] https://www.w3.org/2021/01/20-wot-td-irc

Attendees

   Present
          Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan,
          Kaz_Ashimura, Michael_Lagally, Michael_McCool,
          Sebastian_Kaebisch, Tomoaki_Mizushima

   Regrets
          -

   Chair
          Sebastian

   Scribe
          cris, dape

Contents

    1. [3]Agenda
    2. [4]Last minutes - Review
    3. [5]Defer issue to TD 2.0
    4. [6]Propose closing issues
    5. [7]PR 1025
    6. [8]PR 1030
    7. [9]PR 1034
    8. [10]PR 1031
    9. [11]PR 1032
   10. [12]PR 1035
   11. [13]Issue 617
   12. [14]Issue 980
   13. [15]Issue 1002
   14. [16]Issue 972

Meeting minutes

  Agenda

   Cristiano: Talk about ModBus next week

   McCool: Open PRs from my side we might want to look at

  Last minutes - Review

   see [17]https://www.w3.org/2021/01/13-wot-td-minutes.html

     [17] https://www.w3.org/2021/01/13-wot-td-minutes.html

   Sebastian: any objections?
   … none --> minutes approved

  Defer issue to TD 2.0

   [18]https://github.com/w3c/wot-thing-description/
   issues?q=is%3Aissue+is%3Aopen+label%3A%22Defer+to+TD+2.0%22

     [18] https://github.com/w3c/wot-thing-description/issues?q=is:issue+is:open+label:"Defer+to+TD+2.0"

   Sebastian: Please take a look at these issues and raise
   concerns

  Propose closing issues

   Sebastian: Also here, please comment if you see problems
   … so that we can discuss the issues

  PR 1025

   Sebastian: Introduce observeAllProperties and
   unobserveAllProperties, [19]https://github.com/w3c/
   wot-thing-description/pull/1025

     [19] https://github.com/w3c/wot-thing-description/pull/1025

   Sebastian: there was a bug in the PR Victor fixed
   … PR is about adding op for observeAllProperties and
   unobserveAllProperties
   … PR is ready to be merged
   … arghhh, merge conflicts
   … w.r.t. SVG images
   … fixing it right away
   … any objections before merging?
   … none -> merging...

  PR 1030

   [20]https://github.com/w3c/wot-thing-description/pull/1030

     [20] https://github.com/w3c/wot-thing-description/pull/1030

   Daniel: respec warnings only

   Sebastian: looks good to be merged

  PR 1034

   [21]PR 1034

     [21] https://github.com/w3c/wot-thing-description/pull/1034

   Sebastian: introduced new chapter about link relation types
   … not completed yet
   … the values in link relation table are coming from IANA
   … should re-use them as much as possible
   … e.g., "service-doc"
   … e.g., "alternate" representation like RDF, HTML et cetera

   McCool: link type for directory federation?
   … "proxy-to" to be used?
   … not sure if this is right

   Sebastian: First set at the moment
   … might need to improve
   … we have requirement document

   <mlagally_> Will be back in 5 mins

   <sebastian> [22]https://github.com/w3c/wot-architecture/blob/
   master/REQUIREMENTS/link-relation-types.md

     [22] https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/link-relation-types.md

   <cris> +1 also from my side

   McCool: What about non IANA types?
   … do we propose to add them to IANA?

   Sebastian: There is a column indicating the source.. IANA or
   any other place
   … "extend" coming from WoT Thing Model

   McCool: what about "implements" ?
   … seems important to me
   … for geo-location we need to point where location is

   Lagally: Thanks for addressing the link type comment
   … surprised about being "informative"
   … shouldn't it be normative?
   … we need column about cardinality also
   … e.g., multiple inheritance: 1 or *

   McCool: we need a decision about each

   Sebastian: Makes sense

   Ege: would see link table in Chapter 5

   Sebastian: Was thinking about it also...
   … in/under 5.3.4.1 ?
   … have examples in *new* Section 11
   … where should examples go?

   Ege: In chapter 6 there are already examples

   McCool: Note: "controlledBy" is not yet in the list but in
   example
   … "assembly" is another type

   Lagally: will it ever make sense to have one of this links
   mandatory?

   McCool: in certain contexts, like profiles...
   … in general making them mandatory causes backward
   compatibility issues

   Lagally: Makes sense

   Sebastian: will keep working on the PR

   Ege: in some cases people combine keys

   Sebastian: multiple rel values?
   … yes, I have seen that
   … do we want to allow that?

   McCool: Isn't "link" define somewhere.. what does the RFC say
   … alternative is to duplicate link with different rel type

   Koster: RFC 8288 talks about it

   Ege: "+" used to give further precision
   … will try to find more information

   McCool: "+" in relation names may cause problems
   … "-" is allowed in name

   Sebastian: Let's try to find out more

  PR 1031

   [23]https://github.com/w3c/wot-thing-description/pull/1031

     [23] https://github.com/w3c/wot-thing-description/pull/1031

   <mlagally_> (signing off)

   McCool: PR not complete yet
   … rendering is not working

   Daniel: had same issue, not recalling where to put the
   content.. i guess some parts need to be duplicated

   McCool: Will contact Victor
   … w.r.t. content
   … APIkey vs. PSK
   … APIkey cloud service provider example
   … expanded the description
   … PSK meant when you have standard for key
   … add cypher-suite parameter?
   … in both cases key should be put in TD
   … no assertion ... but we should discourage it
   … Ege can you check my work

   Ege: commented already

  PR 1032

   [24]https://github.com/w3c/wot-thing-description/pull/1032

     [24] https://github.com/w3c/wot-thing-description/pull/1032

   McCool: key as part of URI
   … see Philips hue
   … parameter map pointing will be updated in PR
   … replace with actual set of data schema
   … still WIP
   … I also added explainations
   … extend body to allow more
   … maybe in a seperate issue/PR
   … also, rendering is not working

  PR 1035

   [25]https://github.com/w3c/wot-thing-description/pull/1035

     [25] https://github.com/w3c/wot-thing-description/pull/1035

   Sebastian: multiple op in forms
   … PR gives some kind of guidelines for HTTP
   … there is an example in the PR that shows how to create
   multiple forms
   … for htv:methodName

   Cristiano: looks good to me
   … I am wondering about other protocols
   … maybe have dedicated section in each binding about the
   limitation

   Sebastian: Did not think too much about other protocols yet

   Cristiano: Should find a place for such things... in bindings?

   Sebastian: Yes, should get some experience
   … we are missing the big picture

   Daniel: CoAP would have the same limitation

   Sebastian: Correct, but CoAP is not defined in TD

   Koster: It comes down to how defaults are defined for bindings
   … MQTT could be also such a use case
   … up to bindings to specify defaults
   … for MQTT no command would be required

   Ege: MQTT defaults are up to version 5

   Cristiano: for forms, contentType gets duplicated also?

   Sebastian: Yes, any other metadata should be duplicated also

   <cris> Ok to merge +1

   Sebastian: shall we merge PR?

   Koster: don't see any issues

   Sebastian: relates to a relatively old issue 712
   … -> let's merge then

  Issue 617

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

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

   McCool: No PR yet, working on it

  Issue 980

   <McCool> (have to drop, ttyl)

   [27]https://github.com/w3c/wot-thing-description/issues/980

     [27] https://github.com/w3c/wot-thing-description/issues/980

   Sebastian: schema definition using wrong type
   … issue seems still existing
   … should be fixed
   … I will provide a PR

  Issue 1002

   [28]https://github.com/w3c/wot-thing-description/issues/1002

     [28] https://github.com/w3c/wot-thing-description/issues/1002

   Sebastian: ML asks for term "reliability"
   … correct vs false readings

   CA/Ege: use existing ontologies

   Sebastian: "reliability" comes with multiple different meanings
   … hard to generalize
   … I don't think we should introduce it in core TD
   … should have a discussion with ML

   Koster: "reliability" added where?
   … associated to value?
   … having a model makes sense to me
   … as value constraints it might be useful

   Sebastian: Suggest using existing ontologies

   Koster: reliability for values might make sense

   Sebastian: Is there a standard way? Percentage value?

   Koster: it is usually some number of 999 / percentage
   … there are different ways
   … mean-time failures
   … bunch of different types

   ... what kind of information do we need then?
   … the main use case would be to get reliable data from
   unreliable sensors
   … I think it is a good case

   Sebastian: I think we need Michael Lagally here

   <kaz> [29]IEC 61360 Common Data Dictionary V2.0014.0017 -
   liability of an item

     [29] https://cdd.iec.ch/cdd/iec61360/iec61360.nsf/SearchFrameset?OpenFrameSet

   Kaz: we could use this linked ontology
   … or at least ask the IEC group for use cases and how to use
   their ontologies.

   Sebastian: good

   Kaz: We should define a policy for the Thing Description model.
   like how to introduce new terms, because we can't define
   everything and TD should concentrate on the basic framework
   based on the affordance model.

   Sebastian: I agree. If this term can be generalized we could
   employ it. But it is not easy

  Issue 972

   <kaz> [30]Issue 972

     [30] https://github.com/w3c/wot-thing-description/issues/972

   Sebastian: about issue 972 we are discussing about a json
   schema for TM
   … I think we could postpone the discussion since daniel is not
   here
   … maybe Cristiano has any input?

   Cristiano: basically now a Thing Model is really similar to a
   Partial TD. In the future the TM may has more requirements.
   Which field should we require in a TM?

   Sebastian: good question, right now I don't have a clear answer
   we should talk more in the future calls.

   Sebastian: maybe @context could be required

   Koster: we could even have multiple templates in the Schema

   Sebastian: right, let's continue the discussion in the next
   meeting

   <kaz> [adjourned]


    Minutes manually created (not a transcript), formatted by
    [31]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

     [31] https://w3c.github.io/scribe2/scribedoc.html

Received on Wednesday, 3 March 2021 10:03:34 UTC