Extensions to the Semantic Sensor Network Ontology

W3C First Public Working Draft

This version:
Latest published version:
Latest editor's draft:
Simon Cox (CSIRO)
GitHub w3c/sdw
File a bug
Commit history
Pull requests


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. This note describes some extensions to the SSN ontology to enable:

  1. linking to the ultimate feature-of-interest for an observation, act of 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 namespace for SSN Extension terms is http://www.w3.org/ns/ssn/ext/

The suggested prefix for the SSN namespace is ssn
The suggested prefix for the SOSA namespace is sosa
The suggested prefix for the SSN Extension namespace is ssn-ext

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/proposals/ssn-extensions/rdf.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

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.

This document was published by the Spatial Data on the Web Interest Group as a First Public Working Draft.

GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-sdwig@w3.org (archives).

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 February 2018 W3C Process Document.

1. 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, the identity of the ultimate feature-of-interest can be obtained only by following a chain of one or more sosa:isSampleOf relationships. This may not be possible in a single request on a data service;
  2. observations are usually made as part of a set or collection, in which one or more of the observation properties - hasFeatureOfInterest, observedProperty, madeBySensor, usedProcedure, phenomenonTime, resultTime - are shared by all members of the collection. For efficient discovery and data transfer the set of observation descriptions can be packaged in a standard way that captures the common properties at the collection level.

This Note describes solutions to these requirements.

2. Notation and namespaces

Classes and properties from the are denoted in this specification using Compact URIs [curie].

The namespace for the SSN-Extensions graph is http://www.w3.org/ns/ssn/ext/. SSN-Extension re-uses elements from SSN and SOSA [vocab-ssn].

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

Prefix Namespace
ex http://example.org/ssn/
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/
ssn-ext http://www.w3.org/ns/ssn/ext/
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].

3. Principles and vocabulary overview

This section is non-normative.

3.1 Ultimate feature of interest

The object of the hasFeatureOfInterest property of an observation, act of sampling or actuation is the immediate or proximate FeatureOfInterest. In some cases this is not the the ultimate thing that the observation, act of 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. 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. The relationship of the ultimate feature of interest to observations and acts of sampling is illustrated in the figures below.

Observation feature-of-interest patterns
Figure 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
Figure 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 property 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. That approach was unnecessarily coy about satisfying the principle requirement, which is to know the ultimate feature of interest. The solution described here is explicit, and also applies to acts of sampling and actuation.

3.2 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 a new class ObservationCollection which may hold one or more of the properties hasFeatureOfInterest, observedProperty, madeBySensor, usedProcedure, phenomenonTime, or resultTime. Where present, the value of the property(s) of the collection are shared by all member observations. Only the value of each actual hasResult is not potentially shared by all member observations.

Collection of observations sharing one or more key properties
Figure 3 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

Collections may be nested. For example, an outer observation-collection may share an observed-property, procedure and sensor, and contain inner observation-collections at different phenomenon-times, each containing a set of observations on different features-of-interest. An observation may be a member of more than one observation-collection, so more than one sequence of nested observation-collections can collect the same set of observations. 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.

Effectively, the results of each observation-collection correspond to a slice in a data-cube composed of the results of the complete set of observations (as long as the values of properties inherited from the collection are not overridden on the nested collections or terminal 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 has not yet been properly explored.

The OBOE core modelThe SSN-ext model arranged to align with OBOE
Figure 4 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.

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

4.1 Classes


4.1.1 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: ssn-ext:ObservationCollection
IRI: http://www.w3.org/ns/ssn/ext/ObservationCollection
Definition: Collection of one or more observations, typically with one or more property shared by all of its members
Restrictions: ssn-ext:hasMember min 1
sosa:hasFeatureOfInterest max 1
ssn-ext:hasUltimateFeatureOfInterest max 1
sosa:madeBySensor max 1
sosa:observedProperty max 1
sosa:phenomenonTime max 1
sosa:resultTime max 1
sosa:usedProcedure max 1

If present, the value of any of sosa:hasFeatureOfInterest, ssn-ext:hasUltimateFeatureOfInterest, sosa:madeBySensor, sosa:observedProperty, sosa:phenomenonTime, sosa:resultTime, or sosa:usedProcedure apply to all member observations, unless overridden by a value attached directly to the member observation. See Inheriting observation properties from a collection for a formal definition of the rule.

4.2 Properties

:hasMember | :hasUltimateFeatureOfInterest

4.2.1 member observation or collection

Property: ssn-ext:hasMember
IRI: http://www.w3.org/ns/ssn/ext/hasMember
Definition: Link to a member of a collection of observations that share the same value for one or more of the characteristic properties
Instance of: owl:ObjectProperty
Sub-property of: rdfs:member
Domain: ssn-ext:ObservationCollection
Range: sosa:Observation or ssn-ext:ObservationCollection

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

4.2.2 has ultimate feature of interest

Property: ssn-ext:hasUltimateFeatureOfInterest
IRI: http://www.w3.org/ns/ssn/ext/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 trasntitively.
Instance of: owl:ObjectProperty
Range: sosa:FeatureOfInterest

No global domain constraints are specified for this property, so its appearance in a data set does not entail that the subject is a member of any particular class. However, the ssn-ext vocabulary adds the following guarded constraint to the sosa:Observation class:

Class: sosa:Observation
Restrictions: ssn-ext: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.

4.3 Rules

4.3.1 Finding ultimate feature of interest 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
CONSTRUCT { ?this ssn-ext:hasUltimateFeatureOfInterest ?f . }
    NOT EXISTS { ?this ssn-ext:hasUltimateFeatureOfInterest ?x . } .
    ?this sosa:hasFeatureOfInterest/(sosa:isSampleOf)+ ?f .
    NOT EXISTS { ?f sosa:isSampleOf ?y . } .

This is included as a SPIN rule [SPIN] in the RDF representation of the SSN extensions ontology.

4.3.2 Inheriting observation properties from a collection

If a sosa:Observation or ssn-ext:ObservationCollection is a member of an ssn-ext:ObservationCollection, the properties of the collection as a whole are associated with all member observations or collections, unless locally specified. Associating properties with the collection provides for efficiencies in both discovery and encoding.

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


Rules currently only allow for one level of nesting. Update to chase up a chain of observation collections.

Property Rule
CONSTRUCT { ?this sosa:hasFeatureOfInterest ?foi . }
    NOT EXISTS { ?this sosa:hasFeatureOfInterest ?x . } .
    ?oc ssn-ext:hasMember ?this .
    ?oc sosa:hasFeatureOfInterest ?foi .
CONSTRUCT { ?this sosa:madeBySensor ?se . }
    NOT EXISTS { ?this sosa:madeBySensor ?x . } .
    ?oc ssn-ext:hasMember ?this .
    ?oc sosa:madeBySensor ?se .
CONSTRUCT { ?this sosa:observedProperty ?op . }
    NOT EXISTS { ?this sosa:observedProperty ?x . } .
    ?oc ssn-ext:hasMember ?this .
    ?oc sosa:observedProperty ?op .
CONSTRUCT { ?this sosa:phenomenonTime ?pt . }
    NOT EXISTS { ?this sosa:phenomenonTime ?x . } .
    ?oc ssn-ext:hasMember ?this .
    ?oc sosa:phenomenonTime ?pt .
CONSTRUCT { ?this sosa:resultTime ?rt . }
    NOT EXISTS { ?this sosa:resultTime ?x . } .
    ?oc ssn-ext:hasMember ?this .
    ?oc sosa:resultTime ?rt .
CONSTRUCT { ?this sosa:usedProcedure ?pr . }
    NOT EXISTS { ?this sosa:usedProcedure ?x . } .
    ?oc ssn-ext:hasMember ?this .
    ?oc sosa:usedProcedure ?pr .

This rule combines the sampling-chain rule and the look-on-the-container rule used in the rest of this section, with the following order of precedence:
1. the (proximate) feature-of-interest of the observation, or the end of its sampling-chain;
2. the explicit ultimate-feature-of-interest of the container collections
3. the (proximate) feature-of-interest of the container collection, or the end of its sampling-chain;
CONSTRUCT { ?this ssn-ext:hasUltimateFeatureOfInterest ?foi . }
    ?this a sosa:Observation .
    NOT EXISTS { ?this ssn-ext:hasUltimateFeatureOfInterest ?x . } .
        ?this sosa:hasFeatureOfInterest/(sosa:isSampleOf)* ?foi1 .
        NOT EXISTS { ?foi1 sosa:isSampleOf ?y3 . } .
    } .
        ?oc ssn-ext:hasMember ?this .
        ?oc ssn-ext:hasUltimateFeatureOfInterest ?foi2 .
    } .
        ?oc ssn-ext:hasMember ?this .
        ?oc sosa:hasFeatureOfInterest/(sosa:isSampleOf)* ?foi3 .
        NOT EXISTS { ?foi3 sosa:isSampleOf ?y3 . } .
    } .
    BIND (COALESCE(?foi1, ?foi2, ?foi3) AS ?foi) .

Implementation of these as SPIN rules [SPIN] are provided in the ssn-ext.spin.ttl alongside the RDF representation of the SSN extensions ontology.

5. Examples


6. Alignments

6.1 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. The RDF Data Cube vocabulary uses the term observation for the results, and the dimensions of a data cube indicate the features of interest and phenomenon times of the results, the measures correspond to the observed properties, and the attributes accommodate information about the procedures and sensors.

A slice selects a subset of the 'observations' by fixing a subset of the dimensions, and thus delivers the set of results of an observation-collection with fixed features-of-interest or phenomenon-times or both.


If the value of the sosa:hasFeatureOfInerest, ssn-ext:hasUltimateFeatureOfInterest, or sosa:phenomenonTime is locally specified, and is different to the value on the containing ssn-ext:ObservationCollection, the results of the collection do not correspond with a splice from a data cube.

A. Acknowledgements

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.

B. References

B.1 Normative references

Semantic Sensor Network Ontology. Armin Haller; Krzysztof Janowicz; Simon Cox; Danh Le Phuoc; Kerry Taylor; Maxime Lefrançois. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/vocab-ssn/

B.2 Informative references

CURIE Syntax 1.0. Mark Birbeck; Shane McCarron. W3C. 16 December 2010. W3C Note. URL: https://www.w3.org/TR/curie/
OBOE: the Extensible Observation Ontology, version 1.1. Mark Schildhauer; Matthew B. Jones; Shawn Bowers; Joshua Madin; Sergeui Krivov; Deana Pennington; Ferdinando Villa; Benjamin Leinfelder; Christopher Jones; Margaret O'Brien.2016. URL: http://dx.doi.org/10.5063/F11C1TTM
Ontology for observations and sampling features, with alignments to existing models. S.J.D. Cox. Semantic Web. 2017. URL: https://content.iospress.com/articles/semantic-web/sw214
OWL 2 Web Ontology Language Manchester Syntax (Second Edition). Matthew Horridge; Peter Patel-Schneider. W3C. 11 December 2012. W3C Note. URL: https://www.w3.org/TR/owl2-manchester-syntax/
SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
SPIN - Overview and Motivation. Holger Knublauch; James A Hendler; Kingsley Idehen. W3C. 22 Feb 2011. W3C Member Submission. URL: https://www.w3.org/Submission/spin-overview/
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
The RDF Data Cube Vocabulary. Richard Cyganiak; Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-data-cube/