The Semantic Sensor Network (SSN) ontology is an ontology for describing sensors and their observations, the procedures used, the features of interest and observed properties that are the subject of observation, samples used in the course of observations, as well as actuators. This document describes some extensions to the SSN ontology to enable:

  1. linking directly to the ultimate feature-of-interest for an act of observation, sampling, or actuation, alongside the link to the (proximate) feature-of-interest, which might be a sample
  2. homogeneous collections of observations, in which one or more of the feature-of-interest, ultimate feature-of-interest, observed-property, procedure, sensor, phenomenon-time or result-time may be shared by all members of the collection

The namespace for SSN terms is http://www.w3.org/ns/ssn/
The namespace for SOSA terms is http://www.w3.org/ns/sosa/

The suggested prefix for the SSN namespace is ssn
The suggested prefix for the SOSA namespace is sosa

The SSN ontology is available at http://www.w3.org/ns/ssn/.
The SOSA ontology is available at http://www.w3.org/ns/sosa/.
The SSN-Extensions ontology is available at https://github.com/w3c/sdw/tree/gh-pages/ssn-extensions/rdf.

For OGC - This is a Public Draft of a document prepared by the Spatial Data on the Web Interest Group (SDWIG) — a joint W3C-OGC project (see charter). The document is prepared following W3C conventions. This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

New classes and properties are introduced in this extension to SSN. The new elements primarily relate to additional requirements for describing observations and collections of observations. The ontology document <owl:imports> the SSN ontology, and adds the new elements and axioms in a new RDF namespace.

Motivation and background

The Semantic Sensor Network (SSN) ontology is an ontology for describing sensors and their observations, the involved procedures, the studied features of interest, the samples used to do so, and the observed properties, as well as actuators [[vocab-ssn]]. The elements of the ontology are defined in two modules:

However, a number of requirements for describing observations that have been described in the research literature ([[?OM-Lite]], [[?OBOE]]) are not supported directly by SSN. In particular:

  1. discovery and use of observation data typically depends on their relationship to an ultimate feature-of-interest, which is a known thing in the world (such as a geological formation, or a specific patient, or the state of the atmosphere). However, if the (proximate) feature-of-interest of the observation is a sample of the ultimate feature-of-interest (such as a rock specimen, a blood or biopsy sample, or a specific transect through the atmosphere), the identity of the ultimate feature-of-interest can be obtained only by following a chain of one or more sosa:isSampleOf relationships, if they are even recorded. This may not be possible in a single request on a data service
  2. discovery and management of samples and sample data depends on the relationship of a sample to the actual feature of interest for which it is a proxy. The sosa:isSampleOf relationship is key, but in many cases there is a chain of samples, each sub-sampling another sample, so the link to the original feature-of-interest is indirect. Furthermore, in some cases (for example chemical analyses) multiple sub-samples are made and used to measure different characteristics, and it is helpful if these can all be related to the original sample that was taken immediately from the feature of interest.
  3. observations are usually made as part of a set or collection, within which variations of the result are of interest. A collection is typically designed so that one or more of the key observation properties are shared by all members of the collection - hasFeatureOfInterest, observedProperty, madeBySensor, usedProcedure, phenomenonTime, resultTime For efficient discovery and data transfer it is helpful if the set of observation descriptions is packaged in a standard way that captures the common properties at the collection level.

This document describes solutions these requirements.

Notation and namespaces

The classes and properties described in this document are denoted using Compact URIs [[curie]]. These classes and properties are put into the RDF namespace for SOSA, i.e. http://www.w3.org/ns/sosa/ which is used for the core elements of SSN [[vocab-ssn]], since the new classes and properties are expected to be used in the same context. However, these extensions to SOSA/SSN are packaged in a separate graph (ontology file) which is denoted http://www.w3.org/ns/ssn/ext/, and is currently available from the GitHub repository.

The table below indicates the full list of namespaces and prefixes used in this document.

Prefix Namespace
owl http://www.w3.org/2002/07/owl#
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http://www.w3.org/2000/01/rdf-schema#
sosa http://www.w3.org/ns/sosa/
ssn http://www.w3.org/ns/ssn/
xsd http://www.w3.org/2001/XMLSchema#

Where class descriptions include local restrictions on properties, these are described using the OWL 2 Manchester Syntax [[owl2-manchester-syntax]].

Examples and other code fragments are serialized using RDF 1.1 Turtle notation [[turtle]]. All examples and tests are available from the GitHub repository.

Principles and vocabulary overview

Ultimate feature of interest

The object of the original hasFeatureOfInterest property of an act of observation, sampling, or actuation is the immediate or proximate FeatureOfInterest. In some cases this is not the the ultimate thing that the act of observation, sampling, or actuation is concerned with, but is an intermediate thing, often a sample of the ultimate feature of interest, or perhaps a sample of a sample, etc. There will often be a specifiable relationship between the proximate and ultimate feature of interest, such as a sampling-chain. If this relationship is recorded, then an ultimate feature of interest might be inferred. Nevertheless, particularly for discovery purposes, it is usually the ultimate feature of interest that really matters to the data user. This requirement is satisfied by an object property called hasUltimateFeatureOfInterest.

Some patterns for the relationship of the ultimate feature of interest to observations () and acts of sampling (), and within sampling-chains, are illustrated below.

Observation feature-of-interest patterns 1
Patterns for observations that relate to the ultimate feature of interest directly (top), or indirectly via one sample (middle) or a chain of samples (bottom) - new property shown in red
Sampling feature-of-interest patterns 2
Patterns for sampling that relate to the ultimate feature of interest directly (top), or indirectly via one intermediate sample (middle) or a chain of intermediate samples (bottom) - new properties shown in red

This requirement was described in OM-Lite [[?OM-Lite]], but was addressed there using a different pattern in which the property oml:featureOfInterest always links to the ultimate feature-of-interest, and an additional property oml:samplingStrategy links to the sample or some other description of the sampling arrangements. However, that approach allowed multiple possible interpretations of ‘featureOfInterest’, and only representated chains of sampling or observation events indirectly. The solution described here is explicit, and also applies to acts of sampling and actuation.

Basis of a chain of samples

Many observation workflows rely on a chain of samples, each making a sub-sample of the predecessor sample. Knowing either the original sample or the initial feature of interest at the base of the chain is often useful for both discovery and management purposes. For example, shows a scenario from geology involving many samples derived from an initial one, with some relationships that may be useful in processing and discovery of subsequent observations, the intention of which will be to characterize various aspects of the original sample which is representative of an ultimate feature of interest. This is supported by two further object properties for relationships between samples and features of interest, called hasOriginalSample and hasSampledFeature.

Sample chain example from geology
It is common to generate a chain of samples in a geology exploration scenario, with initial sample retrieval from the field followed by a sequence of sample preparation steps to generate a series of sub-samples.

Having a direct indication of an original sample allows multiple results to be combined to describe the sample. Having a direct indication of the ultimate feature being sampled allows discovery of many samples that are intended to be representative of that feature.

Note that the scenario in is simplified from real-life scenarios, and also that the diagram only shows a subset of the full set of resources and relationships.

Homogeneous collection of observations

A collection of observations may share a common value for one or more of the characteristic observation properties. For example:

These patterns can be accommodated with the class ObservationCollection individuals of which may hold one or more of the essential properties of an atomic observation, except for the result. Where present, the value of the property(s) of the collection are shared by all member observations. Of the essential properties of an observation, only the value of each actual hasResult is not potentially shared by all member observations, though at least one of the other properties would be expected to vary between members in a typical collection.

For example, describes a collection of remote sensing observations using the same sensor on different scenes, while is a series of the same scene on different days.

Collections of observations 3
A set of remote sensing observations of different scenes on the same day
Collections of observations 4
A series of remote sensing observations of the same scene on the different days

Collections may be nested. For example, an outer observation-collection might share the observed-property, procedure and sensor, and contain inner observation-collections at different phenomenon-times, each of which contain a set of observations on different features-of-interest ().

Nested collections of observations 1
Example of a set of nested collections of four observations of the same property of two features-of-interest at two different times.

Observations can be factored into collections in more than one way, so more than one set of nested observation-collections can collect the same set of atomic results. For example, the same outer collection may contain inner collections concerning different features-of-interests, each containing a set of observations at different phenomenon-times ().

Nested collections of observations 2
Alternative set of nested collections with the same results of the same property of two features-of-interest at two different times.

Effectively, the results of each observation-collection correspond to a slice in a data-cube which is composed of the results of the complete set of observations.

This requirement was addressed in OM-Lite [[?OM-Lite]] following the pattern described here.

This feature might also apply to collections of Actuations but this application has not yet been explored.

Vocabulary specification

In this vocabulary specification, Manchester syntax [[owl2-manchester-syntax]] is used where the value of a field is not a simple term denoted by a URI or cURI [[curie]].

Classes

:ObservationCollection

Collection of observations

An ObservationCollection has at least one member, and may have one of any of the other seven properties mentioned in restrictions ().

Class: sosa:ObservationCollection
IRI: http://www.w3.org/ns/sosa/ObservationCollection
Definition: Collection of one or more observations, which may be nested in further collections, whose members share a common value for one or more property
Restrictions: sosa:hasMember min 1
sosa:hasFeatureOfInterest max 1
sosa:hasUltimateFeatureOfInterest max 1
sosa:madeBySensor max 1
sosa:observedProperty max 1
sosa:phenomenonTime max 1
sosa:resultTime max 1
sosa:usedProcedure max 1
Collection of observations sharing one or more key properties
Model for an observation-collection, in which the collection may carry one or more of the properties of its members if they have a shared value for all members - new properties and classes shown in red

If present, the value of any of sosa:hasFeatureOfInterest, sosa:hasUltimateFeatureOfInterest, sosa:madeBySensor, sosa:observedProperty, sosa:phenomenonTime, sosa:resultTime, or sosa:usedProcedure applies to all member observations. See Inheriting observation properties from a collection for a formal definition of the rule.

Properties

:hasMember | :hasOriginalSample | :hasUltimateFeatureOfInterest | :hasSampledFeature

member observation or collection

Property: sosa:hasMember
IRI: http://www.w3.org/ns/sosa/hasMember
Definition: Links an Observation or ObservationCollection that shares the same value for one or more of the characteristic properties to an ObservationCollection.
Instance of: owl:ObjectProperty
Sub-property of: rdfs:member
Domain: sosa:ObservationCollection
Range: sosa:Observation or sosa:ObservationCollection

The global domain and range constraints mean that any appearance of sosa:hasMember in a dataset entails that the subject of the statement is a sosa:ObservationCollection and the object of the statement is a sosa:Observation or sosa:ObservationCollection.

has original sample

Property: sosa:hasOriginalSample
IRI: http://www.w3.org/ns/sosa/hasOriginalSample
Definition: link to the original sample that is related to the context sample through a chain of isSampleOf relations
Instance of: owl:ObjectProperty
Domain: sosa:Sample
Range: sosa:Sample

The following guarded constraint applies to the sosa:Sample class:

Class: sosa:Sample
Restrictions: sosa:hasOriginalSample max 1

This constraint says that no more than one original-sample is expected for each individual sample.

has ultimate feature of interest

Property: sosa:hasUltimateFeatureOfInterest
IRI: http://www.w3.org/ns/sosa/hasUltimateFeatureOfInterest
Definition: link to the ultimate feature of interest of an observation or act of sampling. This is useful when the proximate feature of interest is a sample of the ultimate feature of interest, directly or transitively.
Instance of: owl:ObjectProperty
Domain: sosa:Observation or sosa:Sampling or sosa:Actuation
Range: sosa:FeatureOfInterest

The following guarded constraint applies to the sosa:Observation class:

Class: sosa:Observation
Restrictions: sosa:hasUltimateFeatureOfInterest min 1

This constraint says that at least one ultimate-feature-of-interest is expected for each individual observation. Typically an observation concerns one ultimate feature-of-interest but in some cases the proximate feature-of-interest is a sample of more than one ultimate feature of interest. The explanation of relationships between multiple ultimate features of interest are beyond the scope of this vocabulary.

has sampled feature

Property: sosa:hasSampledFeature
IRI: http://www.w3.org/ns/sosa/hasSampledFeature
Definition: link to the ultimate feature of interest of the context sample - i.e. the end of a chain of isSampleOf relations
Instance of: owl:ObjectProperty
Domain: sosa:Sample
Range: sosa:FeatureOfInterest

The following guarded constraint applies to the sosa:Sample class:

Class: sosa:Sample
Restrictions: sosa:hasSampledFeature min 1

This constraint says that at least one sampled feature is expected for each individual sample. More than one sampled feature may apply when a single sample proxies for different ultimate features when used in multiple investigations.

Rules

Finding ultimate feature of interest of an Observation or Sampling from a sampling chain

If the ultimate feature-of-interest of an Observation, Sampling or Actuation, or ObservationCollection is not specified, and the feature-of-interest is a Sample, then the ultimate-feature-of-interest can be found by following a path from the feature-of-interest to the end of a sequence of sosa:isSampleOf relations (see Figure 1, Figure 2).

The rule can be expressed formally as a SPARQL query expression [[sparql11-query]] as follows:

Property Rule
sosa:hasUltimateFeatureOfInterest 
          CONSTRUCT { ?this sosa:hasUltimateFeatureOfInterest ?f . }
          WHERE {
            { ?this a sosa:Observation } UNION { ?this a sosa:ObservationCollection } UNION { ?this a sosa:Sampling } UNION { ?this a sosa:Actuation }
            NOT EXISTS { ?this sosa:hasUltimateFeatureOfInterest ?x . } .
            ?this sosa:hasFeatureOfInterest/(sosa:isSampleOf)+ ?f .
            NOT EXISTS { ?f sosa:isSampleOf ?y . } .
          }

Finding the ultimate feature of interest that a Sample represents from a sampling chain

Sometimes it is useful to know what is the actual feature-of-interest that a sample represents. If this is not asserted with a sosa:hasSampledFeature then a candidate feature may be found by following a path from the sample to the end of a sequence of sosa:isSampleOf relations (see Figure 2).

This rule can be expressed formally as a SPARQL query expression [[?sparql11-query]] as follows:

Property Rule
sosa:hasSampledFeature 
            CONSTRUCT { ?this sosa:hasSampledFeature ?f . }
            WHERE {
              ?this a sosa:Sample
              NOT EXISTS { ?this sosa:hasSampledFeature ?x . } .
              ?this (sosa:isSampleOf)+ ?f .
              NOT EXISTS { ?f sosa:isSampleOf ?y . } .
            }

Note that a sample might represent more than one feature of interest, different by scale or some other defining property.

Finding the original Sample from a sampling chain

Sometimes it is useful to know what was the original sample taken from the ultimate feature-of-interest that a sample represents. If this is not asserted with a sosa:hasOriginalSample then a candidate sample may be found by following a path from the sample through a sequence of sosa:isSampleOf relations until the last sample (see Figure 2).

This rule can be expressed formally as a SPARQL query expression [[?sparql11-query]] as follows:

Property Rule
sosa:hasOriginalSample 
          CONSTRUCT { ?this sosa:hasOriginalSample ?os . }
          WHERE {
            ?this a sosa:Sample
            NOT EXISTS { ?this sosa:hasOriginalSample ?x . } .
            ?this (sosa:isSampleOf)+ ?f .
            NOT EXISTS { ?f sosa:isSampleOf ?y . } .
            ?os sosa:isSampleOf ?f . 
            ?this (sosa:isSampleOf)+ ?os .
          }

Note that most important original sample might not be the one closest to the domain feature. For example, in for many practical scenarios it will be a sample retrieved from the field that is of interest, and not the outcrop which is also modeled as a sample of the geologic unit. In such a case an explicit assertion of the original sample will be more relevant than the computed one.

Inheriting observation properties from a collection

If a sosa:Observation or sosa:ObservationCollection is a member of an sosa:ObservationCollection, the properties of the collection as a whole are associated with all member observations or collections.

Assigning properties to a collection provides for efficiencies in both discovery and encoding.

The rules may be defined formally as SPARQL query expressions [[?sparql11-query]] as follows:

Property Rule
sosa:hasFeatureOfInterest sosa:hasUltimateFeatureOfInterest sosa:madeBySensor sosa:observedProperty sosa:phenomenonTime sosa:resultTime sosa:usedProcedure 
CONSTRUCT { ?this $property ?foi . }
WHERE {
  ?this a sosa:Observation .
  NOT EXISTS { ?this $property ?x . } .
  ?oc sosa:hasMember+ ?this .
  ?oc $property ?foi .
}

In the above expression, $property is replaced by any one of the seven properties listed

Alignments

RDF Data Cube vocabulary

The W3C RDF Data Cube vocabulary [[?vocab-data-cube]] provides a means to describe multi-dimensional data according to a 'data cube' model inspired by SDMX, from which a 'slice' represents a collection of observations that is homogeneous in some property or dimension. Hence, for a collection of observations the datacube (qb:) model may be used to express aspects of homogeneity - such as whether a set of observations are all related to the same ultimate feature of interest, or the same type of feature of interest etc. Feature of interest, phenomenon time, observation procedure will typically correspond to qb:dimension sub-properties, qb:measures will be the observed properties and qb:ComponentDescriptions for qb:measures may indicate result types. qb:attribute sub-properties may be used for qualifying and annotating information.

In future a general model for the inter-relation of dimensions, sensors, observed properties, phenomena, units of measure, sampling precision, procedures, etc. could use qb:dimension concepts to describe observation and sampling strategies.

If the value of any of the properties such as the sosa:hasFeatureOfInterest, sosa:hasUltimateFeatureOfInterest, or sosa:phenomenonTime is locally specified, and is different to the value on the containing sosa:ObservationCollection, the results of the collection do not correspond with a slice from a data cube.

OBOE

The OBOE alignment module in SSN [[vocab-ssn]] provided an alignment for the atomic oboe:Measurement to sosa:Observation, but not for oboe:Observation. The ObservationCollection supports the full encoding of an oboe:Observation, which is a collection of oboe:Measurements concerning a common oboe:Entity, with each oboe:Measurement reporting the value of a different oboe:Characteristic, as shown in .

The OBOE core modelThe SSN-ext model arranged to align with OBOE
The OBOE core model (left), shown alongside the SSN-ext model (right) with comparable classes and properties aligned - new properties and classes shown in red.

Acknowledgements

This work was partly supported by TERN.

The editor would like to thank the members of the W3C/OGC Spatial Data on the Web Interest Group for their contributions during the development of this document.