See also: IRC log
<dsr> scribenick: dsr
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
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?
-> 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
seba: next Wednesday, 8am
CET
... if you have topics, please make issues and/or send
emails
... something more to discuss today?
(none)
[ adjourned ]