We need to consider streaming in respect to thing descriptions.
I am working on a demo for access to a stream of electrocardiogram sensor readings. In the simple case there is one channel with an integer value. These are streamed at 100 Hz. One idea for the corresponding thing description is as follows:
This specifies the upper and lower bounds, the sampling rate in Hertz, the URI for the stream, and its protocol.
A more complex example is where the stream includes linear acceleration, along three axes, in addition to the ECG voltage reading. This could be used to count the steps someone walks, as well as to indicate where ECG data may be unreliable due to the physical movement messing up the readings.
Which has a time stamp, the ECG voltage reading, followed by the acceleration along the X, Y and Z axes. Note that the acceleration values are missing every other sample, as the sensor operates at half the frequency of the ECG sensor. Here is one idea for the corresponding thing description:
The above illustrates how property definitions can be nested and how type names can be defined implicitly or explicitly. Metadata can be redefined within an inner scope to override a value defined by an outer scope. This also applies to the explicit type name declarations, so that in this example, the rate for the acceleration values is 32 Hz not 64 Hz.
This is JSON and doesn’t purport to be JSON-LD, but can be translated to RDF with a few simple rules and the addition of links to the semantic context.
For the corresponding APIs, I have started from the HTML5 EventSource and added support for registering streams on the server side. The data is serialised with JSON.stringify().
My demo uses Server Sent Events for streaming over HTTP. This is very easy to implement, and automatically reconnects when a connection drops. My servers are implemented in NodeJS, and I use HTML5 and Canvas2D for the user interface.
p.s. Note that the use of quote marks is messed up from typing into an editor and will be fixed later.
We need to consider streaming in respect to thing descriptions.
I am working on a demo for access to a stream of electrocardiogram sensor readings. In the simple case there is one channel with an integer value. These are streamed at 100 Hz. One idea for the corresponding thing description is as follows:
This specifies the upper and lower bounds, the sampling rate in Hertz, the URI for the stream, and its protocol.
A more complex example is where the stream includes linear acceleration, along three axes, in addition to the ECG voltage reading. This could be used to count the steps someone walks, as well as to indicate where ECG data may be unreliable due to the physical movement messing up the readings.
Here is an example of some successive samples:
Which has a time stamp, the ECG voltage reading, followed by the acceleration along the X, Y and Z axes. Note that the acceleration values are missing every other sample, as the sensor operates at half the frequency of the ECG sensor. Here is one idea for the corresponding thing description:
The above illustrates how property definitions can be nested and how type names can be defined implicitly or explicitly. Metadata can be redefined within an inner scope to override a value defined by an outer scope. This also applies to the explicit type name declarations, so that in this example, the rate for the acceleration values is 32 Hz not 64 Hz.
This is JSON and doesn’t purport to be JSON-LD, but can be translated to RDF with a few simple rules and the addition of links to the semantic context.
For the corresponding APIs, I have started from the HTML5 EventSource and added support for registering streams on the server side. The data is serialised with JSON.stringify().
My demo uses Server Sent Events for streaming over HTTP. This is very easy to implement, and automatically reconnects when a connection drops. My servers are implemented in NodeJS, and I use HTML5 and Canvas2D for the user interface.
p.s. Note that the use of quote marks is messed up from typing into an editor and will be fixed later.