[TD] TD Restructuring minutes - 14 December 2016

available at:
  https://www.w3.org/2016/12/14-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 -

                            TD Restructuring

14 Dec 2016

   See also: [2]IRC log

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

Attendees

   Present
          Kaz_Ashimura, Daniel_Peintner, Takuki_Kamiya,
          Sebastian_Kaebisch, Uday_Davuluru, Darko_Anicic,
          Matthias_Kovatsch, Yingying_Chen, DarkoAnicic,
          Katsuyoshi_Naka

   Regrets
          Dave_Raggett

   Chair
          Sebastian

   Scribe
          Daniel

Contents

     * [3]Topics
         1. [4]decisions about new TD version
     * [5]Summary of Action Items
     * [6]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: dape

decisions about new TD version

   SK: Next week will be the last TD call
   ... next week I would like to discuss PlugFest topics
   ... should finalize TD version
   ... updated CP document according to change requests
   ... got additional comments, see
   [7]https://github.com/w3c/wot/issues/287
   ... issue is about renaming... re-structering
   ... MK proposed changes
   ... we should manage today to make a decision and get ready for
   next PlugFest
   ... MK proposed to use Web vocabulary
   ... e.g., link vs endpoint
   ... e.g., uri vs. href
   ... e.g., mediaType vs type

      [7] https://github.com/w3c/wot/issues/287

   MK: split up issue into 2

   SK: issue #289

   <inserted> [8]Issue-289

      [8] https://github.com/w3c/wot/issues/289

   MK: Instead of uri we should call it href
   ... endpoint is usually socket address..

   <inserted> [9]Matthias' proposal

      [9]
https://github.com/w3c/wot/blob/master/proposals/td-restructuring/mkovatsc-use-known-names.jsonld

   MK: propose to use link and href
   ... this is mainly about name changes
   ... also propose simplifying overall structure
   ... under interaction you have links
   ... should we allow multiple hrefs?
   ... looked at web linking RFC.. just one mediatype is supported
   ... propose ONE mediaType as shown in example
   ... one more tweak... in metadata there is key "base"
   ... essentially base uri
   ... instead of allowing array it should be at most ONE base uri
   ... alternate protocols may use absolute uri

   SK: changes are as follows
   ... instead of endpoint we use links

   <kaz> (much noise on WebEx and people had to rejoin...)

   SK: question to group. What do people think
   ... should simplify processing.. no arithmetic for detecting
   right uri et cetera

   DP: +1

   MK: +1

   TK: think is good

   Kaz: +1

   Uday: fine by me

   YC: +1

   DP: what about type vs mediaType?

   MK: HTML uses type
   ... conflict in JSON schema
   ... however, should be fine
   ... once we have everything together we might consider special
   naming
   ... OR scoping should resolve issue

   SK: Agree ... may confuse a bit

   DP: see difference in JSON schema vs web-linking type
   ... JSON schema tools are out there

   MK: web linking tools come up also..
   ... so same same
   ... TD uses metadata around actual web linking node
   ... link for "temperature" is the actual link and not the
   current TD

   SK: what if we keep mediaType?

   MK: breaks web linking.. which is somewhat broken anyway

   DP: Let's try to stick with type and see whether we run into
   problems... should be resolvable according context

   SK: Darko, do you see any issues?

   Darko: where is "type" defined?
   ... propose to define contexts for IANA and JSON schema

   SK: prefix should make it clear

   DP: propose to look whether prefixes break JSON schema tools

   Darko: Not sure about the issue... JSON schema tools have issue
   already .. type is there twice

   DP/MK: context will resolve issue

   Darko: agree w.r.t. to processing but not w.r.t. semantics

   MK: think we need proper model to resolve those and similar
   issues
   ... e.g., valid JSON-LD document

   Darko: local "type" without prefix means part of TD ... not of
   JSON Schema

   SK: How can we solve the issue?
   ... going back to mediaType key OR look into JSON-LD and how we
   can resolve this issue

   MK: It is not proper fixed by just renaming
   ... scoping/context should apply
   ... for hot fixing propose to rename it to mediaType
   ... anyhow.. have to look into how to resolve it

   SK: OK, lets rename it back to mediaType

   Naka: seems ok also for me

   SK: MK had other issue, #290
   ... rename outputType just to output

   <kaz> [10]Issue-290

     [10] https://github.com/w3c/wot/issues/290

   MK: compared to other examples, outputType, valueType etc it is
   just a hook
   ... get rid of obsoletes nodes and simplify to input and output

   SK: I do not have a strong opinion
   ... type is already in JSON schema... et cetera

   MK: renaming is less critical...
   ... can reconsider that anyway... short and simple

   DP: Can you show example..

   <kaz [11]Example TD for Structured Data

     [11] https://w3c.github.io/wot/current-practices/wot-practices.html

   MK: remove "valueType"

   SK: not sure anymore why we had "valueType" in the first place
   ... guess it was based on semantic annotation

   MK: propose to put semantic on "type" level

   DP: breaks JSON schema tools

   MK: not doing it causes issues with semantic annotations in
   complex types

   SK: JSON schema people restarted their work
   ... should get in touch with them

   DP: Propose to get in touch with them
   ... raise issues

   SK: can do that

   Darko: would not remove valueType unless issue is resolved

   MK: OK. lets put that on hold

   SK: Will integrate changes to CP
   ... freeze CP latest next week
   ... next week is about PlugFest scenarios

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [12]scribe.perl version
    1.148 ([13]CVS log)
    $Date: 2016/12/14 08:15:39 $

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