<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)

-> https://github.com/w3c/wot/issues/281 issue 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

-> https://github.com/w3c/wot/pull/278 issue 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 ]