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

Outline Motivation Requirements Proposal for URIs Conclusions

Motivation There are naming recommendations for URIs in the Linked Data world Use URIs as names for things. 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

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?

Addressing the first set of requirements sensor: hrsensor:1 rdf:type sensor:Sensor ; sensor:measures _measurement. _measurement rdf:type hr:HeartRateMonitor

Addressing the first set of requirements

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

Addressing the second set of requirements Time (sampling or result time?) time%,%end time% Space (inspired by linkedgeodata.org) longitude%/%radius% Time and space titude%,%longitude%/%radius% time%,%end time%/%latitude%,%longitude%/%radius%

17:00:00 hrsensor:1 sensor:measures. rdf:type hr:HeartRateMonitor; hr:heartRate "74"; hr:timestamp " :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?

17:00:00, :00:00 hrsensor:1 sensor:measures. hrsensor:1 sensor:measures. hrsensor:1 sensor:measures. Open question for discussion: add more (explicit) metadata about time?