Re: data streams

Dave,    (and woters)

Streams sounds like a very useful thing to support :-)

- For the multiple sinks, why not use a pub sub broker as the identified 
source of the stream that way any number of sinks can attach to that 
pub-source. Seems to me that setting a proxy output value to point to a 
single output is a limitation that might result in someone creating an 
upstream proxy to split to multiple sinks.

Any thing should be able to redirect any aspect of their source (defined 
by its meta description) to a nearby pub-sub proxy service. Still that 
could be an "on device" (localhost) broker, a home broker, a service 
provider broker or a public broker etc.

It seems reasonable to me to have use case such as one part of the 
stream for the snapshot, another for the live view a third for data 
analysis, a fourth for a remote tele medicine, a fifth for a emergency 
monitoring function etc.

- Even discrete value type of sensors could be handled as a stream if 
only given long enough time to observe

- (Not convinced myself) but perhaps any data points should be allowed 
to be retrieved as a stream with sometime only a single value being sent 
before the connection is being terminated.
Ericsson Signature


- If there is a possibility to "cascade" (or chaining) the streamed data 
points then it might open up for a "network of" data stream functions 
that could apply smartness to the stream such as adding timestamps 
(simple sensors do not have timestamps, but sometimes have sample 
rates), compression, average, de-noising, composite streams.



Thanks!


Br magnus

http://www.ericsson.com/current_campaign 
<http://www.ericsson.com/current_campaign>

*MAGNUS OLSSON * *
*


Ericsson AB
Group Function Technology
Mobilvägen 1
22362 Lund, Sweden
SMS/MMS +46 706 756814
magnus.olsson@ericsson.com
www.ericsson.com



Ericsson




This Communication is Confidential. We only send and receive email on 
the basis of the terms set out at www.ericsson.com/email_disclaimer 
<http://www.ericsson.com/email_disclaimer>

On 2015-06-03 09:16, Dave Raggett wrote:
> I am interested in enabling the Web of Things Framework to handle data 
> streams.
>
> Some sensors produces streams of data as a function of time. Data 
> streams can carry one or more data channels where each channel is a 
> single number or a vector.
>
> An example would be an electrocardiography (ECG) sensor which is used 
> to produce a waveform of the heart's activity over a time period of up 
> to a few seconds (see attached image). In a hospital the sensor and 
> display are connected together with electrical leads.
>
> In the Web of Things, the sensor and the display are both modelled as 
> "things". In place of leads, we set the sensor's output property to 
> the display. The display could be an object in a web page script that 
> displays the waveform using the HTML CANVAS element, or it could be a 
> remote service, e.g. a device that acts as an oscilloscope. The 
> display could have properties that control its behaviour, e.g. how 
> many seconds of data to show. It could also have actions, e.g. to 
> freeze the display to allow a waveform to be studied in more detail.
>
> Script developers ony need to know the object model for the sensor and 
> display. The details of the underlying protocols are dealt with 
> automatically by the server platform. For this to work, we need a 
> standard way to describe data streams as part of the data model for 
> "things".
>
> For a simple thing property, e.g. the state of a light switch, setting 
> the value of the property on the proxy results in the server sending a 
> message to update the physical state of the switch. For streams, the 
> semantics is slightly different. Setting the value of the proxy's' 
> output directs the data stream to the designated object.
>
> This model assumes that a stream can only be sent to a single data 
> sink.  If you want to have multiple sinks, you will need to use a 
> "thing" that acts as splitter. In principle, the thing acting as the 
> sensor could do this, e.g. providing one output for a data logger, and 
> another for a display.
>
> p.s. I am planning on implementing this as part of the NodeJS server 
> project on GitHub. By the way, there are several examples of how to 
> create an ECG monitor with Arduino’s if you want to build your own.
>
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
>
>