Time series observations are a common method of collecting sensor data. The Open Geospatial Consortium (OGC) Sensor Web Enablement (SWE) provides a standard representation for time series observations within the Observations and Measurements language, and therefore is in heavy use on the Sensor Web. By providing a common model, Observations and Measurements (O&M) facilitates syntax-level integration, but lacks the ability to facilitate semantic-level integration. This inability can cause problems with interoperability between disparate sensor networks that may have subtle variations in their sensing methods. An ontological representation of time series observations could provide a more expressive model and resolve problems of semantic-level interoperability of sensor networks on the Semantic Sensor Web. In this paper, such an ontology model is proposed, as well as a real-world usecase from sensor networks currently measuring rainfall in the South Esk river catchment in the North East of Tasmania, Australia.
Sensors are quickly becoming ubiquitous and can be found in a vast range of environments. Therefore, not surprisingly, there are multitudes of ways that sensors generate and represent observation data. Such differences may include the data formats, units of measurement, spatiotemporal resolution, domain of application, quality of observation, and the characteristics of the data over time, e.g. frequency, percentage of data loss, when data loss occurs, etc. All of these factors affect the integration of data from different sensors measuring phenomena.
This is equally true in the water resource management domain. In the Tasmanian South Esk river catchment, several sensor systems of different types are deployed for measuring rainfall. These sensors provide a data rich environment for continuous flow forecasting using Data Driven Modeling (DDM). When integrating data from different sources or mapping data to sensor (or measurement) information models, the semantics of the data need to be well understood. It is also important to register the semantics of shared data elements so that consumers of the data (any system designer, domain experts, and end users) can precisely determine the exact meaning of data occurring at interfaces between components of the information models. Of all the possible types of sensor data models, we focus on time series.
A time series is a sequence of observations which are ordered in time. A time
series observation model is a common method of representing sensor data with a
linear temporal order. As such, time series observations are utilized in a wide variety
of fields such as statistics and signal processing for advanced analysis and forecasting.
Many sensing systems on the Sensor Web use data collection methods that naturally
lend themselves to representation as time series observations. Accordingly, the OGC
Sensor Web Enablement (SWE) [
In order to make our discussion more clear, we will use descriptions of the sensor
systems monitored by the CSIRO Tasmanian ICT Centre as a running example. As of
this writing, there are twenty rain gauge sensor systems in Tasmania monitored by the
Australian Commonwealth Scientific and Industrial Research Organization (CSIRO).
The sensing systems at CSIRO adhere to the OGC-SWE standards and publish
observation data in O&M. In particular, the rain gauge sensors publish rainfall
observation data with the om:TimeSeriesObservation model (the om namespace is
used to represent concepts in O&M). These rain gauge sensors collect rainfall in a
bucket (or cup) and, when filled, the bucket tips and empties its contents. Because the
system is aware of how much rainfall is required to fill the bucket, the rainfall level
can be accurately recorded by monitoring when the bucket tipping events occur.
Figure 1 shows an illustration of a rain gauge sensor [
The remainder of the paper is organized as follows. Section 2 presents background material on the sensor network in the Tasmanian South Esk river catchment, the Sensor Web Enablement, and Semantic Web. Several different types of time series observations are introduced in Section 3. In Section 4, an ontological representation of time series observations is discussed. Finally, conclusions and future work are detailed in section 5.
Scientists have long understood the importance of quality time series observations for
conducting research and analyzing data. This is also true for the sensor network
project in the South Esk river catchment in Tasmania. The models for time series
observations, as described in this paper, are reliant on two sets of standardizations, (1)
the Semantic Web languages defined by the World Wide Web Consortium (W3C),
and (2) the Observations and Measurements (O&M) language defined by the Open
Geospatial Consortium (OGC) Sensor Web Enablement (SWE). This combination is
typical of applications on the Semantic Sensor Web [
Drought is a common problem that has been plaguing Australia for many years. The state of Tasmania is especially affected, with drought conditions worsened in 2008 and many areas reporting no significant rainfall for three years [6]. Consequently, water has become an exceptionally scarce resource. The inefficient management of water resources is exacerbated by a deficiency of quality information about Australia’s water conditions. To overcome this problem, CSIRO has developed the ‘Water for a Healthy Country’ Flagship [7], a national research program addressing sustainable management of Australia’s water resources. As part of this program, the CSIRO Tasmanian ICT Centre aims at establishing a technology platform to provide water information systems delivering dynamic, timely reporting and forecasting of water resources. This will be achieved through four key research areas that will [7]: 1. Enable water information interoperability through standards development, web service integration, semantic web, model interoperability. 2. Improve the usability and availability of water data through development in wireless and wired sensor networks, improved telemetry integration, novel hydrologic measurement techniques, data analysis and data assimilation methods. 3. Develop next generation modeling and forecasting tools through interoperable, modular computer models, advanced computing algorithms and powerful scenario planning tools. 4. Develop improved reporting and visualization tools through new interoperable and modular tools, products and technologies for operating, reporting and accounting of water resources at multiple scales.
The CSIRO Tasmanian ICT Centre is building a test bed system that attempts to incorporate sensors, models and data from multiple organizations operating within the South Esk Catchment [8]. The South Esk Catchment covers an area of approximately 3350 square kilometers and experiences widely varying climatic conditions with rainfall ranging from 500 mm in the low lying areas to 1500 mm in the highlands. Consequently, there is a high spatial variability in runoff yield [9]. Runoff yield is the quantity of water that travels over the land surface, through the soil, and groundwater, and is discharged into surface streams (i.e. the amount of water that leaves the catchment). There is an opportunity to improve water planning and management through continuous monitoring and forecasting of river flow. The project will explore how environmental sensors, hydrological models and decision support tools can be combined in a pluggable hydrological sensor web for continuous flow forecasting. A pluggable hydrological sensor web would have the ability to integrate any sensor into the web-based system without explicit re-configuration.
The Open Geospatial Consortium established the Sensor Web Enablement as a suite
of specifications related to sensors, sensor data models, and sensor Web services that
will enable sensors to be accessible and controllable via the Web [
Sensor Observations Service (SOS) - Standard web service interface for requesting, filtering, and retrieving observations and sensor system information. This is the intermediary between a client and an observation repository or near real-time sensor channel.
Sensor Planning Service (SPS) - Standard web service interface for requesting user-driven acquisitions and observations. This is the intermediary between a client and a sensor collection management environment.
Sensor Alert Service (SAS) - Standard web service interface for publishing and subscribing to alerts from sensors.
Web Notification Services (WNS) - Standard web service interface for
asynchronous delivery of messages or alerts from SAS and SPS web services and
other elements of service workflows [
The Semantic Web, as described by the W3C Semantic Web Activity, is an evolving extension of the World Wide Web in which the semantics, or meaning, of information on the Web is formally defined [10]. Formal definitions are captured in ontologies, making it possible for machines to interpret and relate data content more effectively. In this project, we use the Web Ontology Language (OWL) [11] to encode ontologies and the general purpose rule engine for the Jena Semantic Web Framework to encode rules [12].
As mentioned in the introduction, time series observations are often encoded in O&M. Several attempts have been made in creating an ontological representation of O&M. Probst [13] performs an ontological analysis of the core O&M terms. Through this analysis, an OWL encoding of O&M is aligned with the DOLCE [14] foundational ontology. In a more recent attempt [5], the authors generate an OWL-DL encoding of O&M, called O&M-OWL, in order to reason over sensor data and infer complex features. The ontological representation of time series observations discussed in this paper uses O&M-OWL. The relationships discussed in Section 4.1 were originally described in [5] (with the exception of om-owl:memberOf and without the detailed RDF/XML serialization provided here). In order to avoid confusion, from this point forward we will refer to O&M in OWL as O&M-OWL and prefix concepts with the namespace om-owl, and refer to O&M in XML as O&M-XML and prefix concepts with the namespace om-xml. 3
There are various ways to monitor, collect, and represent sensor data with time series observations. At the CSIRO Tasmanian ICT Centre, there are four distinct methods of monitoring rain gauge sensors, which can be divided along two dimensions: (1) cumulative vs. non-cumulative and (2) interval-based vs. event-based.
Cumulative systems continually increment the observation result value as the monitoring progresses through time.
Non-cumulative systems are not incremental and thus provide an independent value for each observation result.
Interval-based systems generate observation result values at discrete points within a specified interval of time.
Event-based systems generate observation result values only when a defined event occurs.
Interval-based/Non-cumulative systems generate independent observation result values at fixed time points. Each observation result value represents the amount of rainfall measured since the end of the previous interval. Figure 2 shows an example with fixed time points every thirty minutes from 1:00 AM to 3:00 AM. The vertical lines represent the fixed intervals and the dots represent observation result values that have measured rainfall. Each bucket tip event represents 0.2 mm of measured rainfall. So, from this example, we can see that between 1:00 AM and 1:30 AM, one bucket tip event occurred. No such events occurred between 1:30 AM and 2:00 AM. Two events occurred between 2:00 AM and 2:30 AM, and one between 2:30 AM and 3:00 AM.
Interval-based/Cumulative systems generate incremental observations result values at fixed time points. Each observation result value represents the cumulative amount of rainfall measured since the start of the process. Figure 3 shows an example with fixed time points every thirty minutes from 1:00 AM to 3:00 AM. The vertical lines represent the fixed intervals and the dots represent the incremental addition of observation result values measuring rainfall. So, from this example, we can see that between 1:00 AM and 1:30 AM, one bucket tip event occurred. Between 1:00 AM and 2:00 AM, still only one bucket tip occurred. Three events occurred between 1:00 AM and 2:30 AM, and four between 1:00 AM and 3:00 AM.
Event-based/Non-cumulative systems generate independent observations result values whenever a defined event occurs. Each observation result value represents the amount of rainfall measured since the previous event. Figure 4 shows an example with a total time interval from 1:00 AM to 3:00 AM. The vertical lines represent bucket tip events and the dots represent observation result values that have measured rainfall. So, from this example, we can see that at 1:20 AM the first bucket tip event occurred, the second at 2:10 AM, the third at 2:20 AM, and the fourth at 2:50 AM.
Event-based/Cumulative systems generate incremental observation result values whenever a defined event occurs. Each observation result value represents the cumulative amount of rainfall measured since the start of the process. Figure 5 shows an example with a total time interval from 1:00 AM to 3:00 AM. The vertical lines represent bucket tip events and the dots represent the incremental addition of observation result values measuring rainfall. So, from this example, we can see that at 1:20 AM the first bucket tip event occurred, the second at 2:10 AM, the third at 2:20 AM, and the fourth at 2:50 AM.
The authors admit there could be additional methods and categories; however, we hope these will be adequate and are sufficiently general for the current discussion. Table 1 shows how many rain gauge systems monitored by the CSIRO Tasmanian ICT Centre have the properties described above.
A time series observation is a specialized observation collection. More specifically, if
the member observations of an observation collection have the same feature of
interest, the same observed property, and different sampling times, this set of
observations may be represented as a time series observation whose sampling time is
the period encompassing all the member times [
An observation is an act of observing a property or phenomenon, with the goal of
producing an estimate of the value of the property [
<owl:ObjectProperty rdf:about="#featureOfInterest">
<rdfs:domain rdf:resource="#Observation"/>
<rdfs:range rdf:resource="#Feature"/>
<owl:inverseOf rdf:resource="#propertyValueProvider"/>
</owl:ObjectProperty>
om-owl:observedProperty “identifies or describes the phenomenon for which the
observation result provides an estimate of its value. It must be a property
associated with the type of the feature of interest [
<owl:FunctionalProperty rdf:about="#observedProperty"> <rdf:type rdf:resource=
"http://www.w3.org/2002/07/owl#ObjectProperty"/>
<rdfs:domain rdf:resource="#Observation"/>
<rdfs:range rdf:resource="#PropertyType"/>
</owl:FunctionalProperty>
om-owl:samplingTime is the “time that the result applies to the feature-of-interest
[
<owl:FunctionalProperty rdf:about="#samplingTime"> <rdf:type rdf:resource=
"http://www.w3.org/2002/07/owl#ObjectProperty"/> <rdfs:domain rdf:resource="#Observation"/> <rdfs:range rdf:resource="#Time"/> </owl:FunctionalProperty> om-owl:observationLocation is the location of an observation event; usually associated with the location of the sensor when an observation occurred (i.e., om:samplingTime). Example includes a single point observation location with latitude, longitude, and elevation coordinates.
<owl:FunctionalProperty rdf:ID="observationLocation"> <rdf:type rdf:resource=
"http://www.w3.org/2002/07/owl#ObjectProperty"/>
<rdfs:domain rdf:resource="#Observation"/>
<rdfs:range rdf:resource="#Location"/>
</owl:FunctionalProperty>
• om-owl:result is an “estimate of the value of some property generated by a
known procedure [
<owl:FunctionalProperty rdf:about="#result"> <rdf:type rdf:resource=
"http://www.w3.org/2002/07/owl#ObjectProperty"/>
<rdfs:domain rdf:resource="#Observation"/>
<rdfs:range rdf:resource="#ResultData"/>
</owl:FunctionalProperty>
• om-owl:procedure is a “description of a process used to generate the result. It
must be suitable for the observed property [
<owl:FunctionalProperty rdf:ID="procedure"> <rdf:type rdf:resource=
"http://www.w3.org/2002/07/owl#ObjectProperty"/> <rdfs:domain rdf:resource="#Observation"/> <rdfs:range rdf:resource="#Process"/> <owl:inverseOf rdf:resource="generatedObservation"/> </owl:FunctionalProperty> • om-owl:memberOf is a relation to a set of observations, or observation collection.
Example includes a rainfall observation that is a member of a time series observation collection.
<owl:TransitiveProperty rdf:ID="memberOf"> <rdf:type rdf:resource=
"http://www.w3.org/2002/07/owl#ObjectProperty"/> <rdfs:domain rdf:resource="#Observation"/> <rdfs:range rdf:resource="#ObservationCollection"/> <owl:inverseOf rdf:about="#member"/> </owl:TransitiveProperty>
An observation collection is composed of a set of member observations [
<owl:TransitiveProperty rdf:about="#member"> <rdf:type rdf:resource=
"http://www.w3.org/2002/07/owl#ObjectProperty"/> <rdfs:domain rdf:resource="#ObservationCollection"/> <rdfs:range rdf:resource="#Observation"/> <owl:inverseOf rdf:resource="#memberOf"/> </owl:TransitiveProperty>
In addition to being a specialized type of observation collection, a time series
observation is also considered a type of observation. Therefore,
omowl:TimeSeriesObservation inherits properties from both om-owl:Observation and
om-owl:ObservationCollection described above. While
omowl:TimeSeriesObservation is a sub-class of om-owl:Observation, it does not
normally make use of the om-owl:result relationship. (It is conceivable that this
property could be useful when modeling cumulative observation result values,
however, this is not used in the current model for reasons to be detailed below.) On
the other hand, om-owl:samplingTime is a very important property for
omowl:TimeSeriesObservation, whose sampling time is the period encompassing all the
member times [
From the O&M specification, we know that a time series observation is a
specialization of an observation collection with the restriction that all member
observations must share the same feature of interest and the same observed properties
[
"http://www.csiro.au#SouthEskCatchment"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> In addition, a time series observation sub-class, csiro:SouthEskCatchmentRainGuageTimeSeriesObservation, contains the restriction that all instantiations of this type of time series observation have all member observations of type csiro:SouthEskCatchmentRainGuageObservation through the owl:allValuesFrom restriction. <owl:Class rdf:about= "http://www.csiro.au#SouthEskCatchmentRainGuageTimeSeriesObservation”> <rdfs:subClassOf rdf:resource=”#TimeSeriesObservation”/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#member"/> <owl:allValuesFrom rdf:resource= "http://www.csiro.au#SouthEskCatchmentRainGuageObservation"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> Through this combination of OWL property restrictions, we are able to more faithfully and explicitly represent the concept of om:TimeSeriesObservation.
Given the heavy use of O&M-XML on the Sensor Web, it seems reasonable that translating O&M-XML documents into O&M-OWL instances could be a popular means of populating the ontology knowledge base. When generating instances of omowl:TimeSeriesObservation, several property values can be directly translated from corresponding O&M-XML documents, including: om-owl:featureOfInterest, omowl:observedProperty, om-owl:samplingTime, om-owl:observationLocation, and omowl:procedure. The individual om-owl:Observation instances share many property values with the om-owl:TimeSeriesObservation instance of which they are related through the om-owl:memberOf relation. Several of these shared properties can be directly propagated given that a om-owl:member relation holds from an instance of om-owl:TimeSeriesObservation. The relations that may be propagated include omowl:featureOfInterest, om-owl:observedProperty, om-owl:observationLocation, and om-owl:procedure. This translation of property values can be encoded in a set of rules. As an example, the rule for propagating om-owl:featureOfInterest follows (in Jena rule engine syntax [9]): [PropagateFeatureOfInterestRule: (?tso rdf:type om-owl:TimeSeriesObservation) (?tso om-owl:member ?obs) (?tso om-owl:featureOfInterest ?foi) (?obs om-owl:featureOfInterest ?foi)] The other translatable property values have similar rules which we omit for the sake of brevity. The two remaining relations of om-owl:Observation to be instantiated include om-owl:samplingTime and om-owl:result. Sampling time for instances of omowl:Observation can be directly translated from om-xml:samplingTime of the omxml:TimeSeriesObservation. The instantiation of om-owl:result relation is more involved since the cumulative observation result values are dependent on previous observations, and we want to generate an independent representation for all observations. In order to accomplish this, we simply convert the cumulative result values into non-cumulative result values. Unlike the conversion of omowl:samplingTime, om-owl:result can be translated without loss of expressiveness since the cumulative result can always be recalculated. Therefore, there is no need to create sub-classes of om-owl:ResultData nor sub-properties of om-owl:result in order to explicitly represent the cumulative/non-cumulative distinction. The conversion of cumulative result values into non-cumulative result values is a straightforward process of subtracting from each observation the result values of those observations that were generated at a previous time point (either at a fixed time point, or when an event occurred).
The Semantic Sensor Web aims to integrate Semantic Web technologies with sensing systems in order to provide more expressive representation, enhanced analysis, and improved access and discovery of sensor data on the Web. In this paper, we present an ontological representation of time series observations that could add much value to time series sensor data on the Semantic Sensor Web.
In the future we hope to utilize this ontology to provide advanced query and manipulation of time series observations. Previously, queries of time series observations could only return data formatted in the same manner in which it was collected. We believe that by leveraging an ontological representation of time series observations, we may allow for automatic conversion of event-based time series observation to interval-based time series observation, and vice-versa. For example, a user could query against an event-based system and receive an interval-based time series observation as a result. At the CSIRO Tasmanian ICT Centre, a practical use of this representation would be to enable the automated conversion of such observations for input into forecast models, which may, for example, require a time series observation with daily frequency of a given phenomenon which is only available as an hourly measurement. The required conversion methods could be encoded in the time series ontology. In addition, a set of operations on time series observations, such as union, concatenation, and intersection, would be useful for advanced integration. And finally, since time is such an obviously important component of time series observations, we intend on integrating this ontology with OWL-Time [15], a W3C recommended ontology based on temporal calculus that provides descriptions of temporal concepts such as instant and interval, and the relations between them.
We believe that an ontological representation of time series observations is an important addition to the Semantic Sensor Web, and the practical use of this representation at the CSIRO Tasmanian ICT Centre provides a much needed experimental platform for future investigation into the integration of Semantic Web technologies with sensing systems.
Acknowledgments. This research was supported in part by The Dayton Area Graduate Studies Institute (DAGSI), AFRL/DAGSI Research Topic SN08-8: "Architectures for Secure Semantic Sensor Networks for Multi-Layered Sensing." We also thank Andrew Pratt and the sensor network project team at the CSIRO Tasmanian ICT Centre for their contribution towards a better understanding of the use-case scenario involving rain gauge sensors. The Tasmanian ICT Centre is jointly funded by the Australian Government through the Intelligent Island Program and CSIRO. The Intelligent Island Program is administered by the Tasmanian Department of Economic Development and Tourism.
5. Henson, C., Pschorr, J., Sheth, A., and Thirunarayan, K.: SemSOS: Semantic Sensor Observation Service. International Symposium on Collaborative Technologies and Systems (CTS2009), Workshop on Sensor Web Enablement (SWE2009), Baltimore, Maryland, 2009. 6. Drought in Australia, http://en.wikipedia.org/wiki/Drought_in_Australia 7. Water for a Healthy Country Flagship, http://www.csiro.au/org/WfHC.html 8. Guru, S.M., Taylor, P., Neuhaus, H., Shu, Y., Smith, D., Terhorst, A.: Hydrological Sensor Web for the South Esk Catchment in the Tasmanian state of Australia. 4th IEEE International Conference on e-Science, 7-12 December 2008, Indianapolis, Indiana, USA. 9. D. P. I. W. Water Assessment Branch: Surface Water Hydrology of the South Esk River
Catchment. Technical Report. Tech. Rep. WA 07/02, 2007. 10. W3C Semantic Web Activity, http://www.w3.org/2001/sw/ 11. Web Ontology Language (OWL), http://www.w3.org/TR/owl-ref/ 12. Jena Semantic Web Framework, http://jena.sourceforge.net/ 13. Probst, F.: An Ontological Analysis of Observations and Measurements. 4th. International
Conference on Geographic Information Science (GIScience), Munster, Germany, 2006. 14. Masolo, C., et al.: WonderWeb Deliverable D18, Ontology Library (final).
http://www.loa-cnr.it/Papers/D18.pdf, 2003 15. Time Ontology in OWL (OWL-Time), http://www.w3.org/TR/owl-time/