The Semantic Sensor Network Ontology

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.

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

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.

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 conceptualization 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 conceptualization to support semantic interoperability. Therefore, we introduce a realization of the pattern based on the classes and relations provided by DOLCE Ultra Light. This ontology can be either directly used, e.g., for Linked Sensor Data, or integrated into more complex ontologies as a common ground for alignment, matching, translation, or interoperability in general.

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

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.

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

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.

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 minimize the amount of ontological commitments related to the existence of entities in the physical world, observed properties are the only connection between stimuli, sensors, and observations on the one hand, and features of interests on the other hand.

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

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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>
 

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

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>
 

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>
 

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
 

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

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>
 

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>
 

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>
 

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>

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

Figure 5.15 - ssn:MeasurementCapability and ssn:MeasurementProperty

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>
 

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>
 

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>
 

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>
 

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>
 

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>
 

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>
 

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>
 

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>
 

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

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

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>
 

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>
 

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>
 

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.

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

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>
 

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

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>
 

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

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

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>
 

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

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

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 conceptualized 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

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

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.

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

Figure 5.24 - ssn:Condition

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

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.

How to represent a WSN node and its energy components

Figure 5.26 shows how to specialize 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

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

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

  <owl:Ontology rdf:about="http://purl.oclc.org/NET/ssnx/energy/ssn-energy">
  ...
  <energy:Battery rdf:about="http://purl.oclc.org/NET/ssnx/energy/ssn-energy#Panasonic_VRLA_LC-R121R3P">
   <ssn:hasSurvivalProperty>
   <ssn:BatteryLifetime rdf:about="http://purl.oclc.org/NET/ssnx/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/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/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>
 

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>
 

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.

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. (For more information refer to: [Barnaghi and Presser 2010]).

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

The OWL file of the example is also available: [uni-deploy]

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

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

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 modeled 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).

Sensor

Figure 5.31 - Smart product example: Sensor

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>
 

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>

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>
 

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>
 

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>
 

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>
 

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>
 

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>
 

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>
 

Observation

Figure 5.32 - Smart product example: Observation

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>
 

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>
 

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>
 

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.

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

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

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

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.

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

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

Agriculture Meteorology Sensor Network

The Agriculture Meteorology ontology (ssn-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.

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

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

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 ssn-phenonet.xml)

Figure 5.40 - Agriculture meteorology example: ultrasonic wind sensor

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

External ontologies

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

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

---

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)

---

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

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

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 generalization 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

---

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.

---

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.

---

Additional information:

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

---

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.

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 underutilized 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 utilization 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

Figure 5.49 shows the rest of this example of weather station defined with the SSN ontology (OWL File).

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

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.