[TD] TD Restructuring slides and github link - 5 October 2016

Please find attached the slides that I have presented in the web meeting today. Please note, proposals and discussions regarding the TD restructuring topic we are using github:
https://github.com/w3c/wot/issues?q=is%3Aissue+is%3Aopen+label%3ATD


Comments and proposals are welcome.

Best regards
Sebastian




Von: Kazuyuki Ashimura [mailto:ashimura@w3.org]
Gesendet: Mittwoch, 5. Oktober 2016 10:54
An: Public Web of Things IG
Betreff: [TD] TD Restructuring meeting minutes - 5 October 2016

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

also as text below.
Thanks a lot for taking these minutes, Victor!
Kazuyuki

---
   [1]W3C

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


                               - DRAFT -

                            TD Restructuring

05 Oct 2016

   [2]Agenda

      [2] https://lists.w3.org/Archives/Member/member-wot-ig/2016Oct/0001.html


   See also: [3]IRC log

      [3] http://www.w3.org/2016/10/05-wot-td-irc


Attendees

   Present
          Kaz_Ashimura, Achille_Zappa, Daniel_Peintner,
          Dave_Raggett, Lionel_Medini, Matthias_Kovatsch,
          Soumya_Kanti_Datta, Taki_Kamiya, Victor_Carpenay,
          Katsuyoshi_Naka, Andrei_Ciortea, Maxime_Lefrancois,
          Antoine_Zimmermann, Darko_Anicic

   Regrets
   Chair
          Sebastian

   Scribe
          Victor, kaz

Contents

     * [4]Topics
         1. [5]Logistics
         2. [6]Problem statements
         3. [7]Problem statements 2
         4. [8]Classification
         5. [9]First TD Restructuring Ideas
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: Victor

   (Waiting a few minutes more...)

Logistics

   Sebastian_(SK): let's start. Goal here: discuss TD structure
   more in details. First of a series of telcos until next
   PlugFest (February)

   SK: more precisely: around 5 telcos, then time for
   implementation until February.

   <kaz> [12]TD Restructuring proposal

     [12] https://github.com/w3c/wot/tree/master/proposals/td-restructuring


Problem statements

   SK: Motivation to restructure TD: feedback provided during
   PlugFests, on Github and by external organizations (OCF, BIG
   IoT)

   <kaz> [13]TD Restructuring proposal (revisited)

     [13] https://github.com/w3c/wot/tree/master/proposals/td-restructuring


   1. when to use properties/acton/event?

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


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


   not only related to TD.

   2. properties/actions/events are not self-contained

   <mlefranc> [15]https://github.com/w3c/wot/issues/251


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


   example: URI resolution if relative / different protocols or
   encodings at the interaction level (vs. thing level)

   <Zakim> dsr, you wanted to comment on a process question

   Maxime_(ML): question: RDFS range for "encodings" defined? If
   not, one can defined it as Thing or Property/Action/Event.

   SK: should be possible.

   <mlefranc> Dave: encourages the TD subgroup to adopt a more
   formal process

   <mlefranc> use cases, requirements, .. prepare a solid ground
   for the WG

   <mlefranc> part of this work has been started at the beginning
   of the IG

   Dave_(DR): we should adopt a more formal approach here: update
   use case & requirements if we are about to change the TD.
   Example: many encodings and protocols across platforms, which
   ones are we addressing?

   <mlefranc> +1 for Dave's proposal

   SK: volunteers to work on that?

   Kaz: we can do the following in parallel: 1. asking for
   volunteers to update the use case document itself and 2.
   providing proposals for TD Restructuring (during calls and on
   emails) along with concrete use cases

   <mlefranc> Dave: this should be done in parallel

   SK: idea of the PlugFests was to have quick iterations

   <mlefranc> ... what is important is to be able to refer back to
   a decision to justify a feature

   DR: this should be done in parallel

   Daniel_(DP): should be possible to keep track of
   changes/proposals with concrete use cases and example
   notations.

   Kaz: Wiki page to gather all propsals?

   Matthias_(MK): having Github issues is maybe enough

   <dsr> Dave thinks very few members of the IG look at the github
   issues, so that in practice results in only very limited
   scrutiny.

   <kaz> Kaz: GitHub issues is ok and people are encouraged to add
   concrete usecases and examples

   SK: what about regularly compiling the issues in a "changelog"?

   Back to the queue. Darko?

   <dsr> Dave thinks that it is important to keep requirements
   distinct, as JSON is just one possible way to represent
   metadata

   Darko_(DA): previous point: relative URIs might be a limitation
   but they also have benefits, such as "templating" (only the
   base URI is changing between things)

   <mlefranc> +1 for Dave's comment

   SK: next in the queue

   DR: we should really separate requirements from proposals.
   Should engage a discussion in the mailing-list

   <DarkoAnicic> ACTION: Darko to create an issue: properties,
   actions, events can be saved in the TD repository separately as
   templates. A TD can be created based on a concrete set of them
   and instantiate with a concrete URI. In this settings, the
   current proposal with href makes sense. [recorded in
   [16]http://www.w3.org/2016/10/05-wot-td-minutes.html#action01]

     [16] http://www.w3.org/2016/10/05-wot-td-minutes.html#action01]

   <trackbot> Created ACTION-77 - Create an issue: properties,
   actions, events can be saved in the td repository separately as
   templates. a td can be created based on a concrete set of them
   and instantiate with a concrete uri. in this settings, the
   current proposal with href makes sense. [on Anicic Darko - due
   2016-10-12].

   SK: Matthias proposed having first issues and then a summary
   document allows commenting on each topic

   DR: one should be able to comment on the documents as well.

   <kaz> kaz: thinking about how to record those two topics
   separately would make sense

Problem statements 2

   SK: explicit vs. implicit knowledge

   MK: OCF is using other methods than WoT for the same
   operations, we should be able to specifiy methods in the TD as
   well.

   SK: second point, we should also refine spec. of encodings
   (define them at the interaction level, use media types)

   ML: methodology? Who resolves the issues, who takes action?

   SK: first proposal in a separate folder, then discussion during
   the calls until we reach agreement

   ML: what about using PRs?

   MK: precisions about our process: 1. proposal, 2. discussion ->
   consensus?, 3 integrated in the current practices doc (PR?)

   ML: deadline on issues (like 1 month)?

   MK: not sure it is a good idea: some issues have taken longer
   in the past (e.g. charters)

   DP: precisions needed: from 1 issue, 2 were created during the
   discussion -> 3 issues now open that relate to the same one.

   MK: one can reference issues from other issues. We should use
   similar labels (tags?). Common sense needed.

   the person who opened the issue is supposed to track what
   happens and close it when required

   Taki_(TK): possible to notify the mailing-list when an issue is
   open?

   SK: you can also "watch" the repository (see Github)

   Kaz: we encourage all to subscribe the "WoT" repository

   <kaz> [17]WoT repository subscription

     [17] https://github.com/w3c/wot/subscription


   SK: we should send an e-mail to the group pointing that out

   MK: only summaries and clean reports should be sent to the
   mailing-list

   more technical discussions should happen on Github

   ML: from the experience of the Spatial Data on the Web WG (that
   duplicates every issue), the WoT process seems a bit better

   MK: should be raised in our general call today

Classification

   SK: for all issues mentioned here: restructuring/renaming/new
   vocabulary needed?

   slides to be found in the proposal folder (Github)

First TD Restructuring Ideas

   <kaz> [18]Today's Basic TD Structure

     [18] https://github.com/w3c/wot/tree/master/proposals/td-restructuring#user-content-todays-td-basic-structure


   <lmedini> Should we plan to provide mappings with other
   vocabularies, such as Hydra?

   <kaz> [19]Proposed Basic TD Structure

     [19] https://github.com/w3c/wot/tree/master/proposals/td-restructuring#user-content-sample


   SK: maybe go back to the original TD structure? With key
   "interactions" instead of "properties","actions","events"

   + "encodings" and "url" defined for each interaction

   <inserted> scribenick: kaz

   lmedini: mappings with other vocabularies, e.g., Hydra?

   sk: some discussion on Hydra during TPAC

   -> [20]https://www.w3.org/2016/09/22-wot-td-minutes.html#item02

   Hydra breakout during TPAC

     [20] https://www.w3.org/2016/09/22-wot-td-minutes.html#item02


   <kaz> scribenick: Victor

   Victor_(VC): there is an action item pending regarding Hydra (I
   have to take). A separate discussion will take place soon

   VC: I'll create an issue and add a proposal.

   SK: (shows an example with the new structure)

   <lmedini> Yes, thanks victor

   key "endpoint" is added. interactions: [ "name", "endpoint": {
   "urls", "encoding" } ]

   DA: how to provide kind of templates then?

   <dsr> We should feel free to go beyond JSON-LD provided we give
   a means to map to RDF

   <mlefranc> +1 for each of us

   MK: it actually depends on the serialization (here JSON-LD). We
   should maybe focus on the "abstract" model instead

   <lmedini> +1 for abstract model.

   SK: then, how to continue? Which tools should we use to work on
   an abstract model?

   ML: Protégé is a tool the Semantic Web community uses.

   MK: one point: with using JSON-LD we had the hope to attract
   Web developers.

   DA: at the beginning, we created an (OWL) ontology. But it got
   outdated quickly because of too many changes in the JSON-LD
   version.

   <kaz> maxime: can help Victor for that purpose

   Antoine_(AZ): what we should agree on is a rough structure for
   the TD. We could use Turtle for that purpose within the group.
   To the world, we should present JSON-LD examples

   <DarkoAnicic> Darko: I am also willing to contribute on the
   Turtle model for TD

   SK: agreement on working at a more abstract level?

   Combining Turtle (internally) and JSON-LD (externally)?

   action items to turn into issues on Github!

   <kaz> [ adjourned ]

Summary of Action Items

   [NEW] ACTION: Darko to create an issue: properties, actions,
   events can be saved in the TD repository separately as
   templates. A TD can be created based on a concrete set of them
   and instantiate with a concrete URI. In this settings, the
   current proposal with href makes sense. [recorded in
   [21]http://www.w3.org/2016/10/05-wot-td-minutes.html#action01]

     [21] http://www.w3.org/2016/10/05-wot-td-minutes.html#action01


Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [22]scribe.perl version
    1.144 ([23]CVS log)
    $Date: 2016/10/05 08:51:02 $

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

     [23] http://dev.w3.org/cvsweb/2002/scribe/