[TD] TD Restructuring minutes - 12 October 2016

available at:
  https://www.w3.org/2016/10/12-wot-td-minutes.html

also as text below.

Thanks a lot for taking these minutes, Daniel!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                         WoT - TD Restructuring

12 Oct 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/10/12-wot-td-irc

Attendees

   Present
          Kaz_Ashimura, Michael_Koster, Antoine_Zimmermann,
          Maxime_Lefrancois, Daniel_Peintner, Uday_Davuluru,
          Victor_Charpenay, Sebastian_Kaebisch, Kazuo_Kajimoto,
          Matthias_Kovatsch, Yongjing_Zhang, Katsuyoshi_Naka

   Regrets
   Chair
          Sebastian

   Scribe
          Daniel

Contents

     * [3]Topics
         1. [4]Logistics
         2. [5]Properties vs. Actions
         3. [6]Specify encodings
         4. [7]JSON-LD 1.1
         5. [8]Properties vs. Actions
         6. [9]General TD discussions
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   <kaz> scribe: Daniel

   <kaz> scribenick: dape

Logistics

   SK: Let's start with some logistics
   ... weekly call until first of November
   ... re-structering used in next PlugFest
   ... use Github for discussions
   ... plan for today: start with property and actions
   ... also finalize mediatype proposal
   ... handle feedback we got about JSON-LD

Properties vs. Actions

   SK: lets wait for Kaijimoto-san..
   ... switch topic

Specify encodings

   UNKNOWN_SPEAKER: SK: github issue #251
   ... propose to use mimetypes instead of XML, JSON, ...
   ... seems to be agreement about this topic

   <kaz> [12]GitHub Issue 251

     [12] https://github.com/w3c/wot/issues/251

   SK: OK for everybody to integrate this comment?

   All: silence (--> agreement)

   <AZ> encoding is almost universally used in computer sciecnce
   to talk about "character encoding"

   SK: related issues whether to use term "encodings"
   ... Maxime proposed to use format, representationType et cetera

   <inserted> [13]GitHub Issue 253

     [13] https://github.com/w3c/wot/issues/253

   <AZ> content type sounds good

   MK: mediaType and contentType is commonly used

   <maxime> +1 for contentType

   <AZ> media type is fine for me too

   VC: Shall we use mediaType then?

   MK: guess mediaType makes sense
   ... should check IANA for a registered term

   <AZ> +1 mediaType

   SK: Let's think about and comment... will make decision next
   week
   ... ask Daniel to close issue

   DP: OK

JSON-LD 1.1

   SK: related to issue #259

   Dave's proposal not aligned with JSON-LD specification

   <kaz> [14]GitHub Issue 259

     [14] https://github.com/w3c/wot/issues/259

   scribe: Gregg Kellogg mentioned new work is done in JSON-LD
   context
   ... happy to integrate feedback
   ... think we identified missing parts and should report it back
   to the JSON-LD group

   <kajimoto> I faced audio trouble...

   scribe: I am very thankful that we can provide feedback

   DP: any timeline for JSON-LD 1.1?

   VC: No timeframe

   SK: I think they are currently collecting issues and proposals
   ... will try to invite Gregg to one of our next meetings

   <kajimoto> i can speak now, i hope...

   SK: should check back with Gregg

   AZ: JSON-LD 1.1 is not on standard track
   ... developed in community group
   ... unlikely to become standard

   <kaz> [15]JSON-LD CG

     [15] https://www.w3.org/community/json-ld/

   SK: Doesn't sufficient support mean that creating a standard
   would be feasible

   AZ: Yes, .. but there is no timeframe yet

   VC: Do see AZ's concern... using new features in TD might be
   problematic

   AZ: Within interest group looking at it is fine.. in WG we
   should focus on standards

   SK: Let's check with Gregg
   ... uncertainty is not good

Properties vs. Actions

   SK: Difficult topic.... ongoing discussion on Github #247

   <inserted> [16]GitHub Issue 247

     [16] https://github.com/w3c/wot/issues/247

   SK: tried to summarize viewpoints in my slide (TODO LINK)
   ... current WoT assumption... property has static/dynamic
   states
   ... e.g., read temperature, read/set RGB
   ... Actions is more for function which has start and end
   ... e.g. fadeIn
   ... Dom's proposal only readable states
   ... functions to enable/disable etc

   Kajimoto-San: internal software status is property
   ... hardware is action
   ... another proposal is based on API Level
   ... low level is property

   <Yongjing> the latest comment i made on this issue is to
   recommend people to look at the current practice of information
   modeling in oneM2M/SDT, where clear rules are made for
   reference. we don't need to suffer again the similar debate
   that people already experienced somewhere else.

   Kajimoto-San: complex API is actions
   ... another proposal is to say we don't need a separate
   property and action

   SK: Unsure about what "we" should use/pick?

   Kajimoto: another proposal was about object-oriented analogy
   ... read/change was property
   ... function was action
   ... my proposal seems similar to OO-analogy

   <Yongjing> q

   SK: sometimes we do have something in between

   <Yongjing> q me in plz

   SK: not sure in that case

   Yongjing: according to my oneM2M experience.. different ways
   out there.. suggest to look at them
   ... hard for developers to impose strict rules
   ... our way should be flexible and powerful enough to handle
   different protocols

   SK: do you have the same issue in oneM2M (action vs property)

   Yongjing: yes
   ... in oneM2M there are clear rules
   ... we could adapt them
   ... oneM2M has 2 terms for properties: property (static e.g,
   device id) vs data-points (dynamic e.g, measurements)
   ... the latter is functional
   ... difference between data-points and actions: property is
   stateless
   ... action is stateful... e.g, increase temperature by X
   ... this is just a rule.. people might choose different rule

   MK: had same discussion in OCF
   ... difficult to specify hard rules
   ... leave it to the designer
   ... agree we should try to come up with a descriptive
   category...

   SK: ask Yongjing to add input to github

   Yongjing: just did

   MK: looking at semantic annotations... client should be able to
   know which pattern to use
   ... no concrete idea yet
   ... looks at least promising to me

   SK: discussion is ongoing...

   Kajimoto: like Yongjing's proposal

General TD discussions

   SK: Simplify the way how actions/properties and events are
   presented in TD
   ... going back to original TD version
   ... generic interaction container

   <kaz> [17]GitHub Issue 258

     [17] https://github.com/w3c/wot/issues/258

   SK: use @type to mark interaction
   ... even allow @type to be property and event
   ... github issue #258, please comment

   Kajimoto: not sure about @type proposal
   ... purpose of TD is also about designer and which API to use
   ... would like to see some API examples
   ... should consider the combination of TD and API

   SK: Thanks. Will provide some examples on Github

   MK: have an example of another pattern
   ... mapping smart things to schema.org
   ... have type and id (== command)
   ... will provide example on Github
   ... very much RDF-like

   VC: is there a link we could look at?

   MK: Will share link

   SK: next is Github issue #254

   <inserted> [18]GitHub Issue 254

     [18] https://github.com/w3c/wot/issues/254

   SK: Darko proposes to think about templates
   ... not deeply discussed so far
   ... propose to have abstract description of TD
   ... start with abstract TD and enhance it later
   ... please comment
   ... fits also with TD lifecycle
   ... next is Github issue #255

   <inserted> [19]GitHub Issue 255

     [19] https://github.com/w3c/wot/issues/255

   SK: move encodings and base url to resource/interaction
   ... idea is to move global definitions to local definitions
   (being self-contained)
   ... please comment
   ... next is Github issue #256 from Dave

   <inserted> [20]GitHub Issue 256

     [20] https://github.com/w3c/wot/issues/256

   SK: about compound properties

   MK: will add comment... e.g. thing with 6 buttons..
   ... notion of collection

   SK: related to template?

   MK: yes, I think we need both

   SK: will link those 2 issues
   ... next is Github issue #257
   ... about separating requirements from serialization formats
   ... Dave is looking for volunteers to work with him on that

   MK: careful to sign up.... but looks interesting
   ... workflow is important to look at

   SK: That should be it for today..
   ... will ask Gregg to join next meeting

   <kaz> [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [21]scribe.perl version
    1.148 ([22]CVS log)
    $Date: 2016/10/12 08:22:06 $

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