[TD] TD Restructuring minutes - 23 November 2016

available at:
 https://www.w3.org/2016/11/23-wot-td-minutes.html

also as text below.

Thanks for taking the minutes, Dave!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                            TD Restructuring

23 Nov 2016

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2016/11/23-wot-td-irc

Attendees

   Present
          Kaz, Sebastian, Dave, Uday, Yingying, Daniel_Peintner,
          Taki, Victor, Feng_Zhang

   Regrets
   Chair
          Sebastian

   Scribe
          dsr, kaz

Contents

     * [4]Topics
         1. [5]Pull Requests on TD for the draft WG Charter
         2. [6]Streaming and Compound Values (with demo)
         3. [7]MIME types
         4. [8]Next meeting?
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   <dsr> scribenick: dsr

Pull Requests on TD for the draft WG Charter

   Sebastian: Michael McCool has proposed a change to the charter
   in respect to thing descriptions to address the AC Review
   feedback

   Sebastian looks for a way to project the rendered version of
   Michael’s pull request

   Sebastian too provided some suggestions for changes, which
   Michael took into account

   Sebastian notes that his change should make it easier for
   people to understand what the charter is saying.

   We want to avoid misunderstandings about what tools are needed
   to process thing descriptions.

   Things can consume data from other sources, e.g. other things.

   This relates to the declarations about input and output data.

   Kaz: perhaps we should discuss the details of the pull request
   in the main WoT IG call when Michael will be present and able
   to answer questions

   Sebastian discusses the wording around thing lifecycles

   Any questions? [No]

   <kaz> scribenick: kaz

Streaming and Compound Values (with demo)

   dsr: demo of Simulation of leaky water tank
   ... (explains the demo scenario)
   ... there are inlet valve and outlet valve
   ... the outlet valve automatically opens when the water goes
   under the lower line
   ... and the inlet valve automativally opens when the water goes
   above the upper line
   ... there is HTML forms to specify levels, etc.
   ... you can change the limit, etc.
   ... also interfere the movement using "inlet valve"/"outlet
   valve" radio boxes
   ... the green sign shows if you're connected with the server
   ... (shows the issue 281)

   -> [11]https://github.com/w3c/wot/issues/281 issue 281

     [11] https://github.com/w3c/wot/issues/281

   dsr: next shows the demo of Simulation of ECG
   ... server is streaming server-sent events
   ... what do we need to for streaming?
   ... e.g., ECG data
   ... for a digital converter
   ... what is the protocol?
   ... metadata here let you know about the data


   {
     properties: {
       ecg: {
         type: “number”;
         upper: 1023;
         lower: 0;
         rate: 100,
         source: “http://example.com/stream/ecg”,
         protocol: “server sent events”
       }
     }
   }
   ]]

   dsr: more compound example with compound data
   ... time stamp, voltage, etc.


   5.093750,1891.621105,-0.101894,0.698271,9.961602
   5.109375,-156.757717,,,
   5.125000,-2117.106552,-0.101894,0.698271,9.961602
   5.140625,-1169.248790,,,
   ]]

   dsr: ecga includes ecg, x, y, and z


   {
     types: {
       acceleration: {
         type: “number”,
         min: -1.0,
         max: 1.0,
         rate: 32
       }
     },
     properties: {
       ecga: {
         rate: 64,
         source: “http://example.com/stream/ecg”,
         protocol: “server sent events”,
         properties: {
           ecg: {
             type: “number”,
             upper: 1023,
             lower: 0
           },
           x: “acceleration”,
           y: “acceleration”,
           z: “acceleration”
         }
       }
     }
   }
   ]]

   dsr: defining x, y, z separately from the ecg data
   ... nest of properties

   dape: wondering what you need is additional information to get
   the data?

   dsr: server-sent event is an API of HTML5
   ... you provide information of URI, event source and callback
   ... the interface is independent from protocols
   ... very easy to implement using Node.js
   ... not saying HTTP has advantage
   ... but there are many supports for HTTP

   dape: you could change the source from HTTP to any other ones

   dsr: yes

   seba: what kind of media type are you using?
   ... what kind of data format?

   dsr: that's kind of included in the protocol field
   ... not exposed to applications but could be
   ... services essentially sending JSON
   ... array of objects
   ... this API is appropriate to streaming
   ... can register callbacks
   ... the interface exposes the information to applications

   kaz: wondering if we want to gather this kind of use cases for
   TD Restructuring?

   dsr: think so
   ... would be useful for brainstorming

   kaz: in that case, I'd suggest Sebastian sends out a call for
   request for use cases to the group

   seba: ok
   ... btw, not unclear about if this approach is useful for
   today's Web apps
   ... how to handle unsubscribe?

   dsr: you can drop subscription
   ... simple but useful
   ... the client can stop and resume

   seba: ok
   ... the structure you sowed is written in JavaScript
   ... do you use the notation based on the Current Practices?

   dsr: not directly JSON-LD but easily converted to RDF

   seba: would be very nice if we could handle this in Web-like
   approach
   ... you're expecting to understand JSON object notation as well
   ... we're working on independent representation
   ... would handle both JSON object representation and others

   dsr: based on the use cases/requirements we could find which
   would be the appropriate representation

   seba: we'd have some generic representation which could be
   converted to any representations
   ... what the standard side of TD would be?

   dsr: should be based on requirements

   seba: JSON approach vs semantic approach
   ... your example seems to be difficult for semantic
   interpretation here
   ... not very machine understandable...

   dsr: it's very simple
   ... in terms of mapping, it's also simple

   seba: how to handle the rate?

   dsr: using the context mechanism
   ... something maps to a blank node
   ... happy to elaborate during upcoming calls

   seba: there are already existing standards

   dsr: right. we don't want to people to use something they don't
   want to use

   seba: we have to go into more detail once we launch the WG
   ... staying on JSON-LD or some new approach
   ... have to find out the right direction to take

   dsr: need to see pros and cons

   seba: there should not be need for RDF parser
   ... how should we rely on TD notation?
   ... current approach works well for PlugFests
   ... so would stick with JSON-LD
   ... 5 mins remaining
   ... Daniel, your pull request?

MIME types

   -> [12]https://github.com/w3c/wot/pull/278 issue 278

     [12] https://github.com/w3c/wot/pull/278

   dape: issue on MIME types

   seba: tx for your change proposal
   ... will merge this with the Current Practice document
   ... so that we can use that for the next PlugFest
   ... will use a few next days for that

Next meeting?

   seba: next Wednesday, 8am CET
   ... if you have topics, please make issues and/or send emails
   ... something more to discuss today?

   (none)

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [13]scribe.perl version
    1.148 ([14]CVS log)
    $Date: 2016/11/23 08:20:04 $

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