This paper presents an overview of ongoing work to develop a generic ontology design pattern for observation-based data on the Semantic Web. The core classes and relationships forming the pattern are discussed in detail and are aligned to the DOLCE foundational ontology to improve semantic interoperability and clarify the underlying ontological commitments. The pattern also forms the top-level of the the Semantic Sensor Network ontology developed by the W3C Semantic Sensor Network Incubator Group. The integration of both ontologies is discussed and directions of further work are pointed out.
Observations are at the core of empirical science. Sensors transform stimuli from
the physical world into observations and thereby allow to reason about the
observed properties of particular features of interest [
The core motivation of the Sensor Web Enablement (SWE) initiative of the
Open Geospatial Consortium is to make data about sensors and their
observations available on the Web. Besides storage and access, the initiative also
focuses on the tasking of sensors. Hence, SWE supports the full workflow from
the selection of specific sensors, their configuration and deployment, over the
collection of observations, up to changing their location and spatial distribution
in a Web-centric framework. This so-called Sensor Web includes services such
as the Sensor Observation Service (SOS), the Sensor Planning Service (SPS),
and the upcoming Sensor Event Service (SES), as well as data models and
encodings such as Observations and Measurements (O&M) or the Sensor Model
Language (SensorML). Judging from the number of available implementations
for the aforementioned services, the amount of available sensor data encoded in
O&M and SensorML, as well as the number of SWE-based projects, the
initiative has been successful so far. Nevertheless, these services and the stored data
are only available as parts of Spatial Data Infrastructures (SDI) and, hence, only
available to OGC-compliant client applications. Moreover, the retrieval of
sensors and especially observation data and, hence, their re-usability have only been
partially addressed so far [
In contrast, the Semantic Web offers a technology stack for information
retrieval and reasoning beyond keywords as well as knowledge representation
languages for conceptual reference models, i.e., ontologies, used to restrict domain
vocabularies towards their intended interpretations [
To address these challenges, various researchers [
While the presented approaches towards a Semantic Sensor Web and Linked
Sensor Data differ in their underlying assumptions, goals, application areas, as
well as the used technologies, they all build up on the idea of annotating sensor
data using ontologies. Consequently, the development of a sensor ontology has
been a major research topic. The developed ontologies range from sensor-centric
approaches with a strong relationship to SensorML [
The importance of an ontology for sensors and observations is not restricted
to enabling the Semantic Sensor Web but reaches beyond. Gangemi and Presutti
point out that with the advent of Linked Data the Semantic Web can become
an empirical science in its own rights and argue for knowledge patterns as units
of meaning for the Web [
To address the aforementioned challenges, this paper discusses the development of a Stimulus-Sensor-Observation (SSO) ontology design pattern [37]. While the pattern is intended to act as a generic and reusable component for all kinds of observation-related ontologies for Linked Data and the Semantic Web, it also forms the top-level of the Semantic Sensor Network (SSN) ontology developed by the W3C Semantic Sensor Network Incubator Group (W3C SSN-XG)1. The pattern, in turn, is aligned to DOLCE Ultra Light (DUL)2 as a foundational ontology. The relation between these ontologies is best thought of as layers or modules. The first pattern represents the initial conceptualization as a lightweight, minimalistic, and flexible ontology with a minimum of ontological commitments. While this pattern can already be used as vocabulary for some use cases, other application areas require a more rigid conceptualization to support semantic interoperability. Therefore, we introduce a realization of the pattern based on the classes and relations provided by DOLCE Ultra Light. This ontology can be either directly used, e.g., for Linked Sensor Data, or integrated into more complex ontologies as a common ground for alignment, matching, translation, or interoperability in general. For this purpose, we demonstrate how the pattern was integrated as top-level of the SSN ontology. Note that for this reason, new classes and relations are introduced based on subsumption and equivalence. For instance, the first pattern uses the generic involves relation, 1 A W3C incubator group is a 1 – 2 year collaborative activity on a new technology, intended to produce a technical outcome, foster collaboration and interest in the topic, and potentially form the basis of further W3C activities. The wiki of the group is available at http://www.w3.org/2005/Incubator/ssn/wiki/Main_Page and contains links to the ontologies, use cases, meeting minutes, and related literature. 2 see http://www.loa-cnr.it/ontologies/DUL.owl. while the DOLCE-aligned version distinguishes between events and objects and, hence, uses DUL:includesEvent and DUL:includesObject, respectively.
The remainder of this paper is organized as follows. First, we introduce the core concepts and relations of the Stimulus-Sensor-Observation ontology design pattern. Next, we discuss the alignment of this pattern to the DOLCE foundational ontology and present potential extensions. Afterwards, we discuss how the pattern is integrated into the Semantic Sensor Network ontology. We conclude the paper by summarizing the proposed approach and point towards further work. The introduced ontologies are available online at the wiki of the W3C SSN-XG. 2
In the following, we describe the set of classes and relations that jointly form the
Stimulus-Sensor-Observation ontology design pattern; see figure 1. The pattern is
developed following the principle of minimal ontological commitments to make it
reusable for a variety of application areas. A selection of uses cases focused on the
retrieval of sensor metadata and observations can be found at: http://www.w3.
org/2005/Incubator/ssn/wiki/index.php?title=Favorite_Use_Cases_List.
The names of classes and relations have been selected based on a review of
existing sensor and observation ontologies [
Stimuli are detectable changes in the environment, i.e., in the physical world. They are the starting point of each measurement as they act as triggers for sensors. Stimuli can either be directly or indirectly related to observable properties and, therefore, to features of interest. They can also be actively produced by a sensor to perform observations. The same types of stimulus can trigger different kinds of sensors and be used to reason about different properties. Nevertheless, a stimulus may only be usable as proxy for a specific region of an observed property. Examples for stimuli include the expansion of liquids or sound waves emitted by a sonar. The expansion of mercury can be used to draw conclusions about the temperature of a surface that is in close contact. While the expansion is unspecific with respect to the kind of surface, e.g., water versus skin, the usage as stimulus is limited by its melting and boiling points. Moreover, mercury is not restricted to thermometers but e.g., also used in nanometers. Note, that the stimulus is the expansion of mercury, not mercury as such.
Sensors are physical objects that perform observations, i.e., they transform an
incoming stimulus into another, often digital, representation. Sensors are not
Fig. 1. A conceptual map showing the core concepts and relations (inverse
relations are not depicted) forming the Stimulus-Sensor-Observation ontology design
pattern. Sensors observe properties of features of interest by detecting
stimuli, i.e., changes in the physical world, (directly or indirectly) related to these
properties and transforming them to another representation as results. Sensors
implement a procedure that describes the transformation of stimuli to results.
Observations are the context that bring sensors and stimuli together. They are
described by procedures that determine how a certain observation has to be
carried out.
restricted to technical devices but may also include humans [
In the literature, observations are either modeled as database records that store the sensor output and additional metadata or as events in the physical world. We decided to take yet another approach for the design pattern to unify both views. Observations act as the nexus between incoming stimuli, the sensor, and the output of the sensor, i.e., a symbol representing a region in a dimensional space. Therefore, we regard observations as social, not physical, objects. Observations can also fix other parameters such as time and location. These can be specified as parts of an observation procedure. The same sensor can be positioned in different ways and, hence, collect data about different properties. For instance, in contrast to the soil temperature, surface air temperature is measured 2m above ground. Finally, many sensors perform additional processing steps or produce single results based on a series of incoming stimuli. Therefore, observations are rather contexts for the interpretation of the incoming stimuli than physical events.
Properties are qualities that can be observed via stimuli by a certain type of sensors. They inhere in features of interest and do not exist independently. While this does not imply that they do not exist without observations, our domain is restricted to those observations for which sensors can be implemented based on certain procedures and stimuli. To minimize the amount of ontological commitments related to the existence of entities in the physical world, observed properties are the only connection between stimuli, sensors, and observations on the one hand, and features of interests on the other hand. Examples include, temperature, density, duration, or location and can only be defined with respect to a feature of interest such as a flood.
Entities are reifications. They are created in an act of cognition and social convention [39,40] and are constructed by relating observable properties [35]. The decision of how to carve out fields of sensory input to form such features is arbitrary to a certain degree and, therefore, has to be fixed by the observation; see above. For instance, soil temperature is measured to determine an optimum time for seeding. The feature of interest is a particular 3-dimensional body of soil restricted by the size of the parcel and a depth relevant for the growth of crop. Without changing the sensor, type of stimulus, and even the observation procedure, the same setting can be used to measure the soil temperature of another feature – e.g., a part of the same parcel to study effects of erosion.
Procedures describe how a sensor should be constructed, i.e., how a certain type of stimuli is transformed to a digital representation. Consequently, sensors can be thought of as implementations of procedures where different procedures can be used to derive information about the same type of observed property. For instance, there are many different ways to measure temperature. Procedures can describe so-called contract-based methods, e.g., based on the expansion of mercury, or contact-free methods such as used to construct thermal imaging sensors. Besides procedures for the construction of sensors, procedures also fix observation parameters, e.g., how and where a sensor has to be positioned to measure wind speed and direction. Simplifying, one can think of procedures as cooking recipes. The result is a symbol representing a value as outcome of the observation. Results can act as stimuli for other sensors and can range from counts and Booleans, to images, or binary data in general. Example includes the number 23 together with degree Celsius as unit of measure.
Various extensions to the pattern are possible and can be introduced to fit particular application areas. For instance, work on observation-based symbol grounding requires a semantic datum class. This could be introduces as a subclass of Procedure. Other ontologies developed on top of the pattern may add classes such as Deployment and relate it to the Observation as well as the Sensor class. Similarly, while we discussed how properties of sensors can be specified, we do not introduce such properties to keep the pattern flexible and generic. More details on the integration of sensor-centric classes are described in section 4. 3
The presented design pattern is intended as a minimal vocabulary for the Semantic Sensor Web and Linked Data in general. While it introduces the key classes and their relations such as stimuli, sensors, and observations, the terms used for their specification remain undefined. For instance, the pattern does not explain what processes, qualities, or social objects are. The advantage of such an underspecified ontology pattern is its flexibility and the possibility to integrate and reuse it in various applications by introducing subclasses. The downside, however, is a lack of explicit ontological commitments and, therefore, reduced semantic interoperability. Two Linked Data providers can annotate their data using the SSO pattern and still have radically different conceptualizations with respect to the nature of the involved classes. For instance, one provider could consider observations to be events in the real world, while another provider may think of them as database records.
While ontologies cannot fix meaning, their task is to restrict the
interpretation of the introduced classes and relations towards the intended model [
In the following we highlight the major aspects of the DOLCE alignment; see figure 2. Each SSO class is defined as subclasses of an existing DOLCE class and related to other SSO and DUL classes using DUL properties. New types of relations are only introduced when the domain or range have to be changed, in all other cases the relations from DUL are reused. The resulting extension to DUL preserves all ontological commitments defined in section 2.
The SSO class Stimulus can be either defined as a subclass of DUL:Event or its immediate subclasses Action and Process. In contrast to processes, actions require at least one agent as participant and, therefore, would be too restrictive for the design pattern. The classifications of events in DUL is work in progress. For instance, there is nothing said about how processes differ from other kinds of events. Therefore, the pattern defines a Stimulus as a subclass of DUL:Event. As a consequence, stimuli need at least one DUL:Object as participant. Such objects include the mercury participating in the event of expansion or a thermometer involved in the detection of a stimulus.
Sensors are defined as subsclasses of physical objects (DUL:PhysicalObject). Therefore, they have to participate in at least one DUL:Event such as their deployment. This is comparable to the ontological distinction between a human and a human’s life. Sensors are related to procedures and observations using the DUL:isDescribedBy and DUL:isObjectIncludedIn relations, respectively.
The class Observation is specified as a subclass of DUL:Situation, which in turn is a subclass of DUL:SocialObject. The required relation to stimuli, sensors, and results can be modeled using the DUL:includesEvent, DUL:includesObject, and DUL:isSetting relationship, respectively. Observation procedures can be integrated by DUL:satisfies. The decision to model observations as situations is also conform with the observation pattern developed by Blomqvist3.
ObservedProperty is defined as a subclass of DUL:Quality. Types of properties such as temperature or pressure should be added as subclasses of ObservedProperty instead of individuals. A new relation called SSO:isPropoertyOf is defined as a sub-relation of DUL:isQualityOf to relate a property to a feature of interest. 3 see http://ontologydesignpatterns.org/wiki/Submissions:Observation.
Features of interest can be events or objects. We deliberately exclude the DUL classes Quality and Abstract as potential features of interest to avoid complex philosophical questions such as whether there are qualities of qualities. Instead we argue that the need to introduce properties for qualities is an artifact of reification or confuses qualities with features or observations. For instance, accuracy is not a property of a temperature but the property of a sensor or an observation procedure.
Procedure is defined as a subclass of DUL:Method which in turn is a subclasses of DUL:Description. Consequently, procedures are expressed by some DUL:InformationObject such as a manual or scientific paper.
The SSO Result class is modeled as a subclass of DUL:Region. A concrete data value is introduced using the data property DUL:hasRegionDataValue in conjunction with some xsd data type. 4
The SSO pattern and alignment as presented thus far gives a basis for understanding and describing the relationship between sensors and their observations. However, such a pattern is too high level to be immediately useful in many of the domains mentioned in the introduction. It is once the pattern is set in a broader context of sensors, their capabilities, operating conditions, and all the metadata that sets them in their context that the pattern realizes its potential as a language for sensors and observations.
The SSN ontology provides such a broader perspective. It is intended to cover sensing concepts and little else that would be present in multiple domains or that is not a key notion for describing sensors. The ontology supports different views: (1) it can be centered around sensors, their capabilities and constraints, the procedures they execute and the observations they can make; (2) around observations, i.e., what was observed and how, as well as on (3) features and properties and how to observe them. The SSN ontology builds directly on the SSO classes introduced before and adds additional relations and classes (e.g., Sensing) for measurement capabilities, operating conditions, and deployments; see figure 3. In some cases, the DUL relations and classes used in the pattern alignment are too generic for an intuitive understanding in the domain of sensing and sensors. In this cases, the SSN ontology introduces sub-relations or classes with different names, domains, and ranges. For example, SSN:observedBy (as a sub-relation of DUL:includesObject) is used to relate SSN:Observation to SSN:Sensor.
Sensors, in the SSN ontology, as well as making observations by implementing sensing procedures, have capabilities (SSN:MeasurmentCapability) that describe the accuracy, range, resolution and other properties (e.g., SSN:Accuracy and SSN:Resolution) of the sensor. As these are observable characteristics of a sensor, they are modeled as properties (SSO:Property). Similarly, the operating and survival conditions (SSN:OperatingCondition and SSN:SurvivalCondition) are properties of a sensor. Indeed accuracy, battery levels, or further properties can be observed by other sensors. Therefore, one can model a sensor, or parts of it, as a feature of interest observed by another sensor.
The observation model of the SSN ontology, is similar to the O&M model, with observations of properties of particular features of interest being made at particular times and yielding a result of a value for the property. The SSN model describes the sensor (similar to procedure in O&M) that made the observation, thus linking the observation-centric and sensor-centric view points. The model allows for further refinements describing how the sensor was used. The main difference between the O&M and SSN-XG models is the distinction of classifying them as events and social objects, respectively. While the distinction was discussed above, both views are compatible from a data-centric perspective, i.e., they allow to assign values for observed properties by sensors.
Stimuli, features of interest, observed properties, and the modeling of observation results are taken directly from the SSO pattern and do not need to be subclassed in the SSN ontology. Adding types of properties, for instance, is out of scope for the W3C SSN-XG but up to ontologies such as SWEET.4 Features of interest can be added as subclasses and imported from domain ontologies such as the Ordnance Survey hydrology ontology.5
The remaining parts of the SSN-XG ontology are various physical objects such as platforms (SSN:Platform), systems (SSN:Systems), devices (SSN:Device), and the deployment (SSN:Deployment) process that all serve to further define sensors and place them in the context of other systems. Deployments represent the ongoing processes related to deploying a sensor in the field (and are thus subclasses of DUL:Process). A deployment relates a sensor, a platform to which it was deployed, and a time frame, and may involve parts such as installation and maintenance. 4 see http://sweet.jpl.nasa.gov/ontology/. 5 see http://www.ordnancesurvey.co.uk/oswebsite/ontology/Hydrology/v2.0/
Hydrology.owl.
The presented work introduces a generic Stimulus-Sensor-Observation ontology design pattern intended as a building block for work on the Semantic Sensor Web and Linked Sensor Data. The key classes and relations are discussed in detail and illustrated by examples. To support semantic interoperability and restrict the interpretation of the introduced classes towards their intended meaning, the design pattern is aligned with the DOLCE foundational ontology. The integration of the pattern (as well as DUL) into the Semantic Sensor Network ontology is discussed.
By providing a richer axiomatization, the DUL alignment should also improve semantic search, pattern mining, similarity and analogy-based reasoning, and other services. At the same time, the added complexity makes using and populating the ontology more difficult. Open-world reasoning ensures that many required parts of the ontology need not to be filled. For instance, each individual sensor of the aligned SSN ontology requires an event to participate in, e.g., a deployment, as well as a stimulus, and, similarly, each feature of interest either requires the instantiation of a participating object or an event in which the feature participates; however, these need not actually be instantiated as they are implied. Nevertheless, the DOLCE alignment may still be over-engineered for some applications and especially Linked Data and, therefore, restrict the usage of the ontologies. For this reason, the W3C SSN-XG intends to deliver the ontologies together with a script to free them from the DUL alignment. To ensure that first-time users are still aware of the ontological commitments, the ontologies are stored with the alignment by default.
Finally, the presented ontologies and the alignment are still work in progress and will be part of the final report of the W3C SSN-XG. Among other aspects, the relation between sensors and results needs further work. For instance, DUL:Region may be replaced by DUL:Parameter in the future. Further work will also focus on documentations and use cases to demonstrate how to integrate the ontologies or develop extensions. These use cases and additional user feedback will be used for further refinement. Developing modular ontologies at different abstraction levels and based on common agreement raises many other challenges for collaborative ontology engineering and keeping these ontologies in sync.
The presented work is part of the W3C Semantic Sensor Network Incubator Group and the 52 N orth semantics community. We are thankful to our colleagues from both initiatives, as well as to Werner Kuhn and Simon Scheider for their input to improve the quality of the paper and the developed ontologies. This work was in part supported by CSIRO’s Water for a Healthy Country Flagship. 35. Scheider, S., Probst, F., Janowicz, K.: Constructing bodies and their qualities from observations. In: Proceeding of the 2010 Conference on Formal Ontology in Information Systems (FOIS 2010), IOS Press (2010) 131–144 36. Kuhn, W.: Semantic reference systems (guest editorial). International Journal of
Geographical Information Science 17(5) (2003) 405–409 37. Gangemi, A.: Ontology design patterns for semantic web content. In Gil, Y., Motta, E., Benjamins, V., Musen, M., eds.: The Semantic Web – ISWC 2005. Volume 3729 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (2005) 262–276 38. Sowa, J.F.: Knowledge Representation: Logical, Philosophical and Computational
Foundations. Brooks Cole Publishing Co., Pacific Grove, CA, USA (2000) 39. Mark, D.M.: Toward a theoretical framework for geographic entity types. In: Spatial Information Theory: A Theoretical Basis for GIS, International Conference COSIT ’93. (1993) 270–283 40. Lehar, S.: The World in Your Head: A Gestalt View of the Mechanism of Conscious Experience. Lawrence Erlbaum (2003)