• 1 Introduction
  • 1.1 Semantics and Sensors
  • 1.2 The Incubator Group Activity (XG)
• 2 Intent and Process
  • 2.1 Scope of the SSN XG
  • 2.2 Process
• 3 Motivating Use cases (Sensor Web and Sensor Networks)
  • 3.1 Drivers for the creation of the XG
    • 3.1.1 Sensor Web Enablement (SWE) Languages
  • 3.2 Use case categories for the XG vision
    • 3.2.1 Role of OGC and W3C standards in the use cases
  • 3.3 Use case details
    • 3.3.1 Data Discovery and Linking
    • 3.3.2 Device Discovery and Selection
    • 3.3.3 Provenance and Diagnosis
    • 3.3.4 Device Operation Tasking and Programming
• 4 Review of Sensor and Observation ontologies
  • 4.1 Overview of this activity
    • 4.1.1 Reviewed ontologies
    • 4.1.2 Surveys of Sensor and Observation ontologies
    • 4.1.3 Ontologies and other models which have been partially reviewed or not reviewed
    • 4.1.4 Outcomes of the SSN XG review
  • 4.2 Reviews
    • 4.2.1 CSIRO Sensor Ontology
    • 4.2.2 OntoSensor
    • 4.2.3 SWAMO
    • 4.2.4 SDO
    • 4.2.5 MMI Device Ontology
    • 4.2.6 SensorML Processes
    • 4.2.7 CESN
    • 4.2.8 WISNO
    • 4.2.9 A3ME
    • 4.2.10 Ontonym - Sensor
    • 4.2.11 SEEK OBOE
    • 4.2.12 SERES O&M
    • 4.2.13 Stimuli-Centered
    • 4.2.14 Sensei Observation and Measurement Ontology
    • 4.2.15 OOSTethys
    • 4.2.16 O&M-OWL (SemSOS)
    • 4.2.17 Socio-Ecological Research and Observation oNTOlogy (SERONTO)
• 5 The Semantic Sensor Network Ontology
  • 5.1 Introduction
  • 5.2 Ontology structure
  • 5.3 Ontology described module by module
    • 5.3.1 The Skeleton of the Semantic Sensor Network Ontology
      • 5.3.1.1 Skeleton module
      • 5.3.1.2 The Stimulus-Sensor-Observation Ontology Design Pattern
        • 5.3.1.2.1 Stimuli
        • 5.3.1.2.2 Sensors
        • 5.3.1.2.3 Observations
        • 5.3.1.2.4 Observed Properties
        • 5.3.1.2.5 Features of Interest
        • 5.3.1.2.6 Procedure
        • 5.3.1.2.7 Result (or SensorOutput)
        • 5.3.1.2.8 Implementation of the Stimulus-Sensor-Observation design pattern in SSN
      • 5.3.1.3 Aligning the SSN Ontology and the core SSO design pattern with DOLCE
        • 5.3.1.3.1 Stimuli
        • 5.3.1.3.2 Sensors
        • 5.3.1.3.3 Observations
        • 5.3.1.3.4 Observed Properties
        • 5.3.1.3.5 Features of Interest
        • 5.3.1.3.6 Sensing
        • 5.3.1.3.7 SensorOutput
        • 5.3.1.3.8 Device, System, Deployment, ...
    • 5.3.2 System
      • 5.3.2.1 System module
      • 5.3.2.2 How to represent a system composed of sensors
    • 5.3.3 Process
      • 5.3.3.1 Process module
      • 5.3.3.2 How to represent a characteristic transfer function implemented by a sensor
      • 5.3.3.3 How to represent a process implemented by a sensor (for programming use case)
    • 5.3.4 Measuring
      • 5.3.4.1 Measuring module
      • 5.3.4.2 How to create a description of a sensor?
    • 5.3.5 MeasuringCapability
      • 5.3.5.1 MeasuringCapability module
      • 5.3.5.2 How to describe capabilities of a sensor?
    • 5.3.6 Observation
      • 5.3.6.1 Observation module
      • 5.3.6.2 How to represent an observation of a sensor?
    • 5.3.7 Deployment
      • 5.3.7.1 Deploy module
      • 5.3.7.2 How to represent a deployment of a network of sensors?
    • 5.3.8 PlatformSite
      • 5.3.8.1 PlatformSite module
      • 5.3.8.2 How to represent a site?
    • 5.3.9 OperatingRestriction
      • 5.3.9.1 Operating Restriction module
      • 5.3.9.2 How to represent operational and survival conditions?
    • 5.3.10 Data
      • 5.3.10.1 Data module
      • 5.3.9.2 How to attach a data value to a property?
  • 5.3.11 ConstraintBlock (Condition)
    • 5.3.11.1 ConstraintBlock module
    • 5.3.11.2 How to define a property for specific conditions?
  • 5.3.12 Device
    • 5.3.12.1 Device module
  • 5.3.13 Energy
    • 5.3.13.1 Energy module
    • 5.3.13.2 How to represent a WSN node and its energy components
    • 5.3.13.3 How to represent a WSN node with information about its energy consumption
    • 5.3.13.4 How to represent the operating power range of a sensor
• 5.4 Additional examples
  • 5.4.1 University deployment example
    • 5.4.1.1 Introduction
    • 5.4.1.2 Deployment
    • 5.4.1.3 Sensor
  • 5.4.2 Smart product example
    • 5.4.2.1 Introduction
    • 5.4.2.2 Sensor
    • 5.4.2.3 Measurement capabilities
    • 5.4.2.4 Observation
  • 5.4.3 Wind sensor (WM30)
    • 5.4.3.1 Introduction
    • 5.4.3.2 Wind Sensor system
    • 5.4.3.3 Specification of the method used in the Wind Sensor
    • 5.4.3.4 Operating Range
    • 5.4.3.5 Survival Range
    • 5.4.3.6 Wind Feature and properties
  • 5.4.4 Agriculture Meteorology Sensor Network
    • 5.4.4.1 The Agriculture Meteorology ontology (phenonet)
      • 5.4.4.2.1 Sensor selection
      • 5.4.4.1.2 System view
      • 5.4.4.1.3 Sensor view
    • 5.4.4.2 External ontologies
      • 5.4.4.2.1 Automatic Weather Station ontology
      • 5.4.4.2.2 CF (Climate and Forecast) ontologies
      • 5.4.4.2.3 Units of measurement and quantity ontologies
  • 5.4.5 Sensor Discovery on Linked Data
    • 5.4.5.1 Introduction
    • 5.4.5.2 Sensor Discovery
    • 5.4.5.3 Linking Sensor Data to other resources of the LOD cloud
    • 5.4.5.4 Provenance tracking in the Linked Sensor Data cloud

• 6 Semantic Markup
  • 6.1 Review of basic annotation techniques
    • 6.1.1 XLink
    • 6.1.2 RDFa
    • 6.1.3 Other Annotation Techniques
    • 6.1.4 Comparison of techniques
  • 6.2 Semantic Markup for OGC standards
    • 6.2.1 Current use of XLink in OGC standards
    • 6.2.2 Recommended Technique
    • 6.2.3 Pending issues
  • 6.3 Examples
    • 6.3.1 Simple Example
    • 6.3.2 Sensor Discovery Example
    • 6.3.3 Inference Example
• 7 Mappings
  • 7.1 Introduction
  • 7.2 Lineage of terms
    • 7.2.1 Annotation method
    • 7.2.2 Sources of term definitions
    • 7.2.3 Documentation generation solution
    • 7.2.4 Summary of Term Mappings
  • 7.3 Relationships to OGC standards
• 8 Conclusion and Recommendations
  • 8.1 Directions for future work
  • 8.2 Adoption of the SSN Ontology
  • 8.3 Recommendations
• 9 Misc.
  • 9.1 References
    • 9.1.1 Motivating Use cases (refs)
    • 9.1.2 Review of Sensor and Observations Ontologies (refs)
    • 9.1.3 The Semantic Sensor Network Ontology (refs)
    • 9.1.4 Semantic Markup (refs)
    • 9.1.5 Conclusion and Recommendations (refs)
  • 9.2 Additional resources
  • 9.3 Acronyms

1 Introduction

1.1 Semantics and Sensors

As networks of sensors become more commonplace there is a greater need for the management and querying of these sensor networks to be assisted by standards and computer reasoning. The OGC's Sensor Web Enablement activities have produced a services-based architecture and standards, including four languages for describing sensors, their capabilities and measurements, and other relevant aspects of environments involving multiple heterogeneous sensors. These standards assist, amongst other things, in cataloguing sensors and understanding the processes by which measurements are reached, as well as limited interoperability and data exchange based on XML and standardised tags. However, they do not provide semantic interoperability and do not provide a basis for reasoning that can ease development of advanced applications.

Ontologies and other semantic technologies can be key enabling technologies for sensor networks because they can improve semantic interoperability and integration, as well as facilitate reasoning, classification and other types of assurance and automation not addressed in the OGC standards. A semantic sensor network will allow the network, its sensors and the resulting data to be organised, installed and managed, queried, understood and controlled through high-level specifications. Sensors are different to other technologies, such as services in service-oriented architectures, because of the event based nature of sensors and sensor networks and the temporal and spatial relationships that need to be considered. Further, when reasoning about sensors, complex physical constraints such as limited power availability, limited memory, variable data quality, and loose connectivity need to be taken into account. When these constraints are formally represented in an ontology, inference techniques are more readily applied.

1.2 The Incubator Group Activity (XG)

Given the current state of the overall subject of sensor ontologies and the different ways to annotate those, it became clear that the best approach would be to create an Incubator group, which provides an opportunity to share perspectives on the topic with all the advantages noted by the W3C. Once the group was launched, the group's Charter was posted with all the details regarding the group's assignments, rules, and deliverables. Among the instructions, SSN-XG members were reminded that membership conditions include patent disclosure obligations as set out in Section 6 of the W3C Patent Policy and of their goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy.

2 Intent and Process

2.1 Scope of the SSN XG

The SSN-XG worked on two main objectives:

1. the development of ontologies for describing sensors, and
2. the extension of the Sensor Model Language (SensorML), one of the four SWE languages, to support semantic annotations.

The first objective, ontologies for sensors, provides a framework for describing sensors. These ontologies allow classification and reasoning on the capabilities and measurements of sensors, the provenance of measurements and the connection of a number of sensors as a macroinstrument. Following W3C recommendation, OWL 2 DL is the selected language for ontology specification. The sensor ontologies, to some degree, reflect the OGC standards and, given ontologies that can encode sensor descriptions, mapping between the ontologies and OGC models is an important topic addressed by the SSN-XG.

The second objective, of semantic annotation of sensor descriptions and services that support sensor data exchange and sensor network management, serves a similar purpose to that offered by the semantic annotation of Web services.

2.2 Process

The Group attracted a lively average participation of 18 regular attendees and contributors from 19 member organisations, and 4 invited experts. We met weekly by teleconference and simultaneous IRC chat using the facilities provided by the W3C. Our meeting dates and minutes are recorded and publicly available on the wiki. We also held a full day face-to-face meeting at the headquarters of SURA, Washington DC, USA on the 24th October 2009.

The wiki was used to organise the information, upload files, maintain progress of the activities, write the report and to provide public information about the activity.

The public mailing list was used to conduct discussion between meetings, and for announcements.

As ontology design issues became more complex and vigorous, we used the tracker (issue, action and resolution tracking tool for W3C Groups, only accessible to W3C members) to follow the progress of the more significant and contested issues.

3 Motivating Use cases (Sensor Web and Sensor Networks)

3.1 Drivers for the creation of the XG

The creation of this incubator activity and the definition of its two main objectives defined in the XG charter were motivated by several factors:

• The opportunity for several W3C member organisations working on Sensor Ontologies, Semantic Sensor Web and Semantic Sensor Networks applications to merge their research effort in this area,
• The recognition that the legacy mechanisms used to embed domain-specific vocabularies in several Sensor Web Enablement (SWE) standards developed by the Open Geospatial Consortium (SensorML, SWE common) should be replaced by approaches based on the semantic web languages developed by W3C, in particular OWL DL,
• The sentiment that the development of a Semantic Sensor Network ontology and of mechanisms to support semantic annotations could improve interoperability and integration of the services using these standards, as well as facilitate reasoning, classification and other types of assurance and automation not included in the OGC standards.

The work done by the XG on these two objectives is presented in the next sections. During the course of the XG, the group also identified four principal classes of use cases. These uses cases are presented here because they helped to prioritise parts of the ontology for development.

3.1.1 Sensor Web Enablement (SWE) Languages

In SWE, members of the OGC are building a framework of open standards for exploiting Web-connected sensors and sensor systems of all types. This framework is called a Sensor Web, and refers to web accessible sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application program interfaces (APIs). SWE is composed of three languages and four service specifications. The languages include the Sensor Model Language ([SENSORML 2007]), Observations and Measurements ([OM 1 2007], [OM 2 2007]), and Transducer Markup Language ([TML 2007]). The services include the Sensor Observation Service ([SOS 2008]), Sensor Planning Service ([SPS 2007])], and Sensor Alert Service ([SAS 2006]).

• Sensor Model Language (SML): Standard models and XML Schema for describing sensors systems and processes; provides information needed for discovery of sensors, location of sensor observations, processing of low-level sensor observations, and listing of taskable properties.

• Observation & Measurements (O&M): Standard models and XML Schema for encoding observations and measurements from a sensor, both archived and real-time.

• Sensor Observation Service (SOS) GetCapabilities: The Sensor Observation Service includes three core operations: GetObservation, DescribeSensor, and GetCapabilities. The GetObservation operation provides an interface to query over observation data and returns an O&M document. The DescribeSensor operation provides an interface to query for the description of a sensor and returns a SensorML document. The GetCapabilities operation provides an interface to query for the description of a Sensor Observation Service. GetCapabilities allows clients to retrieve service metadata about a specific service instance and returns a GetCapabilites response document.

3.2 Use case categories for the XG vision

A set of use cases have been identified to motivate the work that has been done by the SSN-XG. They can be roughly classified into four main groups, according to the following two axes:

1) User classification: from users who directly manage sensors and sensor networks; through to users who use and manipulate data (but may not have any direct interest in sensors).

2) Technology: from Semantic Web through Sensor Web to Sensor Network.

The following table and figures provide different viewpoints on this classification, providing names for these four groups of use cases (data discovery, device discovery and selection, provenance and diagnosis, and device operation tasking and programming). The reason to identify several use case categories is that each one requires different levels of detail for the modelling of the sensors, the features they observe, their capabilities, their environment and their conditions of use. These use cases will be described next.

Table 3.1: Use case categories

Use Case Class	Short Description
1. Data Discovery and Linking	Find all observations that meet certain criteria, and possibly link them to other external data sources. The user may use different criteria to select the spatial area, temporal window, and types of observations to be found, and may relate the results obtained to external data sources.
2. Device Discovery and Selection	Find all the devices that meet certain criteria. The criteria may include type, geographic region, measured phenomenon, range of measurement, availability, owner or responsible party, and manufacturer, or combinations of those.
3. Provenance and Diagnosis	Provide extra information about the instrument to better evaluate or process the data
4. Device Operation Tasking and Programming	Command a device's operation using its description and information on its conditions of use

3.2.1 Role of OGC and W3C standards in the use cases

Figure 3.1 suggests a possible distribution of responsibility amongst OGC standards (standards based on XML web services) and W3C Semantic Web standards. It corresponds to that which is is currently feasible when these two platforms are deployed independently. At the bottom level, for sensor and sensor network applications, there are no ubiquituous standards. The backbone of the sensor service infrastructure and the API to sensors can be provided by OGC standards. Semantic Web standards (RDF, OWL, SPARQL) can be leveraged at a later stage of integration when the data is integrated as linked data and in mashups. In this situation, the semantic sensor network ontology is mainly used once the data has been converted into RDF and in the semantic annotations which may help to realise this conversion.

Figure 3.1 - Standards Landscape: Sensor Networks, Sensor Web, Semantic Web

While the work done by the XG can be applied in this configuration, it is not representative of the original vision, nor many current applications, which offer a much wider scope of roles for the ontology and the semantic markup.

Figure 3.2 illustrates how the various configurations are covered by the four categories of uses cases described in this section.

Figure 3.2 - Technologies and Use cases

3.3 Use case details

Some additional information for each use case is provided below. More information on the XG participants' projects and their relevance for the Incubator activity is available from the XG wiki .

3.3.1 Data Discovery and Linking

Background
We start by providing some background on a potential application where this use case can be better understood. This description is based on an application for flood detection and management in Southern UK that is being built in the context of the SemsorGrid4Env R&D project.

The Channel Coastal Observatory (CCO) is a well-used sensor network data source in the Solent region (in Southern UK). This network consists of a large number of deployed nodes with sensors, which, when associated with an appropriate spatial model, can detect if a flood is ongoing or likely in the near future throughout the Solent region. If this information can be combined with additional data sets pertaining to assets and ecological services, the impact of flood may be minimised by providing additional details during an emergency response and planning mode.

Use case description and actors
In this context, users (environmental managers and emergency response officers) may need to find observations obtained from the CCO network that meet certain criteria, and to link them to external data sources. For example, they may want to find all the observations related to weather conditions and tide information available in a specific bounding box (or in a specific region) and obtained in the last 24 hours, and to link them to the economic assets that could be affected by a potential flood event. These users work under the assumption that although CCO is the primary data source used, there could be other data sources (sensor-based or not) that could dynamically appear in the regions of interest, which they might not control, but which can provide useful information.

Hence, the primary actors in this use case are users with operational functions - such as emergency response, ship management (port operations) or recreational vessel monitoring and management - who will benefit from access to information that is embellished with real-time representation of sea state and height, and who may benefit from integrating this with other existing datasets in order to support multi-criteria decisions and operations. Other additional actors or stakeholders include professional and public users of environmental data who rely on access to existing major public information services, scientists conducting experiments (interested in data that suits their needs), forecast modellers, or citizen scientists.

Ontology usage
Sensor and other data assets are described with respect to the SSN ontology. In this context, special care has been taken to provide information about the related measurements and observations, with less attention paid to the descriptions of the sensor hardware from which these measurements and observations are made (and deployed as part of the Channel Coastal Observatory) since this is out of the scope of this use case.

Geospatial and temporal coverage of the overall sensor network is, however, critical since this must be aligned and linked with the regions identified by the users of the use case, both in the context of their roles and responsibilities and for the data sources they wish to use and link. These specific regions are often bespoke to the user or data source (e.g. the Solent, or coverage of an ecological asset data set) and do not appear in existing ontologies (e.g. Ordnance Survey ones), so must be included and appropriately linked. This also happens with asset descriptions, which are also related to other domain ontologies (e.g., ontologies about weather conditions, tide information, coastal defences and shipping). And finally, spatial and temporal information is also added in order to facilitate the data discovery process.

3.3.2 Device Discovery and Selection

Background
The Device Discovery and Selection use case mirrors the Data discovery use case with more emphasis on the structure and capabilities of the sensor or sensor networks than on how it relates to its environment.

Assessing the fitness of a particular sensor product for a specific task is often difficult. For rainfall gauges, information on how sensors perform in extreme conditions like high intensity rainfall or hail events is not always available. Selecting sensors in the context of international scientific collaborations like Fluxnet is even a bigger challenge, especially when (as for FluxNet) sensor assets are administered by national bodies but with the goal to produce a world-wide carbon-climate field dataset which is globally consistent.

The quality of fact sheets and of other technical documentation provided by sensor manufacturers is highly variable, especially for the description of secondary capabilities like, for example, the performance of rainfall sensors for the measurement of rainfall intensity. The authority for this type of sensor, the World Meteorological Organization, has conducted intercomparison studies ([WMO 2006], [WMO 2009]) to evaluate the performance of 25 models of sensors based on various measuring principles (e.g. tipping bucket, and impact disdrometer). The evaluation covers laboratory and field conditions for both normal and extreme conditions of use. This data would be very useful to users wishing to select the best sensor available for a given mission.

Fluxnet is an international network of over 500 sensor towers deployed in 35 countries, with an average of 20 sensors deployed on each tower. The OzFlux sub-network is administered by CSIRO with 14 stations in Australia. These ground stations are designed to provide continuous, long term micro-meteorological measurements of the exchanges of carbon dioxide, water vapour, and energy between the biosphere and atmosphere. The data they provide is used in conjunction with data from satellite-based sensors, to help scientists to validate new scientific theories and models.

Use case description and actors
The central user in this use case wishes to develop a new sensing capability or complete an existing one. This user may also be in charge of the setup of sensor assets and be the custodian of the site-specific data and of the observations produced by the sensors. To be able to pick the right sensor, this user needs to collect information about sensor types, models, and performance in a range of conditions from multiple places:

• Organisations defining sensor categories and standards for their field of application,
• Manufacturers of sensors,
• And organisations setting up sensor assets.

In this context, search and mashup capabilities are equally important for the user. Ideally, experts for various fields of applications should be tasked to provide the domain-specific extensions to the SSN Ontology allowing sensor manufacturers to describe their products in a more consistent and complete way. Then, manufacturers should provide the data for each model in their catalogues so that it can be mashed up by electronic commerce and comparison web sites designed to let buyers compare and select the sensor which is the best match for their application. Users deploying sensors should then focus on the collection and the dissemination of the deployment-specific data rather than manufacturers' data about categories or models of sensors.

The data provided by manufacturers may also be used directly by end users deploying sensor assets when they merge it with their own data to share with their users. This capability, currently offered via a Service API based on SensorML, could be replaced by mashups, with potentially huge savings for virtual organisations managing many sensor assets like the Fluxnet collaboration.

Note: The latter part of this use case is related to the next use case "Provenance and Diagnosis" which covers the specific needs of users wishing to know more about the context in which data as been produced or to diagnose the causes of errors in the data produced by the sensors. Manufacturers of smart products may also decide to expose this data via a Sensor API so that it is always accessible. This case is discussed in the last use case "Device Operation Tasking and Programming".

Ontology usage

The ontology should capture information about sensor capabilities, performance, and the conditions in which it can be used. It should include the most common metrological definitions like accuracy, precision, drift, sensitivity, selectivity, measurement range, detection limit, response time, frequency and latency.

One caveat is that to define sensor types, it is necessary to import external definitions. The simplest approach is to define categories of sensors by a reference to the generic quantity it can measure or of the corresponding units of measurement it uses. This works well in some applications (e.g. Pachube) but not in the general case as the need to refine quantity definitions specifically for each domain of application quickly arises. Then, other information such as the type of feature or phenomenon to be observed or the procedure to be followed are also needed (this aspect is discussed in the "Data Discovery" use case).

This dependency on domain-specific definitions like the type of property which is measured or the type of feature which is observed can be served without presuming which external ontologies are selected as the source of definitions for these. However, the quality of these external resources, for example, their ability to cover multiple domains of application with accurate and unambiguous definitions, is a very important consideration.

3.3.3 Provenance and Diagnosis

Background

Organisations deploying sensors need to monitor their assets to detect the possible occurrences of faults and the degradation in the quality of measurement over time (drift), possibly caused by changes in the operating conditions. Provenance data is important for the users of sensor networks wishing to evaluate the fitness of the data for their purpose. Provenance also enables data citations which will be a critical incentive to encourage the sharing of data, especially when it is produced by government or scientific organisations.

There is an urgent need for better management of information about water resources, especially in Australia, as the driest inhabited continent. Information infrastructure that supports real-time or near-real-time situation awareness is required for managing reservoirs and environmental flows, for efficient water trading, for compliance monitoring and irrigation planning, for hydro-electric power generation and for reliable flood warnings. A pilot project to develop real time water information systems (RT-WIS) is being developed in the context of the South Esk river catchment in Tasmania, Australia, by CSIRO and several partners including Tasmanian Department of Primary Industries, Parks, Water and Environment, Hydro Tasmania, Bureau of Meteorology, 52°North and the University of Muenster (Germany) and the Rensselaer Polytechnic Institute (USA). The RT-WIS is based on the OGC SWE architecture, and employs real time sensor observations and real-time predictive modelling [Liu et al. 2010].

In order to support the interpretation of information produced through the RT-WIS, it is proposed to develop a comprehensive provenance information management service. This service will take advantage of the developing W3C work on Provenance [Provenance XG 2010] and is using the SSN ontology to describe the origins of the sensed data, arising from stream gauges and weather stations managed by separate organisations in the region.

Description The ontology needs to provide information about the sensor that is used to derive measurement data. Firstly, it needs to describe the physical property being observed, and properties of the sensor's measuring capability such as frequency, accuracy, measurement range, and precision. This can be used to check whether the sensor has been properly used to derive some subsequent conclusion, and could also be used to derive error bounds on derived results such as forecasts.

Further, the ontology should describe the physical structure on which the sensor is deployed and its location (in our case we may want to include the altitude or depth below a normative stream height), the custodian responsible for the sensor, the maintenance schedule for the device (e.g. how often is the sensor checked and freed of weeds) and the environmental conditions under which the sensor is expected to operate according to specification. The custodian information and maintenance information can be used to determine trust in the data. The environmental conditions might be used to diagnose the reasons for an apparent data failure.

Actors In many cases the information may be used for direct human interpretation, like a printed data sheet. However, software agents may also use the information to make inferences about the reasons for unexpected or anomalous results.

3.3.4 Device Operation Tasking and Programming

Background

The device operation tasking and programming use case is presented in the context of the Phenonet sensor network for agricultural microclimate monitoring. This sensor network and its modelling with the SSN ontology is described further here: Agriculture Meteorology Sensor Network. As this is a highly experimental network, with the aim of collecting information about different aspects of different experimental field crops at different stages in their growth cycles, it is implemented with a heterogeneous range of sensors deployed in a mix of heterogeneous networks over a common spatial region. It is required to offer agricultural scientists, as end users, the ability to change the data collection method (systems, devices, and sensors employed, frequency of measurement, location of measurement if mobile, local aggregation and memory management) taking into account the capability of the sensor network. Some sensing devices are subsystems of Mote-like network nodes which can be programmed in the NesC or SNlog programming languages. Others are passive data loggers, and others still are programmable directly through a proprietary command-line based language.

Description

The words tasking and programming are used interchangeably here to refer to the assembly and transmission of instructions intended to control the behaviour of the sensing device. Tasking is normally used in the OGC SWE context, referring perhaps to the tasking of assets used for surveillance, but programming would be a more natural term for Mote-like devices and the sensor network developer community. Although sensing devices are sometimes also actuation devices, in this context we confine our attention to the control of sensing behaviour and actuation that is necessary to obtain the desired sensing data (for example, changing the angle of tilt of a camera).

The ontology should capture sufficient information about the capability of sensor devices and about the current state of the devices to support a palette of options for selection by the user. For example, a user should be able to define the desired observation frequency expressed in terms of the possible frequencies identified for the sensing device. It should be possible to extend the ontology to capture command language templates sufficient for device drivers to translate a completed template to an executable device-specific program. See How to represent a process implemented by a sensor for one way to model this and [Taylor and Penkala 2009] for another.

The user should be able to understand the network resource cost of proposed instructions (for example, power required per measurement, current battery life, latency before instruction can be executed). These qualities could be interpreted by the scientist user directly, or by an automated agent aiming to optimise network efficiency through resource scheduling and optimisation algorithms. The scientist or agent user should also be able to use information on sensor operating conditions to determine whether a sensor can be used as required, possibly by tasking another sensor to determine whether those conditions are met. For example, see Operating Range to see how to represent that a sensor can only operate under given environmental and battery power conditions.

The ontology should also be able to provide capability documentation and a vocabulary of instructions for the Sensor Planning Service ([SPS 2007]).

Actors

The intended primary actor would be an engineer or scientist issuing commands to the sensor network, supported by software that uses the ontology as the primary description of the network. In other cases it might be a software developer incorporating the sensor network into a larger observation or information system, requiring information on the control mechanisms available.

4 Review of Sensor and Observation ontologies

4.1 Overview of this activity

Prior to the start of the ontology engineering work on the SSN ontology, the group extensively reviewed ontologies and data models describing sensors and their capabilities as well as observations, using these attributes.

This part of the report presents the 17 sensor-centric and observation-centric ontologies which were analysed in detail. This report also provides a record of other ontologies which were identified but which did not match the objectives stated in the SSN XG charter.

DISCLAIMER: 8 out of the 17 ontologies which are reviewed here were developed by organisations participating in the SSN XG and may have been reviewed by the participants of the XG who were involved in their development. This is because the goal of this review phase was to better understand the similarities and differences between all the existing ontologies to refine the scope of the SSN XG ontology. At such an early stage of the XG work, it was efficient to allocate the review of an ontology to someone involved in its development rather than to ask someone else from the group to do it.

Special thanks to John Graybeal, W3C Invited expert for the SSN XG at the time of this review, for taking notes during the July 1 teleconf discussion on the reviewed ontologies and for initiating this part of the report.

4.1.1 Reviewed ontologies

The reviewed ontologies are listed in next two tables. The first table lists the ontologies which are sensor-centric.

Table 4.1: Reviewed Sensor Ontologies

Ontology Name	References	URL	Image URL	Presenter	Comments
CSIRO Sensor Ontology	[Neuhaus and Compton 2009] [Compton et al. 2009b]	OWL	334K png	Michael Compton	focus: sensing
OntoSensor	[Goodwin and Russomanno 2006] [Goodwin et al. 2007] [Russomanno et al. 2005] [Russomanno et al. 2005b]	OWL	small png complete 2M png	Danh Le Phuoc
Sensor Web for Autonomous Mission Operations (SWAMO) ontology	[Underbrink et al. 2008]	N/A	JPGs: SMLc SMLp Platforms Observations Agents	John Graybeal	references add'l links
Sensor Data Ontology (SDO)	[Eid et al. 2006] [Eid et al. 2007]	N/A (paper only)	image from paper	Raúl García Castro
MMI Device Ontology	[Marine Metadata Interoperability 2008]	OWL	png	Luis Bermudez	in progress
SensorML Processes	[Robin and Botts 2006]	N/A	png	Luis Bermudez	refactored around processes
Coastal Environmental Sensor Networks (CESN) ontology	[Calder et al. 2010]	OWL	png	Holger Neuhaus
WIreless Sensor Networks Ontology (WISNO)	[Hu et al. 2007]	N/A	no image	Oscar Corcho	OWL ontology requested but no answer yet from the authors
Agent-based Middleware Approach for Mixed Mode Environments (A3ME) ontology	[Herzog et al. 2008] [Herzog and Buchmann 2009]	OWL	png	Arthur Herzog
Ontonym - Sensor	[Stevenson et al. 2009]	Web, OWL	No image	Raúl García Castro

The second table lists the ontologies which are more observation-centric.

Table 4.2: Reviewed Observation Ontologies

Ontology Name	References	URL	Image URL	Presenter	Comments
SEEK Extensible Observation Ontology (OBOE)	[Madin et al. 2007]	ontologies	image	Kevin Page
Semantic Reference Systems (SeReS) O&M	[Probst et al. 2006] [Probst 2006] [Probst 2007] [Probst 2008]	ontologies	image	Krzysztof Janowicz
Stimuli-centered ontology	[Stasch et al. 2009]	gsn09hs, haskell musil.uni-muenster.de	x	Krzysztof Janowicz
Sensei O&M	[Barnaghi et al. 2009] [Wei and Barnaghi 2009]	OWL	x	Payam Barnaghi	Sensei O&M Ontology Review
O&M-OWL (SemSOS)	[Henson et al. 2009]	OWL	x	Cory Henson	An encoding of O&M in OWL. Used in a semantic Sensor Observation Service.
OOSTethys	[Bermudez et al. 2009] [Bermudez 2010]	OWL	png	Luis Bermudez	Observation, procedure, systems and other semantics needed in OGC SWE services.
Socio-Ecological Research and Observation oNTOlogy (SERONTO)	[Skov and Petit 2005] [van der Werf et al. 2009]	OWL	N/A	Laurent Lefort	previously known as CEDEX or ALTER-NET Core

4.1.2 Surveys of Sensor and Observation ontologies

Two peer-reviewed survey papers ([Bell et al. 2009], [Compton et al. 2009a]) were presented at the 2nd International Workshop on Semantic Sensor Networks 2009.

[Compton et al. 2009a] also discusses the ontologies developed by:

• [Avancha and Patel 2004]
• [Kim et al. 2008] (which is related to OntoSensor)
• [Matheus et al. 2005]
• [Preece et al. 2008]

In July 2007, a NSF Observations Workshop was held by Mark Schildhauer and Peter McCartney at NCEAS (National Center for Ecological Analysis and Synthesis), Santa Barbara, California, with presentations on LTER-Europe's CEDEX ontology (Mirtl), CUAHSI's ODM standard (Horsburgh), TDWG's OSR standard (Kelling), NatureServe's ODS standard (Stein), NASA's SWEET ontology (Raskin), Spire's ETHAN ontology (Parr), CDP's TreeBase standard (Zeman), OGC's O&M framework (Bermudez), VSTO's ontology (McGuinness) and SEEK's OBOE ontology [Madin et al. 2007]. A comparison of OBOE, CEDEX and CUAHSI ODM has been done by [Madin et al. 2008].

From the same community, it is no longer possible to find the SEEK ontologies [Williams et al. 2006] but other ontologies developed by SEEK collaborators for the SPIRE project are still available. All this work has fed into the development of the OBOE ontology.

4.1.3 Ontologies and other models which have been partially reviewed or not reviewed

Annex E.5 in earlier versions of O&M ([OM 1 2007], [OM 2 2007]) included a 'phenomenon' ontology, based on the SWE phenomenon schema, described in Annex C.3 of the same document. The ontology is incomplete, was in fact only intended to be illustrative of how the requirements described in the schema might be satisfied. Also note that if OWL had been more mature when the work started (2001) it would have been used instead of this bespoke XML serialisation. See O&M Phenomenon Dictionary

SWEET [Raskin and Pan 2005] has some parts which are relevant but too shallow for direct use like sciInstrument. The VSTO ontology ([Fox et al. 2007] , [Fox et al. 2008]) extends SWEET to support the integration of data sourced from Earth Observation sensors. The SPASE data model [SPASE 2010] and the NEESGRID ontology [Peng and Law 2005] are also aimed at environmental monitoring applications.

4.1.4 Outcomes of the SSN XG review

At the end of this activity, the group identified concepts that should be included, but found that none of the ontologies under review supported all of those required concepts. The group opted to use one of the 17 ontologies as the starting point for the development of the Semantic Sensor Network ontology. The Sensor ontology developed by Michael Compton, Holger Neuhaus and Nguyen Tran from CSIRO (Australia) was selected. This ontology (SensorOntology2009) and its documentation are available for the readers wishing to compare it to the final product of the working group.

Some of its users have called it the Draft W3C Semantic Sensor Network Ontology ([O'Byrne et al. 2010]) instead of the denomination CSIRO Sensor Ontology 2009 which is now preferred.

4.2 Reviews

4.2.1 CSIRO Sensor Ontology

(Presented by Michael Compton)

Primary purpose/target: Why was this ontology created? > For describing and reasoning about sensors, observations and scientific models. Provide a semantic description of sensors for use in workflows.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Actively being developed. Not yet complete/finished - was designed not to be 'complete' in the sense that it should provide a language to specify sensors, but is agnostic about domain concerns, units of measurement, location, time series, etc. (these are mentioned, but should be included from separate ontologies using the usual OWL mechanisms). Also, observations and sensors are fairly tightly coupled concepts, so a sensor ontology could really be a sensor-and-observation ontology and this one isn't that yet

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Sometimes

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > some

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). > Sensor, Grounding, OperationModel and Process (and then Feature etc. from a domain perspective)

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > I think it's reasonably broad, but there is more to include from say from SensorML, O&M and OntoSensor

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Not a hierarchy of concepts, has some restrictions etc.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> No, there are a small number of examples.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? >

Composition -- A key question (as John pointed out on the wiki) is where does composition live. From my review this is the only ontology that we have considered that can do proper composition (others can do something limited or something closer to part-of) so that aspect should be included.

Plug and Play -- Removing the ontology from domain concerns, issues of how to represent units of measurements, locations etc. is a good modularity feature. The SSN ontology shouldn't include these, but rather allow any such ontology to be plugged in.

Hierarchy of Sensors -- This ontology doesn't include any hierarchy of sensors, in the sense of a thermometer is a temperature sensor etc., the idea in creating the ontology was that this hierarchy lives parallel to the more capabilities and limitations description that the ontology does give. The hierarchy of sensors approach is a) more domain influenced and b) can probably be automatically derived from the other (in that the hierarchy can be set up such that sensors described in the given ontology are automatically classified into the correct places.) . However, I acknowledge that some aspects are generic and perhaps a combination of the two approaches is what the incubator should produce (ontosensor has elements of both).

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? >

Other remarks: Anything else of particular interest that you think people should know about? >

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Yes

---

Additional documentation derived from the OWL file is available here:

• SensorOntology2009

Slides:

• Compton et al. 2009 Semantic Sensor Network Ontology, Presentation at the SSN XG Face-to-Face meeting, Washington, 24 October 2009
• Neuhaus and Compton 2009 The Semantic Sensor Network Ontology A Generic Language to Describe Sensor Assets AGILE 2009

---

4.2.2 OntoSensor

(Presented by Danh Le Phuoc, plus comments from Laurent Lefort)

Primary purpose/target: Why was this ontology created? > OntoSensor was created to build a knowledge base of sensor (University of Memphis). This knowledge base can be queried via a Protege plugin.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not?> Not updated since 2008. It is incomplete: it mostly covers the sensors listed in Crossbow catalogue.

Key framework concept(s): What are the one, two, or three key concepts around which the ontology is organised? Provide the name and brief description (a phrase) describing each of the key concepts.>

• Sensor
• Capabilities description
• Measurand

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive?> OntoSensor is narrowly focused on technical specifications of sensor. It targets to a small set of sensor features such as data acquisition boards, sensing elements, processor/radio units in the Crossbow 2006 catalogue.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated?> It provides a small taxonomy of sensors, but, it contains several complicated properties.

Dependencies: Which upper ontologies/concepts/properties does it depend on?>

• IEEE SUMO: Process, ContentDevelopment, MeasuringDevice, TransportationService
• ISO 19115: MD_LegalConstraints, MD_SecurityConstraints, CI_ResponsibleParty, CI_Citation, CI_OnlineResouce
• SensorML:
• GML:

Adoption: Is anyone other than the creator using this ontology?> Yes, [Kim et al. 2008].

Best feature(s): What aspects or parts of this ontology should be incorporated into the SSN ontology if possible?> The best feature for me is the inclusion of 32 individuals (instances) definitions. Recommendation: ignore all the classes and properties definitions which are not leveraged by these instances.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? (Do not consider lack of completion as an issue, in this context.)>The organization of concepts and properties is so messy to use in other application or to extend.

Other remarks: Anything else of particular interest that you think people should know about?

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts?> No.

4.2.3 SWAMO

(Presented by John Graybeal)

Primary purpose/target: Why was this ontology created? > Enable dynamic, composeable interoperability of sensor web products and services. Describing autonomous agents for system-wide resource sharing, distributed decision making, autonomic operations.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Actively maintained, and in progress (not complete).

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3).> SWE sensor systems (and semantics). Autonomous agent control systems. Maximum interoperability.

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Fairly broad, somewhat deep. It focuses on the sensor domain, and particularly on processes to control them.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Sophisticated.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Applied to multiple MidSTAR1 instances (sensor, computer, battery actuator).

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Interoperable with SWE descriptions. Its inclusion of real-time information should be considered (position, orientation, etc.). Its organization of "everything is an X" (X=component in this case) is analogous to SensorML. Targets dynamic and composeable interoperability.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Classes look a little mixed -- acceleration is in the Position class. The highest level class (Component) does not appear to reference itself.

Other remarks: Anything else of particular interest that you think people should know about? > May be further along than our image shows.

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Components on Agents. (Would something like the Position class and subclasses be useful?)

4.2.4 SDO

(Presented by Raúl García Castro )

Primary purpose/target: Why was this ontology created? > To search relevant sensor data over distributed and heterogeneous sensor networks.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > The ontology is not available for use. It does not seem actively maintained, it was only described in two papers in 2006 and 2007 with "identical" content.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Unknown.

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No.

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). >

• Reuses the SUMO ontology as a whole. The rest of the modules reference to the SUMO ontology.
• Sensor Hierarchy Ontology.
  • Only a figure is available.
  • Describes Sensors and Sensor data.
  • Built from IEEE 1451.4
    • Does not completely cover the standard
    • Some modelling errors: Mix subclass properties with ad-hoc properties (e.g., has, characterised_by)
    • Non-justified modelling decisions. E.g., they say that "A sensor is an actuator or a transducer" and in IEEE it appears that "A transducer is a sensor or an actuator".
• Sensor Data Ontology. There is nothing available. From the paper:
  • "Describes the dynamic and observational properties of transducers data that goes beyond describing individual transducers"
  • "Describes the context of a sensor with respect to spatial and/or temporal observations"
  • "Provides abstract measurements/operations by groping transducers (virtual transducer)"
• Extension Plug-in Ontologies. There is nothing available. Each plug-in ontology includes the representation for a particular domain of sensor data and networks.

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Narrowly focused.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Not clear, but it seems quite lightweight (a basic hierarchy of concepts with some properties).

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> The ontology has not been released for third party use.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Not parts of the ontology but general concepts:

• Alignment with standard
• Alignment with upper ontologies?
• Abstraction of groups of sensors/sensor networks in virtual sensors
• Modular development

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Limited information available, some conflicts with standards.

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.

4.2.5 MMI Device Ontology

(Presented by Luis Bermudez)

Primary purpose/target: Why was this ontology created? > Develop an ontology of oceanographic devices, including both sensors (which measure things) and samplers (which pick up things). The first priority is to be able to broadly characterise the devices (i.e., sort them into groups). One significant use of such characterizations is to help users (or web applications) discover sensors or data of interest, but a set of use cases is being developed to flesh out the work

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Not completed. In progress. Meetings every 2 weeks.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > some

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). > It is organised around a system concept. System is a Process. System has capabilities, like measurement capabilities (accuracy etc..)

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Even though was meant to be for oceanographic sensor it could be used in other contexts.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > It contains properties and hierarchy of classes and some restrictions

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Not sure

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > System and capabilities concepts including the hierarchies.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Not sure (not well tested)

Other remarks: Anything else of particular interest that you think people should know about? >

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Yes, system and capabilities

4.2.6 SensorML Processes

(Presented by Luis Bermudez)

Primary purpose/target: Why was this ontology created? > To represent SensorML model and serve as a starting ontology for the MMI device ontology

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > NO. Not maintained

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > it is based on the SensorML schema

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). > Process.

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Narrowly focus on Processes

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Basic

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> No

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > None

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > based on the schema and not a conceptual SensorML model

Other remarks: Anything else of particular interest that you think people should know about? >

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.

4.2.7 CESN

(Presented by Holger Neuhaus)

Primary purpose/target: Why was this ontology created? > The CESN (Coastal Environment Sensor Network) ontology was created as part of the "CESN Semantic Data Reasoner" project

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > The paper "Machine reasoning about anomalous sensor data" (Calder et al.) "extended ontology will be complete and in place by autumn 2009", so assumably work in progress.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > There are near to no comments in the OWL file.

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No.

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each. > The Sensor that is restricted to measure only one PhysicalProperty (and by that performing a PhysicalProperty); Instrument containing several Sensors; and Deployment, relating Instruments readings to time and place of a real-world event.

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > quite narrow (more like an application ontology)

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > The sophistication is more in the entire system the ontology is only a part of. "Sensor" is more like a black box.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Probably not.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > A representation of the hierarchy Sensor - Instrument - Deployment (which, in the proposed initial version is similar to Transducer - Sensor - Grounding)

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > The explicit mention of sensor types will always be incomplete.

Other remarks: Anything else of particular interest that you think people should know about? > The rules applied in the entire system the ontology is part of - which aren't in focus of the XG - could be of interest for someone using the ontology.

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.

4.2.8 WISNO

(Presented by Oscar Corcho)

Primary purpose/target: Why was this ontology created? > To provide a few terms related with sensors and actuators. This is a poster demo, with no real ontology backing it up (no answer from creators), and looks like a very simple proof of concept of how to use OWL and SWRL.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > No

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > References to SensorML and IEEE 1454.1 (transducers)

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). > Sensor are classified into transducers and actuators.

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Really broad, lack of detail.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > basic hierarchy of concepts

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> No examples about it.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > None

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > N/A

Other remarks: Anything else of particular interest that you think people should know about? > N/A

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No

Discussion: One of those papers that should not be discussed about nor even referenced, but included here for completeness of our descriptions.

4.2.9 A3ME

(Presented by Arthur Herzog)

Primary purpose/target: Why was this ontology created? >

• basic simple classification for self-description and discovery of devices and their capabilities in heterogeneous networks including resource constrained sensor nodes.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >

• Actively maintained; complete, since it has to stay simple (but can be extended).

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >

• No

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >

• FIPA Device Ontology
• OntoSensor
• SOPRANO context ontology

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). >

• Device classification: tag, mote, mobile, workstation, server, vehicle and multimedia
• General capability classes: sensor, actuator, communication, storage, computing, energy
• Subclasses for each capability class

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >

• moderately broad

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >

• basic hierarchy of concepts

Adoption: Is anyone other than the creator using this ontology? Are there many examples?>

• no (just published)

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? >

• basic classification of device capabilities, with sensor as one of the capability classes

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? >

Other remarks: Anything else of particular interest that you think people should know about? >

• Suggestion: Use of a simple classification of capabilities/sensors as core and build an extended semantically sophisticated version of the ontology on top of this core.

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >

• basic classification of capabilities as basis

4.2.10 Ontonym - Sensor

Ontonym is a set of upper ontologies that represent core concepts in pervasive computing (time, location, people, sensing, provenance, events, device, resource).

Next, we focus only on the sensor ontology.

Primary purpose/target: Why was this ontology created? > To describe sensors and the data that they generate.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > It is a recent ontology, but it seems that there is some interest in maintaining it.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Often.

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > Yes.

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3).>

• Sensor. High level description of a sensor and its capabilities (Frequency, Coverage, Accuracy and precision pairs).
• Sensor data. Description of sensor observations (Observation-specific information, metadata, sensor, timestamp, time period over which the value is valid, rate of change).
• These ontologies must be extended to characterise any specific sensor and its data

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > It is narrowly focused and small. It contains 8 classes, 13 object properties and 1 datatype property.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Is lightweight (a basic hierarchy of concepts with some properties).

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> It doesn't seem so.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Not parts of the ontology but a general concept: To ground on existing ontologies and theories for representing Time, Location, People and Events.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > -

Other remarks: Anything else of particular interest that you think people should know about? > -

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.

4.2.11 SEEK OBOE

(Presented by Kevin Page)

Primary purpose/target: Why was this ontology created? >

The SEEK Extensible Observation Ontology (OBOE) was developed for the SEEK project, and has since been used by Spire.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >

OBOE is now maintained by the Scientific Observations Network - SONet - here.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >

Yes, nearly always. The comment documentation appears good.

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >

No.

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). >

There is a core observations ontology, a units extension, and a further extension for domain use (coastal ecosystems).

• The ontology separates separates observations from the entity being observed: the observation has a measurement while the entity has characteristics, and the measurement is then of that characteristic.

Figure 4.1 - Overview of the OBOE ontology

• Entities are extension points into domain models.

• Observations can occur within a context, which in turn is an observation; this property is transitive.

Figure 4.2 - Handling of nested contexts and observations in OBOE

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >

This is very much an observation ontology, not a device ontology.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >

This is more than a basic hierarchy of concepts.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?>

As far as I can see there is not widespread adoption of the ontology beyond the projects that have developed it.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN observation ontology if possible? >

The context concept (as an observation) is an interesting approach worth considering; whether this is the right match for the SSN ontology given other design requirements (OGC alignment, dovetailing with the device ontology, etc.) is a different matter.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN observation ontology? >

Other remarks: Anything else of particular interest that you think people should know about? >

Several observation ontologies/models have a similar set of concepts - the separation of observation from entity/feature of interest, measurements, some form of context - although the properties may differ. Further discussion and investigation is required to identify whether this is a better (or significantly different) approach than that in e.g. the OGC O&M model.

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >

The general design and structure seems clean, clear, and practical; but see previous comment.

---

Additional information:

• S. Bowers, Ontology Frameworks for Modeling Observational Data Semantics (source of figures 4.1 and 4.2)

---

4.2.12 SERES O&M

(Presented by Krzysztof Janowicz)

Primary purpose/target: Why was this ontology created? >

To align the core concepts from O&M to DOLCE.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >

There are three ontologies, a raw version of OGC's O&M, a modified version of O&M, and an extension of DOLCE to better support observations and measurements. The O&M ontologies are not actively maintained because they are in a stable stage but the DOLCE extension is still under development.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >

In most cases.

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >

Yes, the changes to the original version of O&M are motivated in a discussion paper (Probst et al. 2006])

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). >

In the O&M ontologies the key concepts are Observation, Feature(OfInterest), Result,.... In the DOLCE extension different kinds of quality spaces, regions, and qualities are introduced to integrate O&M into DOLCE.

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >

The O&M versions can be used/combined with our sensor ontology. the DOLCE extension is more a high level approach (and relevant if we would like to align our work to DOLCE).

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >

The DOLCE extension is a full axiomatised ontology (in FOL with a partial mapping to OWL) The O&M parts are basically OWL versions of the O&M specs.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?>

The ontologies are used at our department (Institute for Geoinformatics, University of Muenster, Germany)

Best feature(s): What conceptual aspects of this ontology should be represented the SSN observation ontology if possible? >

We could at least use the 1:1 mapping from the original O&M specs and integrate it into the sensor ontology.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN observation ontology? > ...

Other remarks: Anything else of particular interest that you think people should know about? > ...

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >

Yes, at least the O&M mapping and more if we want to link our sensor ontology to DOLCE.

---

Additional information:

• OWL raw version of O&M
• OWL modified version of O&M:
• DOLCE extension (in OWL)

---

4.2.13 Stimuli-Centered

(Presented by Krzysztof Janowicz)

Review of the stimulus-centric ontology presented as part of the paper on A Stimulus-Centric Algebraic Approach to Sensors and Observations [Stasch et al. 2009] (note that I am a co-author of , hence this review is somehow biased).

Primary purpose/target: Why was this ontology created?> This ontology aims at bridging between the sensor-centric Sensor Model Language (SensorML) and the user-centric Observations & Measurements (O&M) specification by focusing on stimuli as objects of sensing. It does not require a strong link between sensors and features of interests such as O&M. It also include humans as sensors which are the key to volunteered geographic information.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not?> It is actively maintained. As it is a top-level kind of ontology, it is not complete in the sense of listing sensor(types) or observations but focuses on establishing a common ground for both.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)?> There are many additional details provided in the paper (see below) and in the haskell source code file.

Key framework concept(s): What are the one, two, or three key concepts around which the ontology is organised? Provide the name and brief description (a phrase) describing each of the key concepts.>

• Stimuli
• Observations
• Sensors

Figure 4.3 - The role of stimuli as a proxy between the sensor and the object of sensing

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive?> This ontology is focused on providing a top-level view on observation, not on specific sensors (however they can be aligned to the ontology).

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated?> The ontology provides algebraic specifications using the haskell programming language to define the core concepts, hence it provides rich semantics.

Dependencies: Which upper ontologies/concepts/properties does it depend on?> It is based on work on SensorML, O&M, as well as Dolce.

Adoption: Is anyone other than the creator using this ontology?> The ontology is under development and so far only used in our work. It is part of the work done in the 52°North semantics community.

Best feature(s): What aspects or parts of this ontology should be incorporated into the SSN ontology if possible?> The ontology provides a detailed view on the process of observing and could (together with others) be used as top-level for the SSN ontology. However, IMO it would be better to use it as top level for an ontology of observations (and stimuli).

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? (Do not consider lack of completion as an issue, in this context.)> Needs a OWL version to work with the W3C SSN ontology.

Other remarks: Anything else of particular interest that you think people should know about?

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts?> Yes, see above.

4.2.14 Sensei Observation and Measurement Ontology

(Presented by Payam Barnaghi)

Primary purpose/target: Why was this ontology created? > To annotate sensor observation and measurement data; The O&M ontology is then incorporated into the SENSEI resource model.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > No. This is only a draft version based on OGC's observation and measurement model.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). > An observation and measurement data can be related to an Entity of Interest (EoI) and it is provided via a Resource. The processes and services that make the O&M data available are provided through a Resource End Point (REP).

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > This is a general observation and measurement ontology and is constructed based on the OGC model.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > > Basic hierarchy of concepts, very few property restrictions.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> The SENSEI project.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > The observation and measurement model.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > The property restrictions are not completely defined. The SWE properties and relations to other concepts are not included.

Other remarks: Anything else of particular interest that you think people should know about? >

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > The observation and measurement structure which it is based on SWE's O&M model.

---

Additional information:

• slides

---

4.2.15 OOSTethys

(Presented by Luis Bermudez)

Primary purpose/target: Why was this ontology created? > To have a source that holds concepts required to tag OGC SWE services. Also to help communicate the observation model, a procedure and complex systems.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Not completed. It is maintained within OOSTethys, updates every ~ 3 months.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >?

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). > An observation is a procedure which estimates the value of property of a feature of interest. The process is a system. A system is composed of other systems or processes that are atomic (detectors).

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Is a general Observation model but focuses on the procedure.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Basic hierarchy of concepts, very few property restrictions. Some instances.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> The OOSTethys community.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > The observation model and the hierarchy of procedures and systems.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > The details of other semantics used in SWE, like the URI of the contact role.

Other remarks: Anything else of particular interest that you think people should know about? >

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > The observation model and the hierarchy of procedures and systems.

4.2.16 O&M-OWL (SemSOS)

(Presented by Cory Henson)

Primary purpose/target: Why was this ontology created? > The O&M-OWL ontology was created so that we may reason over sensor data to infer "high-level" concepts from "low-level" phenomena. These concepts were then incorporated into a Sensor Observation Service so that users may query for events without requiring expert knowledge of how events and phenomena are related.

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > The ontology is actively maintained. We currently have 160 million observations (1.7 billion triples) describing 20,000 weather stations and eight historical weather events. This knowledge base is now a part of the Linked Open Data Cloud.

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Yes. Almost all concepts have textual descriptions.

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > Yes. All concepts derived from another source (e.g., Observations and Measurements) have references to the original specification.

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). > The ontology is organised around four major concepts: (1) Observation -- act of observing a phenomenon (2) Process -- method, algorithm or instrument, or system of these (3) Feature -- an abstraction of real world phenomena, or "real-world" entity (4) Phenomenon -- property of a feature that can be "sensed" or measured

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Moderately broad. Doesn't deal with different types of sensors, but rather how sensors can be combined into a system. Although, we have descriptions of domain specific weather sensors in our extension.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > More than just a hierarchy of concepts. Semantics are found in the relations between the four major concepts described before. Using OWL to infer types of observations, phenomena, sensors, etc., given partial annotation.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Not yet.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Since our ontology is based on O&M, it is already aligned with the SensorML language, which is a major foundation for the SSN ontology. For example, the concept of process within O&M is taken directly from SensorML.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Expressive representations of time and space are not found in O&M, so we have included concepts from OWL-Time and GML, respectively, but these domains could be better represented.

Other remarks: Anything else of particular interest that you think people should know about? > In the ontology given on the wiki, there are also concepts from the weather domain that are not relevant to the SSN ontology, but they are clearly labelled with the namespace of "weather", and thought they may be of interest so left them in.

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Yes. All.

---

Additional information:

• Semantic Sensor Web
• Linked Sensor Data

---

4.2.17 Socio-Ecological Research and Observation oNTOlogy (SERONTO)

(Reviewed by Laurent Lefort)

Primary purpose/target: Why was this ontology created? >

Created in the context of Long Term Ecological Research (LTER) semantic data integration (ALTER-NET).

Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >

ALTER-NET project finished in March 2009. Funding for ontology work does not seem to be planned in follow-up activities.

Current version corresponds to 2nd round of development (with a test of fitness for semantic integration ability (using OntoPrise in between). It seems to be almost finished (two unsatisfiable classes left).

Finally, the intent of the developers is to get a results which is compatible with other approaches (here compatible means, either "able to reuse" external ontologies (e.g. OBOE) or mappable to existing schemas (e.g. EML (Ecological Markup Language) or the ISO 19115 metadata schemas or the Infobase data model).

Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >

Rarely, except those which corresponds to "enumerated types"

Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >

No. But there are multiple documents (reports or slides and wiki) which details the ontology creation process which has been used, what other models have been looked at, how thje results has been evaluated.

Key framework concept(s): What are the key concepts around which the ontology is organised? Provide a phrase describing each (up to 3). >

Observation = ValueSet

• hasDevice a investigation_device (one class not further defined by the ontology)
• has a parameter_method (combo of method and parameter description, including units)
• hasInvestigationItem physical_thing which is a real world object (SamplingFeature)

The object of the observation is a selection_description which is based on a Population.

Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >

Definitively an Observation ontology developed for BioDiversity apps.

Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >

Pretty sophisticated. It should look good in the UML view of TopBraid (assumption based on the content of the report + evidence that TopBraid was used). It also looks okay in Protege with not too many root classes.

Adoption: Is anyone other than the creator using this ontology? Are there many examples?>

There is large list of contributors. There are good and thorough examples of domain ontologies which complete the core ontology.

Best feature(s): What conceptual aspects of this ontology should be represented the SSN observation ontology if possible? >

The BioDiversity use case (handling of observation which corresponds to a population) is partially covered by O&M so anything which is handled in SERONTO and in OBOE should be taken in consideration.

Many generic aspects of an observation are covered in details.

SERONTO imports a unit ontology which looks okay.

Weakest feature(s): What issues does this ontology have that should be avoided in the SSN observation ontology? >

• the use of subPropertyOf to group properties by themes.
• the presence of unsatisfiable concepts
• the choice of using owl:individual (see Individuals by Classes tab in Protege)
  • This is both good
    • Because it grounds the abstract classes into complementary definitions
  • and bad
    • these definitions are less self-descriptive: the end user needs to read the comments (and they are not well documented elsewhere)
    • this design choice could also be a roadblock for possible extensions.

Other remarks: Anything else of particular interest that you think people should know about? >

CEDEX ~ first iteration of SERONTO: to understand the major differences, you can compare:

• Figure 2 in [van der Werf et al. 2009]
• Figure 1 in [Madin et al. 2008]

Does someone knows what these guys plan to do next, and who they plan to collaborate with (e.g. TDWG or OBOE-led activities)?

Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >

Yes, it shows what can be archived in terms of simplicity vs. versatility. It capture a range of uses cases at the generic level (especially some requirements which fall in the gaps between the multiple OGC standards).

Also, there is a notable effort to define the ontology against other initiatives like EML or ISO 19115.

5 The Semantic Sensor Network Ontology

5.1 Introduction

The Group, recognising the interoperability and broader applicability benefits of a collaborative effort, has developed a formal OWL DL ontology for modelling sensor devices (and their capabilities), systems and processes. The development was informed by a thorough review of previous sensor ontologies (included in this report), and the concurrent development of an informal vocabulary of the main terms, drawing on earlier vocabularies like OIML/VIM and OGC/SWE (SensorML and O&M).

The ontology is based around concepts of systems, processes, and observations. It supports the description of the physical and processing structure of sensors. Sensors are not constrained to physical sensing devices: rather a sensor is anything that can estimate or calculate the value of a phenomenon, so a device or computational process or combination could play the role of a sensor. The representation of a sensor in the ontology links together what it measures (the domain phenomena), the physical sensor (the device) and its functions and processing (the models).

The ontology is available as a single OWL file: SSN ontology and a semi-automatically generated documentation derived from it is also provided as a standalone document. Additional annotations have been added to split the ontology into thematic "modules" which are introduced below. To make the ontology and its documentation more usable, separate documentation pages are provided for each modules with ontology snippets extracted from the examples developed by the XG participants. Five worked examples are included to illustrate different parts of the SSN ontology: University deployment, Smart product, Wind sensor, Agriculture Meteorology, and Linked Sensor Data. The OWL files for the examples and for the imported ontologies are also available.

5.2 Ontology structure

The Semantic Sensor Network ontology revolves around the central Stimulus-Sensor-Observation pattern (see the description of the pattern). Several conceptual modules build on the pattern to cover key sensor concepts. These modules can be seen in Figure 5.1 and the relationships between them appear in Figure 5.2, which contains an overview of the main classes and properties inside the ontology modules.

Figure 5.1 - Overview of the Semantic Sensor Network ontology modules

The ontology can be used for a focus on any (or a combination) of a number of perspectives:

• A sensor perspective, with a focus on what senses, how it senses, and what is sensed;
• A data or observation perspective, with a focus on observations and related metadata;
• A system perspective, with a focus on systems of sensors; or,
• A feature and property perspective, with a focus on features, properties of them, and what can sense those properties.

The modules as described here allow further refining or grouping of these views on sensors and sensing. The description of sensors may be detailed or abstract. The ontology does not include a hierarchy of sensor types; these definitions are left for domain experts, and for example could be a simple hierarchy or a more complex set of definitions based on the workings of the sensors.

Figure 5.2 - Overview of the Semantic Sensor Network ontology classes and properties

The modules contain the classes and properties that can be used to represent particular aspects of a sensor or its observations: for example, sensors, observations, features of interest, the process of sensing (i.e. how a sensor operates and observes), how sensors are deployed or attached to platforms, the measuring capabilities of sensors, as well as their environmental, and survival properties of sensors in particular environments (a detailed enumeration of these properties can be found in Figure 5.3).

Figure 5.3 - Enumeration of the measurement, environmental and survival properties

The main classes of the Semantic Sensor Network ontology have been aligned with classes in the DOLCE Ultra Lite (DUL) foundational ontology to facilitate reuse and interoperability. Figure 5.4 shows in blue arrows the subclass properties used to align these two ontologies. More information about this alignment can be found throughout this report and also in a dedicated section.

Figure 5.4 - Alignment of the Semantic Sensor Network ontology to DOLCE Ultra Lite

Finally, Figure 5.5 shows how the ontology modules defined above support the use cases described in the previous section:

• Users developing Semantic Sensor Web applications, represented in orange in the figure, should be more specifically interested in the modules connected to the Data Discovery and Linking and Provenance and Diagnosis uses cases,
• Users developing Semantic Sensor Web applications, represented in green in the figure, also need the modules connected to the Device Discovery and Selection and Device Operation Tasking and Programming uses cases.

Figure 5.5 - Use cases and ontology modules

5.3 Ontology described module by module

Notation: Most of the figures describing the ontology and the examples have been created with the help of the Concept-map (CMAP) Ontology Editor (or COE).

Readers which are not familiar with the COE tool should consult this COE introductory presentation and the COE notation and conventions section in the COE Manual.

Readers familiar with the COE tool should note that the COE conventions have been modified for the figures presented in this report:

• the label are used by COE for rdfs:subClassOf arrows, linking a class to another class, has been replaced by the label subclass,
• the label is_a used by COE for rdf:type arrows, linking an individual to a class, has been replaced by the label instance.

5.3.1 The Skeleton of the Semantic Sensor Network Ontology

This section outlines and discusses the skeleton first and then describe the alignment of the skeleton to the DOLCE foundational ontology and the development of the SSN ontology based on this alignment.

The design of the Semantic Sensor Network Ontology is the result of two iterations.

• Phase 1: development of the ontology modules and examples,
• Phase 2: alignment to the DOLCE Ultra Lite (DUL) upper ontology.

During the first phase, the group used the results from the review of existing sensor and observation ontologies [Compton et al. 2009a] and the input from all the participants. Figure 5.6 provides an overview of the ontology structure at the end of this first phase: the sensors themselves may have particular properties, such as an accuracy in certain conditions, or may be deployed to observe a particular feature, and thus the whole SSN ontology unfolds around this central pattern, which at its heart relates what a sensor detects to what it observes.

Figure 5.6 - Overview of the ontology structure prior to its modularisation and alignment to DUL

Before the end of the first phase, a proposal to align the SSN ontology with the DOLCE Ultra Lite (DUL) upper ontology was made on the basis of some preliminary alignment work done by one of the group participants using a core design pattern called the Stimulus-Sensor-Observation (SSO) Ontology Design Pattern. After careful consideration, this proposal was accepted by the group as a mean to refine and improve the ontology skeleton and make it more easy to use it in conjunction with other ontologies, especially ones which are also based on a compatible "upper ontology" skeleton.

This means that the SSN ontology skeleton is the sum of:

• a number of (mostly "local") ontology design decisions made during the first phase,
• plus re-engineering work done to align the ontology with SSO and DUL.

This section provides:

• a description of the core skeleton and of how it relates to Stimulus-Sensor-Observation Ontology pattern originally aimed at,
• a description of the alignment to DOLCE Ultra Lite (DUL),

The relation between the three ontologies (the SSN ontology contained at the end of the first phase, the core skeleton and the DUL-aligned version) is best thought of as layers or modules. The core skeleton (also referred to as ontology design pattern) represents the initial conceptualisation as a lightweight, minimalistic, and flexible ontology with a minimum ontological commitment. While this pattern can already be used as vocabulary for some use cases, other application areas require a more rigid conceptualisation to support semantic interoperability. Therefore, we introduce a realisation 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.

5.3.1.2 The Stimulus-Sensor-Observation Ontology Design Pattern

The Stimulus-Sensor-Observation Ontology Design Pattern, presented in Figure 5.7, aims at all kind of sensor or observation based ontologies and vocabularies for the Semantic Sensor Web and especially Linked Data. The pattern is developed following the principle of minimal ontological commitments to make it reusable for a variety of application areas. It is not aligned to any other top-level ontology and introduces a minimal set of classes and relations centered around the notions of stimuli, sensor, and observations. Based on the work of Quine, the skeleton defines stimuli as the (only) link to the physical environment. Empirical science observes these stimuli using sensors to infer information about environmental properties and construct features of interest.

Figure 5.7 - The Stimulus-Sensor-Observation Ontology Design Pattern

5.3.1.2.1 Stimuli

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.

5.3.1.2.2 Sensors

Sensors are physical objects that perform observations, i.e., they transform an incoming stimulus into another, often digital, representation. Sensors are not restricted to technical devices but also include humans as observers. A clear distinction needs to be drawn between sensors as objects and the process of sensing. We assume that objects are sensors while they perform sensing, i.e., while they are deployed. Furthermore, we also distinguish between the sensor and a procedure, i.e., a description, which defines how a sensor should be realised and deployed to measure a certain observable property. Similarly, to the capabilities of particular stimuli, sensors can only operate in certain conditions. These characteristics are modelled as observable properties of the sensors and includes their survival range or accuracy of measurement under defined external conditions. Finally, sensors can be combined to sensor systems and networks. Many sensors need to keep track of time and location to produce meaningful results and, hence, are combined with further sensors to sensor systems such as weather stations.

5.3.1.2.3 Observations

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 observation procedure. The same sensor can be positioned in different ways and, hence, collect data about different properties. In many cases, 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.

5.3.1.2.4 Observed Properties

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 minimise 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.

5.3.1.2.5 Features of Interest

Features of Interest are entities in the real world that are the target of sensing. As entities are reifications, 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 (procedure).

5.3.1.2.6 Procedure

Procedure is a description of how a sensor works, i.e., how a certain type of stimuli is transformed to a digital representation, perhaps a description of the scientific method behind the sensor. Consequently, sensors can be thought of as implementations of sensing methods where different methods can be used to derive information about the same type of observed property. Sensing methods can also be used to describe how observations where made: e.g., how a sensor was positioned and used. Simplifying, one can think of sensing as recipes for observing.

5.3.1.2.7 Result (or SensorOutput)

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

5.3.1.2.8 Implementation of the Stimulus-Sensor-Observation design pattern in SSN

Figure 5.8 illustrates the changes applied to the Stimulus-Sensor-Observation Ontology Design Pattern to include the classes and relations already present in the SSN ontology. In particular, several "shortcut" properties have been added to provide users with more options to create links between the main classes: Observation, Sensor, Stimulus Property and FeatureOfInterest.

Also, a few class names have been changed to match the choices previously made for the SSN ontology:

• Result has been replaced by SensorOutput,
• Procedure has been replaced by Sensing,
• And SensorInput has been kept as a class equivalent to Stimuli.

Figure 5.8 - Implementation of the Stimulus-Sensor-Observation design pattern in the SSN Ontology

5.3.1.3 Aligning the SSN Ontology and the core SSO design pattern with DOLCE

Figure 5.9 - Alignment of the SSN Ontology core to the DOLCE Ultra Lite upper ontology

To ease the interpretation of the used primitives as well as to boost ontology alignment and matching, the SSO pattern has been aligned to the ultra light version of the DOLCE foundational ontology and refined to match the content 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, while the DOLCE-aligned version distinguishes between events and objects and, hence, uses DUL:includesEvent and DUL:includesObject, respectively.

Each class of the SSN ontology is then defined as a subclass of an existing DUL class and related to other SSN and DUL classes. 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 aim of the resulting extension to DUL is to preserve all ontological commitments defined before.

5.3.1.3.1 Stimuli

The 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.

5.3.1.3.2 Sensors

Sensors are defined as subclasses 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 their sensing method and observations using the DUL:implements and DUL:isObjectIncludedIn relations, respectively.

  <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/ssn">
  ...
  <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn#Sensor"> 
   <rdfs:label>Sensor</rdfs:label>
   ...
   <rdfs:subClassOf rdf:resource="http://www.loa-cnr.it/ontologies/DUL.owl#PhysicalObject"/>
   ...
  </owl:Class>
 

As an example, the code snippet shows how sensors are defined as physical objects in terms of DOLCE.

5.3.1.3.3 Observations

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 modelled using the DUL:includesEvent, ssn:observedBy, and ssn:observationResult relationship, respectively. Observation procedures can be integrated by DUL:sensingMethod.

The change to the Observation class should be noted and is visible in the figures presented above:

• In Figure 5.6, which shows the ontology structure prior to the DUL alignment, Observation is presented as a sub-class of Event. This corresponds to the approach preferred by the users of the Observations and Measurement standard (O&M) [OM 1 2007], [OM 2 2007].
• In Figure 5.9, a representation of the final version of the SSN ontology, Observation is presented as a sub-class of a dul:Situation. It is defined as a Situation in which a Sensing method has been used to estimate or calculate a value of a Property of a FeatureOfInterest. Links to Sensing and Sensor describe what made the Observation and how; links to Property and Feature detail what was sensed; the result is the output of a Sensor; other metadata details times etc.

This difference is documented in the ontology: Observation in this ontology and O&M are described differently (O&M records an observation as an act/event), but they record the same thing and are essentially interchangeable. The difference is in the ontological structure of the two, not the data or use. Observation here records a Situation (the estimation of the value of a Property) and a description of the method that was used (along with the participants), while O&M interprets an Observation as the event itself; there must, however, have been an event that led to our situation, so both are records of events. The distinction is between the event itself and the record of what happened in that event.

5.3.1.3.4 Observed Properties

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:isPropertyOf is defined as a subrelation of DUL:isQualityOf to relate a property to a feature of interest.

5.3.1.3.5 Features of Interest

Features of interest can be events or objects but not qualities and abstracts to avoid complex questions such as whether there are qualities of qualities. The need to introduce properties for qualities is an artifact of reification and 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.

5.3.1.3.6 Sensing

Sensing (Procedure in the SSO pattern) is defined as a subclass of DUL:Method which in turn is a subclass of DUL:Description. Consequently, procedures are expressed by some DUL:InformationObject such as a manual or scientific paper.

5.3.1.3.7 SensorOutput

The SensorOutput class (Result in the SSO pattern) is modelled as a subclass of DUL:InformationObject. The management of the concrete data value is introduced through a hasValue relationships to a DUL:Region and then through the data property DUL:hasRegionDataValue in conjunction with some xsd data type.

5.3.1.3.8 Device, System, Deployment, ...

As suggested in Figure 5.4, other parts of the SSN Ontology have also been aligned to DUL. Figure 5.10 is a more complete view of this alignment. It represents the links between the classes defined in the SSN ontology classes and in DOLCE Ultra Lite.

Figure 5.10 - Alignment of the SSN ontology to DUL

The alignment between the two ontologies is also defined through links between the properties which have not been represented in Figure 5.10. The complete list of relationships between the two ontologies is provided as an appendix of the generated documentation.

5.3.2 System

This section describes how to create a System object and uses a simple example to show how to model a system composed of sensors in the SSN ontology. More complex examples where the system class is used in the context of a deployment or when operating restrictions are added to the system definition are provided in the Deploy module documentation.

The ssn:System class for parts of a sensing infrastructure. A system has components, its subsystems, which are other systems. The ssn:hasSubSystem property is used to relate a system to its sub-systems.

Figure 5.11 - the ssn:System class and the ssn:hasSubSystem property (System module)

5.3.2.2 How to represent a system composed of sensors

In this example , the system is a sensor network node (a "mote") which includes a Temperature sensor and a Humidity sensor (this is allowed because SensingDevice is a sub-class of System).

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <!-- System (TelosB Mote) -->
 <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A sample sensor network node. The data is for
  TELOS-B product and the data sheet is available at: http://www.willow.co.uk/TelosB_Datasheet.pdf </rdfs:comment>
  <ssn:hasSubSystem>
   <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TemperatureSensor-TSB-ABC01">
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">The embedded temperature sensor.</rdfs:comment>
   </ssn:SensingDevice>
  </ssn:hasSubSystem>
  <ssn:hasSubSystem>
   <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#HumiditySensor-TSB-ABC01">
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">The embedded humidity sensor.</rdfs:comment>
   </ssn:SensingDevice>
  </ssn:hasSubSystem>
 </ssn:System>
 

Snippet from uni-deploy, University deployment example

5.3.3 Process

The ssn:Process class in the SSN ontology is defined as the specification of the procedure implemented in a sensor. It may be specified as a known principle or method or, if a computer science approach is followed, as a function which has an output and possibly some inputs.

Figure 5.12 - ssn:Process (Process module)

5.3.3.2 How to represent a characteristic transfer function implemented by a sensor

In this example, the process is used to define the characteristic transfer function of a Wind Sensor.

This sensor implements a known formula for relating the spinning of the cups to windspeed and has different accuracies in different conditions

  <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30">
  ...
  <!-- Sensor --> 
  <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30#WM30_WindSpeed">
  <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#implements"/>
      <owl:someValuesFrom>
         <owl:Class>
           <owl:oneOf rdf:parseType="Collection">
            <rdf:Description rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30#wm30_CharacteristicTransferFunction"/>
          </owl:oneOf>
        </owl:Class>
      </owl:someValuesFrom>
      </owl:Restriction>
    </rdfs:subClassOf>
  </owl:Class>
 
 
Snippet from WM30, Wind sensor example

The WM30's characteristic transfer function is the formula used by the device to relate the turning of the cups to windspeed: i.e. it is really the method of measurement used. That is why it is specified here as a sensing method. The actual transducer in the device outputs frequency measured in Hertz and the WM30 converts this to WindSpeed via the function. Thus another modelling option would be to model the whole chain (subdivide the WM30 into further components and show how the output of the transducer is the input of the characteristic transfer function, etc.) indicating more closely how the device actually makes the measurement.

There are any number of ways to specify the characteristic transfer function. DUL's information objects and realisations could be used to provide some other concrete description. In an application that needs to read in the function, perhaps if the specification is of an abstract sensor that needs to be realised at runtime, then some systematic standard or format should be used. Technically, anything could be attached: formatted text, a reference to a scientific paper describing the measurement process, MathML, an algorithm specification in a formal language, program code or an executable. Here the description is just attached as text.

  <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30#WM30_CharacteristicTransferFunction">
    <owl:equivalentClass>
      <owl:Class>
        <owl:oneOf rdf:parseType="Collection">
          <rdf:Description rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30#wm30_CharacteristicTransferFunction"/>
        </owl:oneOf>
      </owl:Class>
    </owl:equivalentClass>
    <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Sensing"/>
    <rdfs:comment>T</rdfs:comment>
  </owl:Class>

  <owl:NamedIndividual rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30#wm30_CharacteristicTransferFunction">
    <rdf:type rdf:resource="http://purl.oclc.org/NET/ssnx/meteo/WM30#WM30_CharacteristicTransferFunction"/>
    <sensingDescription rdf:datatype="&xsd;string">Characteristic transfer function 
      U = -0.24 + 0.699 × F 
     (where U = wind speed [m/s], F = output frequency [Hz]) 
    </sensingDescription>
  </owl:NamedIndividual>

 
Snippet from WM30, Wind sensor example

5.3.3.4 How to represent a process implemented by a sensor (for programming use case)

In this example, the Process instance is used to specify the output of a Ultrasonic Wind Sensor which is part of an Automatic Weather Station and specifies which physical quantity and which unit of measurement should be used. This specification can be used to create the program which retrieves this information from the sensor if other information on the command to be issued to the sensor is also provided (e.g. the variable code in this example).

  <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/meteo/phenonet">
  ...
  <aws:UltrasonicWindSensor rdf:about="http://purl.oclc.org/NET/ssnx/meteo/phenonet#Wxt520Windcap">
    <dul:isPartOf>
      <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/meteo/phenonet#VaisalaWxt520"/>
    </dul:isPartOf>
    <ssn:implements>
      <ssn:Process rdf:about="http://purl.oclc.org/NET/ssnx/meteo/phenonet#Process24">
        <ssn:hasOutput>
          <ssn:Output rdf:about="http://purl.oclc.org/NET/ssnx/meteo/phenonet#SpeedAve">
            <dul:hasParameter>
              <dim:VelocityOrSpeedUnit rdf:about="http://purl.org/NET/ssnx/qu/unit#metrePerSecond"/>
            </dul:hasParameter>          
            <phenonet:variable_code>SM</phenonet:variable_code>
            <phenonet:variable_name>Speed Ave</phenonet:variable_name>
            <phenonet:snlog_code>24</phenonet:snlog_code>
            <phenonet:sensor_name>WXT520 Windcap</phenonet:sensor_name>
            <phenonet:sensor_id>WIND</phenonet:sensor_id>
          </ssn:Output>
        </ssn:hasOutput>
        <dul:hasQuality>
          <dim:VelocityOrSpeed rdf:about="http://purl.oclc.org/NET/ssnx/cf/cf-property#wind_speed"/>
        </dul:hasQuality>
      </ssn:Process>
    </ssn:implements>
    ...
  </aws:UltrasonicWindSensor
 
 
Snippet from phenonet, Agriculture Meteorology example

5.3.4 Measuring

The class ssn:Sensor in the ontology provides the structure to represent a concrete sensing object. The ontology defines several properties for instances of the class ssn:Sensor:

• ssn:observes: points to a property observed by a sensor (e.g., temperature, acceleration, wind speed). An object of this property must be an instance of the class ssn:Property.
• ssn:hasMeasurementCapability: Points to the description of the sensor's measurement capability expressed as an instance of the class ssn:MeasurementCapability. The description of a measurement capability includes such parameters as frequency, accuracy, measurement range, etc.

The class ssn:Sensor can represent any object with the sensing capability (e.g., in some cases a human observer can be a sensor).

In most scenarios the sensors are implemented as devices. The ssn:Device is described in the Device module documentation.

Figure 5.13 - ssn:Sensor (Measuring module)

5.3.4.2 How to create a description of a sensor?

A description of a sensor is created by defining an instance of the class ssn:SensingDevice. For example, the following description represents a concrete sensor (accelerometer) attached to a kitchen tool (knife).

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/product/smart-knife">
 ...
 <ssn:SensingDevice rdf:about="#ExampleWiTilt30Accelerometer">
   <ssn:observes rdf:resource="http://purl.oclc.org/NET/muo/ucum/physical-quality/acceleration"/>
   <rdfs:comment>A specific instance of a WiTilt 3.0 accelerometer attached to a knife.</rdfs:comment>
   <ssn:hasMeasurementCapability rdf:resource="#ExampleWiTiltAccelerometerMeasurementCapability"/>
   <ssn:onPlatform rdf:resource="#Knife_123"/>
 </ssn:SensingDevice>
 
  
Snippet from smart-knife, Smart product example

Note that the SSN ontology does not contain a vocabulary of possible properties which can be measured by sensors. Specific instances of the class ssn:Property have to be created by the user or (preferably) imported from an existing ontology. For example, such ontologies as the MyMobileWeb Measurement Units Ontology (populated with instances), the QUDV ontology, the QUDT ontology, and others provide vocabularies of physical properties and corresponding units of measurement. In order to link an external ontology of measurement properties to the sensor ontology, it is possible to use class subsumption or equivalence links. For example, incorporating the physical properties from the MyMobileWeb ontology (represented by the class muo:PhysicalQuality) can be done in the following way:

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/product/smart-knife">
  <rdfs:comment> An example description of a hypothetical accelerometer sensor related to one of the
  SmartProducts use cases (cooking guidance).
  The ontology describes measurement capabilities of a class of accelerometer sensors (WiTilt v3.0 [1]), 
  and an example of such a sensor attached to a kitchen utensil (knife). 
  [1] http://www.sparkfun.com/datasheets/Accelerometers/WiTilt-v3.pdf </rdfs:comment>
  <owl:imports rdf:resource="http://purl.oclc.org/NET/muo/ucum/"/>
  <owl:imports rdf:resource="http://purl.oclc.org/NET/ssnx/ssn"/>
 </owl:Ontology>
 ...
 <owl:Class rdf:about="http://purl.oclc.org/NET/muo/muo#PhysicalQuality">
  <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Property"/>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

Note that an instance of the class ssn:SensingDevice represents one concrete physical object. It is possible that a use case deals with many sensors sharing common attributes: e.g., sensors measuring a specific property or sensing devices of the same model, which have the same measurement capabilities. In order to describe such groups of sensors with common properties, it is possible to define subclasses of the class ssn:Sensor with restricted property values. In the example below, the class Accelerometer is defined as a subclass of sensors which measure the acceleration property, and the class WiTilt30Accelerometer represents accelerometers of a specific model.

 <owl:Class rdf:about="#Accelerometer">
  <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensingDevice"/>
  <rdfs:subClassOf>
   <owl:Restriction>
    <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observes"/>
    <owl:hasValue rdf:resource="http://purl.oclc.org/NET/muo/ucum/physical-quality/acceleration"/>
   </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:comment>Accelerometer is a subclass of sensing devices which measures acceleration. 
  The individual describing a physical quality "acceleration" is defined in the imported MyMobileWeb 
  ontology of measurement units. To align the MyMobileWeb ontology with the SSN ontology, the class 
  muo:PhysicalQuality from the MyMobileWeb ontology is defined as a subclass of the class ssn:Property.</rdfs:comment>
 </owl:Class>
 ...
 <owl:Class rdf:about="#WiTilt30Accelerometer">
  <rdfs:subClassOf rdf:resource="#Accelerometer"/>
  <rdfs:subClassOf>
   <owl:Restriction>
    <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementCapability"/>
    <owl:allValuesFrom rdf:resource="#WiTilt30AccelerationMeasurementCapability"/>
   </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:comment>This class describes WiTilt v3.0 accelerometers. 
  All possible configurations of their measurement capabilities are defined using the class
  WiTilt30AccelerationMeasurementCapability, so the property ssn:hasMeasurementCapability is 
  restricted to instances of this class.</rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

Then, the description of our example accelerometer will look like:

 <owl:Thing rdf:about="#ExampleWiTilt30Accelerometer">
  <rdf:type rdf:resource="#WiTilt30Accelerometer"/> 
  <rdfs:comment>
A specific instance of a WiTilt 3.0 accelerometer attached to a knife.
 </rdfs:comment></nowiki>
 <ssn:hasMeasurementCapability rdf:resource="#ExampleWiTiltAccelerometerMeasurementCapability"/> 
 <ssn:onPlatform rdf:resource="#Knife_123"/> 
 </owl:Thing> 
</nowiki>

 
Snippet from smart-knife, Smart product example

5.3.5 MeasuringCapability

The measurement capabilities of a sensor are collected using the class ssn:MeasurementCapability. Each instance of the class ssn:MeasurementCapability describes a set of measurement properties of a sensor in specific conditions. Possible measurement properties of a sensor are represented as subclasses of the class ssn:MeasurementProperty. Currently, the ontology defines the following types of measurement properties (follow links to definitions):

• ssn:Drift
• ssn:Sensitivity
• ssn:Selectivity
• ssn:Accuracy
• ssn:MeasurementRange
• ssn:DetectionLimit
• ssn:Precision
• ssn:ResponseTime
• ssn:Frequency
• ssn:Latency
• ssn:Resolution

One instance of ssn:MeasurementCapability can describe a set of measurement properties linked by the property ssn:hasMeasurementProperty and connected to a property using ssn:forProperty (a sensor can observe a number of properties and this allows measurement capabilities to be defined for each property). The conditions, in which these measurement properties are valid, are specified using the property ssn:inCondition and expressed using an instance of the class ssn:Condition. The sensor ontology defines conditions as ssn:Property (i.e. observable conditions that affect the operation of the sensor) but as with all properties doesn't define any further structure: an imported domain vocabulary must be used for this purpose. A sensor can have different measurement capabilities depending on conditions. In this case, one instance of ssn:Sensor can have multiple values for the property ssn:hasMeasurementCapability.

Figure 5.14 - ssn:Sensor and ssn:MeasurementCapability (MeasuringCapability module)

Figure 5.15 - ssn:MeasurementCapability and ssn:MeasurementProperty (MeasuringCapability module)

5.3.5.2 How to describe capabilities of a sensor?

In order to describe measurement properties of one specific sensor, it is necessary to define one or several instances of the class ssn:MeasurementCapability and use the property ssn:hasMeasurementCapability to link the sensor with its measurement capabilities. For example, in case of an accelerometer sensor attached to a knife, this can be described in the following way:

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/product/smart-knife">
 ...
 <owl:Thing rdf:about="#ExampleWiTilt30Accelerometer">
   <rdf:type rdf:resource="#WiTilt30Accelerometer"/>
   <rdfs:comment>
   A specific instance of a WiTilt 3.0 accelerometer attached to a knife.
   </rdfs:comment>
   <ssn:hasMeasurementCapability rdf:resource="#ExampleWiTiltAccelerometerMeasurementCapability"/>
 ...
 </owl:Thing>
 
  
Snippet from smart-knife, Smart product example

Please note that an instance of the class ssn:MeasurementCapability describes measurement properties of a specific physical sensor object. If it is necessary to describe measurement capabilities of a class of sensors, then it is necessary to define a restriction on the property ssn:hasMeasurementCapability for a particular subclass of ssn:Sensor which describes sensors of a specific type.

If all sensors of the same class have exactly the same measurement capabilities, then it is sufficient to define one instance of the class ssn:MeasurementCapability. Sometimes it is necessary to describe a range of possible measurement capabilities. In this case, one needs to define a subclass of the class ssn:MeasurementCapability where certain properties are restricted. For example, below is a superclass for all measurement capabilities of accelerometer sensors:

 <owl:Class rdf:about="#AccelerationMeasurementCapability">
   <rdfs:label>Acceleration measurement capability</rdfs:label>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#MeasurementCapability"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#forProperty"/>
       <owl:hasValue rdf:resource="http://purl.oclc.org/NET/muo/ucum/physical-quality/acceleration"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:comment>This class describes measurement capabilities for accelerometer sensors. 
   The property ssn:forProperty is restricted to ucum:acceleration.</rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

Now, in our example, we want to describe possible measurement capabilities of a specific type of accelerometer sensor devices (WiTilt 3.0). These sensors can be calibrated to measure acceleration in the ranges of +/-1.5g, +/-2g, +/-4g, and +/-6g. Moreover, they can operate in four modes with different output frequency: degree mode (50Hz), gravity mode (135Hz), raw ADC mode (220Hz), and binary mode (610Hz). To express possible measurement ranges, we define a subclass of the class ssn:MeasurementRange:

 <owl:Class rdf:about="#WiTilt30MeasurementRange">
   <rdfs:label>WiTilt 3.0 measurement range</rdfs:label>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#MeasurementRange"/>
   <rdfs:comment>
   This class defines possible measurement ranges of a WiTilt 3.0 accelerometer sensor. 
   These sensors can be calibrated to measure acceleration in the ranges of +/-1.5g, +/-2g, +/-4g and +/-6g. 
   These four ranges are expressed using instances of this class: WiTilt30MeasurementRange_1...WiTilt30MeasurementRange_4. 
   Because the SSN ontology does not specify how the values of measurement properties should be expressed, 
   three properties are introduced: hasMeasurementPropertyValue (for exact values), hasMeasurementPropertyMaxValue 
   (for maximal values), and hasMeasurementPropertyMinValue (for minimal values).
   </rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

Then, we define four instances of this class corresponding to each measurement range:

 <owl:Thing rdf:about="#WiTilt30MeasurementRange_1">
   <rdf:type rdf:resource="#WiTilt30MeasurementRange"/>
   <hasMeasurementPropertyMaxValue rdf:resource="#WiTilt30MeasurementRange_1MaxValue"/>
   <hasMeasurementPropertyMinValue rdf:resource="#WiTilt30MeasurementRange_1MinValue"/>
 </owl:Thing>
 ...
 <owl:Thing rdf:about="#WiTilt30MeasurementRange_1MaxValue">
   <rdf:type rdf:resource="#AccelerationValue"/>
   <hasQuantityValue rdf:datatype="&xsd;float">1.5</hasQuantityValue>
 </owl:Thing>
 ...
 <owl:Thing rdf:about="#WiTilt30MeasurementRange_1MinValue">
   <rdf:type rdf:resource="#AccelerationValue"/>
   <hasQuantityValue rdf:datatype="&xsd;float">-1.5</hasQuantityValue>
 </owl:Thing>
 
  
Snippet from smart-knife, Smart product example

Note that the sensor ontology does not restrict the way in which specific measurement properties are described. In our example, we defined our own RDF properties to define values of measurement properties (hasMeasurementPropertyMinValue, hasMeasurementPropertyValue, hasMeasurementPropertyValue) and defined a subclass AccelerationValue of the class ObservationValue. For this class, we defined properties hasQuantityValue and hasQuantityUnitOfMeasurement and restricted the property hasQuantityUnitOfMeasurement:

 <owl:Class rdf:about="#AccelerationValue">
   <rdfs:label>Acceleration value</rdfs:label>
   ...
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#hasQuantityUnitOfMeasurement"/>
       <owl:hasValue rdf:resource="http://purl.oclc.org/NET/muo/ucum/unit/acceleration/standard-acceleration-of-free-fall"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:comment>Acceleration value measured in g - standard acceleration of free fall.</rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

In the same way, we define possible output frequency values:

 <owl:Class rdf:about="#WiTilt30MeasurementFrequency">
   <rdfs:label>WiTilt 3.0 measurement frequency</rdfs:label>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Frequency"/>
   <rdfs:comment>This class describes maximal output frequency values of WiTilt 3.0 accelerometers in four modes: 
         degree mode (50Hz), gravity mode (135Hz), raw ADC mode (220Hz), and binary mode (610Hz). 
   </rdfs:comment>
 </owl:Class>
 ...
 <WiTilt30MeasurementFrequency rdf:about="#WiTilt30BinaryModeFrequency">
   <hasMeasurementPropertyValue rdf:resource="#WiTilt30BinaryModeFrequencyValue"/>
 </WiTilt30MeasurementFrequency>
 ...
 <owl:Thing rdf:about="#WiTilt30BinaryModeFrequencyValue">
   <rdf:type rdf:resource="#FrequencyValue"/>
   <hasQuantityValue rdf:datatype="&xsd;float">610</hasQuantityValue>
 </owl:Thing>
 ...
 <owl:Class rdf:about="#FrequencyValue">
   <rdfs:label>Frequency value</rdfs:label>
   ...
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#hasQuantityUnitOfMeasurement"/>
       <owl:hasValue rdf:resource="http://purl.oclc.org/NET/muo/ucum/unit/frequency/Herz"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:comment>Frequency value measured in Hz.</rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

Now, if we want to describe all acceptable measurement capabilities of WiTilt 3.0 accelerometers, we can define the following subclass of ssn:MeasurementCapability:

 <owl:Class rdf:about="#WiTilt30AccelerationMeasurementCapability">
   <rdfs:label>WiTilt 3.0 acceleration measurement capability</rdfs:label>
   <rdfs:subClassOf rdf:resource="#AccelerationMeasurementCapability"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementProperty"/>
       <owl:onClass rdf:resource="#WiTilt30MeasurementRange"/>
       <owl:qualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:qualifiedCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementProperty"/>
       <owl:onClass rdf:resource="#WiTilt30MeasurementFrequency"/>
       <owl:qualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:qualifiedCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

In this description, measurement capabilities are characterised by two parameters: measurement range and frequency. Possible values of these parameters are described by classes WiTilt30MeasurementRange and WiTilt30MeasurementFrequency respectively. A specific instance of a WiTilt 3.0 sensor must have exactly one value for each of these parameters. In other words, its property ssn:hasMeasurementCapability can only take values from the class WiTilt30AccelerationMeasurementCapability defined above.

 <owl:Class rdf:about="#WiTilt30Accelerometer">
   <rdfs:subClassOf rdf:resource="#Accelerometer"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementCapability"/>
       <owl:allValuesFrom rdf:resource="#WiTilt30AccelerationMeasurementCapability"/>
     </owl:Restriction>
   </rdfs:subClassOf>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

Now, we assume that our example sensor attached to a knife operates in the binary output mode and has its measurement range set to +/-1.5g. As shown above, its measurement capabilities are described using the instance ExampleWiTiltAccelerometerMeasurementCapability. This instance is defined in the following way:

 <owl:Thing rdf:about="#ExampleWiTiltAccelerometerMeasurementCapability">
   <rdf:type rdf:resource="#WiTilt30AccelerationMeasurementCapability"/>
   <ssn:hasMeasurementProperty rdf:resource="#WiTilt30BinaryModeFrequency"/>     
   <ssn:hasMeasurementProperty rdf:resource="#WiTilt30MeasurementRange_1"/>
 </owl:Thing>
 
  
Snippet from smart-knife, Smart product example

5.3.6 Observation

The class ssn:Observation in the ontology provides the structure to represent a single observation. An observation is a situation that describes an observed feature, an observed property, a sensor and method of sensing used and a value observed for the property: that is, an observation describes a single value attributed to a single property by a particular sensor. Observations of multiple features or multiple properties of the one feature should be represented as either compound properties, features and values or as multiple observations, grouped in some appropriate structure.

The SSN ontology defines several properties for instances of the class ssn:Observation:

• ssn:featureOfInterest: points to the observed feature of interest. A feature of interest can be any observed real-world phenomenon (e.g., geographic entity, entity, etc.).
• ssn:observedProperty: points to the specific quality (properties in the ontology are qualities that can be observed by a sensor; qualities, on the other hand, can also abstract, qualities of abstract things, or in some other way not able to be sensed) of the feature of interest which was observed (e.g., temperature, acceleration, or speed).
• ssn:observedBy: points to a sensor which produced the observation (an instance of the class ssn:Sensor).
• ssn:sensingMethodUsed: points to a method used to produce the observation (an instance of the class ssn:Sensing). This could describe, for example, a particular way in which the sensor is used to make the observation.
• ssn:observationResult: points to a result of the observation expressed as an instance of the class ssn:SensorOutput.
• ssn:qualityOfObservation: points to the adjudged quality of the result. This is complementary to the measurement capability information expressed for the sensor itself (see Measurement Capability).
• ssn:observationResultTime: points to the time when the observation result became available.
• ssn:observationSamplingTime: points to the time when the observation result applies to the feature of interest.

The last two properties are defined as object properties, as the SSN ontology does not prescribe a specific format for the representation of time instants.

The result of an observation is expressed by an instance of the class ssn:SensorOutput. The ontology defines the following properties applicable to the class:

• ssn:isProducedBy: points to a sensor which produced the output (an instance of the class ssn:Sensor).
• ssn:hasValue: points to the actual value of the observation (e.g., "30°C", "60 mph", etc.). This is expressed as an instance of the class ssn:ObservationValue. The ontology does not restrict the format of an observation value: the actual properties can be defined by the user or imported from a third-party ontology.

Figure 5.16 - ssn:Observation (Observation module)

Please note that Figure 5.16 is also a simplification of Figure 5.10. Figure 5.10, included in the Semantic Sensor Network Ontology skeleton section, describes the alignment of the SSN ontology to the DOLCE ULtra Lite ontology.

Information about the time at which the observation has been made, known has the "sampling time" and/or the time at which the result is available can be attached to the ssn:Observation class. This can be done with the help of the ssn:observationSamplingTime and ssn:observationResultTime properties.

It is also possible to provide some information on the quality of an observation through the ssn:qualityOfObservation property.

Figure 5.17 - Properties of ssn:Observation (Observation module)

5.3.6.2 How to represent an observation of a sensor?

In order to describe an observation made by a sensor, an instance of the class ssn:Observation should be used. For example, in our setting (see the Smart product example) we have a sensor which is attached to a knife and measures its acceleration to capture the time when the user is cutting. To represent its observations, we define a class AccelerationObservation as a subclass of the class ssn:Observation.

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/product/smart-knife">
 ...
 <owl:Class rdf:about="#AccelerationObservation">
   <rdfs:label>Acceleration observation</rdfs:label>
   <rdfs:comment>A class describing acceleration observations. Properties ssn:observationResult, ssn:observedBy, and 
                 ssn:observedProperty are restricted accordingly.</rdfs:comment>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Observation"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observationResult"/>
       <owl:allValuesFrom rdf:resource="#AccelerationSensorOutput"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observedBy"/>
       <owl:allValuesFrom rdf:resource="#Accelerometer"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observedProperty"/>
       <owl:hasValue rdf:resource="&ucum;physical-quality/acceleration"/>
     </owl:Restriction>
   </rdfs:subClassOf>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

In this class definition, we define that the class instances are used to define the observations of acceleration made by accelerometer sensors. The output of these sensors is represented using the class AccelerationSensorOutput.

 <owl:Class rdf:about="#AccelerationSensorOutput">
   <rdfs:label>Acceleration sensor output</rdfs:label>
   <rdfs:comment>A class describing sensor output for acceleration measurements. Properties ssn:hasValue and ssn:isProducedBy are
                 restricted accordingly.</rdfs:comment>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensorOutput"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasValue"/>
       <owl:allValuesFrom rdf:resource="#AccelerationValue"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#isProducedBy"/>
       <owl:allValuesFrom rdf:resource="#Accelerometer"/>
     </owl:Restriction>
   </rdfs:subClassOf>
 </owl:Class>
 
  
Snippet from smart-knife, Smart product example

Then, having these subclasses, we can represent the results produced by our accelerometer. For example, it captured a movement of the knife with the acceleration of 0.98g. This observation can be encoded using the following three instances:

 <owl:Thing rdf:about="#KnifeCuttingObservation_435782677">
   <rdf:type rdf:resource="#AccelerationObservation"/>
   <rdfs:comment>An example of the acceleration observation produced by our ExampleWiTilt30Accelerometer. </rdfs:comment>
   <ssn:observationResult rdf:resource="#KnifeSensorOutput_2355676"/>
   <ssn:featureOfInterest rdf:resource="#Knife_123"/>
   <ssn:observedBy rdf:resource="#ExampleWiTilt30Accelerometer"/>
 </owl:Thing>
 ...
 <owl:Thing rdf:about="#KnifeSensorOutput_2355676">
   <rdf:type rdf:resource="#AccelerationSensorOutput"/>
   <rdfs:comment>An example of the acceleration sensor output produced by our ExampleWiTilt30Accelerometer. </rdfs:comment>
   <ssn:isProducedBy rdf:resource="#ExampleWiTilt30Accelerometer"/>
   <ssn:hasValue rdf:resource="#ZAxisAccelerationMeasurementValue"/>
 </owl:Thing>
 ...
 <AccelerationValue rdf:about="#ZAxisAccelerationMeasurementValue">
   <hasQuantityValue rdf:datatype="&xsd;float">0.98</hasQuantityValue>
 </AccelerationValue>
 
 
Snippet from smart-knife, Smart product example

The measurement value is expressed using the class AccelerationValue defined as a subclass of the class ssn:ObservationValue (see section Measurement Capability). In this example, the accelerometer (expressed by an instance #ExampleWiTilt30Accelerometer) measures the acceleration of the knife to which it is attached (#Knife_123). Thus, #Knife_123 plays the role of the feature of interest. In general, a feature of interest can be any real-world object the properties of which are observed by a sensor. This can be, e.g., a geographical point (for weather sensors), a piece of equipment (for diagnostic sensors), etc.

5.3.7 Deployment

This section describes creating a Deployment instance for a System object. The ssn:System class is an abstraction for parts of a sensing infrastructure. The ssn:Sensor class in the ontology provides the structure to represent a concrete sensing object. Sensor can represent any object with the sensing capability (e.g., in some cases a human observer can be also a sensor). However, in many scenarios the sensors are devices. The ssn:Device class describes a device and inherits all the properties of the ssn:System class. The following provides an overview of the main classes and properties related to deployment of a network of sensors in the ontology. The classes and properties are shown in the Figure.

• ssn:hasDeployment: Points to deployment description of sensor expressed as an instance of the ssn:Deployment class. The description of a Deployment refers to ssn:System and it is also a subclass of ssn:DeploymentRelatedProcess and inherits all the properties from this class.
• The ssn:DeploymentRelatedProcess class groups various Processes related to Deployment. For example, it includes installation, maintenance and deployment features.
• The ssn:System class for parts of a sensing infrastructure. A system has components, its subsystems, which are other systems. A system is deployed on a Platform.
• ssn:deployedOnPlatform points to platform on which the system is deployed.
• ssn:Platform includes different components that can be attached to Sensor and also different features such as measurement properties, operating properties and system settings.
• ssn:deployedSystem provides relation between a deployment and a deployed system.

Figure 5.18 - ssn:Deployment (Deployment module)

5.3.7.2 How to represent a deployment of a network of sensors?

A deployment of a system is created by defining an instance of the ssn:Deployment class.

A Platform can be used for multiple sensors. In the following OWL example, the defined Platform handles two sensors participating in a deployment scenario and belonging to the same system. The system is a sensor network node (a "mote") which includes a Temperature sensor and a Humidity sensor (this is allowed because SensingDevice is a sub-class of System).

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <!-- Deployment -->
 <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment">
  <ssn:deployedOnPlatform>
   <ssn:Platform rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform"/>
  </ssn:deployedOnPlatform>
  <ssn:deployedSystem>
   <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A deployment which includes a temperature and a humidity
    sensor on the same sensor network node.</rdfs:comment>
   </ssn:System>
  </ssn:deployedSystem>           
 </ssn:Deployment>
 <!-- Platform (and Operating conditions) -->
 <ssn:Platform rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform">
  <DUL:hasLocation>
   <DUL:PhysicalPlace rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#PhysicalPlace_UNiSTestBED-BA03A">
    <DUL:isLocationOf rdf:resource="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform"/>
   </DUL:PhysicalPlace>
  </DUL:hasLocation>
  </ssn:Platform>
  <!-- System (TelosB Mote) -->
  <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
   <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A sample sensor network node. The data is for
   TELOS-B product and the data sheet is available at: http://www.willow.co.uk/TelosB_Datasheet.pdf </rdfs:comment>
   <ssn:hasDeployment>
    <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment"/>
   </ssn:hasDeployment>
   <ssn:hasSubSystem>
    <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TemperatureSensor-TSB-ABC01">
     <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">The embedded temperature sensor. </rdfs:comment>
    </ssn:SensingDevice>
   </ssn:hasSubSystem>
  <ssn:hasSubSystem>
   <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#HumiditySensor-TSB-ABC01">
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">The embedded humidity sensor.</rdfs:comment>
   </ssn:SensingDevice>
  </ssn:hasSubSystem>
 </ssn:System>
 <!-- Temperature sensor -->
 <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TemperatureSensor-TSB-ABC01">
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A specific instance of temperature sensor. </rdfs:comment>
  <ssn:hasDeployment>
   <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment"/>
  </ssn:hasDeployment>
 <!-- Humidity sensor -->
 <ssn:SensingDevice rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#HumiditySensor-TSB-ABC01">
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A specific instance of humidity sensor. </rdfs:comment>
  <ssn:hasDeployment>
   <ssn:Deployment rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#ABC01Deployment"/>
  </ssn:hasDeployment>
 </ssn:SensingDevice>
 
 
Snippet from uni-deploy,  University deployment example

5.3.8 PlatformSite

The SSN ontology defines relationships between classes such as Deployment, System and Platform. However it does not provide some aspects such as spatial attributes for the Platform class. There are three options to represent locations.

When the DOLCE Ultra Lite alignment is enforced, a Platform is a DUL:Physical:Object and as such may have a DUL:hasLocation relation to a DUL:PhysicalPlace location. A PhysicalPlace is an abstraction of a real-world place. Hence, this option allows statements like: the sensor/platform hasLocation the eastern edge of the lake; the sensor/platform hasLocation room S323; the sensor/platform hasLocation car123; and the like.

As well as the relative locations above, DOLCE Ultra Lite also allows absolute locations. The location of an entity is an observable aspect of the entity and is thus a ssn:Property, properties have values (ssn:hasValue), represented as regions, in this case a DUL:SpaceRegion. Hence, a sensor or platform can be given, for example, an absolute latitude and longitude, a location relative to another co-ordinate, or any other sort of value for location. Of course, if this method is to be used often, sub properties of hasValue could be defined (e.g. hasLatLong, hasAbsoluteLocation, hasCoordinates, etc.) to provide descriptive names for locations, depending on the method used.

The third option is to define or import a further method for representing locations.

Relative locations are shown in the Figure 5.19.

Figure 5.19 - Using ssn:Platform in conjunction with dul:PhysicalPlace (PlatformSite module)

5.3.8.2 How to represent a site?

The following example shows how location attributes are defined for a platform by using concepts from the DOLCE Ultra Lite ontology.

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <ssn:Platform rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform">
  <DUL:hasLocation>
   <DUL:PhysicalPlace rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#PhysicalPlace_UNiSTestBED-BA03A">
    <DUL:isLocationOf rdf:resource="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#UNiS-TSBPlatform"/>
   </DUL:PhysicalPlace>
  </DUL:hasLocation>
 </ssn:Platform>
 
  
Snippet from uni-deploy,  University deployment example

5.3.9 OperatingRestriction

The operational and survival restrictions can be described for System. The operational properties are referred to by using ssn:hasOperatingRange, which in turn ssn:hasOperatingPropertys such as Maintenance Schedule and Operating Power Range. The survival properties are referred to by using ssn:hasSurvivalRange and include properties (ssn:hasSurvivalProperty) such as Battery Life Time and System Life Time.

The main classes and properties to describe the Operating Restrictions for a system are shown in Figure 5.20.

Figure 5.20 - ssn:OperatingRange and ssn:SurvivalRange (OperatingRestriction module)

ssn:SurvivalRange describes environmental conditions to which a sensor can be exposed without causing damage: i.e., the sensor continues to operate as defined using MeasurementCapability. If, however, the SurvivalRange is exceeded, the sensor could be 'damaged' and MeasurementCapability specifications may no longer hold. ssn:SurvivalRange is related to ssn:SurvivalProperty class by using ssn:hasSurvivalProperty.

ssn:SurvivalProperty represents the attributes that describe extent of the useful life of sensors.

ssn:OperatingRange describes the environmental conditions and attributes of a system/sensor's normal operating environment. It is related to ssn:OperatingProperty by using ssn:hasOperatingPropery.

ssn:OperatingProperty describes characteristic of the environmental and other conditions in which the sensor is intended to operate. This includes features such as power ranges, power sources, standard configurations, and attachments.

An Operational Restriction can be defined in a condition. inCondition ssn:inCondition relates a MeasurementCapability to a Condition.

ssn:Condition specifies ranges for qualities that act as conditions on a system/sensor's operation. For example, the accuracy features of a sensor represented by SurvivalRange and OperatingRange (see the next section) are defined in a certain temperature (e.g. 25 degree Celsius).

5.3.9.2 How to represent operational and survival conditions?

The following example describes the operating power range restriction for a Sensor Node system.

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
  <ssn:hasOperatingProperty>
   <ssn:OperatingPowerRange rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TSBOperatingPowerRange">
    <ssn:hasValue>
     <DUL:Amount rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#Current_Draw_Idle">
      <DUL:hasDataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">21 μA</DUL:hasDataValue>
       <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Current Draw in Idle mode</rdfs:comment>
       <DUL:isClassifiedBy>
        <DUL:UnitOfMeasure rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#microAmpere"/>
       </DUL:isClassifiedBy>
      </DUL:Amount>
     </ssn:hasValue>
    </ssn:OperatingPowerRange>
   </ssn:hasOperatingProperty>
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A sample platform description for sensors. 
  The data is for sample TELOSB sensors and the data sheet is available at: 
  http://www.willow.co.uk/TelosB_Datasheet.pdf</rdfs:comment>
 </ssn:System>
 
  
Snippet from uni-deploy,  University deployment example

The usage of ssn:Condition is the same as for Measurement Capabilities. A more complete example is provided in the Condition module documentation page.

5.3.10 Data

The two figures below shows two examples where the SSN ontology is used in conjunction with the DUL ontology to manage data.

Figure 5.21 shows how a ssn:ObservationValue which is a sub-class of DUL:Region is attached to a ssn:SensorOutput.

Figure 5.21 - Using ssn:hasValue for observation results (Data module)

5.3.10.2 How to attach a data value to a property?

Figure 5.22 shows how an example of how data value can be attached to a ssn:Property (here a ssn:OperatingPowerRange).

This example uses DUL:Amount, a subclass of DUL:Region which is the DUL class to handle a quantity value. The DUL:UnitOfMeasure can also be defined. In DUL, Units of measure are conceptualised as parameters on regions and defined as a subclass of DUL:Parameter.

Figure 5.22 - Using ssn:hasValue to add data to a operational restriction property (Data module)

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
   <ssn:OperatingPowerRange rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TSBOperatingPowerRange">
    <ssn:hasValue>
     <dul:Amount rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#Current_Draw_Idle">
      <dul:hasDataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">21</dul:hasDataValue>
      <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Current Draw in Idle mode</rdfs:comment>
      <dul:isClassifiedBy>
       <dul:UnitOfMeasure rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#microAmpere"/>
      </dul:isClassifiedBy>
     </dul:Amount>
    </ssn:hasValue>
   </ssn:OperatingPowerRange>
 
  
Snippet from uni-deploy,  University deployment example

5.3.11 ConstraintBlock (Condition)

ssn:Condition is used to specify ranges for qualities that act as conditions on a system/sensor's operation. For example, wind speed of 10-60m/s is expressed as a condition linking a quality, wind speed, a unit of measurement, metres per second, and a set of values, 10-60, and may be used as the condition on a MeasurementProperty, for example, to state that a sensor has a particular accuracy in that condition.

ssn:inCondition describes the prevailing environmental conditions for Measurement Capabilites, Operating Conditions and Survival Ranges. Used for example to say that a sensor has a particular accuracy in particular conditions (see also the MeasuringCapability module documentation).

Figure 5.23 - Classes using ssn:Condition in the SSN Ontology (ConstraintBlock (Condition) Module)

This is called 'Storage temperature' on the WM30 data sheet. The intention is likely to be the same as SurvivalRange: i.e. if the device is stored outside this temperature range it no longer works as specified.

In any case, for the purposes of the example it shows the use of ssn:Condition to specify a SurvivalRange.

Figure 5.24 - ssn:Condition ConstraintBlock (Condition) Module

  <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30">
  ...
  <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30#WM30_SurvivalRange">
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SurvivalRange"/>
   <rdfs:subClassOf>
    <owl:Restriction>
     <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#inCondition"/>
     <owl:someValuesFrom>
      <owl:Class>
       <owl:intersectionOf rdf:parseType="Collection">
        <owl:Class>
         <owl:oneOf rdf:parseType="Collection">
          <rdf:Description rdf:about="http://purl.oclc.org/NET/ssnx/qu/dim/Temperature"/>
         </owl:oneOf>
        </owl:Class>
        <owl:Restriction>
         <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasValue"/>
          <owl:someValuesFrom>
           <owl:Class>
           <owl:intersectionOf rdf:parseType="Collection">
            <rdf:Description rdf:about="http://purl.oclc.org/NET/ssnx/meteo/WM30#ValueRange"/>
            <owl:Restriction>
             <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/meteo/WM30#unitOfMeasure"/>
             <owl:someValuesFrom>
              <owl:Class>
               <owl:oneOf rdf:parseType="Collection">
                <rdf:Description rdf:about="http://purl.oclc.org/NET/ssnx/qu/unit/degreeCelsius"/>
               </owl:oneOf>
              </owl:Class>
             </owl:someValuesFrom>
            </owl:Restriction>
            <owl:Restriction>
             <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/meteo/WM30#hasRangeMaxValueInclusive"/>
             <owl:hasValue rdf:datatype="&xsd;float">65.0</owl:hasValue>
            </owl:Restriction>
            <owl:Restriction>
             <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/meteo/WM30#hasRangeMinValueInclusive"/>
             <owl:hasValue rdf:datatype="&xsd;float">-60.0</owl:hasValue>
            </owl:Restriction>
           </owl:intersectionOf>
          </owl:Class>
         </owl:someValuesFrom>
        </owl:Restriction>
       </owl:intersectionOf>
      </owl:Class>
     </owl:someValuesFrom>
    </owl:Restriction>
   </rdfs:subClassOf>
  </owl:Class>
 
 
Snippet from: WM30, Wind sensor example

5.3.12 Device

In most scenarios the sensors are implemented as devices. The class ssn:Device describes an abstract device and inherits all the properties of the class ssn:System (subcomponents, platform to which a system is attached, deployment in which a system participates, operating and survival range). All physical sensor devices are represented by the class ssn:SensingDevice in the ontology. Instances of this class possess all properties of the classes ssn:Sensor and ssn:Device.

This module only has one class ssn:Device which lies in an intermediate position in the class hierarchy as shown in Figure 5.25. Generally, instance of ssn:SensorDevice will be created. An example of device is included in the Measuring module documentation and is used in the MeasuringCapability module documentation to illustrate how a ssn:MeasurementCapability can be specified.

Figure 5.25 - ssn:SensingDevice (Device module)

5.3.13 Energy

This module is a placeholder for possible extensions for SSN ontology users wishing to model the energy management aspects of a sensor network. It contains two classes ssn:BatteryLifetime and ssn:OperatingPowerRange.

5.3.13.2 How to represent a WSN node and its energy components

Figure 5.26 shows how to specialise the ssn:Device to add the energy-focused elements of a system, in this case the battery, solar panel and board of a wireless sensor network node.

Figure 5.26 - Energy device (Energy module)

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy">
 ...
 <!-- A Wsn Node Example (Classes) -->
 <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#SolarPanel">
  <rdfs:subClassOf>
   <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#EnergyDevice"/>
  </rdfs:subClassOf>
 </owl:Class>
 <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#Board">
  <rdfs:subClassOf>
   <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#EnergyDevice"/>
  </rdfs:subClassOf>
 </owl:Class>
 <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#Battery">
  <rdfs:subClassOf>
   <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#EnergyDevice"/>
  </rdfs:subClassOf>
 </owl:Class>
 <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#EnergyDevice">
  <rdfs:subClassOf>
   <owl:Class rdf:about="http://purl.oclc.org/NET/ssnx/ssn#Device"/>
  </rdfs:subClassOf>
 </owl:Class>
 <!-- A Wsn Node Example (instances) -->
 <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#WsnNode">
  <ssn:hasSubSystem>
   <energy:Board rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#WsnNodeBoard"/>
  </ssn:hasSubSystem>
  <ssn:hasSubSystem>
   <energy:Battery rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#Panasonic_VRLA_LC-R121R3P"/>
  </ssn:hasSubSystem>
  <ssn:hasSubSystem>
   <energy:SolarPanel rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#WsnNodeSolarPanel"/>
  </ssn:hasSubSystem>
  <ssn:implements>
   <ssn:Process rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#Process111">
    <ssn:hasOutput>
     <ssn:Output rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#BatteryVoltage12VBattery"/>
      <dul:hasParameter>
       <dim:ElectricPotentialUnit rdf:about="http://purl.org/NET/ssnx/qu/unit#millivolt"/>
      </dul:hasParameter>
     </ssn:Output>
    </ssn:hasOutput>
    <dul:hasQuality>
     <dim:ElectricPotential rdf:about="http://purl.org/NET/ssnx/qu/quantity#voltage"/>
    </dul:hasQuality>
   </ssn:Process>
  </ssn:implements>
 </ssn:System>
 
 
Snippet from ssn-energy

5.3.13.3 How to represent a WSN node with information about its energy consumption

The example below illustrates how to define the lifespan of a battery in function of the current drawn from it. Generally, more than one ssn:BatteryLifetime instance will be used to model how the battery performs in various conditions. Figure 5.27 shows how to define a lifetime of 20 hours for a sensor node battery when it is used to deliver an electric current of 65 milliamperes.

Figure 5.27 - ssn:BatteryLifetime (Energy module)

  <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy">
  ...
  <energy:Battery rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#Panasonic_VRLA_LC-R121R3P">
   <ssn:hasSurvivalProperty>
   <ssn:BatteryLifetime rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#Panasonic_VRLA_LC-R121R3P_20hours">
    <ssn:inCondition>
     <dim:ElectricCurrentRate rdf:about="http://purl.org/NET/ssnx/qu/quantity#electricCurrentRateFor20Hours">
     <ssn:hasValue>
      <dul:Amount rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#rateFor20Hours">
       <dul:hasDataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">65</dul:hasDataValue>
        <dul:isClassifiedBy>
         <dim:ElectricCurrentRateUnit rdf:about="http://purl.org/NET/ssnx/qu/unit#milliAmpere"/>
        </dul:isClassifiedBy>
       </dul:Amount>
      </ssn:hasValue>
     </dim:ElectricCurrentRate>
    </ssn:inCondition>
    <ssn:hasValue>
     <dul:Amount rdf:about="http://purl.oclc.org/NET/ssnx/ssn/energy/ssn-energy#Lifespan20Hours">
      <dul:hasDataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">20</dul:hasDataValue>
       <dul:isClassifiedBy>
        <dim:DurationUnit rdf:about="http://purl.org/NET/ssnx/qu/unit#hour"/>
       </dul:isClassifiedBy>
      </dul:Amount>
     </ssn:hasValue>
    </ssn:BatteryLifetime>
   </ssn:hasSurvivalProperty>
  </energy:Battery>
  
 
Snippet from ssn-energy

5.3.13.4 How to represent the operating power range of a sensor

This is an extract of the SSN-Uni deployment which shows how this can be done.

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy">
 ...
 <ssn:System rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#SN-Node-TSB-ABC01">
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A sample sensor network node. The data is for TELOS-B product and the data sheet is available at: http://www.willow.co.uk/TelosB_Datasheet.pdf</rdfs:comment>
  <ssn:hasOperatingProperty>
   <ssn:OperatingPowerRange rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#TSBOperatingPowerRange">
    <ssn:hasValue>
     <dul:Amount rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#Current_Draw_Idle">
      <dul:hasDataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">21</dul:hasDataValue>
      <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Current Draw in Idle mode</rdfs:comment>
      <dul:isClassifiedBy>
       <dul:UnitOfMeasure rdf:about="http://purl.oclc.org/NET/ssnx/uni/uni-deploy#microAmpere"/>
      </dul:isClassifiedBy>
     </dul:Amount>
    </ssn:hasValue>
   </ssn:OperatingPowerRange>
  </ssn:hasOperatingProperty>
 </ssn:System>
 
  
Snippet from uni-deploy,  University deployment example

5.4 Additional examples

The five examples developed by the group members are further described below to demonstrate the diversity of contexts in which the Semantic Sensor Network Ontology can be used and the complementarity of the SSN and the DUL ontologies. The objective here is to highlight the versatility of the SSN ontology, its capability to be used in conjunction with various external ontologies (e.g. ontologies for units of measurement) and to be further extended to specific domains of application (e.g. Agriculture Meteorology).

Readers wishing to further study these examples can consult the additional references included in this report and find more resources on the group wiki, using:

• the tagged bibliography collection,
• the wiki page listing the publications and the talks delivered by the group members.

5.4.1 University deployment example

Sensor descriptions, sensor deployment platforms, and operational and survival conditions can be related to other spatial, temporal and thematic data. Figure 5.28 demonstrates this in the context of the SENSEI project. In this work the sensor platform descriptions are associated to location data obtained from open linked-data (i.e. in particular by querying DBPedia SPARQL end-points). The sensor platform and location data are then used to demonstrate sensor information on an overlay Google Map mash-up application.

Figure 5.28 - University deployment example: sensor data mashup

The sensor platform location data in this example is defined as linked-data location information and is also associated to local location ontology descriptions. This enables navigation through a set of linked sensor data and querying sensors based on their deployment and other attributes as well as their physical locations.

---

Available resources:

• OWL file: uni-deploy.
• Paper: [Barnaghi and Presser 2010], Publishing Linked Sensor Data.

---

The following figures provide an overview of the modules of the SSN ontology which are illustrated by this example.

5.4.1.2 Deployment

Figure 5.29 illustrates how the Deployment, System, Platform, OperatingPowerRange and SensingDevice classes are used. More information about this part of the example is available on Deployment module documentation page.

Figure 5.29 - University example - Deployment (uni-deploy)

5.4.1.3 Sensor

Figure 5.30 shows how Measuring Capabilities are defined. For more information, see the documentation pages for the MeasuringCapability module and the Condition module.

Figure 5.30 - University example - Sensors (uni-deploy)

5.4.2 Smart product example

This is an example on a demo from the SmartProducts project scenario involving an accelerometer sensor. The SmartProducts project deals with consumer products which possess sensing, reasoning, and communicating capabilities.

In our example, there is a knife equipped with an accelerometer sensor which recognises when the user is cutting something. The observations are passed to a "cooking assistance" device which guides the user through the cooking process and recognises from the user actions that a certain step was performed (e.g., "the user stopped to cut vegetables").

The sensor modelled in this example is a WiTilt 3.0 accelerometer. It has 4 possible measurement ranges (+/-1.5g, +/-2g, +/-4g, +/-6g) and 4 possible frequency modes (50 Hz max in degree mode, 135 Hz max in gravity mode, 220 Hz max in raw ADC mode, 610 Hz max in binary mode).

This example is used to document the Measuring module and MeasuringCapability module - see Figure 5.31 showing only a subset of the the possible measurement modes with one range and one frequency) and the Observation module (Figure 5.32).

---

Available resources:

• OWL file: smart-knife.
• Position paper: [Sabou et al. 2009] Realizing Smart Products: Challenges for Semantic Web Technologies.

---

5.4.2.2 Sensor

Figure 5.31 - Smart product example: Sensor (smart-knife)

The sensor in our example is implemented as a mechanical device. Thus, in order to represent this sensor, we need to create an instance of the class ssn:SensingDevice. However, in our case we want to model all sensors measuring a specific property (acceleration) and also all sensors of a specific model (WiTilt 3.0). In order to do it, we create the class Accelerometer as a subclass of the class ssn:SensingDevice.

 <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/product/smart-knife">
 ...
 <owl:Class rdf:about="#Accelerometer">
  <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensingDevice"/>
  <rdfs:subClassOf>
   <owl:Restriction>
    <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observes"/>
    <owl:hasValue rdf:resource="http://purl.oclc.org/NET/muo/ucum/physical-quality/acceleration"/>
   </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:comment>Accelerometer is a subclass of sensing devices which measures acceleration. 
  The individual describing a physical quality "acceleration" is defined in the imported MyMobileWeb ontology 
  of measurement units. To align the MyMobileWeb ontology with the SSN ontology, the class muo:PhysicalQuality 
  from the MyMobileWeb ontology is defined as a subclass of the class ssn:Property.</rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife

Note that we imported an external ontology (MyMobileWeb Measurement Units Ontology) describing physical properties and units of measurement. The SSN ontology itself does not contain its own model for these concepts and does not restrict the user in the choice of an ontology to model them.

Having the generic class of accelerometer sensors, we create a subclass representing accelerometers of a certain model (WiTilt 3.0).

 <owl:Class rdf:about="#WiTilt30Accelerometer">
  <rdfs:subClassOf rdf:resource="#Accelerometer"/>
  <rdfs:subClassOf>
   <owl:Restriction>
    <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementCapability"/>
    <owl:allValuesFrom rdf:resource="#WiTilt30AccelerationMeasurementCapability"/>
   </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:comment>This class describes WiTilt v3.0 accelerometers. 
  All possible configurations of their measurement capabilities are defined using
  the class WiTilt30AccelerationMeasurementCapability, so the property ssn:hasMeasurementCapability 
  is restricted to instances of this class.</rdfs:comment>
</owl:Class>
</nowiki>

  
Snippet from smart-knife

Then, we can define an instance of this class which will represent our specific WiTilt 3.0 accelerometer attached to a knife.

 <owl:Thing rdf:about="#ExampleWiTilt30Accelerometer">
  <rdf:type rdf:resource="#WiTilt30Accelerometer"/>
  <rdfs:comment>A specific instance of a WiTilt 3.0 accelerometer attached to a knife.</rdfs:comment>
  <ssn:hasMeasurementCapability rdf:resource="#ExampleWiTiltAccelerometerMeasurementCapability"/>
  <ssn:onPlatform rdf:resource="#Knife_123"/>
 </owl:Thing>

  
Snippet from smart-knife

Our accelerometer is attached to a knife in order to capture its movements. Thus, a knife in this example serves both as a platform, on which the sensor is installed, and a feature of interest observed by the sensor.

 <ssn:FeatureOfInterest rdf:about="#Knife_123">
   <rdf:type rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Platform"/>
   <rdfs:comment>An example knife with an attached WiTilt 3.0 accelerometer. It belongs to both ssn:Platform and ssn:Feature
                 because it is both the platform of the sensor and the feature being observed by the sensor.</rdfs:comment>
 </ssn:FeatureOfInterest>
 
  
Snippet from smart-knife

5.4.2.3 Measurement capabilities

In the description above, we specified that the class WiTilt30Accelerometer must have a value for the property ssn:hasMeasurementCapability belonging to the class WiTilt30AccelerationMeasurementCapability. This class defines possible configurations of measurement capabilities for WiTilt 3.0 accelerometers: measurement ranges (+/-1.5g, +/-2g, +/-4g, +/-6g) and frequency modes (50 Hz, 135 Hz, 220 Hz, 610 Hz).

 <owl:Class rdf:about="#WiTilt30AccelerationMeasurementCapability">
   <rdfs:label>WiTilt 3.0 acceleration measurement capability</rdfs:label>
   <rdfs:subClassOf rdf:resource="#AccelerationMeasurementCapability"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementProperty"/>
       <owl:onClass rdf:resource="#WiTilt30MeasurementRange"/>
       <owl:qualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:qualifiedCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementProperty"/>
       <owl:onClass rdf:resource="#WiTilt30MeasurementFrequency"/>
       <owl:qualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:qualifiedCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
 </owl:Class>
 
  
Snippet from smart-knife

To express possible measurement ranges, we define a subclass of the class ssn:MeasurementRange:

 <owl:Class rdf:about="#WiTilt30MeasurementRange">
   <rdfs:label>WiTilt 3.0 measurement range</rdfs:label>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#MeasurementRange"/>
   <rdfs:comment>
   This class defines possible measurement ranges of a WiTilt 3.0 accelerometer sensor. 
   These sensors can be calibrated to measure acceleration in the ranges of +/-1.5g, +/-2g, +/-4g and +/-6g. 
   These four ranges are expressed using instances of this class: WiTilt30MeasurementRange_1...WiTilt30MeasurementRange_4. 
   Because the SSN ontology does not specify how the values of measurement properties should be expressed, 
   three properties are introduced: hasMeasurementPropertyValue (for exact values), hasMeasurementPropertyMaxValue 
   (for maximal values), and hasMeasurementPropertyMinValue (for minimal values).
   </rdfs:comment>
 </owl:Class>
Then, we define four instances of this class corresponding to each measurement range:
 <owl:Thing rdf:about="#WiTilt30MeasurementRange_1">
   <rdf:type rdf:resource="#WiTilt30MeasurementRange"/>
   <hasMeasurementPropertyMaxValue rdf:resource="#WiTilt30MeasurementRange_1MaxValue"/>
   <hasMeasurementPropertyMinValue rdf:resource="#WiTilt30MeasurementRange_1MinValue"/>
 </owl:Thing>
 ...
 <owl:Thing rdf:about="#WiTilt30MeasurementRange_1MaxValue">
   <rdf:type rdf:resource="#AccelerationValue"/>
   <hasQuantityValue rdf:datatype="&xsd;float">1.5</hasQuantityValue>
 </owl:Thing>
 ...
 <owl:Thing rdf:about="#WiTilt30MeasurementRange_1MinValue">
   <rdf:type rdf:resource="#AccelerationValue"/>
   <hasQuantityValue rdf:datatype="&xsd;float">-1.5</hasQuantityValue>
 </owl:Thing>
 
  
Snippet from smart-knife

Note that the sensor ontology does not restrict the way in which specific measurement properties are described. In our example, we defined our own RDF properties to define values of measurement properties (hasMeasurementPropertyMinValue, hasMeasurementPropertyValue, hasMeasurementPropertyValue) and defined a subclass AccelerationValue of the class ssn:ObservationValue. For this class, we defined properties hasQuantityValue and hasQuantityUnitOfMeasurement and restricted the property hasQuantityUnitOfMeasurement:

 <owl:Class rdf:about="#AccelerationValue">
   <rdfs:label>Acceleration value</rdfs:label>
   ...
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#hasQuantityUnitOfMeasurement"/>
       <owl:hasValue rdf:resource="http://purl.oclc.org/NET/muo/ucum/unit/acceleration/standard-acceleration-of-free-fall"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:comment>Acceleration value measured in g - standard acceleration of free fall.</rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife

In the same way, we define possible output frequency values:

 <owl:Class rdf:about="#WiTilt30MeasurementFrequency">
   <rdfs:label>WiTilt 3.0 measurement frequency</rdfs:label>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Frequency"/>
   <rdfs:comment>This class describes maximal output frequency values of WiTilt 3.0 accelerometers in four modes: 
         degree mode (50Hz), gravity mode (135Hz), raw ADC mode (220Hz), and binary mode (610Hz). 
   </rdfs:comment>
 </owl:Class>
 ...
 <WiTilt30MeasurementFrequency rdf:about="#WiTilt30BinaryModeFrequency">
   <hasMeasurementPropertyValue rdf:resource="#WiTilt30BinaryModeFrequencyValue"/>
 </WiTilt30MeasurementFrequency>
 ...
 <owl:Thing rdf:about="#WiTilt30BinaryModeFrequencyValue">
   <rdf:type rdf:resource="#FrequencyValue"/>
   <hasQuantityValue rdf:datatype="&xsd;float">610</hasQuantityValue>
 </owl:Thing>
 ...
 <owl:Class rdf:about="#FrequencyValue">
   <rdfs:label>Frequency value</rdfs:label>
   ...
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#hasQuantityUnitOfMeasurement"/>
       <owl:hasValue rdf:resource="http://purl.oclc.org/NET/muo/ucum/unit/frequency/Herz"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:comment>Frequency value measured in Hz.</rdfs:comment>
 </owl:Class>
 
  
Snippet from smart-knife

Now, we assume that our example sensor attached to a knife operates in the binary output mode and has its measurement range set to +/-1.5g. As shown above, its measurement capabilities are described using the instance ExampleWiTiltAccelerometerMeasurementCapability. This instance is defined in the following way:

 <owl:Thing rdf:about="#ExampleWiTiltAccelerometerMeasurementCapability">
   <rdf:type rdf:resource="#WiTilt30AccelerationMeasurementCapability"/>
   <ssn:hasMeasurementProperty rdf:resource="#WiTilt30BinaryModeFrequency"/>     
   <ssn:hasMeasurementProperty rdf:resource="#WiTilt30MeasurementRange_1"/>
 </owl:Thing>
 
  
Snippet from smart-knife

5.4.2.4 Observation

Figure 5.32 - Smart product example: Observation (smart-knife)

In this section, we describe an example of an observation which our sensor can produce. An observation is represented by an instance of the class ssn:Observation. To describe acceleration observations, we define the class AccelerationObservation as a subclass of the class ssn:Observation.

 <owl:Class rdf:about="#AccelerationObservation">
   <rdfs:label>Acceleration observation</rdfs:label>
   <rdfs:comment>A class describing acceleration observations. Properties ssn:observationResult, ssn:observedBy, and 
                 ssn:observedProperty are restricted accordingly.</rdfs:comment>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Observation"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observationResult"/>
       <owl:allValuesFrom rdf:resource="#AccelerationSensorOutput"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observedBy"/>
       <owl:allValuesFrom rdf:resource="#Accelerometer"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observedProperty"/>
       <owl:hasValue rdf:resource="&ucum;physical-quality/acceleration"/>
     </owl:Restriction>
   </rdfs:subClassOf>
 </owl:Class>
 
  
Snippet from smart-knife

Moreover, we define the class AccelerationSensorOutput as a subclass of the class ssn:SensorOutput to represent results of acceleration observations.

 <owl:Class rdf:about="#AccelerationSensorOutput">
   <rdfs:label>Acceleration sensor output</rdfs:label>
   <rdfs:comment>A class describing sensor output for acceleration measurements. 
   Properties ssn:hasValue and ssn:isProducedBy are restricted accordingly.</rdfs:comment>
   <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensorOutput"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#hasValue"/>
       <owl:allValuesFrom rdf:resource="#AccelerationValue"/>
     </owl:Restriction>
   </rdfs:subClassOf>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#isProducedBy"/>
       <owl:allValuesFrom rdf:resource="#Accelerometer"/>
     </owl:Restriction>
   </rdfs:subClassOf>
 </owl:Class>
 
  
Snippet from smart-knife

Then, having these subclasses, we can represent the results produced by our accelerometer. For example, it captured a movement of the knife with the acceleration of 0.98g. This observation can be encoded using the following three instances:

 <owl:Thing rdf:about="#KnifeCuttingObservation_435782677">
   <rdf:type rdf:resource="#AccelerationObservation"/>
   <rdfs:comment>An example of the acceleration observation produced by our ExampleWiTilt30Accelerometer. </rdfs:comment>
   <ssn:observationResult rdf:resource="#KnifeSensorOutput_2355676"/>
   <ssn:featureOfInterest rdf:resource="#Knife_123"/>
   <ssn:observedBy rdf:resource="#ExampleWiTilt30Accelerometer"/>
 </owl:Thing>
 ...
 <owl:Thing rdf:about="#KnifeSensorOutput_2355676">
   <rdf:type rdf:resource="#AccelerationSensorOutput"/>
   <rdfs:comment>An example of the acceleration sensor output produced by our ExampleWiTilt30Accelerometer. </rdfs:comment>
   <ssn:isProducedBy rdf:resource="#ExampleWiTilt30Accelerometer"/>
   <ssn:hasValue rdf:resource="#ZAxisAccelerationMeasurementValue"/>
 </owl:Thing>
 ...
 <AccelerationValue rdf:about="#ZAxisAccelerationMeasurementValue">
   <hasQuantityValue rdf:datatype="&xsd;float">0.98</hasQuantityValue>
 </AccelerationValue>
 
  
Snippet from smart-knife

5.4.3 Wind sensor (WM30)

The Vaisala WM30 wind sensor measures wind speed and direction. The WM30 has two options for wind direction: the WMS301 and the WMS302, which have different measurement ranges. The accuracy of its wind speed measurements is condition dependent: accuracy of +-3m/s at low wind speed and +-2% at higher wind speeds.

Thus, as an example, it shows how to describe a device with multiple sensing capabilities, how to describe the multiple subtypes of the same device and how to describe accuracy (or other properties) relative to prevailing conditions. Further, it shows the detail that can be expressed through the accuracy, as both relative and absolute error, and through different properties for the two wind speed options.

---

Available resources:

• OWL file: WM30
• Paper: [Compton et al. 2009b]
  Reasoning about Sensors and Composition (using CSIRO ontology)

---

5.4.3.2 Wind Sensor system

The WM30 is a device (a piece of hardware and embedded software 260x300mm); however, for the purposes of the example, the two parts of the WM30 are left underspecified. The specification isn't concerned if the wind speed and direction sensors are devices or not. If they were separable from the WM30 and usable separately they should each be modelled as devices. As it stands, the WM30 is a single device with two sensing capabilities that aren't separable from the device; hence they are just modelled as sensors that implement sensing (the use of hasSubSystem means they must be Systems, which is fair enough as they are pieces of technology).

Figure 5.33 - Wind Sensor example: System (WM30)

5.4.3.3 Specification of the method used in the Wind Sensor

The wind speed sensor uses a known formula to convert the speed of the cups to an observation of wind speed. Here we detail the formula and specify that all WM30 devices implement this sensing method.

Figure 5.34 - Wind Sensor example: Sensing method (WM30)

5.4.3.4 Operating Range

WM30 devices are rated to operate between -40 and +55 degrees C. Here we model this environmental operating condition along with a power input requirement as the device's operating range.

Figure 5.35 - Wind Sensor example: Operating range (WM30)

The WM30 example also shows how to enter more than one Measurement Capability value for a given property: with wind speed 0.4--10m/s the WM30's accuracy is +-3m/s, while from 10m/s to 60m/s it's +-2%. See the WM30_WindSpeed concept in the example which has the two measurement capabilities ("WSless10ms" and "WSgt10ms") and the conditions under which they apply.

5.4.3.5 Survival Range

Similarly, the device should not be subjected to temperature extremes outside -60 to +65 degrees C. This is modelled as a survival range to state that if exposed to such conditions the device no longer operates as specified.

Figure 5.36 - Wind Sensor example: Survival range (WM30)

5.4.3.6 Wind Feature and properties

This example also includes a definition for Wind as a Feature of Interest with two properties: wind direction and wind speed.

Figure 5.37 - Wind Sensor example: Feature of interest (WM30)

5.4.4 Agriculture Meteorology Sensor Network

5.4.4.1 The Agriculture Meteorology ontology (phenonet)

The Phenonet project led by the High Resolution Plant Phenomics Centre is using CSIRO-developed smart sensor nodes to record microclimate and plant data in the field in an effort to select new plant varieties suited to difficult growing conditions.

The Phenonet sensor network system uses a range of different micro-climate sensors such as automatic weather stations, solar radiation and photosynthetically active radiation sensors, soil moisture and soil temperature sensors, and infrared thermometers to measure leaf temperature.

The example presented here serves two purposes:

• to showcase the addition to the SSN ontology of "sensor type" definitions for the Agriculture Meteorology domain, and the dependency of these definitions on feature and property definitions,
• to serve as the source of definitions for the application software developed for the sensor network and for other applications exploiting the data generated by the sensors.

In field experiments, different kinds of sensors may be combined to serve the scientific objectives of a sensor network deployment. For example, different soil moisture sensors can be used to record the soil moisture at different depths or a master weather station can be used in conjunction with less expensive temperature sensors to record the temperature in several locations.

This example uses an ontology derived from the Automatic Weather Station taxonomy proposed by WMO experts for the specification of AWS Metadata catalogue, some feature and property definitions from the Climate and Forecast Metadata Conventions and a quantity and unit of measurement ontology, extending the SysML QUDV ontology with data sourced from UN/CEFACT recommendation 20.

This example also shows how output variables can be defined as a list of independent processes implemented by each sensor. This specification captures some of the information required to program the software modules run on the sensor nodes and to provide the data to the end user after its capture. More information on this second use case is provided in the Process module documentation.

---

Available resources:

• OWL file: phenonet

---

5.4.4.1.1 Sensor selection

Figure 5.38 shows how the SSN ontology can be extended to specify the sensors, properties and features of the Phenonet system so that it is possible to answer questions such as "which sensor can provide data about a particular feature?". On the left side of the figure, the classes with a name starting with aws: belong to the Automatic Weather Station ontology which provides a taxonomy of the different types of sensors which can be used in Agriculture Meteorology. On the middle and right hand side of the figure, the classes and individuals with a name starting with cf: and cf-features: belong to the Climate and Forecast ontologies.

Figure 5.38 - Agriculture meteorology example: sensors and features (phenonet)

5.4.4.1.2 System view

Figure 5.39 below shows an example of an Automatic Weather Station based on the Vaisala WXT 520 model.

It shows the weather station as a system and the relation to its subsystems (sensors) which perform the different sensing tasks and collect the following variables: pressure, temperature, humidity, wind speed and direction, and rain intensity and volume. In the model we use, the pressure, temperature, and humidity sensors are combined in a specific sub-system (PTU). This sub-system is not represented here.

The sensor type hierarchy for the different types of sensors included in this Weather Station model is also pictured. And for each instance of a sensor, the relation to the type of observed property is defined using the definitions from the Climate and Forecast standard names vocabulary.

Figure 5.39 - Agriculture meteorology example: weather station (phenonet)

5.4.4.1.3 Sensor view

The definition of the UltrasonicWindSensor presented in Figure 5.40 is sourced from the Automatic Weather Station ontology (aws.xml). In the example below, the UltrasonicWindSensor class is defined as a Sensor which observes SpeedOrVelocity (wind speed) or Angle (wind direction). In this approach where the sensor classes definitions use the generic quantities from the QU ontologies and not the domain-specific properties defined in the CF ontologies. This solution based on generic dimensions has been preferred because:

• in many cases, the only information available about the type of a sensor is the unit of measurement used for its outputs,
• it separates the class definitions from the instances definitions (in phenonet)

Figure 5.40 - Agriculture meteorology example: ultrasonic wind sensor (phenonet)

Figure 5.41 shows how the Process class is refined to model the specification of a sensor as something which produces outputs. The types of variables and their units are required to enable the generation of software modules used to program the sensor network. The same information may also be attached to the SensorOutput but only after the data has been collected (through an Observation Result).

Figure 5.41 - Agriculture meteorology example: wind sensing process (phenonet)

5.4.4.2 External ontologies

5.4.4.2.1 Automatic Weather Station ontology

The sensor taxonomy for the Agriculture Meterology domain is brought by the Automatic Weather Station ontology (aws.xml). Figure 5.42 below shows a subset of the class hierarchy defined by this ontology for the different types of sensors used in Agriculture Meteorology: Radiation, Temperature, Atmospheric pressure, Wind, Humidity and Precipitation measurements.

Figure 5.42 - Agriculture meteorology example: AWS ontology (aws)

The Automatic Weather Station ontology is mainly based on the technical literature published by the World Meteorological Organisation (WMO).

---

Available resources:

• OWL file: AWS and WMO AWS Metadata catalogue

---

Additional information:

Amongst other things, it reuses the outputs of the June 2010 meeting by WMO working group on Automatic Weather Stations:

• Input document list
• Output document list

Especially the content of these two documents:

• WMO AWS Metadata catalogue or pdf version available via [1] proposed extensions of the list of sensors types
• BUFR Descriptors Related to AWS (Doc. 10.1) list of variables for each category of measurement (also hydro and marine observations e.g. discharge) with definitions which are mappable to CF

These definitions are a follow-up of earlier work done at WMO and elsewhere. Here are some extra references which provides some extra information on the Agriculture Meteorology domain and on specific sensor categories:

• WMO Guide to Agricultural Meteorological Practices (GAMP) Draft 3rd Edition (WMO-No.134) (chapter 2)
• Darnhofer Meteorological elements and their observations
• Charlesworth Soil Water Monitoring, Irrigation Insights 2nd edition
• WMO Field Intercomparison of Rainfall Intensity (RI) Gauges
• WMO CIMO Guide (extract on Pressure sensors)

---

5.4.4.2.2 CF (Climate and Forecast) ontologies

The Automatic Weather Station ontology relies on domain-specific definitions sourced from the Climate and Forecast Metadata Conventions , which includes a collection of standard names for climatic data variables. Jonathan Gregory, one of the curators of this vocabulary, has published a CF grammar which aims at a "comprehensive and systematic description of the existing names". This work has been leveraged here to identify the core feature types and instances sourced used by the CF community, which are presented in Figure 5.43.

Figure 5.43 - Agriculture meteorology example: CF features (cf-feature)

Figure 5.44 shows how ssn:hasProperty is used to link the CF features to the CF properties and how CF properties are defined as instance of the quantity classes defined in the QU ontologies. This linkage was an important criterion in the choice of a unit of measurement and quantity ontology (see discussion below).

Figure 5.44 - Agriculture meteorology example: CF properties (cf-property)

---

Available resources:

• OWL file: cf-property and Climate and Forecast Metadata Conventions
• OWL file: cf-feature and CF grammar

---

5.4.4.2.3 Units of measurement and quantity ontologies

The QU and QU-Rec20 ontologies apply the QUDV specification issued by the SysML 1.2 Revision Task Force (RTF). The instance data is derived from a range of resources (see QU Rec 20 for a complete list), including the UN/CEFACT Recommendation 20 which is a list of codes for international commerce.

Figure 5.45 shows how the quantities and unit of measurement are managed in the QU and QU-Rec20 ontologies. For each dimension (Length, Mass, SpeedOrVelocity, Pressure, ...), two classes are defined, one for the quantity kind and one for the unit. The figure shows how additional quantities can be defined as instances and linked using the generalisation property to the root quantity. A single "base" unit of measurement is defined for each dimension and is used as the reference for the conversion of the other available units belonging to the same dimensional category.

Figure 5.45 - Agriculture meteorology example: quantity and unit of measurement (qu and qu-rec20)

---

Available resources:

• OWL file: qu, documentation and QUDV web site
• OWL file: qu-rec20 and UN/CEFACT recs

---

Additional information:

We could also have used:

• QUDT developed by the Nexiom project (NASA, TopQuadrant): QUDT - Quantities, Units, Dimensions and Data Types in OWL and XML
• or Ontology of units of Measure (OM): om-1.6 developed by a team of researchers at Wageningen UR (wurvoc.org)

According to Hans Peter de Koning, QUDV and QUDT are both being considered as input for the work by OASIS on a Quantities and Units of Measure Ontology Standard (QUOMOS) which was not available at the time this example was developed.

---

5.4.5 Sensor Discovery on Linked Data

This example shows how the SSN Ontology can be applied to extend the work done at the Ohio Center of Excellence in Knowledge Enabled Computing (Kno.e.sis) on sensor discovery, linked sensor data and sensor data provenance.

---

Available resources:

• OWL file: station
• Paper: [Pschorr et al. 2010] Sensor Discovery on Linked Data
• Paper: [Patni et al. 2010a] Linked Sensor Data
• Paper: [Patni et al. 2010b] Provenance Aware Linked Sensor Data

---

Additional information:

• Semantic Sensor Web
• Linked Sensor Data
• Provenance Aware Linked Sensor Data
• Provenir Ontology

---

5.4.5.2 Sensor Discovery

There has been a drive recently to make sensor data accessible on the Web. However, because of the vast number of environmental sensors, finding relevant sensors on the Web is a non-trivial challenge.

Figure 5.46 presents an application developed by Kno.e.sis ([Pschorr et al. 2010]) where users can type in a location of interest in the search box provided at the top of the page. The application provides an auto suggest list of locations that have sensors nearby. Once the user clicks on a location, all the sensors located nearby are displayed on a map. Users can click to get more information about the sensor, such as the sensor capabilities, coordinates and also current weather observations.

Figure 5.46 - Linked sensor data example: a sensor being discovered at a named location

This approach for discovering sensors uses a standard service interface to query Linked Sensor Data, a semantic sensor network middleware that includes a sensor registry and a sensor discovery service that extends the OGC Sensor Web Enablement.

The application gives access to the following datasets sourced from MesoWest, a project within the Department of Meterology at the University of Utah that has been aggregating weather data since 2002:

• MesoWest/Kno.e.sis Sensor Observation Dataset - This RDF dataset contains expressive descriptions of hurricane and blizzard observations in the United States. observations collected include measurements of phenomena such as temperature, visibility, precipitation, pressure, wind speed, humidity, etc. The dataset includes observations within the entire United States during the time periods that several major storms were active -- including Hurricane Katrina, Ike, Bill, Bertha, Wilma, Charley, Gustav, and a major blizzard in Nevada in 2002. These observations are generated by weather stations described in the MesoWest/Kno.e.sis Sensor Description Dataset introduced below. Currently, this dataset contains around one-billion triples.
• MesoWest/Kno.e.sis Sensor Description Dataset - This RDF dataset, originated at MesoWest contains expressive descriptions of ~20,000 weather stations in the United States. On average, there are about five sensors per weather station measuring phenomena such as temperature, visibility, precipitation, pressure, wind speed, humidity, etc. In addition to location attributes such as latitude, longitude, and elevation, there are also links to locations in Geonames that are near each weather station. This sensors description dataset is now part of the LOD.

5.4.5.3 Linking Sensor Data to other resources of the LOD cloud

This intuitive discovery is possible by linking concepts from Linked Sensor Data knowledge base to concepts in GeoNames knowledge base. This linking of concepts is a fundamental principle of Linked Data. A number of government, corporate, and academic organizations are collecting enormous amounts of data provided by environmental sensors. However, this data is too often locked within organizations and underutilised by the greater community. This is accomplished by converting raw sensor observations to RDF and linking with other datasets on LOD. With such a framework, organizations can make large amounts of sensor data openly accessible, thus allowing greater opportunity for utilisation and analysis.

The Linked Sensor Data resource produced by Kno.e.sis enables sensor data to be openly accessible on the Linked Open Data (LOD) Cloud. Now available through the Comprehensive Knowledge Archive Network, this resource contains expressive descriptions of ~20,000 weather stations in the United States with more than 18000 links to GeoNames places as shown in Figure 5.47.

Figure 5.47 - Linked sensor data example: sensor data published on the LOD cloud

The DUL:hasLocation relationship should be used to define the links between sensor sites and geographical places. Figure 5.48 shows how the link between the AGTC1_HMP50 weather station and its Geonames location can be implemented.

Figure 5.48 - Linked sensor data example: linking between a Sensor and a GeoNames place (station)

Figure 5.49 shows the rest of this example of weather station defined with the SSN ontology.

Figure 5.49 - Linked sensor data example: representation of a weather station using SSN ontology (station)

5.4.5.4 Provenance tracking in the Linked Sensor Data cloud

The development of the SSN Ontology, its alignment with DUL and its use in conjunction with external ontologies will foster new opportunities to link sensor data to other resources of the LOD cloud like DbPedia. It will also support the ongoing efforts to capture the provenance of sensor data.

Provenance, from the French word 'provenir', describes the lineage or history of a data entity. Provenance is critical information in the sensors domain to identify a sensor and analyze the observation data over time and geographical space. In this paper, we present a framework to model and query the provenance information associated with the sensor data exposed as part of the Web of Data using the Linked Open Data conventions. This is accomplished by developing an ontology-driven provenance management infrastructure that includes a representation model and query infrastructure. This provenance infrastructure ([Patni et al. 2010b]), called Sensor Provenance Management System (PMS), is underpinned by a domain specific provenance ontology called Sensor Provenance (SP) ontology.

6 Semantic Markup

The last few years have seen an explosion in the number and variety of sensors being deployed in all manner of environments around the globe; and this trend will continue as sensors are becoming cheaper and more readily available. The outcome of this development is an avalanche of observational data that must be analyzed and explained in order to achieve an understanding of our environment. Currently, this data is too often stove piped, with a strong tie between the sensor network, observation database, and end-user application. With the advent of projects such as the OGC Sensor Web Enablement (SWE) and the W3C Semantic Sensor Networks Incubator Group (SSN-XG) this information is now being set free and made available on the Web. With this new freedom, however, comes significant challenges, such as the following

• How do we discover, access and search sensor data on the Web?
• How do we integrate the sensor data when it comes from many heterogeneous sources?
• How do we make raw sensor data meaningful to Web applications and naive users?

SWE has taken important initial steps towards answering these questions. It includes the development of a set of XML-based languages and Web service interface specifications. The service interfaces, such as the Sensor Observation Service (SOS) [SOS 2008], provide a means to discover, access and search sensor data (as much as it is possible in XML-level syntactic interoperability level and through the use of standardised tags); and the languages, such as the Sensor Model Language (SensorML) [SENSORML 2007] and Observations and Measurements (O&M) [OM 1 2007], [OM 2 2007], provide a means to integrate data from heterogeneous sources in a standard format accessible to Web users. Such syntactic level interoperability is a good start and provides a solid framework to begin exploring the issue of semantic level interoperability. The latter issue falls under the charter of the W3C SSN-XG and is being explored through the investigation of two separate but closely related projects -- the development of an ontology for describing sensors and sensor data, and an annotation framework for adding semantic metadata to the SWE standards. This is a description of the latter.

In this document, the semantic annotation of sensor data is being considered within the scope of the SWE specifications (SensorML, O&M, SOS, etc.). In addition to considerations of the documents to be encoded, several use-cases have been defined which showcase the value of semantically annotating sensor data. These use-cases include (1) data discovery and linking, (2) device discovery and selection, (3) provenance and diagnosis, and (4) device operation tasking and programming. For more detail regarding these use-cases, see Section 3.

6.1 Review of basic annotation techniques

6.1.1 XLink

XLink (XML Linking Language) is an XML markup language for creating hyperlinks in XML documents. XLink is a W3C recommendation and outlines methods of describing links between resources in XML documents. Any element in an XML document can behave as a link. XLink supports simple links (like HTML) and extended links (for linking multiple resources together). In addition, with XLink, the links can be defined outside the linked files. XLink attributes can be added to SensorML and O&M documents to provide semantic annotations for the sensor data. XLink is already used in SWE documents, thus, no syntactic or structural changes are required. This explains the relative success of XLink-based approaches in earlier attempts to add semantic annotations to SWE documents, so recognizing which XLink attributes correspond to semantic annotations and which correspond to permissible SWE usages could become difficult.

Two versions of the XLink specification are available, XLink 1.0 [XLINK 2001] and XLink 1.1 [XLINK11 2010]. The description below covers XLink 1.0 because this is the specification which is used in OGC standards like GML [GML 2007].

XLink attributes

• xlink:type - Every element defining an XLink *must* contain a "type" attribute, which specifies what type of link it is - the value for this attribute may be any one of "simple", "extended", "locator", "arc", "resource", "title" or "none".

• xlink:href - The "href" attribute is used to specify the URL of a remote resource, and is mandatory for locator links. In addition to the URL of the remote resource, it may also contain an additional "fragment identifier", which drills down to a specific location within the target document.

• xlink:show - The "show" attribute is used to define the manner in which the endpoint of a link is presented to the user. The value of this attribute may be any one of "new" (display linked resource in a new window); "replace" (display linked resource in the current window, removing whatever is currently there); "embed" (display linked resource in a specific area of the current window); "other" (display as per other, application-dependent directives); or "none" (display method unspecified)

• xlink:actuate - The "actuate" attribute is used to specify when a link is traversed - it may take any of the values "onLoad" (display linked resource as soon as loading is complete); "onRequest" (display linked resource only when expressly directed to by the user, either via a click or other input); "other" and "none".

• xlink:label - The "label" attribute is used to identify a link for subsequent use in an arc.

• xlink:from and xlink:to - The "from" and "to" attributes are used to specify the starting and ending points for an arc respectively. Both these attributes use labels to identify the links involved.

• xlink:role and xlink:arcrole - The "role" and "arcrole" attributes reference a URL which contains information on the link's role or purpose.

• xlink:title - The "title" attribute, not to be confused with the title type of link, provides a human-readable descriptive title for a link.

6.1.2 RDFa

RDFa (Resource Description Framework - in - attributes) is a W3C Recommendation [RDFA SYNTAX 2008] that adds a set of attribute level extensions to XHTML for embedding rich metadata within Web documents. The RDF data model mapping enables its use for embedding RDF [RDF SYNTAX GRAMMAR 2004] triples within XHTML documents, it also enables the extraction of RDF model triples by compliant user agents. RDFa attributes can be added to SensorML and O&M documents to provide semantic annotations for the sensor data. Approaches based on RDFa look promising at the level of SWE documents since it would be easy to process the annotations independently of the rest of the document. Further work is required to check that the introduction of RDFa would not bring major changes for the implementers of the SWE standards and also to investigate how RDFa-enabled SWE services could be further integrated with other RDFa-based Web mashups.

RDFa attributes

• rdfa:about - A URI or CURIE [CURIE 2009] specifying the resource the metadata is about; in its absence it defaults to the current document.

• rdfa:rel - and rdfa:rev Specifies a relationship or reverse-relationship with another resource.

• rdfa:href, rdfa:src, and rdfa:resource - Specifies the partner resource.

• rdfa:property - Specifies a property for the content of an element.

• rdfa:content - Optional attribute that overrides the content of the element when using the property attribute

• rdfa:datatype - Optional attribute that specifies the datatype of text specified for use with the property attribute

• rdfa:typeof - Optional attribute that specifies the RDF type(s) of the subject (the resource that the metadata is about).

6.1.3 Other Annotation Techniques

• GRDDL [GRDDL 2007] - A markup format for Gleaning Resource Descriptions from Dialects of Languages. It is a W3C Recommendation, and enables users to obtain RDF triples out of XML documents, including XHTML. It defines the syntax to include a reference to a lifting script in a source document - the lifting script can then be used to transform the document to RDF.

• Microdata - Allows nested groups of name-value pairs to be added to documents, in parallel with the existing content. A non-semantic alternative to RDFa.

• SAWSDL [SAWSDL 2007] - A set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. Allows the user to record the mapping of WSDL elements to concepts defined in a reference ontology and to specify the lifting scripts which can be applied to the output of a service to transform it into a RDF file using the reference ontology concepts.

• hRESTs [Kopecky et al. 2008] - A microformat to add additional meta-data to REST API descriptions in HTML and XHTML. Developers can directly embed meta-data from various models such an ontology, taxonomy or a tag cloud into their API descriptions. The embedded meta-data can be used to improve search (for example: perform faceted search for APIs), data mediation (in conjunction with XML annotation) as well as help in easier integration of services to create mashups.

• SA-REST [Sheth et al. 2007] and Micro-WSMO [Kopecky et al. 2009] - two similar methods to semantically annotate REST services using the same microformat (hRESTs) and a different target ontology. This is similar to SAWSDL (including the possibility to include a reference to a lifting script) but applicable to an HTML-based description of a service).

6.1.4 Comparison of techniques

This report focuses on XLink and RDFa because they are the two primary techniques to add semantic annotations. For additional information on how these approaches can be applied to the development of geospatial mashups, see [Lefort 2009 ].

The following tables demonstrate the mapping of XLink and RDFa attributes to RDF, respectively. Such mapping guides the translation of semantic annotations to RDF syntax.

Table 6.1: Mapping XLink to RDF

Attribute	Description	Intended RDF
xlink:href	Identifier of the resource which is the target of the association, given as a URI	rdf:about of range resource
xlink:role	Nature of the target resource, given as a URI	rdf:about of class of range resource
xlink:arcrole	Role or purpose of the target resource in relation to the present resource, given as a URI	rdf:about of object property linking domain element to range resource
xlink:title	Text describing the association or the target resource	rdfs:comment

Table 6.2: Mapping RDFa to RDF

Attribute	Description	Intended RDF
rdfa:about	The identification of the resource (to state what the data is about)	rdf:about of domain resource
rdfa:typeof	RDF type(s) to associate with a resource	rdf:about of class of a resource
rdfa:href	Partner resource of a relationship ('resource object')	rdf:about of range resource
rdfa:property	Relationship between a subject and some literal text ('predicate')	rdf:about of datatype property
rdfa:rel	Relationship between two resources ('predicate')	rdf:about of object property
rdfa:rev	Reverse relationship between two resources ('predicate')	rdf:about of (inverse) object property
rdfa:src	Base resource of a relationship when the resource is embedded ('resource object')	rdf:about of domain resource
rdfa:resource	Partner resource of a relationship that is not intended to be 'clickable' ('object')	rdf:about of range resource
rdfa:datatype	Datatype of a property	XML type range of datatype property
rdfa:content	Machine-readable content ('plain literal object')	Value for datatype property

Below is a comparison of the capabilities of XLink and RDFa to express types defined in RDF. In this respect, as the table demonstrates, RDFa is more expressive than XLink.

Table 6.3: Comparison of XLink and RDFa

RDF Mapping	XLink	RDFa
Domain Instance		rdfa:about or rdfa:src
Domain Class	xlink:role	rdfa:typeof
Object Property	xlink:arcrole	rdfa:rel
Inverse Object Property		rdfa:rev
Range Instance Object Property	xlink:href	rdfa:href or rdfa:resource
Range Class		rdfa:typeof
Datatype Property		rdfa:property
Range Value		rdfa:content or element content

6.2 Semantic Markup for OGC standards

The Semantic Markup approach proposed below leverage two common features of the Sensor Web Enablement (SWE) languages, inherited from the design conventions originally defined for the Geography Markup Language [GML 2007]: its basic structure with nested resource-property pairs and the use of XLink as a linking mechanism to externally managed resources.

The overall compatibility of the design principles applied in GML with RDF is now acknowledged ([Schade and Cox 2010]). The OGC community is now aware that "only minor changes to current SDI standards" are required to allow the augmentation of Spatial Data Infrastructure with Linked Data ([Schade et al. 2010]). Some of these changes have already been engaged, e.g. the replacement of the Uniform Resource Names (URNs), previously mandated for the identification of resources governed by OGC, by HTTP URIs ([Cox 2010])

6.2.1 Current use of XLink in OGC standards

The OGC was an early adopter of XLink. Traditionally, however, the OGC has defined the use of XLink annotation as a composition by inclusion of remote resources. This definition regards annotation as a pointer to a remote resource such that the description is deferred. While this definition is useful for pointing to concepts in an ontology, it does not allow use of annotation for adding information to an existing resource description. To add further complexity to the situation, there are several (subtly) different usages of XLink in sub-communities of OGC. The GML specification authorises four variants on the use of XLink:

• A reference to an object element in the same GML document may be encoded as:

 <myProperty xlink:href="#o1"/> 
 

• A reference to an object element in a remote XML document using the gml:id value of that object may be encoded as:

 <myProperty xlink:href="http://my.big.org/test.xml#o1"/> 
 

• A reference to an object element in a remote XML document (or GML object repository) using the gml:identifier property value of that object may be encoded as:

 <myProperty xlink:href="http://my.big.org/test.xml#element(//gml:GeodeticCRS[./gml:identifier[
                         @codeSpace="urn:x-ogc:def:crs:EPSG:6.3:"]="4326"])"/>
 

• A reference to an object element with a uniform resource name may be encoded as follows (note that a URN resolver is required to resolve the URN and access the referenced object):

 <myProperty xlink:href="urn:x-ogc:def:crs:EPSG:6.3:4326"/> 
 

These four uses of XLink correspond to the definition of XLink annotation as a composition by inclusion of remote resources. Within this framework xlink:href is used to point to a target instance and xlink:role is used to point to its nature or type (e.g. to handle unknown features in this example). Describing XLink annotation as a semantic annotation, xlink:href would be used to point to an individual in an ontology and xlink:role would be used to point to a class in an ontology.

6.2.2 Recommended Technique

We recommend the use of XLink for providing semantic annotations to sensor data. While, as demonstrated above, RDFa is more expressive, XLink is already widely used within the sensor web community -- in particular the Open Geospatial Consortium. Therefore, XLink provides a low barrier to entry and requires no change to the existing Sensor Web Enablement specifications.

Table 6.4: Recommended Technique

Attribute	Definition	Intended RDF
xlink:href	link to ontology individual	rdf:about of range resource
xlink:role	link to ontology class	rdf:about of class of range resource
xlink:arcrole	link to ontology object property	rdf:about of object property linking domain element to range resource

Currently, xlink should only be used to annotate property nodes within the SWE XML languages; the latest specification does not cover issues dealing with "nested" annotations, or semantic annotations embedded within inner nodes of the XML tree. The use of xlink for this type of semantic annotation is being considered as a future extension.

6.2.3 Pending issues

The recommendation issued here does not cover all the use cases identified in [Maue et al. 2009] especially the opportunity to annotate service descriptions discussed in [Lefort 2009 ] or the two-step mapping annotation mechanism investigated by the SAPIENCE project.

The Review of semantic annotation proposals and [group discussion on Semantic Markup] also list specific issues like the migration from Uniform Resource Names (URNs) to HTTP URIs representing semantic web resources.

A solution mixing Xlink for the XML content and RDFa for the HTML content could be required to support hybrid standards like KML ([KML 2008]) and GeoRSS ([Reed et al. 2006]).

6.3 Examples

The examples provided here are based on standards which fully apply the GML design principles: Observations and Measurements (O&M) and Sensor Observation Service (SOS).

6.3.1 Simple Example

Sensor Observation Service (SOS) GetCapabilities: The following example illustrates an observation offering with sensor rain_gauge_sth_esk_up_esk_rd_bridge that measures thickness_of_rainfall_amount

 <swes:offering xlink:role="http://purl.oclc.org/NET/ssnx/ssn#Observation"
    xlink:arcrole="http://www.loa-cnr.it/ontologies/DUL.owl#hasSetting>
  <sos:ObservationOffering>        
    <swes:procedureIdentifier 
        xlink:role="http://purl.oclc.org/NET/ssnx/ssn#SensingDevice"
        xlink:href="http://purl.oclc.org/NET/ssnx/ssn-dev#rain_gauge_sth_esk_up_esk_rd_bridge" 
        xlink:arcrole="http://purl.oclc.org/NET/ssnx/ssn#observedBy">
      http://csiro.au/sw/rain_gauge_sth_esk_up_esk_rd_bridge
    </swes:procedureIdentifier>
    <swes:observableProperty 
        xlink:href="http://purl.oclc.org/NET/ssnx/cf/cf-property#thickness_of_rainfall_amount"
        xlink:arcrole="http://purl.oclc.org/NET/ssnx/ssn#observedProperty"
        xlink:role="http://purl.oclc.org/NET/ssnx/qu/dim#Distance"/>
    <sos:phenomenonTime 
        xlink:role="http://www.w3.org/2006/time-entry#Interval">
        xlink:arcrole="http://purl.oclc.org/NET/ssnx/ssn#observationTime"
      <gml:TimePeriod gml:id="phenomenonTime11">
        <gml:beginPosition
            xlink:role="http://www.w3.org/2006/time-entry#begins"
            xlink:arcrole="http://www.w3.org/2001/XMLSchema#time">
          2001-01-11T16:22:25.00
        </gml:beginPosition>
        <gml:endPosition
            xlink:role="http://www.w3.org/2006/time-entry#ends"
            xlink:arcrole="http://www.w3.org/2001/XMLSchema#time">
          2005-10-18T19:54:13.000Z
        </gml:endPosition>
      </gml:TimePeriod>
    </sos:phenomenonTime>
  </sos:ObservationOffering>
 </swes:offering>
 

6.3.2 Sensor Discovery Example

The following provides a more comprehensive example of the annotation of a SOS GetCapabilities document useful for sensor discovery.

Description - Find all the sensors that meet certain criteria. While all (or most) criteria necessary for sensor discovery can be found in a SensorML document, parsing through hundreds or thousands of XML documents to find a sensor matching a set of criteria would be terribly inefficient. Therefore, like finding most resources on the Web, sensor discovery will likely occur through Web services rather than document searches. The Sensor Observation Service [SOS 2008] is the prominent service within the OGC Sensor Web Enablement for searching and accessing sensor data. The Sensor Observation Service, however, currently has no method for finding relevant sensors and encourages the use of catalogue services for this task. However, by semantically annotating the GetCapabilities document of an SOS, we can provide the ability to discover relevant sensors through several criteria of interest for this use-case (i.e., location, property, availability, etc.). The following table details the search criteria for the sensor discovery use-case and the resources that contain this information.

Table 6.5: Criteria (with Resource Availability)

Criteria	SensorML	SOS GetCapabilities
Type	yes
Within geographic region (location)	yes	yes
Measured phenomenon	yes	yes
Range of measurement	yes
Availability	yes	yes
Owner/responsible party	yes
Manufacturer	yes
Application Domain+		yes

+ Note: The Application Domain criteria is not part of the original Sensor Discovery Use Case description, but is part of the SOS GetCapabilities and may be useful for discovery (e.g., for Water Resource Management).

The SOS DescribeSensor method returns a SensorML document with all the information about a particular sensor, however, you must know about the sensor (i.e., sensor ID) before invoking the method. Therefore, DescribeSensor is not sufficient for finding relevant sensors based on particular attributes. The following table describes the parameters of DescribeSensor:

Table 6.6: Parameters of DescribeSensor

Attribute	Definition
outputFormat	The outputFormat attribute specifies the desired output format of the DescribeSensor operation.
SensorId	The sensorId parameter specifies the sensor for which the description is to be returned. This value must match the value advertised in the xlink:href attribute of a procedure element advertised in the SOS GetCapabilities response.
service	Service type identifier (i.e., SOS)
version	Specification version for operation

The SOS GetCapabilities method, on the other hand, returns a service description that contains several attributes that could be useful for sensor discovery (i.e., location, property, availability, etc.).

Table 6.7: SOS GetCapabilities output

Attribute	Definition	Related Criteria
time	Time period for which observations can be obtained. This supports the advertisement of historical as well as real-time observations.	Availability
observedProperty	The observable/phenomenon that can be requested in this offering.	Measured phenomenon
featureOfInterest	Features or feature collections that represent the identifiable object(s) on which the sensor systems are making observations. In the case of an in-situ sensor this may be a station to which the sensor is attached representing the environment directly surrounding the sensor. For remote sensors this may be the area or volume that is being sensed, which is not co-located with the sensor. The feature types may be generic Sampling Features (see O&M) or may be specific to the application domain of interest to the SOS. However, features should include spatial information (such as the GML boundedBy) to allow the location to be harvested by OGC service registries.	Location
intendedApplication	The intended category of use for this offering such as homeland security or natural resource planning	Application Domain
procedure	A reference to one or more procedures, including sensor systems, instruments, simulators, etc., that supply observations in this offering. The DescribeSensor operation can be called to provide a SensorML or TML description for each system.

The following example illustrates an SOS GetCapabilities document describing a service for a weather station. The sensor description is semantically annotated with model references to classes and individuals related to a sensor, observed properties, and a location.

 <sos:Contents>
  <sos:ObservationOfferingList>
    <sos:ObservationOffering gml:id="urn:ogc:def:procedure:JPEO-CBD::WeatherStation_1">
      <gml:name>urn:ogc:def:procedure:JPEO-CBD::WeatherStation_1</gml:name>
      <gml:boundedBy>
        <gml:Envelope srsName="urn:ogc:def:crs:EPSG:4326">
          <gml:lowerCorner>18.556825 -72.297935</gml:lowerCorner>
          <gml:upperCorner>18.556825 -72.297935</gml:upperCorner>
        </gml:Envelope>
      </gml:boundedBy>
      <sos:time>
        <gml:TimeInstant xsi:type="gml:TimeInstantType">
          <gml:timePosition indeterminate="now"/>
        </gml:TimeInstant>
      </sos:time>
      <sos:procedure xlink:href="http://purl.oclc.org/NET/ssnx/ssn-dev#WeatherStation_1"/>
      <sos:observedProperty xlink:href="http://purl.oclc.org/NET/ssnx/cf/cf-property#snow-precipitation"/>
      <sos:observedProperty xlink:href="http://purl.oclc.org/NET/ssnx/cf/cf-property#temperature"/>
      <sos:observedProperty xlink:href="http://purl.oclc.org/NET/ssnx/cf/cf-property#windspeed"/>
      <sos:featureOfInterest xlink:href="http://sws.geonames.org/5248611/"/>
      <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat>
      <sos:resultModel xmlns:ns="http://www.opengis.net/om/1.0">ns:Observation</sos:resultModel>
      <sos:responseMode>inline</sos:responseMode>
      <sos:responseMode>resultTemplate</sos:responseMode>
    </sos:ObservationOffering>
  </sos:ObservationOfferingList>
 </sos:Contents>
 

6.3.3 Inference Example

An important benefit of semantically annotating sensor data is the additional expressivity supplied by an ontological representation. For example, if a weather ontology provides definitions for winter storms and their observable properties, then annotating sensor data with concepts (i.e., classes, individuals, and relations) from this ontology enables the ability to reason over such concepts. The GetCapabilities document above represents an offering with a weather station capable of observing three properties. Each property is a semantically annotated with a link to its definition within an ontology. From observations generated by this weather station, a blizzard may be inferred. Such knowledge may then be added to the original GetCapablities document. The GetCapabilities document below illustrates this example. In particular, notice the added sos:featureOfInterest tag which links to a blizzard individual. Within a standard Sensor Observation Service that has been extended with semantic annotations, we have now provided the ablitity to query for high-level weather events, along with low-level weather phenomena.

  <sos:Contents>
   <sos:ObservationOfferingList>
     <sos:ObservationOffering gml:id="urn:ogc:def:procedure:JPEO-CBD::WeatherStation_1">
       <gml:name>urn:ogc:def:procedure:JPEO-CBD::WeatherStation_1</gml:name>
       <gml:boundedBy>
         <gml:Envelope srsName="urn:ogc:def:crs:EPSG:4326">
           <gml:lowerCorner>18.556825 -72.297935</gml:lowerCorner>
           <gml:upperCorner>18.556825 -72.297935</gml:upperCorner>
         </gml:Envelope>
       </gml:boundedBy>
       <sos:time>
         <gml:TimeInstant xsi:type="gml:TimeInstantType">
           <gml:timePosition indeterminate="now"/>
         </gml:TimeInstant>
       </sos:time>
       <sos:procedure xlink:href="http://purl.oclc.org/NET/ssnx/ssn-dev#WeatherStation_1"/>
       <sos:observedProperty xlink:href="http://purl.oclc.org/NET/ssnx/cf/cf-property#snow-precipitation"/>
       <sos:observedProperty xlink:href="http://purl.oclc.org/NET/ssnx/cf/cf-property#temperature"/>
       <sos:observedProperty xlink:href="http://purl.oclc.org/NET/ssnx/cf/cf-property#windspeed"/>
       <sos:featureOfInterest xlink:href="http://sws.geonames.org/5248611/"/>
       <b><i><sos:featureOfInterest xlink:href="http://purl.oclc.org/NET/ssnx/ssn-dev#Blizzard_1"/></i></b>
       <sos:responseFormat>text/xml;subtype="om/1.0.0"</sos:responseFormat>
       <sos:resultModel xmlns:ns="http://www.opengis.net/om/1.0">ns:Observation</sos:resultModel>
       <sos:responseMode>inline</sos:responseMode>
       <sos:responseMode>resultTemplate</sos:responseMode>
     </sos:ObservationOffering>
   </sos:ObservationOfferingList>
  </sos:Contents>
 

7 Mappings

7.1 Introduction

At the 2010-02-02 teleconf the Group resolved to amend the second deliverable of the Charter, from How mappings can be constructed both from these ontologies to existing standards and from suitably annotated documents complying with existing standards to the ontologies.

This is now replaced by Illustrate [the SSN ontology's] relationship to OGC Sensor Web Enablement standards. The relationship is illustrated in two ways:

• Lineage of terms: Reference sources of SSN vocabulary terms are identified in the ontology as annotations of the terms, and also (more readably) on our SSN-XG wiki.
• Relationships to OGC standards: Worked examples are provided that show the application of our recommended markup technique to SWE technologies (especially Sensor ML and SOS).

In addition, we have aligned the SSN ontology with the Dolce Ultra-Lite upper ontology to support the integration of the SSN ontology with others. This alignment is documented elsewhere and summarised below.

- See also 2010-06-02 teleconf

7.2 Lineage of terms

Reference sources of SSN vocabulary terms are identified in the ontology as annotations of the terms, and are also presented on our SSN-XG wiki and summarised in this section.

7.2.1 Annotation method

The Group developed the following principles for annotation of terms in the ontology.

1. Every class and property definition is supported by the annotation property "rdfs:comment" which contains a textual string explaining the intended meaning of the class or property in English. This would not generally be a rewritten form of the formal class definition, but should support that definition by placing it in a real-world context, using words drawn from the ontology where appropriate.

2. Every class and property definition is supported by the annotation property "dc:source" which contains a textual string that identifies the source of the term and the corresponding "rdfs:comment" annotation property. This can be done informally e.g. it might contain "This is similar to MMI, but the notion of system that it depends on is different", or "This is new for this ontology -- we haven't seen this concept before". In most cases URLs are given to reference the sources. In some cases a term from the W3C SKOS vocabulary (Simple Knowledge Organization System (SKOS) is embedded in the "dc:source" annotation to relate the term to its use in an external vocabulary referenced by a URL.

3. Each class and property definition is supported by an annotation property "rdfs:seeAlso" which contains a URL pointing to a page on our SSN-XG wiki . This identifies the term as belonging to a module of the ontology and also points to its English explanation. This URL is used to generate the wiki presentation of the explanations, organised by module, from the original explanation that is maintained in the "rdfs:comment" of the ontology.

- See also 2010-06-08 teleconf-

7.2.2 Sources of term definitions

SSN definitions have been sourced from existing resources like OGC (SWE_terms) and VIM (VIM_terms) or from other lists of definitions previously developed e.g. MMI_OntDev_terms or MINET_Glossary. Relevant Wikipedia definitions (Wikipedia_terms) were also collected: the rationale was to identify terms which can be interpreted in multiple ways in different contexts which Wikipedia handles with its "disambiguation" mechanism.

In some cases, e.g. for the Issue 2 "All processes are systems" discussion, it was not possible to find applicable definitions from the resources listed above and the group opted to develop new definitions.

7.2.3 Documentation generation solution

We use an XSLT tool to generate the ontology documentation adapted from the tool chain developed by Ian Davis . The tool uses some Dublin Core, RDFS, and Creative Commons vocabulary terms for the ontology header:

• dc:title
• dc:date
• dc:created
• dc:modified
• dc:creator
• dc:author
• dc:contributor
• dc:description
• rdfs:comment
• dc:rights
• cc:license

The output is an HTML file which can be converted into a wiki page (using Open Office to do the transformation from HTML to MediaWiki syntax) and uploaded to the wiki. Our XSLT tool also exploits the rdfs:seeAlso annotations to split the OWL content into thematic modules and isolates important information such as the dc:source annotations included for term lineage and the links to external ontologies like DOLCE Ultra Lite.

See also Issue-7 Doc format/generation Documentation format - Generation of documentation derived from the OWL file

7.2.4 Summary of Term Mappings

This table presents the a summary of the sources of terms used in the SSN ontology. It is extracted from the "rdfs:seeAlso" annotation of the respective classes and properties in the SSN ontology. Those terms without a corresponding entry in the Mapping column of the table are original in the SSN ontology.

Table 7.1: Summary of Term Mappings

Module	Term Name	Mapping
Skeleton	ssn:FeatureOfInterest	skos:exactMatch 'feature' [O&M]
Skeleton	ssn:Observation	skos:closeMatch 'observation' [O&M] Observation in this ontology and O&M are described differently (O&M records an observation as an act/event), but they record the same thing and are essentially interchangeable. The difference is in the ontological structure of the two, not the data or use. Observation here records a Situation (the estimation of the value of a Property) and a description of the method that was used (along with the participants), while O&M interprets an Observation as the event itself; there must, however, have been an event that lead to our situation, so both are records of events. The distinction is between the event itself and the record of what happened in that event. skos:closeMatch 'measurement result' [Measurement VIM 2.9] result in VIM is the measured value plus any other relevant information, which means that measurement result and observation will often be associated to the same data (a value, a time, a property, etc.).
Skeleton	ssn:Property	skos:exactMatch 'property' [O&M]
Skeleton	ssn:Sensing	[SSN XG]
Skeleton	ssn:Sensor	skos:exactMatch 'sensor' [SensorML OGC-0700] skos:closeMatch 'observation procedure' [O&M] O&M allows sensors, methods, instruments, systems, algorithms and process chains as the processUsed of an observation; this ontology allows a similar range of things (any thing that can do sensing), just they are all grouped under the term sensor (which is thus wider than the O&M concept).
Skeleton	ssn:SensorInput	[SSN XG]
Skeleton	ssn:SensorOutput	[SSN XG] skos:closeMatch 'observation result' [O&M] See comments at ObservationValue.
Skeleton	ssn:Stimulus	[SSN XG]
Skeleton	ssn:detects
Skeleton	ssn:featureOfInterest	skos:exactMatch 'featureOfInterest' [O&M - ISO/DIS 19156]
Skeleton	ssn:forProperty
Skeleton	ssn:hasProperty
Skeleton	ssn:implementedBy
Skeleton	ssn:implements
Skeleton	ssn:isPropertyOf
Skeleton	ssn:isProxyFor
Skeleton	ssn:observationResult	skos:closeMatch 'result' [O&M - ISO/DIS 19156]
Skeleton	ssn:observedBy
Skeleton	ssn:observedProperty	skos:exactMatch 'observedProperty' [O&M - ISO/DIS 19156]
Skeleton	ssn:ofFeature
Skeleton	ssn:sensingMethodUsed	[VIM]
System	ssn:System	[SSN XG]
System	ssn:hasSubSystem
Process	ssn:Input	[MMI Dev]
Process	ssn:Output	[MMI Dev]
Process	ssn:Process	[SSN XG]
Process	ssn:hasInput
Process	ssn:hasOutput
Process	ssn:isProducedBy
Measuring	ssn:SensingDevice	[SSN XG]
Measuring	ssn:SensorDataSheet	[SSN XG]
Measuring	ssn:observes
MeasuringCapability	ssn:Accuracy	skos:exactMatch 'measurement accuracy/accuracy' [VIM 2.13]
MeasuringCapability	ssn:DetectionLimit	skos:exactMatch 'detection limit' [VIM 4.18]
MeasuringCapability	ssn:Drift	skos:exactMatch 'instrumental drift' [VIM 4.21]
MeasuringCapability	ssn:Frequency
MeasuringCapability	ssn:Latency
MeasuringCapability	ssn:MeasurementCapability	Similar idea to MeasurementCapability in MMI Device Ontology http://marinemetadata.org/community/teams/ontdevices But the the two express the relationship between constraints and multiple measurement properties differently. The conditions linked to a MeasurementCapability are skos:exactMatch to 'influence quantity' [VIM 2.52] http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf
MeasuringCapability	ssn:MeasurementProperty
MeasuringCapability	ssn:MeasurementRange	skos:exactMatch 'measuring interval/measurement range' [VIM 4.7]
MeasuringCapability	ssn:Precision	skos:exactMatch 'measurement precision/precision' [VIM 2.15]
MeasuringCapability	ssn:Resolution	skos:exactMatch 'resolution' [VIM 4.14]
MeasuringCapability	ssn:ResponseTime	skos:exactMatch 'step response time' [VIM 4.23]
MeasuringCapability	ssn:Selectivity	skos:exactMatch 'selectivity' [VIM 4.13]
MeasuringCapability	ssn:Sensitivity	skos:exactMatch 'sensitivity' [VIM 4.12]
MeasuringCapability	ssn:hasMeasurementCapability
MeasuringCapability	ssn:hasMeasurementProperty
Observation	ssn:madeObservation
Observation	ssn:observationResultTime	[O&M]
Observation	ssn:observationSamplingTime	[O&M]
Observation	ssn:qualityOfObservation	skos:exactMatch 'resultQuality' [O&M - ISO/DIS 19156]
Deployment	ssn:Deployment	skos:closeMatch 'Deployment' [MMI Dev]
Deployment	ssn:DeploymentRelatedProcess	[SSN XG]
Deployment	ssn:deployedOnPlatform
Deployment	ssn:deployedSystem
Deployment	ssn:deploymentProcessPart
Deployment	ssn:hasDeployment
Deployment	ssn:inDeployment
PlatformSite	ssn:Platform	skos:exactMatch 'platform' [SensorML OGC-0700]
PlatformSite	ssn:attachedSystem
PlatformSite	ssn:onPlatform
OperatingRestriction	ssn:MaintenanceSchedule
OperatingRestriction	ssn:OperatingProperty
OperatingRestriction	ssn:OperatingRange	skos:broaderMatch 'reference operating condition' [The VIM 4.11] difference is that here we also allow for qualities that aren't VIM influence quantities [VIM 2.52] - for example, a quantity that alters the power requirements, but doesn't affect the measurement properties - conditions specified in MeasurementCapability should be influence quantities.
OperatingRestriction	ssn:SurvivalProperty
OperatingRestriction	ssn:SurvivalRange	skos:narrowerMatch 'limiting operating condition' [VIM 4.10]
OperatingRestriction	ssn:SystemLifetime
OperatingRestriction	ssn:hasOperatingProperty
OperatingRestriction	ssn:hasOperatingRange
OperatingRestriction	ssn:hasSurvivalProperty
OperatingRestriction	ssn:hasSurvivalRange
Data	ssn:ObservationValue	skos:exactMatch 'measured quantity value' [VIM 2.10] skos:exactMatch 'observed value' [SensorML OGC-0700] skos:closeMatch 'observation result' [O&M] O&M conflates what we have as SensorOutput and ObservationValue into observation result, though the OGC standard does say "result contains a value" and "a result which has a value", which fits naturally with the model here.
Data	ssn:hasValue
Time	ssn:endTime
Time	ssn:startTime
ConstraintBlock	ssn:Condition
ConstraintBlock	ssn:inCondition
Device	ssn:Device	[SSN XG]
EnergyRestriction	ssn:BatteryLifetime
EnergyRestriction	ssn:OperatingPowerRange

7.3 Relationships to OGC standards

As a major deliverable of the XG, the Group has developed a proposal for Semantic Markup (also known as Semantic annotation) that suggests how the SSN ontology can be used in conjunction with OGC standards such as Observations and Measurements (O&M) and the Sensor Web Enablement (SWE) services. This is documented in the Semantic Markup section of this report. The proposal relies on embedding ontology references within XML attributes in a style that is consistent with OGC recommendations and some community practice. In order to illustrate the SSN ontology's relationship to OGC Sensor Web Enablement standards, worked examples are provided that show the application of our recommended markup technique to SWE technologies (especially Sensor ML and the Sensor Observation Service). See the examples in the Semantic Markup section and also see Linked Sensor Data for a description of an application for the SSN ontology in combination with OGC SWE.

Although not an OGC standard, the DOLCE foundational ontology is well known in the OGC research community, and is sometimes used for representing spatial and temporal concepts. We have aligned the SSN ontology to the DOLCE-derived OWL DL ontology known as DOLCE Ultra Lite, or DUL (see Skeleton module). This is intended to support integration with other domain ontologies as illustrated by the Agriculture Meteorology example.

8 Conclusion and Recommendations

8.1 Directions for future work

The value of the Semantic Sensor Network Ontology developed by the group lies in its formal model, its documentation and examples, and its ability to be integrated with existing sensor web standards and external ontologies. It answers a demand for harmonisation which is now better understood, thanks to the review of existing ontologies, the identification of the four flagship use cases, and the numerous examples of applications published by the group participants and early adopters outside the group.

The ontology developed by the group can act as a reference model for both the Semantic Sensor Network and Semantic Sensor Web realms, and with its emphasis on interoperability with other ontologies, it is primarily aimed at developers of Linked Sensor Data applications or sensor applications powered by other semantic data management architectures. It is also possible to embed the SSN ontology definitions within standardised APIs between the Internet of Things and the Internet for Services, including, but not limited to, client-side APIs to access metadata information related to sensor assets. A third opportunity, reserved to developers of OGC standards willing to leverage semantic web technologies, is to take advantage of the strong ties between the Semantic Sensor Network Ontology and existing OGC Sensor Web standards to enrich them.

This suggests three main directions for future work:

• Standardise the SSN ontology to use it in a Linked Sensor Data context
• Standardise the SSN ontology to bridge the Internet of Things and the Internet of Services
• Foster the adoption of the SSN ontology in the OGC community

Standardise the SSN ontology to use it in a Linked Sensor Data context: This approach faces two challenges. W3C normally refrains from standardizing vocabularies or ontologies for specific application areas unless they have foundational character (e.g., SKOS) or are an integral part of a W3C activity. Sensing is a transversal activity domain which does not fit well within the current split of the W3C Semantic Web activity into vertical applications. And the alignment of the SSN XG to DOLCE Ultra Lite triggers a dependency to a third party specification which is not endorsed by any standard development organisation and for which there is no credible alternative yet available.

Standardise the SSN ontology to bridge the Internet of Things and the Internet of Services: This approach raises two different issues. The ontology should cover other categories of "Things" and be bundled as an "Ontology and API" package following the model of what is done by the W3C Media Annotations working group. Two examples of "things" not yet modelled in the SSN ontology are actuators for applications such as industrial monitoring and control applications and smart labels (attached to physical artefacts) for logistics. Richer APIs giving access and possibly control for all types of devices are needed for new applications, such as the provision of sensor feeds from portable devices and fixed sensors to augmented reality applications.

Foster the adoption of the SSN ontology in the OGC community: There has been some preliminary work to extract linked sensor data from existing applications and to work on new sensor information model API on the basis of the SSN Ontology. As indicated in the Semantic Markup section of this report, it is possible to embed links to the SSN ontology in existing applications and to apply semantic web services standards like SAWSDL to inject these definitions prior to, or during, the triplification of the data. Some early adopters of the SSN ontology have directly used RDB2RDF transformation tools such as D2RQ to achieve the same goal. A preliminary attempt to select "the best parts of both SensorML and the SSNO [sic] in an alternative sensor information model" has also been made ([Malewski et al. 2011]). In both cases, one priority is to understand if the modelling approach used by the group, based on OWL, is compatible or not with the modelling principles currently applied by the OGC community: this is something which the ISO Technical Committee 211 has started to work on ([ISO/TC211 2009]).

8.2 Adoption of the SSN Ontology

A description of the major projects which have driven the SSN ontology development is available on the Participants page of the XG wiki. The examples section of this report also includes a short description of some of these projects.

Linked Sensor Data

The Semantic Sensor Web group at Kno.e.sis is converting raw sensor observations to RDF and linking with other datasets to build a Linked Sensor Data subset on the Linked Open Data cloud Linked Open Data Cloud. With such a framework, organizations can make large amounts of sensor data openly accessible, thus allowing greater opportunity for utilisation and analysis. Several W3C members backing this group have also worked on Provenance management for sensor data, working with participants of the W3C Provenance incubator group and working group.

SPITFIRE

The EU-funded SPITFIRE project aims at integrating application-level protocols, software, development environments, and evaluation methodologies from the Web and the Internet of Things. To achieve this goal of interoperability, the SPITFIRE project works at different layers: from the low-level inter-servicing protocol and network-agnostic communication, to the semantically enhanced description of sensor data and real-world semantic entities, providing semantics-driven service composition and query facilities to end-users. Further research is expected in this area because Internet-connected objects will be an integral component of the future internet and must therefore become integrated into emerging internet service delivery models, such utility and cloud computing.

SemSorGrid4Env

The EU FP7 project SemSorGrid4Env integrates the SSN XG ontology at the core of its ontology suite ([Garcia-Castro et al. 2011]), alongside domain ontologies describing the services and datasets which are integrated with sensor observations in the end-user applications, e.g., flood defence assets, topographic objects, metocean forecast models, etc.

The SSN ontology - specifically the Observation and Upper models - are the key link used to bridge the technical infrastructure (including sensor networks such as the Channel Coastal Observatory ones) with the information concepts applied by end users. Application developers can then access data services such as sensor network observations by querying them in terms relevant to the user domain (using the stSPARQL query language).

The SemSorGrid4Env project has also developed simplified web APIs to access observations made by sensors with RESTful access to traditional formats such as OGC WFS, OGC O&M, and GeoJSON, married to a linked data interface for RDF representation. More recent developments provide a more generally applicable service, incorporating data from any source that can be applied to the Observation model, including streaming data services, and utilising the latest version of the SSN ontology. These APIs have been exercised in the development of a flood response and planning web application for Southern UK coastal regions.

CSIRO SSN TCP

The Australian CSIRO Sensors and Sensor Networks Transformational Capability Platform is a strategic initiative to create technologies and capability that will transform the process of scientific discovery. Its aim is to radically increase the availability and accessibility of empirical data about the natural world. The outcomes of its research are equipping scientists with new tools for data driven scientific discovery and improved understanding and management of the environment and our impact on it. The SSN ontology is being used in the Phenonet agricultural meteorology network for plant phenomics and other applications are planned [Taylor and Leidinger 2011].

Other applications of the SSN ontology

The XG participants and early adopters have also published many research papers describing applications and possible extensions of the SSN ontology. A selection of these papers is available as a Tagged Bibliography on the SSN XG wiki, through BibBase and through the ssn-xg-public group hosted by Mendeley.

8.3 Recommendations

The first recommendation of the group is to initiate the process for the creation of a W3C community group focused on the maintenance and extension of the SSN Ontology. The group has not discussed if the inclusion of new themes like actuation should be envisaged but has agreed that for this work to continue in the best conditions, it must target a broader community of developers and adopters with common interests. We estimate, on the basis of the list of publications we have collected, that this new community should attract support from multiple W3C member organisations, including several which were not involved in the XG. A community group is also the best formula to build bridges between W3C and other standard organisation interested by the SSN ontology. To target more granular APIs and to increase the impact of the SSN ontology in new areas like Augmented Reality, it may be important to maintain or even refine the modular structure of the ontology described in this report.

The second recommendation is to encourage W3C peers to continue to work on the generic issues raised by the decision to align the SSN ontology to an upper ontology (e.g. DOLCE Ultra Lite). Such an alignment is a key feature of the SSN ontology for developers wishing to build a set of interoperable ontologies (or foundry) around it for a specific application or science domain. One of the findings of the group is that this alignment raises specific challenges for the publication, packaging and maintenance of the SSN Ontology which are not frequently addressed by other W3C groups publishing recommendations focusing on ontologies.

The third recommendation of the group is to encourage its participants and followers to join the Provenance working group to work on sensor-specific issues. Provenance is one of the flagship use cases identified by the group because this type of data is important for users of sensor data to understand its origin and the conditions in which it has been produced so that they can assess its quality. For governmental or scientific organisations operating sensor assets, provenance data and the data citations which can be derived from it will provide a critical incentive to encourage the sharing of data.

The fourth recommendation of the group is to request the W3C to promote uptake of the SSN ontology in the W3C community, especially through adoption by other W3C activities and also application by member organisations that produce relevant device or software products.

Finally, this incubator activity has allowed W3C members interested in semantic web, sensor web and geospatial standards to explore some issues which are mostly outside the core areas of competence of W3C and OGC. The final recommendation of this report is to encourage W3C and OGC to coordinate their activities in this area and especially to build a larger pool of experts by targeting organisations which are already or could be interested in becoming dual members.

9 Misc.

9.1 References

The references below are provided in function of the first section they appear in the report.

9.1.1 Motivating Use cases (refs)

[Liu et al. 2010] Liu, Q., Bai, Q., Zednik, S., Taylor, P., Fox, P. A., Taylor, K. L., Kloppers, C., Peters, C., Terhorst, A., West, P., Compton, M. and Shu, Y. A Provenance Model for Real-Time Water Information Systems. Abstract #IN41B-1361. American Geophysical Union, Fall Meeting, 13-17 Dec, San Francisco, Cal, USA 2010.

[OM 1 2007] S. Cox Observations and Measurements - Part 1 - Observation schema. OGC Implementation Standard OGC, 2007.

[OM 2 2007] S. Cox Observations and Measurements - Part 2 - Sampling Features. OGC Implementation Standard OGC, 2007.

[PROV XG 2010] Y. Gil, J. Cheney, P. Groth, O. Hartig, S. Miles, L. Moreau, P. Pinheiro da Silva (Eds) Provenance XG Final Report. W3C Incubator Group Report 08 December 2010, 2010.

[SAS 2006] I. Simonis OpenGIS Sensor Alert Service. OGC Candidate Implementation Specification OGC, 2006.

[SENSORML 2007] M. Botts OpenGIS Sensor Model Language (SensorML). OGC Implementation Standard OGC, 2007.

[SOS 2008] A. Na and M. Priest OpenGIS Sensor Observation Service. OGC Implementation Standard OGC, 2008.

[SPS 2007] I. Simonis OpenGIS Sensor Planning Service Implementation Specification. OGC Implementation Standard OGC, 2007.

[Taylor and Penkala 2009] Kerry Taylor and Patrick Penkala Using Explicit Semantic Representations for User Programming of Sensor Devices, In Proc. Australasian Ontology Workshop 2009 (AOW 2009), Melbourne, Australia. CRPIT, 112. Meyer, T. and Taylor, K. Eds., ACS. 47-55.

[TML 2007] S. Havens OpenGIS Transducer Markup Language. OGC Implementation Standard OGC, 2007.

[WMO 2006] World Meteorological Organisation Laboratory Intercomparison of Rainfall Intensity Gauges, WMO/TD-No. 1304, 2006.

[WMO 2009] World Meteorological Organisation Field Intercomparison of Rainfall Intensity (RI) Gauges, Instruments and Reporting Methods Report N. 99, 2009.

9.1.2 Review of Sensor and Observations Ontologies (refs)

[Avancha and Patel 2004] S. Avancha and C. Patel Ontology-driven adaptive sensor networks. In The First Annual International Conference on Mobile and Ubiquitous Systems Networking and Services 2004 MOBIQUITOUS 2004, pp. 194-202, 2004.

[Barnaghi et al. 2009] P. Barnaghi, S. Meissner and M. Presser Sense and sensability: Semantic data modelling for sensor networks. In Proceedings of the ICT Mobile Summit 2009, pp. 1-9, 2009.

[Bell et al. 2009] D. Bell, B. R. Heravi and M. Lycett Sensory Semantic User Interfaces (SenSUI): Position Paper. In Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN09) at ISWC 2009, pp. 96-109, 2009.

[Bermudez et al. 2009] L. Bermudez, E. Delory, T. O'Reilly and J. del Rio Fernandez Ocean observing systems demystified. In OCEANS 2009, MTS/IEEE Biloxi - Marine Technology for Our Future: Global and Local Challenges, pp. 1 -7, 2009.

[Bermudez 2010] L. Bermudez OGC Ocean Science Interoperability Experiment Phase II Report. OGC Engineering Report Open Geospatial Consortium, 2010.

[Calder et al. 2010] M. Calder, R. A. Morris and F. Peri Machine reasoning about anomalous sensor data. In Ecological Informatics 5(1), pp. 9-18, 2010.

[Compton et al. 2009a] M. Compton, C. Henson, H. Neuhaus, L. Lefort and A. Sheth A Survey of the Semantic Specification of Sensors. In Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN09) at ISWC 2009, pp. 17-32, 2009.

[Compton et al. 2009b] M. Compton, H. Neuhaus, K. Taylor and K. Tran Reasoning about Sensors and Compositions. In Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN09) at ISWC 2009, pp. 33-48, 2009.

[Eid et al. 2006] M. Eid, R. Liscano and A. El Saddik A Novel Ontology for Sensor Networks Data. In Proceedings of 2006 IEEE International Conference on Computational Intelligence for Measurement Systems and Applications, pp. 75-79, 2006.

[Eid et al. 2007] M. Eid, R. Liscano and A. El Saddik A Universal Ontology for Sensor Networks Data. In 2007 IEEE International Conference on Computational Intelligence for Measurement Systems and Applications, pp. 59-62, 2007.

[Fox et al. 2009] P. Fox, D. L. McGuinness, L. Cinquini, P. West, J. Garcia, J. L. Benedict and D. Middleton Ontology-supported scientific data frameworks: The Virtual Solar-Terrestrial Observatory experience. In Computers and Geosciences 35(4), pp. 724 - 738, 2007.

[Fox et al. 2008] P. Fox, D. Mcguinness, R. Raskin and K. Sinha Integrating Inter-disciplinary Science Data with Semantic Mediation. In Earth Science Technology Conference (ESTC) 2008, 2008.

[Goodwin and Russomanno 2006] C. Goodwin and D. J. Russomanno An ontology-based sensor network prototype environment. In Fifth International Conference on Information Processing in Sensor Networks, 2006.

[Goodwin et al. 2007] J. C. Goodwin, D. J. Russomanno and . J Survey of semantic extensions to UDDI: implications for sensor services. In Proceedings of the International Conference on Semantic Web and Web Services, pp. 16-22, 2007.

[Henson et al. 2009] C. A. Henson, J. K. Pschorr, A. P. Sheth and K. Thirunarayan SemSOS: Semantic sensor Observation Service. In 2009 International Symposium on Collaborative Technologies and Systems, pp. 44-53, 2009.

[Herzog et al. 2008] A. Herzog, D. Jacobi and A. Buchmann A3ME - An Agent-Based Middleware Approach for Mixed Mode Environments. In The Second International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies (UBICOMM 2008), pp. 191-196, 2008.

[Herzog and Buchmann 2009] A. Herzog and A. Buchmann Predefined Classification for Mixed Mode Environments. Technische Universitat Darmstadt, 2009.

[Hu et al. 2007] Y. Hu, Z. Wu and M. Guo Ontology driven adaptive data processing in wireless sensor networks. In InfoScale '07: Proceedings of the 2nd international conference on Scalable information systems, pp. 1-2, 2007.

[Kim et al. 2008] J. Kim, H. Kwon, D. Kim, H. Kwak and S. Lee Building a Service-Oriented Ontology for Wireless Sensor Networks. In Seventh IEEE/ACIS International Conference on Computer and Information Science, pp. 649-654, 2008.

[Madin et al. 2007] J. Madin, S. Bowers, M. Schildhauer, S. Krivov, D. Pennington and F. Villa An ontology for describing and synthesizing ecological observation data. In Ecological Informatics 2(3), pp. 279 - 296, 2007.

[Madin et al. 2008] J. S. Madin, S. Bowers, M. P. Schildhauer and M. B. Jones Advancing ecological research with ontologies. In Trends in Ecology & Evolution 23(3), pp. 159 - 168, 2008.

[Marine Metadata Interoperability 2008] MMI Sensors Ontology: A Community Development Project, Marine Metadata Interoperability, 2008.

[Matheus et al. 2005] C. J. Matheus, D. Tribble, M. M. Kokar, M. G. Ceruti and S. C. McGirr Towards a Formal Pedigree Ontology for Level-One Sensor Fusion. In International Command Control Research and Technology Symposium, 2005.

[Neuhaus and Compton 2009] H. Neuhaus and M. Compton The Semantic Sensor Network Ontology: A Generic Language to Describe Sensor Assets. In AGILE Workshop Challenges in Geospatial Data Harmonisation, 2009.

[O'Byrne et al. 2010] D. O'Byrne, R. Brennan and D. O'Sullivan Implementing the draft W3C semantic sensor network ontology. In, pp. 196 -201, 2010.

[Peng and Law 2005] J. Peng and K. H. Law Reference Data Models for Supporting the Network for Earthquake Engineering Simulation (NEES). In Computing in Civil Engineering, pp. 1-10, 2005.

[Preece et al. 2008] A. Preece, M. Gomez, G. de Mel, W. Vasconcelos, D. Sleeman, S. Colley, G. Pearson, T. Pham and T. L. Porta Matching sensors to missions using a knowledge-based approach. In SPIE Defense Transformation and Net-Centric Systems, 2008.

[Probst et al. 2006] F. Probst, A. Gordon and I. Dornelas OGC Discussion Paper: Ontology-based Representation of the OGC Observations and Measurements Model, Technical report, Institute for Geoinformatics (ifgi), University of Muenster, Germany, Retrieved from seres.uni-muenster.de, 2006.

[Probst 2006] F. Probst An Ontological Analysis of Observations and Measurements. In Proc. of the 4th. International Conference on Geographic Information Science (\GIScience\), pp. 304-320, 2006.

[Probst 2007] F. Probst Semantic Reference Systems for Observations and Measurements., 2007.

[Probst 2008] F. Probst Observations, measurements and semantic reference spaces. In Applied Ontology, pp. 63-89, 2008.

[Raskin and Pan 2005] R. G. Raskin and M. J. Pan Knowledge representation in the semantic web for Earth and environmental terminology (SWEET). In Computers & Geosciences 31(9), pp. 1119 - 1125, 2005.

[Robin and Botts 2006] A. Robin and M. E. Botts Creation of Specific SensorML Process Models (DRAFT) (internal OGC paper only accessible to members), 2006.

[Russomanno et al. 2005] D. J. Russomanno, C. Kothari and O. Thomas Building a sensor ontology: A practical approach leveraging ISO and OGC models. In the 2005 International Conference on Artificial Intelligence (IC-AI 2005), pp. 637-643, 2005.

[Russomanno et al. 2005b] D. J. Russomanno, C. Kothari and O. Thomas Sensor ontologies: from shallow to deep models. In Proceedings of the Thirty-Seventh Southeastern Symposium on System Theory, 2005. SSST '05, pp. 107-112, 2005.

[Skov and Petit 2005] F. Skov and R. Petit ALTER-Net A Long-Term Biodiversity, Ecosystem and Awareness Research Network. ALTER-Net consortium, 2005.

[SPASE 2010] . SPASE A Space and Solar Physics Data Model from the SPASE Consortium. SPASE Consortium, 2010.

[Stasch et al. 2009] C. Stasch, K. Janowicz, A. Bröring, I. Reis and W. Kuhn A Stimulus-Centric Algebraic Approach to Sensors and Observations. In GSN '09: Proceedings of the 3rd International Conference on GeoSensor Networks, pp. 169, 2009.

[Stevenson et al. 2009] G. Stevenson, S. Knox, S. Dobson and P. Nixon Ontonym: a collection of upper ontologies for developing pervasive systems. In CIAO '09: Proceedings of the 1st Workshop on Context, Information and Ontologies, pp. 1-8, 2009.

[Underbrink et al. 2008] A. Underbrink, K. Witt, J. Stanley and D. Mandl Autonomous Mission Operations for Sensor Webs. In AGU Fall Meeting Abstracts, pp. C5+, 2008.

[van der Werf et al. 2009] B. van der Werf, B. Magagna, J. Peterseil and H. Schentz (eds.) SERONTO A Socio-Ecological Research and Observation Ontology: the core ontology. Alter-Net Deliverable 4.I6.D2, 2009.

[Wei and Barnaghi 2009] W. Wei and P. Barnaghi Semantic annotation and reasoning for sensor data. In EuroSSC'09: Proceedings of the 4th European conference on Smart sensing and context, pp. 66-76, 2009.

[Williams et al. 2006] R. J. Williams, N. D. Martinez and J. Golbeck Ontologies for ecoinformatics. In Web Semantics: Science, Services and Agents on the World Wide Web 4(4), pp. 237 - 242, 2006.

9.1.3 The Semantic Sensor Network Ontology (refs)

[Barnaghi and Presser 2010] P. Barnaghi and M. Presser Publishing Linked Sensor Data. In The 3rd International workshop on Semantic Sensor Networks 2010 (SSN10) in conjunction with the 9th International Semantic Web Conference (ISWC 2010), 2010.

[Janowicz and Compton 2010] K. Janowicz and M. Compton The Stimulus-Sensor-Observation Ontology Design Pattern and its Integration into the Semantic Sensor Network Ontology. In The 3rd International workshop on Semantic Sensor Networks 2010 (SSN10) in conjunction with the 9th International Semantic Web Conference (ISWC 2010), 2010.

[Patni et al. 2010a] H. Patni, C. Henson and A. Sheth Linked Sensor Data. In 2010 International Symposium on Collaborative Technologies and Systems (CTS), 2010 International Symposium on, pp. 362-370, 2010.

[Patni et al. 2010b] H. Patni, S. Sahoo, C. Henson and A. Sheth Provenance Aware Linked Sensor Data. In 2nd Workshop on Trust and Privacy on the Social and Semantic Web, Co-located with ESWC, Heraklion Greece, June 2010.

[Probst et al. 2006] F. Probst, A. Gordon and I. Dornelas OGC Discussion Paper: Ontology-based Representation of the OGC Observations and Measurements Model, 2006.

[Pschorr et al. 2010] J. Pschorr, C. Henson, H. Patni and A. Sheth Sensor Discovery on Linked Data. Kno.e.sis Center, Wright University, Dayton, USA, 2010.

[Sabou et al. 2009] M. Sabou, J. Kantorovitch, A. Nikolov, A. Tokmakoff, X. Zhou and E. Motta Position Paper on Realizing Smart Products: Challenges for Semantic Web Technologies. In Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN09) at ISWC 2009, pp. 135-147, 2009.

9.1.4 Semantic Markup (refs)

[CURIE 2009] M. Birbeck and S. McCarron CURIE Syntax 1.0. Candidate Recommendation W3C, 2009.

[Cox 2010] S. Cox OGC Identifiers - the case for http URIs. OGC White Paper OGC, 2010.

[GML 2007] C. Portele OpenGIS Geography Markup Language (GML) Encoding Standard. OGC Implementation Standard OGC, 2007.

[GRDDL 2007] D. Connolly Gleaning Resource Descriptions from Dialects of Languages (GRDDL). Recommendation W3C, 2007.

[Kopecky et al. 2008] J. Kopecky, K. Gomadam and T. Vitvar hRESTS: An HTML Microformat for Describing RESTful Web Services. In IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology, pp. 619-625, 2008.

[Kopecky et al. 2009] J. Kopecky, T. Vitvar and D. Fensel D3.4.3 MicroWSMO and hRESTS. Service Oriented Architectures for All (SOA4All), 2009.

[KML 2008] T. Wilson OGC KML. OGC Implementation Standard OGC, 2008.

[Lefort 2009 ] L. Lefort Review of semantic enablement techniques used in geospatial and semantic standards for legacy and opportunistic mashups. In Australasian Ontology Workshop 2009 (AOW 2009) , pp. 17-26 , 2009 .

[Maue et al. 2009] P. Maue, P. Duchesne and S. Schade Semantic annotations in OGC standards. OpenGIS Discussion Paper Open Geospatial Consortium, 2009.

[Reed et al. 2006] C. Reed, R. Singh, R. Lake, J. Lieberman and M. Maron An Introduction to GeoRSS: A Standards Based Approach for Geo-enabling RSS feeds.. OGC White Paper OGC, 2006.

[RDF SYNTAX GRAMMAR 2004] D. Beckett RDF/XML Syntax Specification (Revised). Recommendation W3C, 2004.

[RDFA SYNTAX 2008] B. Adida, M. Birbeck, S. McCarron, and S. Pemberton RDFa in XHTML: Syntax and Processing. Recommendation W3C, 2008.

[SAWSDL 2007] H. Lausen and J. Farrell Semantic Annotations for WSDL and XML Schema. Recommendation W3C, 2007.

[Sheth et al. 2007] A. P. Sheth, K. Gomadam and J. Lathem SA-REST: Semantically Interoperable and Easier-to-Use Services and Mashups. In IEEE Internet Computing, 11(6), pp. 91-94, 2007.

[XLINK11 2010] E. Maler, D. Orchard, S. DeRose and N. Walsh XML Linking Language (XLink) Version 1.1. Recommendation W3C, 2010.

[XLINK 2001] S. DeRose, E. Maler and D. Orchard XML Linking Language (XLink) Version 1.0. Recommendation W3C, 2001.

[Schade and Cox 2010] S. Schade and S. Cox Linked Data in SDI or How GML is not about Trees. In 13th AGILE International Conference on Geographic Information Science (AGILE 2010 ), 2010.

[Schade et al. 2010] S. Schade, C. Granell and L. Diaz Augmenting SDI with Linked Data. In Workshop On Linked Spatiotemporal Data 2010, 2010.

9.1.5 Conclusion and Recommendations (refs)

[ISO/TC211 2009] ISO Technical Committee ISO/TC 211, Geographic information/Geomatics Report from stage 0 Project 19150 Geographic information - Ontology ISO/TC 211 N 2705 May 2009.

[García Castro et al. 2011] R. García Castro, C. Hill and O. Corcho Sensor network ontology suite v2. Deliverable D4.3v2, SemSorGrid4Env SemSorGrid4Env: Semantic Sensor Grids for Rapid Application Development for Environmental Management, 2011.

[Malewski et al. 2011] C. Malewski, I. Simonis, S. Cox, and A. Terhorst An Alternative Sensor Description Mark-Up Language EGU General Assembly 2011, Geophysical Research Abstracts Vol. 13, EGU2011-10348-4, 2011.

[Taylor and Leidinger 2011] K. Taylor and L. Leidinger, Ontology-Driven Complex Event Processing in Heterogenous Sensor Networks. In The Semantic Web: Research and Applications, LNCS 6644, pp. 285-299, Springer 2011.

9.2 Additional resources

Table 9.1 gives access to the additional documentation, directly generated from the SSN ontology OWL file.

Table 9.1: Additional documentation

Section of the report	Module documentation
5.3.1 The Skeleton of the Semantic Sensor Network Ontology	Skeleton Module, DUL
5.3.2 System	System Module
5.3.3 Process	Process Module
5.3.4 Measuring	Measuring Module
5.3.5 MeasuringCapability	MeasuringCapability Module
5.3.6 Observation	Observation Module
5.3.7 Deployment	Deployment Module
5.3.8 PlatformSite	PlatformSite Module
5.3.9 OperatingRestriction	OperatingRestriction Module
5.3.10 Data	Data Module
5.3.11 ConstraintBlock (Condition)	ConstraintBlock Module
5.3.12 Device	Device Module
5.3.13 Energy	Energy Module

And Table 9.2 lists the available OWL files (from which the figures and code snippets have been sourced) and the references of the papers describing the context in which the examples have been developed.

Table 9.2: Available resources

Example	Resources
5.4.1 University deployment	OWL file: uni-deploy Paper: [Barnaghi and Presser 2010], Publishing Linked Sensor Data.
5.4.2 Smart product	OWL file: smart-knife Position paper: [Sabou et al. 2009] Realizing Smart Products: Challenges for Semantic Web Technologies.
5.4.3 Wind sensor (WM30)	OWL file: WM30 Paper: [Compton et al. 2009b] Reasoning about Sensors and Composition (using CSIRO ontology)
5.4.4 Agriculture Meteorology Sensor Network	OWL file: phenonet OWL file: AWS and WMO AWS Metadata catalogue OWL file: CF (properties) and Climate and Forecast Metadata Conventions OWL file: CF (features) and CF grammar OWL file: QU, documentation and QUDV web site OWL file: QU Rec 20 and UN/CEFACT recs
5.4.5 Sensor Discovery on Linked Data	OWL file: Weather Station Paper: [Pschorr et al. 2010] Sensor Discovery on Linked Data Paper: [Patni et al. 2010a] Linked Sensor Data Paper: [Patni et al. 2010b] Provenance Aware Linked Sensor Data

9.3 Acronyms

ADC Analog Digital Conversion

ALTER-NET A Long-Term Biodiversity, Ecosystem and Awareness Research Network

API Application Programmable Interface

AWS Automatic Weather Station

BUFR Binary Universal Format for Representation

CCO Channel Coastal Observatory

CEDEX Classes for Environmental Data Exchange

CIMO Commission for Instruments and Methods of Observation

CF Climate and Forecast

CDP Canopy Database Project

CUAHSI Consortium of Universities for the Advancement of Hydrologic Science

DL Description Logics

DOLCE Descriptive Ontology for Linguistic and Cognitive Engineering

DUL DOLCE Ultra Lite

ETHAN Evolutionary Trees and Natural History

FIPA Foundation for Intelligent Physical Agents

FOL First Order Logic

GML Geography Markup Language

IEEE Institute of Electrical and Electronics Engineers

ISO International Organization for Standardization

LOD Linked Open Data

LTER Long Term Ecological Research

MMI Marine Metadata Interoperability

NCEAS National Center for Ecological Analysis and Synthesis

NSF National Science Foundation

O&M Observations and Measurements

OBOE Extensible Observation Ontology

ODM Observations Data Model

ODS Observation Data Standard

OGC Open Geospatial Consortium

OSR Observation and Specimen Records

SEEK Science Environment for Ecological Knowledge

SPASE Space Physics Archive Search and Extract

SSN Semantic Sensor Network

SUMO Suggested Upper Merged Ontology

SWE Sensor Web Enablement

SWEET Semantic Web for Earth and Environmental Terminology

TDWG Taxonomic Database Working Group

UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business

VIM International Vocabulary of Metrology

VSTO Virtual Solar Terrestrial Observatory

WMO World Meteorological Organization