[TD-TF] minutes - 10 February 2021

available at:
  https://www.w3.org/2021/02/10-wot-td-minutes.html

also as text below.

Thanks a lot for taking the minutes, Cristiano!

Kazuyuki

---
   [1]W3C

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

                             WoT-WG - TD-TF

10 February 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Feb_10.2C_2021
      [3] https://www.w3.org/2021/02/10-wot-td-irc

Attendees

   Present
          Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan,
          Jack_Dickinson, Kaz_Ashimura, Michael_Koster,
          Sebastian_Kaebisch, Tomoaki_Mizushima

   Regrets
          -

   Chair
          Sebastian

   Scribe
          cris

Contents

    1. [4]agenda
    2. [5]previous minutes
    3. [6]master to main
    4. [7]bindings
    5. [8]PR 1032
    6. [9]PR 1024
    7. [10]issue 1020
    8. [11]adding term for stream of data

Meeting minutes

  agenda

   Sebastian: today we have to discuss about the migration from
   master to main, protocol bindings and Github PRs/issues
   … something else?
   … ok

  previous minutes

   Sebastian: we discussed modbus binding document and PRs

   <kaz> i|discussed|[12]Feb-3|

     [12] https://www.w3.org/2021/02/03-wot-td-minutes.html

   Sebastian: notice now we are able to define multiple responses
   in TDs
   … also we discussed about different topics around the Thing
   Model
   … we still need a jsonschema for Thing Model
   … any objections to publish the minutes?
   … ok

  master to main

   Sebastian: there are some issues in the process of renaming
   … Michael McCool is working on it.
   … in a couple of weeks it should be solved
   … any comments?

   Daniel: I'm not sure what will happen to open PRs

   Sebastian: good point. let's wait for Michael's input on the
   issue

  bindings

   Sebastian: modbus, any news?

   Cristiano: sorry I am in late. let's discuss it next week

   Sebastian: ok

   Sebastian: then we have OPC-UA binding. As you now there's a
   liaison between our group and OPCF but there's still not common
   activities
   … I think it's a good time to start a collaboration with them
   … the motivation is that we can use TDs to describe OPC
   endopoints
   … it is the same motivation of other bindings.
   … I know that opc ua is not so common in the web domain, but it
   is wide known in the industry field

   Sebastian: I think the work is minimal. we can use the other
   documents as example
   … it is important to evaluate the security patterns in OPC-UA
   … the outcome should be a document, an ontology and finally a
   prototype.

   Kaz: Do you want to talk about the liaison with OPC-UA today?

   Sebastian: yes, it was my intention

   Kaz: I have some trouble to understand this proposal. In my
   understanding concrete binding document should be handled by
   external organizations (like OPCF). Why do we need a joint
   specification work?
   … if we go down that path we should do the same also for other
   bindings (mqtt, Fiware, etc.)

   Sebastian: then I can ask why do we have this liaison
   … ?

   Kaz: it is mostly for discussion about implementation and
   use-cases
   … we don't need a joint specification
   … work

   Sebastian: we can ask the OPCF to do the work in their
   Companion specification document.
   … however the document would be difficult to connect with W3C
   and WoT
   … OPCF is comparable in size to W3C. They have their management
   process to update spec and it could be a problem if our
   specification disalign with theirs.

   Kaz: we could start from an integration of a OPC-UA device to
   WoT in a PlugFest
   … but first we have to start to actual need for this
   integration

   Ege: the benefit could be to prove again that the WoT could be
   applicable in this field too
   … a joint specification is more powerful

   Sebastian: agree
   … it is a way to have more impact in the industry domain
   … it is kinda a marketing aspect
   … the joint work is helpful to have aligned solution in both
   organizations

   Kaz: I am not objecting to the liaison itself. I am always open
   to discussion with external organization. However, I wonder if
   the joint specification is really needed. We should start from
   plugfest.

   Kaz: we should start from discussion with the group and then
   extend the liaison to the next level (e.g., joint specification
   documents)

   Sebastian: so which is the concrete next step here?
   … we already had some discussion with the opcf group
   … I need a concrete next step suggestion

   Kaz: based on the discussion we had, we can start from the
   plugfest integration
   … why can't we start from plugfest?

   Sebastian: option 1: UA foundation create a sub group for the
   definition of the protocol binding. Option 2 work together. I
   like option 2 more.

   Kaz: we could start discuss about the collaboration

   Sebastian: did you join the meeting about the validation?
   … I can share slides. I think we already did this kind of
   pre-work

   Koster: my advice is to continue the work on the spec
   separately under the current simple liaison
   … maybe later join together

   <kaz> kaz: exactly

   Sebastian: which is the advantage?

   Koster: I don't see this option as a disadvantage. The
   disadvantage is that the joint spec open some IP problems

   Daniel: W3C WoT WG generates W3C specs and OPC UA generates OPC
   specs, so no IPR problems there
   … correct?

   Sebastian: it should. all the content from the companion spec
   should be hosted publicly in a w3c site.

   Kaz: we could refer to existing ontologies in our document
   safely
   … for a joint spec we need to discuss the process beforehand

   Sebastian: maybe we are on the same page
   … starting from the ontology. It should be generated by the
   OPCF or from some expert from that group. It is not our job
   … I'd expect this as the main outcome
   … the ontology could be hosted in OPC UA side

   Koster: do we need to claim authorship of this joint spec?who's
   responsible for it

   Sebastian: right

   <kaz> [13]WebRTC REC - collaboration between W3C and IETF

     [13] https://www.w3.org/TR/2021/REC-webrtc-20210126/

   Sebastian: we need just the ontology

   <kaz> [14]Spatial Data on the Web Best Practices -
   collaboration between W3C and OGC

     [14] https://www.w3.org/TR/2017/NOTE-sdw-bp-20170928/

   Sebastian: then our work is to describe how to map those
   concepts and network communication with an OPC UA device.
   … ok, I'll take some time to think about it. Probably we could
   start from the Companion specification and contribute there

   Kaz: I shared two examples
   … as you can see collaboration can happen
   … for example ogc and w3c published a joint note

   Sebastian: we can considered this option
   … like a joint document where to describe the vocabulary

   Kaz: based on the discussion today, my impression on the
   relationship between w3c and opcf is similar to w3c and IETF.
   We can simply acknowledge opcf work citing their vocabulary
   ontology, etc.

   Kaz: we could invite experts in our binding call and work
   together

   Sebastian: so should I delete the current draft document?

   Kaz: we can continue the discussion under the current liaison
   with opc-ua. Starting from this document.
   … maybe just rename charters to liaison. Or rather move to a
   proper location
   … the document is a good starting point

   Sebastian: thank you for the input

   Kaz: I think there is a possibility of a joint specification
   but only when we identify a substantial missing building block.

  PR 1032

   <kaz> [15]PR 1032 - Add URI template location for security
   scheme parameters

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

   Sebastian: number 1032 uri template for security scheme
   parameters

   Sebastian: the approach here is similar to uriVariables
   … in the text there's a clarification about how to solve
   possible name conflicts
   … I am ok merging this

   Cristiano: I am afraid to have a lot of similar mechanisms for
   the same thing

   Cristiano: it might be difficult to read

   Sebastian: the thing model has templating but it has a clear
   different scope

   Sebastian: currently we don't have a better idea

   Daniel: I kinda of agree with Cristiano. I wonder now weather
   to put placeholder in other document at all

   <kaz> [16]Sebastian shows section "10. Thing Model" around
   "Example 45"

     [16] https://w3c.github.io/wot-thing-description/#example-45-mybuzzerthingmodelserialized-in-json

   Sebastian: the problem is that the Thing model uses the concept
   of the TD model

   <dape> ack

   Sebastian: the idea is also to move the Thing Model in other
   docuemnt

   Sebastian: back to the PR. I am ok merging it. It is self
   contained.
   … we can improve also the number of devices described by a TD
   … any objections to merge?
   … merged

  PR 1024

   Sebastian: next PR

   <kaz> [17]PR 1024 - Topics around Thing Model

     [17] https://github.com/w3c/wot-thing-description/pull/1024

   <kaz> [18]Preview of section "10. Thing Model"

     [18] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#thing-model

   Sebastian: it's about Thing Model chapter
   … (showing the preview)

   Ege: there's an issue in the version field in the TM model

   Sebastian: please note that down in github

   Sebastian: showing examples of TMs

   <kaz> [19]Example 49 on the Preview

     [19] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#example-49-thing-model-with-the-required-term-for-interaction-affordances

   Sebastian: I introduced the relation type called "type"
   … it serves as an indication that a TD is an instance of a TM

   Sebastian: the required keyword can force the presence of a
   particular field in the final TD instance

   Ege: some issues:
   … I don't like the require keyword clashes with DataSchema
   required

   Sebastian: it is another level

   Ege: for validation it will be challenging
   … I am not super happy about this new require feature

   <Zakim> dape, you wanted to required causes validation issues
   array/object

   Ege: it would be better to have just a flag
   … required on not

   Koster: we could have just one place to list the required
   affordances
   … flags it might be a problem for reusability.

   Sebastian: so how's this solved in sdf?

   Koster: we a field with pointers to required properties/values

   Sebastian: Ok, I'll add a note in the required section stating
   that it is under discussion
   … also we'll discuss about sdf pointers in the F2F meeting
   … actually the whole TM section has a note saying that is under
   discussion

   Ege: I'll create an issue on this

   Ege: what if in TM I don't put forms? or other required TD
   field without a placeholder?
   … it should be clear that in the end other properties will be
   add in the final TD
   … we have an use-case to not have forms in a TM, however from
   the text it is not clear. It seems that I need to put a place
   holder to generate forms automatically

   <kaz> [20]Example 51

     [20] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#example-51-thing-description

   Sebastian: right

   Cristiano: this issue is really linked with the work we are
   doing in the scripting API

   Sebastian: yeah it can be multiple ways
   … in ediTDor we ask to the user

   Cristiano: I think there's two phases. One filling the
   placeholders and the other filling missing required properties

   Sebastian: yeah I agree. I'll describe the process focusing
   more in the in end goal

   Daniel: +1 to Cristiano's point
   … it might be valuable to have shared algorithm for
   PartialTD->TD process

   Koster: in ODM we have a more schema oriented approach. We
   should spend sometime to think about it
   … approach about placeholders

   Sebastian: schema approach?

   Koster: Like macro preprocessing
   … we could use an object instead of the place holder.
   … the object could act like a schema

   Sebastian: placeholder are easier for overriding

   Koster: in ODM it is a not-mechanically checkable rule that
   states that if you are overriding something you should maintain
   the semantic.

   Sebastian: by the way there's a npm module which is doing the
   heavy lifting for replacing placeholders

   Daniel: first comment is about the required. I'll post on the
   github issue

   <Ege> dape, I am in your service: [21]https://github.com/w3c/
   wot-thing-description/issues/1046

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

   Daniel: I am not sure if we need to enforce a particular style
   for placeholders
   … it could be just a best practice

   Sebastian: I can lessens the wording.

   <Ege> [22]https://github.com/w3c/wot-thing-description/issues/
   1047

     [22] https://github.com/w3c/wot-thing-description/issues/1047

   Sebastian: ok PR not merged, it needs more iterations

   <Ege> [23]https://github.com/w3c/wot-thing-description/issues/
   1045

     [23] https://github.com/w3c/wot-thing-description/issues/1045

   Sebastian: (capturing TODOs in the PR)

   <kaz> [24]Sebastian's comments for PR 1024

     [24] https://github.com/w3c/wot-thing-description/pull/1024#issuecomment-776855059

   Sebastian: thank you for the feedback

  issue 1020

   <kaz> [25]Issue 1020 - Which is better to actuate devices,
   invoking ACTION or writing PROPERTY?

     [25] https://github.com/w3c/wot-thing-description/issues/1020

   Sebastian: current definition of actions or properties it is
   not very precise
   … different people use properties or actions for the same
   concepts
   … ok there's more comments on the issue. Let's discuss next
   time

  adding term for stream of data

   <kaz> [26]Issue 1044 - Adding term to indicate a stream of data

     [26] https://github.com/w3c/wot-thing-description/issues/1020#issuecomment-776676562

   Ege: currently scripting api define how to handle stream of
   data

   however there's no way to understand that from TD

   Daniel: it is kind of a hint

   Ege: to me it is a requirement
   … kind of contentEncoding

   Cristiano: it might be more an hint
   … but we need more experience with the new api to judge

   Sebastian: I agree, leave issue open
   … however I'm surprised to see that content Type could be also
   an array.

   Ege: +1

   Cristiano: +1

   Kaz: out of time

   Sebastian: adjourned


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

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

Received on Wednesday, 3 March 2021 10:15:44 UTC