1. Linked Stream Data: a URI naming proposal Juan F. Sequeda – Oscar Corcho University of Texas at Austin Universidad Politécnica de Madrid http://www.semsorgrid4env.eu/

2. Outline Motivation Requirements Proposal for URIs Conclusions

3. Motivation There are naming recommendations for URIs in the Linked Data world Use URIs as names for things. http://www.w3.org/TR/cooluris/ Use HTTP URIs so that people can look up those names. When someone looks up a URI, provide useful information, using appropriate standards (RDF, SPARQL) Include links to other URIs, so that more things can be discovered. However, there are no such recommendations for how to encode URIs for Linked Stream Data

4. Requirements (I) Identification and querying Use URIs as names for things. Sensors should be identified by URIs. Stream Data emitted by sensors should be identified by URIs. The information returned by a sensor URI should be its metadata. E.g., SensorML-like data The information returned by a stream data URI should be the observations of the sensor. Open question for discussion: is this the right level of abstraction? Is the RDF data that we provide enough/adequate/correct?

5. Addressing the first set of requirements http://www.linkeddatastreams.org/sensor/heartrate/1 @prefix owl: @prefix rdfs: @prefix rdf: @prefix hr: @prefix hrsensor: @prefix sensor: hrsensor:1 rdf:type sensor:Sensor ; sensor:measures _measurement. _measurement rdf:type hr:HeartRateMonitor

6. Addressing the first set of requirements

7. Requirements (II) Stream data should be identified… Temporal requirements in specific moments in time in specific time windows Time used to describe time points or time windows should be expressed in a given unit of time (milliseconds, seconds, minutes, etc) Spatial requirements for a specific location in a bounding area Bounding areas can be defined by a radio, square or poliygon Spatio-temporal requirements at a specific moment in time and specific location in a time window at a specific location at a specific moment in time and in a bounding area in a time window and in a bounding area

8. Addressing the second set of requirements Time (sampling or result time?) http://www.linkeddatastreams.org/sensor/name/%time% http://www.linkeddatastreams.org/sensor/name/%start time%,%end time% Space (inspired by linkedgeodata.org) http://www.linkeddatastreams.org/sensor/name/%latitude%, longitude%/%radius% Time and space http://www.linkeddatastreams.org/sensor/name/%time%/%la titude%,%longitude%/%radius% http://www.linkeddatastreams.org/sensor/name/%start time%,%end time%/%latitude%,%longitude%/%radius%

9. http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00 hrsensor:1 sensor:measures. rdf:type hr:HeartRateMonitor; hr:heartRate "74"; hr:timestamp "2009-07-15 17:00:00"^^xsd:dateTime. Open question for discussion: is this the right level of abstraction? Is the RDF data that we provide enough/adequate/correct?

10. http://www.linkeddatastreams.org/sensor/heartrate/1/2009-07-15 17:00:00, 2009-07-15 18:00:00 hrsensor:1 sensor:measures. hrsensor:1 sensor:measures. hrsensor:1 sensor:measures. Open question for discussion: add more (explicit) metadata about time?