A Proposal for Linked Stream Data

In the previous section, we have presented several requirements in order to identify sensors and stream data coming from sensors on the web. Per our motivation, we believe Stream Data can become part of the Web of Data by defining a URI-based mechanism, following the linked data principles, to identify sensors and stream data, optionally given their spatial and temporal context, which can be provided in many different forms. In this section, we present a proposal of human-friendly URIs¹ to identify sensors and stream data.

1 It is important to note that the fact of using a human-friendly URI that encodes implicitly its semantics in the URI itself does not mean that the explicit semantics are necessarily provided for them. However, in our proposal we aim at combining human readability and the provision of explicit semantics when the URI is dereferenced. This last one is the only one that will allow automation of tasks based on semantics. The first one is only for human consumption and should be always considered like that by any application that uses them.

4.1 URI for Sensors

Sensors are real objects that can be identified by a URI. The data that is returned after de- referencing the URI is the sensor or sensor network metadata (type of sensor, type of measurements made, etc.).

For example, for the sensor that streams the Heart Rate for a Patient 1, we could use the following URI:

http://www.linkeddatastreams.org/sensor/heartrate/1

Following the guidelines on "cool URIs" for real-world objects², these URIs have to be de- referenceable on the Web and be unambiguous, which is the case in our proposal.

For example, de-referencing the URI that identifies Heart Rate Sensor for Person 1 would lead us to the following RDF document³:

@prefix owl: <http://www.w3.org/2002/07/owl#>

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

@prefix hr:

<http://www.linkeddatastreams.org/sensors/ontology/HeartRateMonitor.owl#>

@prefix hrsensor: <http://www.linkeddatastreams.org/sensor/heartrate/>

@prefix sensor: <http://www.csiro.au/Ontologies/2009/SensorOntology.owl#>

hrsensor:1 rdf:type sensor:Sensor ;

sensor:measures _measurement . _measurement rdf:type hr:HeartRateMonitor .

4.2 URIs for Time

Sensors normally emit data at a certain frequency. In the Heart Rate case, data is streamed every couple seconds. In the Linear Road Benchmark, data is streamed every 30 seconds. Hence it is advisable to have a URI scheme that identifies the observations that the sensor emits at a given time, such as the following:

http://www.linkeddatastreams.org/sensor/name/%time%

Furthermore, in many situations it would be also useful to represent time windows (intervals of time), as it happens with most data stream and sensor network query languages (e.g., CQL [3]).

Therefore we propose the following URI scheme:

2 http://www.w3.org/TR/cooluris

3 Please note that the type of metadata that a sensor can provide is not standardised, and this is only a simple example of how the URI would be dereferenced. The W3C incubator group on Semantic Sensor Networks is currently working on different types of sensor ontologies, which include sensor types, observations and measures, etc.

http://www.linkeddatastreams.org/sensor/name/%start time%,%end time%

For example, the following URI identifies the observations from the Heart Rate sensor of Person 1 on July 15, 2009 at 17:00:

http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00

De-referencing this URI may lead us to an RDF document like the following:

hrsensor:1 sensor:measures

<http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00>.

<http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00>

rdf:type hr:HeartRateMonitor;

hr:heartRate "74";

hr:timestamp "2009-07-15 17:00:00"^^xsd:dateTime .

And the following URI identifies the observations from the Heart Rate sensor of Person 1 between July 15, 2009 at 17:00 and July 15, 2009 at 18:00:

http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00, 2009-07-15 18:00:00

For example, de-referencing this URI may lead us to the following RDF document⁴:

hrsensor:1 sensor:measures

<http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00>.

hrsensor:1 sensor:measures

<http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:05>.

hrsensor:1 sensor:measures

<http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:10>.

Note that if %start time% and %end time% are the same, then the time window is 0, hence the URI would be the same as the URI with one given time. For example:

<http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00, 2009-07-15 17:00:00>

owl:sameAs

<http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00>

4.3 URIs for Space

A sensor may also emit its current location together with the rest of data, if it is mobile, or may have as part of its metadata information about the location where it is place, in the case of static

4 The three measures hereby shown as an example may also come bundled in an RDF list.

ones. In the Heart Rate and the Linear Road cases, sensors are mobile, hence their coordinates depend on the sensor location.

The Linked GeoData project has already proposed a way of representing spatial dimensions as Linked Data. Therefore we follow their guidelines. A URI to identify spatial dimension from a sensor would be:

http://www.linkeddatastreams.org/sensor/name/%latitude%,%longitude%/%radius%

For example, the following URI identifies the car position emitted from Car 1 in a 1 meter radius from the coordinates 50.60242, -2.5225.

http://www.linkeddatastreams.org/sensor/car/1/50.60242,-2.5225/1

For example, de-referencing this URI would lead us to the following RDF document:

@prefix carsensor: <http://www.linkeddatastreams.org/sensor/car/>

carsensor:1 sensor:measures

<http://www.linkeddatastreams.org/sensor/car/1/50.7, -2.6>.

carsensor:1 sensor:measures

<http://www.linkeddatastreams.org/sensor/car/1/51.2, -3.3>.

…

This leads us to have URIs that identify observations from sensors are specific locations. If this type of URI would be de-referenced, it would lead us to the following RDF document:

carsensor:1 sensor:measures

<http://www.linkeddatastreams.org/sensor/car/1/50.7, -2.6>.

<http://www.linkeddatastreams.org/sensor/car/1/50.7, -2.6>

rdf:type lr:CarLoc;

lr:speed "60";

hr:timestamp "2009-07-15 17:00:00"^^xsd:dateTime .

A same location can emit different observations, and this would be differentiated through time, because we assumed that two or more observations of a sensor cannot be emitted at the same time.

In these examples, we have used a radius as the bounding area. Other possibilities can be the use of a bounding box or a bounding polygon.

4.4 URIs for Time and Space

Now that we have proposed how to represent Time and Space in URIs separately, we propose a way to represent them together. As discussed before, this type of URI makes more sense for sensors that are mobile. Given that we have proposed two ways of representing time in URIs (specific time and time window), we therefore propose the following two schemes for

representing time and space in URIs (please note that temporal attributes go before the spatial attributes, however, there is no strong reason for this and it could be done in a different order):

http://www.linkeddatastreams.org/sensor/name/%time%/%latitude%,%longitude%/%r adius%

http://www.linkeddatastreams.org/sensor/name/%start time%,%end time%/%latitude%,%longitude%/%radius%

The following URI identifies the observations of the Heart Rate sensor of Person 1 on July 15, 2009 at 17:00 when it was in a 1 meter radius from the coordinates 50.60242, -2.5225:

http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00/50.60242,-2.5225/1

The following URI takes in account a time window and identifies the observations of the Heart Rate sensor of Person 1 between July 15, 2009 at 17:00 and July 15, 2009 at 18:00 when it was in a 1 meter radius from the coordinates 50.60242, -2.5225:

http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00,2009- 07-15 17:00:00/50.60242,-2.5225/1