Markus Stocker bio photo

Markus Stocker

Between information technology and environmental science with a flair for economics, the clarinet, and the world of soups and salads.

Email Twitter Google+ LinkedIn Github

I’m assuming a given repository for time-series as it is common for sensor data. Such a repository may be any kind of RDBMS. In the following, I discuss what may be one possible way to serve data managed in the repository to client applications. I’m further assuming that a standard client operation is to retrieve time-series for a time interval [t1, t2] for a specific sensor managed by the repository. Finally, we may have a number of different clients, e.g. users connecting with a browser and applications that reuse the data for some purpose.

A solution could be to expose the data in the repository using a RESTful framework, e.g. Restlet. Part of the elegance of this approach lies in URI templates. For the purpose discussed here, we could route the following URI template to a specific resource,{sensorId}/{t1}/{t2}

and replace the templates for sensorId, t1 and t2 with values for a specific request, being t1 and t2 points in time representing an interval. The approach is also elegant because content negotiation allows us to serve multiple representations of the resource, i.e. serve different representations of the time-series depending on the user agent. Notably, a user calling the resource within a browser may want to see a plot of the time-series while an application calling the same resource would be better served with an RDF/XML representation of the time-series, e.g.

<Sensor rdf:about="#sensor-001">
  <label>My Sensor</label>

<Observation rdf:about="#observation-001">

<Observation rdf:about="#observation-002">

Naturally, XML or SensorML may be served also, possibly as a separate representation.