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

[TD-TF] minutes - 15 May 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 10 Jun 2020 20:55:07 +0900
Message-ID: <87imfzt9t0.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the notes, Mizushima-san!



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

                               - DRAFT -

                             WoT-WG - TD-TF

15 May 2020


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


          Kaz_Ashimura, Daniel_Peintner, Michael_Koster,
          Taki_Kamiya, Sebastian_Kaebisch, Tomoaki_Mizushima,
          Victor_Charpenay, Ege_Korkan



          Mizushima, kaz


     * [3]Topics
         1. [4]Agenda
         2. [5]last minutes
         3. [6]TPAC 2020
         4. [7]Repo logistics - render script
         5. [8]Issues
         6. [9]Hypermedia control
     * [10]Summary of Action Items
     * [11]Summary of Resolutions

   <kaz> scribenick: Mizushima


   Sebastian: (goes through the agenda)
   ... in person TPAC is canceled

last minutes

   <kaz> [12]May-8

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

   Sebastian: Last minutes is approved and will be published

TPAC 2020

   Sebastian: W3C decided to cancel TPAC2020

   Kaz: physical meeting is cancelled and will be an online
   meeting, but we still need to respond to the logistics
   ... ... so we must decide what important sessions (e.g., joint
   sessions) are.

   <scribe> scribenick: kaz

Repo logistics - render script

   Kaz: so we could handle the main text and the table part, which
   is automatically generated by the script.sh, for a while
   ... and could update the table later based on the HTML tags

   Victor: yes


   [13]Issue 900

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

   Daniel: suggestion to add an additional option of "description"
   field to identify what each link does

   [14]Web Linking (RFC8288)

     [14] https://httpwg.org/specs/rfc8288.html#serialisation-defined-attributes

   Koster: there are many registered "relation-type" at IANA


     [15] https://www.iana.org/assignments/link-relations/link-relations.xhtml

   Sebastian: "license" information would be ok
   ... but for human-readable purposes, what kind of information
   to be handled?

   <Mizushima> kaz: Is there user case ?

   <Mizushima> ... technically is ok, but use case is important

   Kaz: could you elaborate a possible use case a bit?

   [16]example comparison for switch-enum-type.sdf.json

     [16] https://danielpeintner.github.io/wot-pages/sdf/

   Daniel: shows an example TD

   Sebastian: but I'm a bit confused
   ... is it enough to add "description"?

   Daniel: maybe doesn't need to identify all the features
   ... so adding "description" seems to be valid to me

   Sebastian: Victor, can you provide some example?

   Victor: ok


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

   [18]Issue 903

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

   Sebastian: would like to talk about the OneDM example next
   ... related to the SDF example at:

     [19] https://github.com/mjkoster/ODM-Examples/blob/master/test-definitions/switch-enum-type.sdf.json

   Koster: application level semantics
   ... SDF is designed to capture the semantics for a lot of
   existing device definitions
   ... there is a spreadsheet including 13 definitions
   ... SDF as a common mechanism
   ... could do with schema.org for application schema
   ... we have ODM object corresponding to TD
   ... TD template can correspond to the object
   ... contain all the interaction affordance
   ... (looks into the example)
   ... odmProperty, odmAction, odmData
   ... SDF also has a feature to composition internally
   ... reusing the data type like "StateData"
   ... there are more examples there
   ... making the file smaller and linking to get the details
   ... would like to decouple the semantics from the concrete data
   type, e.g., enum

   Daniel: trying to convert this to TDT
   ... but within the odmData area
   ... there are multiple definition for switch
   ... possible name collision there
   ... we don't have this level within TD
   ... action and property are the same level
   ... but why only "odmData" has yet anther nested level?

   Koster: you can create a standalone definition of
   action/event/property for some particular function
   ... it allows you and the model to isolate individual functions
   ... and put all the affordance together
   ... we would like to convert this notation to iot.schema
   ... but there is also some problem
   ... probably you would convert "On" to "switchOn", etc.
   ... you could use "switchAction", etc., as well
   ... and could another layer for the conversion
   ... in the real world there are multiple levels

   Daniel: I indeed named "On" as "switchOn"

   Kaz: would like to suggest again that we continue the
   discussion based on some specific use case

   <Zakim> dape, you wanted to odmObject with

   Daniel: encountered two issues

   "odmData": {
     "StateData": {
       "odmEnum": {
         "On": {
           "type": "string",
           "const": "on",
           "description": "The on state"
         "Off": {
           "type": "string",
           "const": "off",
           "description": "The off state"

   Koster: good information to see you sort it out
   ... any other way to add type for enum?
   ... missing semantic anchor
   ... interesting question on how to handle it
   ... on/off could be 1/0 or true/false
   ... or anything non-zero
   ... that would have to go into the TD as well
   ... not a whole difference

   Sebastian: one of the advantage is one-of is already
   standardized within json.schema

   Victor: my main question is
   ... if you have a model for a specific instance for events
   ... what is the future of iotschema happen?
   ... still active?

   Koster: iotschema is still active and will have a meeting next
   ... create this vocabulary to annotate descriptions like TD
   ... collaboration just happening with ODM
   ... want to converge all the possible models including zigbee
   and bluetooth
   ... the project should happen including all the stakeholders
   ... bringing it back to iotschema, we still need to handle
   extension for schema.org
   ... still need some engineering

   Kaz: really would like to repeat we continue the discussion
   based on a concrete use case with some concrete device/app
   setting so that we can clarify what to be done on the ODM side
   and what to be done on the TD side

   Sebastian: wondering about who is leading the discussion on the
   ODM side

   Koster: ODM is not an organization but a liaison
   ... some resources are on the playground site

   [20]ODM Playground

     [20] https://github.com/one-data-model/playground

   Koster: we don't have any namespaces within the playground yet

   Kaz: that's why the attribute names themselves say

   Koster: yeah, so it's a bit confusing
   ... should be based on the SDF model instead of ODM

   Sebastian: this is the first shot to see the similarity and
   ... btw, there will be a WISHI workshop meeting today
   ... would be useful to let them as well know about this survey

   [21]Daniel's survey (revisited)

     [21] https://danielpeintner.github.io/wot-pages/sdf/

   Daniel: for example, we don't have features for "odmData"

   Sebastian: possible to describe using SHACL?
   ... expressing multiple occurrence

   <inserted> [22]Sebastian shows Issue 898

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

   Victor: yes

   Sebastian: good to start this discussion
   ... though we need some concrete use case description as Kaz

Hypermedia control


     [23] https://github.com/w3c/wot-thing-description/tree/master/proposals/hypermedia-control

   [24]Issue 899

     [24] https://github.com/w3c/wot-thing-description/issues/899

   Victor: the main problem is
   ... illustrated here in the "Use Case Example" section
   ... (explain the data transfer sequence)
   ... there is no concrete feature for this behavior
   ... my proposal is very much inline is some proposal at IETF
   ... hypermedia control between the agend and the consumer
   ... (hoes the example TD code)
   ... several formats there
   ... Proposal: Piecewise Consumption of TD

       "href": "/fade/1",
       "htv:methodName": "GET"
       "href": "/fade/1",
       "htv:methodName": "PUT"
       "href": "/fade/1",
       "htv:methodName": "DELETE"

   Victor: "/fade/1" could be used for GET, PUT and DELETE
   ... the idea is a TD possible consumed more than once
   ... there should be some protocol for negotiation
   ... but the essential idea is that a TD possible could be
   consumed more than once
   ... it's up to the consumer to make decision

   Ege: in the action and level of "fade" within the TD, could we
   specify that?

   Sebastian: this is about the runtime behavior?

   Victor: yes

   Koster: generate indication of the document is handled?

   Victor: it's really the same as the standard hypermedia control
   ... this is something well-known
   ... would like to apply that mechanism to TD

   Koster: a fragment of TD can be handled?

   Victor: yes, that's possible
   ... as long as the proxy exposes a full TD

   Koster: if more than action is exposed

   Victor: yes, that would be OK

   Sebastian: what kind of new definition to be added to TD?

   Victor: we can do without any changes
   ... if consumers can handle this example

       "href": "/fade/1",
       "htv:methodName": "GET"
       "href": "/fade/1",
       "htv:methodName": "PUT"
       "href": "/fade/1",
       "htv:methodName": "DELETE"

   Sebastian: but how to handle using TD?

   Victor: to me it doesn't have to be known
   ... no need to mention at the beginning

   Kaz: it would be helpful to explain the background the expected
   use cases

   Sebastian: this is a kind of old issue and derived from the
   proposal from Ben on WebThings using the Oracle cloud

   Kaz: in that case, it would be easier to understand we mention
   the fact and think about this proposal based on that

   Sebastian: it seems this proposal requires an addition of
   "fade" to the "actions" feature

   Victor: (goes back to the example TD)

     "@context": "https://www.w3.org/2019/wot/td/v1",
     "id": "urn:ex:thing",
     "actions": {
       "fade": {
         "input": {
           "type": "number",
           "description": "duration (in ms)"

   Sebastian: would suggest everybody read this proposal again
   ... also revisit the background and the use case
   ... then let's continue the discussion next week
   ... aob for today?



Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [25]scribe.perl version
    1.152 ([26]CVS log)
    $Date: 2020/06/05 06:14:03 $

     [25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 10 June 2020 11:54:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 10 June 2020 11:54:25 UTC