This paper discusses an OWL ontology for specifying sensors. The ontology is intended as the basis for the semantic representation of sensors and as the formal description for reasoning about sensors and observations. The paper describes the ontology, presents two example sensor descriptions and shows how standard reasoning and querying techniques can be used to perform tasks including classi cation and composition. In conjunction with the technical material the trade-o s required to express complex material in OWL is also discussed.
A number of ontologies for specifying sensors have been developed and published.
However, all lack the ability to describe sensors as compositions of existing
sensors and algorithms. SensorML [
This paper presents an ontology that can describe the capabilities and
properties of sensors as well as describing sensors as compositions of their
components (x3). Two examples of sensors encoded in the ontology are presented (x4).
The rst (x4.1) shows the encoding of details of an actual sensor into the
ontology, and the second (x4.2) discusses composition and virtual instruments. The
examples are used to illustrate a discussion on OWL classi cation (x5) and
reasoning other than OWL (x5.1). The main discussion on reasoning (x5.2) shows
how the SPARQL plus OWL reasoning in SPARQL-DL [
Sensors observe physical qualities of features: for example, the temperature (quality) of a lake (feature). Here we take sensors to be sources that react to stimulus (physical or digital) and produce values representing a quality, thus including transducers, sensor devices and computations: for example, the speci cation of wind chill sensor in Section 4.1 could be implemented as an in situ device that measures wind speed and ambient temperature and calculates wind chill or a program that reads wind speed and ambient temperature measurements from external, co-located sensors and calculates wind chill.
While semantics can assist in searching for existing sensors, a more advanced use is to automatically compose a sensor satisfying a query if no such sensor exists. Once composed, such a sensor should be available as a sensor in its own right, and available to be used as a component of new virtual sensors. For example, a query such as \report event E each time condition C is reached in time period P ", requires nding or composing a sensor that can detect C, nding or making a process that builds an E from a C and understanding the constraints in availability, power, and eventual degradation of the sensors over P .
Searching for and, if required, automatically or semi-automatically
composing web services remains a much researched topic for Web services; see, for
example, the September 2008 edition of the Data Engineering Bulletin [
Specifying detailed aspects of sensors and compositions requires a modelling capacity beyond the expressive and reasoning limits of OWL. Numeric information in describing accuracy, for example, cannot be reasoned about in description logic. However, trade-o s between the accuracy of the description and the ability to reason in OWL need to be made even for seemingly simple choices such as describing what a sensor measures or the input and output types of processes. The technical material on sensors and compositions in this paper is used to highlight a number of the choices that must be made to describe sensors in OWL.
In this paper OWL refers to the OWL2 Candidate Recommendation [
to indicate that role is a DL role with domain ConceptA and range ConceptB . The de nition of a role may be superscripted with F to indicate a functional role, T for transitive; S for symetric and R for re exive. Composition of roles is written r1 r2 for roles r1 and r2 . That individual a is classi ed into concept C is written C (a). In general, the so-called German DL Syntax is used. 2
See the survey paper in the same proceedings [
The OntoSensor [
Eid et al. [
Calder et al. [
Whitehouse, Zhao and Liu [
DL inference and LP are used with the ISTAR sensor ontology to nd sensors
that have outputs matching a task's requirements; a set covering algorithm is
then used to nd combinations that can cover all requirements [
Horan [
Clearly then, research on Web service speci cation and composition is
relevant to the semantic speci cation of sensors. Mixtures of DL inference, structural
similarity and information retrieval techniques, as in Klusch et al. [
Although the ontology3 is reasonably small with fewer than one hundred de nitions of each of concepts and roles, it is still too large to give the complete de nition here. Figure 1 pictorially represents the important parts of the ontology for this paper. 3 A version is available at http://www.w3.org/2005/Incubator/ssn/wiki/images/ 4/42/SensorOntology20090320.owl.xml. $$# $$# ! # ' $ ! $ $ ) $ $ ) ! ! ) ,
, , ! ,
* / /
! !& !&
! % !
* $ ' ! % ! !" & $ % ' % $ ! . ! % $ ! * ) + ) ) * ' )
' * % ) + % ) ) ) % $ + !$( ! ) & !$% % % ! !) ( $
! $% $ ) ! $% + !) !$() ! ! !) !( & ! ! % ! % !$ !$ , % !& !$ %, * $ $ !+
, !!" !" ! " ! ( ! "
The ontology is built around the central notion of a sensor, and then three important clusters of concepts referenced by the sensor: domain concepts, abstract sensor properties and concrete properties. The abstract properties specify sensors' functions and capabilities. The concrete properties ground the abstract by providing, for example, the interface details to the functions. It is essentially the di erence between specifying the properties of a sorting algorithm and giving a path to a binary. The abstract and concrete sections are independent in that neither requires the other: for example, the wind chill sensor in Section 4.2 speci es only the abstract properties | it is a schema for all wind chill sensors of this type and thus cannot specify the groundings, much as a speci cation of a sorting algorithm cannot also specify all implementations.
Separating concrete and abstract aspects of sensors means that descriptions of types of sensors, functions and the like can be shared among speci cations and also that a single sensor type can have multiple concrete descriptions, promoting reuse and allowing for di erences in deployment. The domain ontology is left unspeci ed: a general sensor ontology cannot hope to capture all possible domains. Instead the ontology references abstract representations of real world entities (Feature, for example, a lake), which are not observed directly but through their observable qualities (PhysicalQuality , for example, temperature or depth). Similarly, units of measurement, locations and time are not described by the ontology, but rather deferred to appropriate authoritative sources. Any external ontologies can be included with OWL imports. The SensorGrounding models the concrete realisation of a sensor. The grounding represents, in the case of an instrument, its physical implementation, including size, shape, materials and location. The grounding also models the concrete aspects of accessing data from the sensor, including the types and expected formats of input when calling functions, the format of output and other details for accessing the sensor (radio, network or physical access, for example). Each sensor may have any number of OperationModel s describing the operations (functions) of the sensor, how the measurements are made and properties of the measurements.
Process is used to model the structure and data ow of an operation. An AtomicProcess models a single computation step. A CompositeProcess can model many ways of combining processes to form new processes. An AbstractProcess is used as a unit of abstraction, allowing a single speci cation to be described at multiple levels of abstraction. The Input and Output of processes is unconstrained, allowing the model to describe physical processes as well as computations.
A ResponseModel is use to represent a sensor's responses to stimuli under various conditions. Each OperationModel may have a number of Result s which specify properties such as the function that the operation computes (its E ect ), accuracy and latency and in various Conditions .
The ontology shows a number of important issues in specifying sensors and processes in OWL. Firstly, it is not possible to actually specify in OWL what a process does: for example, the WindChillCalculation process in Section 4.2 cannot express in OWL that it computes the wind chill formula given wind speed and temperature measurements. The processes can show the process structure, data ow, etc., but some details must be handled outside OWL. Here, an Expression in some MathLanguage is essentially a string in the given language that can be parsed and interpreted outside of OWL | this is the same handling as OWL-S. Also, the types of Input s, Output s and what a sensor measures are not able to be properly expressed in OWL.4 Following OWL-S, the types of inputs and outputs are represented as the URIs of concepts, while measures follows the approach used in previous sensor ontologies.
The following examples illustrate the ontology further and demonstrate how the TBox and ABox are used to encode sensor types and sensor instances. 4
Sensors are encoded in the ontology using an interplay of TBox concepts, expressing what it means to be a particular type of sensor, and ABox individuals and roles, expressing properties of sensor instances. In the following a number of de nitions are omitted but can be reasonably inferred from the context. 4.1
The Vaisala WM30 wind sensor5 measures wind speed and direction. As an example, it shows two important aspects of the ontology. First, the two di erent measurements of the WM30 show the capacity of the ontology to describe multiple capabilities of a single sensing device. Second, since the WM30 performs 4 The de nition 9measures:Temperature, intending that the sensor measures temperatures, does not capture the correct meaning because OWL roles link individuals to individuals: there is no way to link to the concept Temperature | OWL-FULL in OWL1 can link individuals to concepts with roles, but cannot reason about such roles. Other sensor ontologies seem to take resolve this di cultly by interpreting the intention rather than the de nition.
See also the Semantic Web Best Practice Descriptions discussion on this issue http://www.w3.org/TR/swbp-classes-as-values/ 5 See http://www.vaisala.com/files/WM30_Brochure_in_English.pdf for the the Vaisala WM30 data sheet. di erently under various conditions | it's accuracy is rated at 0:3m=s for wind speeds below 10m=s, at 2% for wind speeds up to 60m=s and isn't rated for wind speeds over 60m=s | it shows how the ontology can encode ne distinctions in operation. In this case showing, not only di erent accuracies in di erent conditions, but also accuracy expressed as both relative and absolute error. That the wind and direction measurements have di erent accuracies, direction being rated at < 3 , further shows the detail that can be obtained.
The de nitions begin with those for the domain of sensing.
WindSpeed ; WindDirection v WindQuality v PhysicalQuality Next, the main de nitions of the WM30 sensor and its restrictions.
VaisalaWM30 v Sensor VaisalaWM30 v 9hasOperationModel : VaisalaWM30 v 9hasOperationModel :
VaisalaWM30 v 9measures :WindDirection VaisalaWM30 v 9measures :WindSpeed
VaisalaWM30 v 9supports :VaisalaWM30Grounding
The grounding speci es physical properties and metadata, which includes the URL of Vaisala's data sheet. Some aspects from the data sheet, such as materials, data and electrical connections and power supply are not shown, but are similar to the following de nitions. Note that complex values and units of measurement are not yet included in the ontology and are included as text in OWL data type properties, which are written Concept \value" here to avoid strings of role names; the intent should be clear from the context.
VaisalaWM30Grounding v Grounding VaisalaWM30Grounding v 9hasOperatingCondition: : : :
40 : : : + 55 C "
The de nition of the WM30's sensing capabilities show how accuracy is encoded (again currently as text while our model of values of units are being constructed). Only wind speed is shown, direction is similar.
VaisalaWM30WindSpeed OperationModel v 9hasResult :
and and 9hasResult : and and : : : 9hasResult : 9hasOutput : 9withAccuracy:AbsoluteAccuracy \
0 :3m=s" 9inCondition:expressionBody \0 :4 : : : 10m=s")) 9withAccuracy:RelativeAccuracy \
2 %" and 9inCondition:expressionBody \10 : : : 60m=s")) 8withRange:MeasurementRange \0 :5 : : : 60m=s" 9parameterType:URI \ : : : #WindSpeed "
Other aspects from the data sheet such as the distance constant, starting threshold, transducer output and even the characteristic transfer function (U = 0:24 + (0:699) F ) are encoded as part of the ResponseModel .
There are two options for the WM30 wind direction sensor, the WMS301 and the WMS302, with 355 and 360 measurement ranges respectively. The
these options, with the two sub-concepts inheriting all their properties from
surement range.
These TBox de nitions capture what it is to be a Vaisala WM30. The de nitions are a schema de ning the class of all WM30 sensors in terms of properties that are static for all WM30 instances. WM30 individuals are recorded in the ABox and can be speci ed with a de nition as minimal as asserting an individual to be a WM30.
VaisalaWM30 (wm301 ) The remainder of the individuals de ning wm301 , such as its accuracy and operations, must exist | they are implied by the speci cation | but the TBox de nitions make it unnecessary to include them, unless a particular WM30 instance has properties that require further speci cation. Properties such as location are unique to each individual and are generally asserted for each sensor instance. The de nitions for the wind chill sensor in this section are based on SensorML examples.6 Ambient temperature, T , and wind speed, V , measurements are required to calculate wind chill using the following formula.7
35:74 + (0:6215 T ) 35:75 (V 0:16) + 0:4275 T (V 0:16)
WindChill v WindQuality WindChillSensor v Sensor WindChillSensor v 9measures:WindChill
WindChillSensor v 9hasOperationModel :WindChillSensorOutput Next, a temperature sensor is de ned as a sensor that is also a process to demonstrate that the two concepts can be con ated, giving extra expressive 6 http://vast.uah.edu/downloads/documents/Creating_SensorML_Process_
Models_preV1.0.pdf 7 This is the formula used by the United States National Weather Services, see http: //www.wrh.noaa.gov/slc/projects/wxcalc/windChill.pdf power and the option of de ning the sensor itself as the process of making an observation.
TemperatureSensor v Sensor TemperatureSensor v 9measures:Temperature
TemperatureSensor v 9hasOperationModel :Self
Then, the calculation of wind chill is de ned as a process, showing one option for how the formula itself could be encoded; though, MathML would be a better choice if the aim is automatically composing and orchestrating such a process, rather than human readability. It is also possible to attach a reference to a program that implements the calculation. Wind speed is assumed to come from a process with the only important property that it outputs a wind speed measurement. Types of inputs and outputs are removed throughout this example, see Figure 2 for an indication of what the types are for the various processes and the previous example for how they are de ned. The SplitJoin process models parallel execution of its left and right components, which in this example could be either speed or temperature | the disjunction is added to indication that the wind speed and temperature process can accept processes with the sensors speci ed in either of the two possible orderings.
WindChillCalculation v Process WindChillCalculation v 8hasResult : WindSpeedandTemperature v (9leftComponent :TemperatureSensorProcess 9hasE ect :9expressionLanguage:mathText and expressionBody or and and 9rightComponent :WindSpeedOutput ) (9leftComponent :WindSpeedOutput 9rightComponent :TemperatureSensorProcess) WindChillSensorOutput v Sequence WindChillSensorOutput v 9leftComponent :WindSpeedAndTemperature WindChillSensorOutput v 9rightComponent :WindChillCalculation
The de nitions to this point specify the components of the wind chill sensor and their properties, but do not yet connect the outputs of the wind speed and temperature sensors to the inputs of the calculation. The idea is simple enough, but cannot be expressed precisely in OWL. In specifying bindings in the TBox, it is possible to state that the wind chill sensor connects inputs and outputs of the correct type to the correct type of processes; however, TBox de nitions can't state that the bindings connect the outputs and inputs of the actual left and right components, just any components of the correct type. The same is true of OWL-S and its bindings. The situation in the ABox is somewhat di erent where the precise speci cations of individuals can be made by actually connecting the left and right individual's inputs and outputs. It is another case of needing to interpret the intent of the TBox de nitions rather than the DL; however, this has obvious consequences in classi cation, where the DL reasoner applies the DL semantics, not the intent of the de nition.
Similarly to the previous example the TBox de nitions here de ne a schema for wind chill sensors, under which any number of actual, or virtual, sensors can be classi ed. 5
Reasoning techniques such as DL consistency checking, simple SPARQL queries and LP rules for sensors and data have been published previously and are not discussed further here (see x2). Classi cation is brie y discussed rst, then nonDL reasoning and lastly using DL and SPARQL to automatically compose virtual instruments.
The sensor ontology as presented is an ontology of sensor capabilities. Another view of a sensor ontology is sensors organised into hierarchies of sensing concepts. OWL can classify the sensors into a hierarchy given suitable de nitions: for example,
WindSpeedSensor
9measures :WindSpeed would allow the reasoner to infer VaisalaWM30 v WindSpeedSensor . Similarly, sensors could be classi ed according to accuracy or other properties. This simple use of classi cation demonstrates that hierarchies of capabilities and hierarchies of sensor types are compatible ways of viewing the same ontology. 5.1
We used the OWL-API8 interface to give a Java reasoner access to the ABox. We
expressed the Region Connection Calculus (RCC) in OWL. Our OWL
embedding of RCC is based on Grutter et al.'s [
This RCC example might be possible with rules; however, as the reasoning becomes more complex or if it involves existing reasoning routines (or computational models), rules become cumbersome. We intend to use this style of interaction to allow the results of a range of reasoning engines and computational models to be made available for DL inference.
The RCC example works because there is no interaction between OWL and
RCC | they simply use the same fact base. The di erences between closed- and
open-world reasoning can be made to t into a consistent reasoning package with
rules (though this does not imply that any given set of rules is correct), and in
combining other reasoning with OWL it is important to ensure that the combined
reasoning is consistent. If the RCC and OWL assertions were dependent on each
other then the situation is much more complex (see Baader et al. [
The de nitions of the wind chill sensor can be seen as de ning a search goal. The search goal is to nd existing sensors that can be composed into a wind chill sensor. Given, the TBox de nitions of the WM30 and the wind chill sensor, and ABox de nitions for
WindSpeedOutput (ws1 ) TemperatureSensor (ts1 )
WindChillCalculation(calc1 ) and perhaps many other sensors, but no wind chill sensor individuals, the goal is to construct all the possible wind chill sensors (for the moment constraints like co-location are ignored).
Running a DL reasoner on the de nitions shows that WindChillSensor is satis able | it can have instances. The reasoner can also prove if there are instances composed from existing sensors. If the possible instances for the wind speed, temperature and calculation are enumerated, the reasoner is forced to build a model demonstrating the satis ability of WindChillSensor using only existing sensors. For example, the satis ability of WindChillSensor after asserting
fws1 g fts1 g
fcalc1 g shows that there is a composition of these sensors that makes a wind chill sensor. If there were many more sensors, it wouldn't be possible to determine which sensors the reasoner had used in building its model. If the proofs of satis ability could be extracted from DL reasoners, it could be possible to nd compositions by analysing the proofs; however, DL reasoners only build certain kinds of models, so not all compositions could be found this way.
Compositions can be found using SPARQL-DL, a subset of SPARQL with DL inference. SPARQL-DL will only return results for existing instance, not inferred instance, though the inferred instance can be used as bnodes in SPARQL queries (bnodes, or blank nodes are unnamed nodes in RDF graphs; generally, bnodes are explicitly stated as part or the RDF graph, but in SPARQL-DL they needn't be present if they are implied to exist by the ontology). Hence, simply converting the goal (wind chill sensor concept) to a SPARQL-DL query will not nd compositions. However, the goal is structured enough that a parse tree can be constructed for the process. Issuing a query for each combination in the parse tree will nd all possible compositions (see Figure 3).
For ws1 , ts1 and calc1 , the relevant query is a simple selection on the sensor types (query 3 in Figure 3).
SELECT ?ts ?ws ?calc WHERE { ?ts rdf:type sensor:TemperatureSensor . ?ws rdf:type sensor:WindSpeedOutput .
?calc rdf:type sensor:WindChillCalculation . }
SPARQL-DL returns a result for each binding of variables that satis es the query. Compositions are then constructed by following the speci cation to link the individuals. In this case linking the inputs and outputs of ws1 , ts1 and calc1 and creating new individuals for the bindings, the split join process and the wind chill sensor.
Since this method follows OWL semantics, issues such as searching correctly for sub-concepts are handled by SPARQL-DL. Constraints, such as co-location or accuracy restrictions on sensors, can be added to the query as SPARQL lters. Types, however are still problematic. In this query there is no requirement to match the input and output types of the processes | the de nitions are speci c enough to not require it. In general, the query requires constraints ensuring that the input and output types match, which can be handled by simply matching the stated types. However, it is correct to match an output if it is a sub-type of the required input. But this is not easily handled in the query because the de nition of a type is a datatype URI, which is not amenable to SPARQLDL reasoning, so a simple subClassOf constraint can't be added to the query. The required type checking can be handled by interpreting the query results as potential compositions and, for each, checking that the input and output types match correctly. 6
This paper has discussed an OWL ontology for describing details of sensors. The ontology is more expressive than previous sensor ontologies as it can express complex compositions and ne details of the function and results of sensors and processes. The ontology can also encode much of the information in SensorML documents. Since OWL is unable to express concepts such as the function computed by a process, the ontology includes the ability to express these aspects in other languages. This capability is based on similar features in OWL-S, as is some of the structure of the ontology; however, for example, the modelling of processes, and in particular composite process, does not follow the OWL-S model.
The ontology is designed such that domain semantics, units of measurement, time and time series, and location and mobility ontologies can be easily included with the usual OWL import mechanism.
The SPARQL-DL method of composition is simple, but powerful enough that it will successfully nd compositions even for complex processes. Its biggest drawback is the number of queries that need to be issued as the goal gets more complex; a search strategy is needed if not all compositions are required. We have not yet experimented with its performance.
Sensors cannot be modelled precisely using OWL. Issues involving numbers or describing functions require external mechanisms, but the issues in encoding type information, for example, can have subtle consequences. Here the input and output types of processes were modelled as URIs which captures the correct meaning, but can no longer be reasoned about inside OWL, though they can be processed externally and then used in DL reasoning. The alternate choice of simply using a role, as with measures here, warps the logical interpretation somewhat, though retains the possibility of some reasoning in OWL. However, attempting to model inputs and outputs with this method would still require external reasoning because, for example, a query that asks for processes whose inputs and outputs match requires a quanti cation over the types that can't be expressed in OWL.
In cases such as binding inputs to outputs the TBox isn't able to limit the interpretation to only the intended models. To some extent an external mechanism could be used to interpret such de nitions, but it is not clear in general how to reconcile the intention with the de nition, or a reasoner's handling of it. In essence, each of these issues implies some trade-o between decidability and expressivity.
In future work, we intend to further investigate how Web service composition can be used to automatically construct virtual sensors. We intend to use our ontology in data integration and scienti c work ows. We also plan to extend the ontology to allow descriptions of values and their units as well as observations and results.
This research was conducted as part of the CSIRO Water for a Healthy Country National Research Flagship and the Sensor Network Technologies Theme.
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, Tourism and the Arts.
Khoi-Nguyen Tran worked in this research as a CSIRO summer research scholar and as an honours student at the Australian National University.