The Semantic Sensor Network ontology (SSN) describes the arrangement of actuators and their actuations, sensors
and their observations, and samplers and their samplings, along with the procedures implemented, the features
of interest and samples, and the actuated and observed properties.
The core classes and properties are defined using a minimal set of axioms in modules called SOSA (Sensor,
Observation, Sample, and Actuator), supplemented with additional axiomatization and terms in further SSN
modules.
These allow SSN to support a wide range of applications and use cases, including satellite imagery, large-scale
scientific monitoring, industrial and household infrastructures, social sensing, citizen science,
observation-driven ontology engineering, and the Web of Things.
Alignments to some existing ontologies and specifications are provided.
Patterns for application of SSN are provided.
The namespace for the core terms is http://www.w3.org/ns/sosa/.
The suggested prefix for the SOSA namespace is sosa:.
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
General Information
For the OGC community, this document is a Public Draft prepared by the Spatiotemporal Data on the
Web Working Group (SDW) — a joint W3C-OGC project
(see charter).
The document is prepared following W3C conventions.
The document is released at this time to solicit public comment.
Publication as
a Working Draft does not imply endorsement
by W3C and its Members.
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 a work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
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 that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
Sensors are a major source of data available on the Web today.
However, searching, reusing, integrating, and interpreting sensor data requires more than just the result of an act of
sensing.
For proper interpretation of these values, knowledge of the feature of interest (such as a river), the observed
property (such as flow velocity), the sampling strategy (such as the specific locations and times at which the
velocity was measured), and a variety of other information are required.
Furthermore, the Web of Things makes actuators and the data they produce first-class citizens of the Web.
Parallel to sensors and observations, searching, reusing, integrating, and interpreting actuator data requires more
than just the actuation input and result values.
Knowledge of the feature of interest, such as a smart thermostat, the actuated property, such as temperature
setpoint, and a variety of other information are required.
OGC's Sensor Web Enablement [SWE] Standards — [SensorML], [OandM], [OMS], and [STA] — provide
conceptual models and some encodings for the annotation of sensors and their observations.
Observations, Measurements, and Samples ([OMS]) provides a comprehensive description of the characteristics of
observations and samples.
Integration and alignment of these with W3C Semantic Web technologies and Linked Data embeds this in a global and
densely interconnected graph of data.
The ETSI Smart Applications REFerence ontology ([SAREF]) forms a shared model of consensus intended to enable
semantic interoperability and data portability between solutions from different providers and among various activity
sectors in the Web of Things (WoT), such as smart energy systems, smart cities, smart homes, etc.
[SAREF] provides a generic description of devices, such as sensors and actuators, the functions and individual
commands they expose to some network, and the physical systems upon which these devices act.
1.2 Scope
This document is a W3C Recommendation and OGC Standard that defines the Semantic Sensor Network Ontology (SSN).
SSN provides flexible but coherent perspectives for representing the entities, relations, and activities involved in
actuation, observation, and sampling, including the procedures executed, and the systems that implement the
procedures.
Supporting concepts include platforms, deployments, observed or actuated properties, features of interest, and
resulting samples, along with collections (sets) of executions and results that are typically involved in analysis and
implementation.
A lightweight core module, known as SOSA (Sensor, Observation, Sample, and Actuator) aims to broaden the
audience and application areas that do not need the full capabilities of Semantic Web ontologies.
SOSA acts as minimal interoperability fallback level, i.e., it defines terms (classes and properties) with which data
can be safely exchanged across all uses of SSN, its modules, and SOSA.
Basic subclass and subproperty relationships are included.
The full SSN Ontology has additional axioms that may be useful in richer semantic web applications.
Finally, direct experience with SSN has uncovered a variety of minor issues and possible improvements that have been
addressed or accommodated.
For example, with the increasing diversity of data and data providers, definitions for sensors and actuators have been
broadened to include agents (including humans) and software (simulation).
This edition of the SSN Ontology is designated 2023 Edition corresponding to the year when revision commenced.
It aligns with designation of the ISO standard that triggered the revision work — ISO 19156:2023 ([OMS]).
Note
A number of new terms have been added to the SSN Ontology in the 2023 Edition.
Those that have received little or no implementation testing are marked "non-normative" with a Warning note.
These terms will be updated to normative status if implementation evidence is received during the transition process.
A change log is provided in an Annex of this document.
The Annex describes the changes since the previous edition [vocab-ssn-20171019].
Backward compatibility is maintained since descriptions of Actuations, Observations, Samplings, and Samples using the
SSN Ontology from the previous edition are compatible with the SSN Ontology provided by this 2023 Edition.
Note
A brief account of the Origins of SSN and SOSA through various OGC and W3C initiatives is
provided in an Appendix to this document.
The RDF files of the 2017 edition remain available at their permanent version IRI, which is obtained by substituting
/sosa with /sosa/2017, and /ssn with /ssn/2017. Similarly, the RDF
files of the 2023 edition will remain available at their permanent version IRI, which is obtained by substituting
/sosa with /sosa/2023, and /ssn with /ssn/2023.
There are several RDF serializations available.
The choice of RDF serialization is NOT prescribed by this Recommendation.
In this document, RDF fragments and examples are shown primarily using the compact
Turtle notation [rdf12-turtle], with options for JSON-LD [json-ld11] in some places.
OWL Restrictions are shown using the Manchester Syntax [owl2-manchester-syntax]
2.2 Class and property names
This section is non-normative.
The names (IRIs) of classes and properties in the SSN Ontology use English words or phrases, consistent with
most other W3C ontologies.
This contrasts with the strategy of some other ontology design frameworks, particularly in the
BFO family and
OBO Foundry, which prefer 'opaque' codes in identifiers.
It is intended that the name for each term be a mnemonic or hint for the concept.
Names of some properties are phrases, including the verbs 'had', 'has', 'made', 'makes', 'used', 'uses', etc.
Verb tense varies, and sometimes does not match all uses of properties that may be used both retrospectively and
prospectively.
Do not look for perfect consistency: The name is just a token for identification, while the formal definition
for each term is provided using the skos:definition text and through its axiomatization.
2.3 Diagram notation
This section is non-normative.
2.3.1 Module diagrams
Module diagrams use a notation similar to UML Package Diagrams OMG Unified Modeling Language,
with folders for modules, and dashed directed connectors for dependencies.
However the module diagrams MUST NOT be interpreted according to strict UML rules.
2.3.2 Class and instance diagrams
Class and property diagrams use a notation similar to UML Class Diagrams OMG Unified Modeling Language, with boxes for classes
and individuals, and labelled directed connectors (associations) or class attributes for properties.
However the class diagrams MUST NOT be interpreted according to strict UML rules.
In particular:
- Cardinalities are not shown and SHOULD NOT be inferred
- Object properties are generally shown as association roles.
Exceptions are (i) if a target class is unspecified (ii) to reduce clutter, in which case object properties
appear as class attributes, alongside the datatype properties
Individual members of classes in diagrams showing examples, appear as a box with a dotted-outline.
Properties of instances are shown with a dashed connector.
In some cases, a literal is shown in a box, even though it is not strictly an 'object' or 'individual' in
the RDF or OWL sense (e.g., quantities, location coordinates, time values).
Classes and properties colored grey are included in some diagrams for context, but are described in a
different section of the document
Connectors with open arrowheads indicate subclass relationships.
The purpose of the diagrams is primarily to orient the reader as to how SSN properties are related to the
SSN classes for most applications.
The associations shown in the diagrams match the soft axioms schema:domainIncludes and
schema:rangeIncludes in the ontology.
However, in any diagram the associations and attributes are not exhaustive:
Other associations and attributes exist but are not shown where their presence in the diagram would distract
from the primary message.
⊑ denotes either rdfs:subClassOf or rdfs:subPropertyOf,
depending on the context
⊒ represents the inverse relation
≡ indicates equivalence, corresponding to either owl:equivalentClass
or owl:equivalentProperty, depending on the context
The expression C1 or C2 represents an owl:unionOf class
expression
The expression OP1 o OP2 represents an
owl:propertyChainAxiom
The expression OP only C represents an
owl:allValuesFrom property restriction
The expression OP exactly 1 represents an
owl:cardinality restriction
The expression OP exactly 1 C represents an
owl:qualifiedCardinality restriction
3. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, SHALL, SHOULD, and SHOULD NOT in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all
capitals, as shown here.
3.1 General conformance requirements
Data conforms to SSN if:
Access to data is organized around Actuations, Observations, and Samplings.
These respectively represent executions of Actuating, Observing, and Sampling procedures, which are implemented by
Actuators, Sensors, and Samplers, respectively.
The contents of all data fields are expressed using the appropriate RDF classes and properties from SSN.
Where no such class or property exists, subclasses or subproperties specializing SSN in a domain-specific web
ontology are employed.
Classes and properties from SSN must be used in a way consistent with the semantics declared in this Recommendation.
Any subclasses or subproperties of SSN terms that are defined in domain-specific ontologies must also be consistent
with the SSN definitions.
SSN-compliant knowledge graphs MAY include additional non-SSN class instances, object and data properties, and
additional RDF data.
Ten core modules are defined, each module packaged into an RDF file that implements the module.
Each module corresponds to an OGC Requirements Class.
Dependencies between modules are recorded in the RDF through the owl:imports property.
The definition of each term in the SSN Ontology corresponds to a single Requirement.
OGC Requirements Classes for SSN, their dependencies, and their member Requirements are listed in
4. SSN Ontology Modularization.
Note
OGC Conformance Classes and Tests are not provided explicitly at this time.
A supplement to this document describing SHACL shapes (Shapes Constraint Language (SHACL)) may be provided in the future.
This would provide some testing functionality.
Note
The OGC Policy also specifies that a Target Type be indicated for each Requirements Class.
That is not done in this Recommendation.
However, the accompanying Usage Report considers Ontologies and Datasets as Target Types.
4. SSN Ontology Modularization
The SSN Ontology is defined and distributed in several modules.
The segmentation allows users to access the knowledge they require, reducing the scope to what is necessary in a
given use case.
Lower level modules are independent of their higher level modules and are logically consistent on their own.
Note
Higher level here is not to be confused with upper level ontologies or foundational ontologies.
Upper level ontologies are general knowledge ontologies that can be directly imported in many domains.
4.1 Core modules
Figure 3 summarizes the modules and dependencies within the core SSN
Ontology.
4.1.1 SOSA
The SOSA Module (Sensors, Observations, Samples and Actuations) defines the core classes and
properties, and provides textual definitions and other annotations.
This module uses the lightweight RDFS-Plus profile [RDFS-Plus].
SOSA may be used as-is by an audience who wish to use terminology consistent with the SSN Ontology, thus
ensuring interoperability with SSN-based repositories.
SOSA is composed of four lower level modules:
4.1.1.1 SOSA Common
SOSA Common defines classes and properties that are shared across
Actuation, Observation and Sampling applications, documented in section 5.3 Common terms.
SOSA imports SOSA Actuation, SOSA Observation and SOSA Sampling.
SOSA does not import any other ontologies, so it is independent of modules that add
more expressivity and further ontological commitments to the lightweight semantics of SOSA.
The SSN Modules adds OWL axioms that formally indicate how properties relate to classes.
SSN may be used in semantic web systems that use inference and reasoning, and check consistency of
datasets.
The modularization of SSN mirrors SOSA.
SSN is composed of four lower level modules:
4.1.2.1 SSN Common
SSN Common imports SOSA Common and axiomatizes classes and properties that are shared across
Actuation, Observation and Sampling applications, as documented in section 5.3 Common terms.
SSN Actuation imports SSN Common and SOSA Actuation, and axiomatizes classes and
properties used in Actuations, as documented in section 5.4 Actuations.
SSN Observation imports SSN Common and SOSA Observation, and axiomatizes classes and
properties used in Observations, as documented in section 5.5 Observations.
SOSA-OMS imports SOSA Observation and SOSA Sampling and adds classes and
properties required to provide an RDF implementation of Observations, measurements and samples (OMS).
SOSA-OMS may be used by audiences for whom full conformance to [OMS] (also known as ISO 19156:2023)
is a requirement
The System Capabilities module imports SOSA and adds classes and properties required for the
description of the operating conditions and capabilities of systems, in particular Sensors and Actuators.
Figure 5 summarizes alignments of other ontologies and specifications with the
SSN Ontology that are described in this document.
4.3.1 PROV
The SOSA-PROV module imports SOSA Common, and describes the alignment of SOSA to PROV-O: The PROV Ontology.
SOSA-PROV may be used to integrate data designed using SSN into provenance systems.
The SOSA-OBOE module imports SOSA Observation, and describes the alignment of SOSA to OBOE: the Extensible Observation Ontology, version 1.1.
SOSA-OBOE may be used to integrate observation data structured using OBOE with data using SOSA.
The SOSA-IDO module imports SOSA and IDO, and describes the alignment of SOSA to the
Industrial Data Ontology (IDO).
SOSA-IDO may be used to integrate data designed using SOSA with data designed using IDO.
The SOSA-DUL module imports SOSA, and adds axioms that position SOSA within DOLCE UltraLite
[DUL].
SOSA-DUL may be used to integrate data designed using SOSA into systems otherwise built in the DOLCE
UltraLite framework.
The SOSA-DOLCE module imports SOSA, and adds axioms that position SOSA within DOLCE
[DOLCE].
SOSA-DOLCE may be used to integrate data designed using SOSA into systems otherwise built in the
DOLCE framework.
The SOSA-BFO module imports SOSA, and adds axioms that align SOSA to BFO [BFO] and
CCO [CCO].
SOSA-BFO may be used to integrate data designed using SOSA into systems otherwise built in the BFO
framework.
This section introduces the specifications for the Semantic Sensor Network Ontology and its RDF implementation.
5.1 Overview of the ontology
The SSN Ontology provides a semantic framework for describing certain procedure-executions,
including actuations, observations, and samplings,
the procedures executed, the systems that implement the procedures,
the platforms on which these are mounted, and the deployments of the systems and platforms.
The namespace for the core terms is http://www.w3.org/ns/sosa/
The suggested prefix for the SOSA namespace is sosa:.
Note
5.2.2 Dependencies
Each module of the SSN Ontology is packaged as an RDF file.
The RDF representations use owl:imports statements to implement the dependencies.
Within each graph, where further information (axioms and annotations) is added to an existing term,
rdfs:isDefinedBy indicates the module where the term was originally defined.
5.2.3 Expressivity
The SOSA modules contain the basic definitions of the core terms.
SOSA has axiomatization corresponding to the RDFS-Plus profile [RDFS-Plus] — rdf:type
(ClassAssertion), and using axioms ObjectInverseOf, SubClassOf, and SubObjectPropertyOf.
SOSA includes the key annotations rdfs:label, skos:definition, schema:domainIncludes, and/or
schema:rangeIncludes, plus other annotations as required.
Inverses are named for all object properties.
Note
RDFS-Plus is supported by major RDF implementations, such as
GraphDB and
AnzoGraph.
The SSN module is an OWL 2 DL ontology (OWL 2 Web Ontology Language Document Overview (Second Edition)) that contains the full axiomatization of the core
terms, importing SOSA modules and using constructors such as ObjectUnionOf, DisjointClasses,
ObjectSomeValuesFrom, and ObjectAllValuesFrom.
Note
The generic property constraints rdfs:domain and rdfs:range are not used in the SSN Ontology.
The RDF files of the 2017 edition remain available at their permanent version IRI, which is obtained by
replacing /sosa with /sosa/2017, and /ssn with
/ssn/2017.
Similarly, the RDF files of the 2023 edition will remain available at their permanent version IRI, which is
obtained by replacing /sosa with /sosa/2023, and /ssn with
/ssn/2023.
5.2.5 Index of classes and properties
The following are alphabetical lists of the classes and properties in the SSN Ontology.
Note
Terms added in the 2023 Edition are indicated with an asterisk*.
The SSN classes and properties are described in the following sections, organized by module as described in
Modularization.
A list of all SSN properties and their inverses with the classes that are included in their domains and ranges
is
provided in Tabulation of properties and their inverses.
5.3 Common terms
5.3.1 Overview
This section is non-normative.
The Common module defines terms that are common across Sensing, Observation, Sampling and Actuation
applications.
Some of the classes in the Common module are used as-is in applications
(FeatureOfInterest, Property,
Platform,
Deployment).
Other classes in the Common module are super-classes of more specific classes used in the application modules
(Execution, Procedure, Asset,
and System).
They all support the description of Actuation,
Observation and Sampling instances using patterns
that are common across the applications.
The description of the Common module is organized into the following sections:
Feature Of Interest —
entity that is the target of an Execution, ExecutionCollection, or Deployment
i.e., the entity whose property is being manipulated by an Actuation or ActuationCollection,
or whose property is being estimated by an Observation or ObservationCollection,
or which is being sampled or transformed by an act of Sampling or SamplingCollection,
or which is the target of Executions planned as part of a Deployment.
The 2017 edition defined ActuatableProperty and ObservableProperty.
Those specializations of Property are deprecated in this 2023 edition.
sosa:Property should be used instead.
Property —
identifiable quality of features of interest that can be observed or acted upon
A property can apply to different features of interest.
Note
A model for the description of observable and actuatable Properties is outside the scope of the SSN
Ontology.
See Property definitions for links to some external resources
that address this, and to some catalogues and code lists whose members may be used as instances of
sosa:Property.
Example
Cars (a feature type) have a property "colour"
Windows have a property "open state".
for property —
relation from some Procedure or System to a Property it acts on or observes
Example
from a
Sensor to the properties it can observe;
from a
Actuator to the properties it can act on;
from a
Procedure to the properties it can observe or act
on.
is feature of interest of —
relation from a FeatureOfInterest to an Execution, Execution Collection, or Deployment, operating on that FeatureOfInterest
i.e., to an Actuation or ActuationCollection acting on it,
to an Observation or ObservationCollection about it,
to an act of Sampling or SamplingCollection that sampled it,
or to a Deployment for which it is the target.
is ultimate feature of interest of —
relation from an ultimate FeatureOfInterest to an Execution, ExecutionCollection, or Deployment, for
which that FeatureOfInterest is the ultimate target
Procedure —
workflow, protocol, plan, algorithm, program, or computational method specifying how to make a
Execution
A Procedure is re-usable, and might be applied in many Executions (Actuations, Observations, or
Samplings).
It explains the steps to be carried out to arrive at reproducible results.
Note
A specific model for the description of execution Procedures is outside the scope of the SSN
Ontology.
Example
The measured
wind speed
differs depending on the height of the
Sensor above the surface, due to friction.
For this reason, procedures for measuring wind speed define a standard height for
anemometers above ground, typically 10m for meteorological measures and 2m in
Agrometeorology.
This definition of height,
Sensor placement, etc are defined by
the
Procedure.
Execution —
act of carrying out a Procedure using a System
Note
The different time-properties on a sosa:Execution support
the description of plans, forecasts and predictions as well as descriptions of various historical
scenarios.
See Temporal properties for patterns related to these.
Scope note
Execution generalizes the
Actuation,
Observation, and
Sampling classes.
It is included in the ontology to support the definition of a common pattern for
executions and their properties.
Execution is considered to be abstract.
Individual Executions SHOULD be typed with one of the (concrete) subclasses of Execution.
The following consistency rules apply to the Execution properties listed above:
Where an individual ExecutionCollectionomits a property, a member Execution (direct or
transitive) MAY have any value for that property.
Where an individual ExecutionCollection has a single value
for a property, each member Execution (direct or transitive)
MUST have that same value for that property — i.e., the collection (set) is homogeneous in
that property.
That property MAY then be omitted in any member Execution or
ExecutionCollection.
Where an individual ExecutionCollection has
more than one value for a property, each member Execution
(direct or transitive) MUST have a value for that property that matches one of the values for
the property in the collection.
Where an individual ExecutionCollectionhas a value for a property that is a range or interval, each member
Execution (direct or transitive) MUST have a value for
that property that matches or falls within that range or interval.
Where an individual ExecutionCollectionhas more than one value for a property that is a range or interval, each member
Execution (direct or transitive) MUST have a value for
that property that matches or falls within one of those ranges or intervals.
The members of a collection (set) do not necessarily share a common value for
any property.
ExecutionCollection is considered to be abstract.
Individual execution collections SHOULD be typed with one of the (concrete) subclasses of
ExecutionCollection.
has feature of interest —
relation from an Execution or Deployment to its target entity
i.e., from an Actuation or ActuationCollection to the entity whose property was modified;
from an Observation or ObservationCollection to the entity whose quality was observed;
from an act of Sampling or SamplingCollection to the entity that was sampled;
or from a Deployment to its target
This is the
proximate
feature of interest.
It may be a proxy entity such as a
sample
of the
ultimate
feature of
interest.
Use
sosa:hasUltimateFeatureOfInterest if the intention is to link to the ultimate
feature of interest.
The result of an actuation or observation may be a geometry.
See Location and Geometry for patterns to describe this.
Warning
Where a complex value is encoded as a literal, the processing environment must be configured to support
the specific literal format.
For example, geometries encoded as [GeoSPARQL] literals, or quantities encoded as [CDT] literals,
should only be used in cases where such a configuration is available, or where the value is to be passed
through unchanged.
Note
This
DatatypeProperty provides an
alternative to hasResult, to be used only if the execution result can be expressed as a
Literal
has ultimate feature of interest —
relation from a Deployment or Execution to its ultimate target entity
i.e., from an Actuation or ActuationCollection to the ultimate entity whose property was modified;
from an Observation or ObservationCollection to the ultimate entity whose property was observed;
from an act of Sampling or SamplingCollection to the ultimate entity that was sampled;
or from a Deployment to its ultimate target
made by system —
relation from an Execution to the System that made that Execution
Scope note
madeBySystem generalizes the
sosa:madeByActuator,
sosa:madeBySensor, and
sosa:madeBySampler properties.
It is included in the ontology to support the definition of a common pattern for executions
and their properties.
madeBySystem is considered to be abstract.
Applications SHOULD use concrete subproperties of madeBySystem.
The different time-properties on a sosa:Execution support the description of plans, forecasts and
predictions as well as descriptions of various historical scenarios.
See Temporal properties for patterns related to these.
The different time-properties on a sosa:Execution support the description of plans, forecasts,
and predictions, as well as descriptions of various historical scenarios.
See Temporal properties for patterns related to these.
The following figure provides an overview of the classes and properties that are specifically related to
modeling systems and their deployment.
A sosa:Deployment is an arrangement of Assets (typically Systems and Platforms) with the
intention of
executing actuation, observation, or sampling procedures with respect to designated features of interest
for a specified time interval.
A sosa:Asset is a resource involved in a deployment, such as a system or platform.
A sosa:System is an instrument or equipment, including software systems and
agents where relevant, that implements a procedure in the context of executions.
A system may be composed of subsystems.
A sosa:Platform hosts one or more systems in the context of a deployment.
Stationary platforms include stations, or fixtures.
Mobile platforms include vehicles, watercraft, aircraft, satellites, mobile phones, etc.
5.3.5.2 Specification
This section introduces the following classes and properties:
Asset generalizes the System and Platform
classes, or other resource types that are relevant to deployments.
It is included in the ontology to support the definition of a common pattern for deployments.
Asset is considered to be abstract.
Individual assets SHOULD be typed with one of the (concrete) subclasses of Asset.
Deployment —
arrangement of one or more Assets to execute Procedures with respect to designated features of interest.
Note
A Deployment may have a geographic location.
See Location and Geometry for patterns to describe this.
Example
a temperature Sensor deployed on a wall
a network of Sensors deployed for an Observation campaign.
Note
A
sosa:Deployment will usually be for a specified time interval.
It MAY involve sosa:Platforms, or sosa:Systems, or both.
A sosa:Deployment can be used quite flexibly to describe the use of systems, and
platforms that host systems, with respect to a feature of interest.
The INSPIRE 'Environmental Monitoring Facility' may be implemented using SOSA by the OWL/RDFS
class
'Platform'.
Example
A post, tree, buoy, vehicle, ship, aircraft, satellite, mobile phone, human, or animal may act as
Platforms for (technical or biological)
Sensors or
Actuators.
An environmental monitoring facility.
System generalizes the
Actuator,
Sensor, and
Sampler classes.
It is included in the ontology to support the definition of a common
pattern for executions and their properties.
System is considered to be abstract.
Individual systems SHOULD be typed with one of the (concrete) subclasses of System.
Scope note 2
Specific system types may be implemented as subclasses of this class or its
subclasses.
Their descriptions may capture the properties and characteristics of a whole class of systems,
corresponding with the information typically found in a datasheet.
Individual system instances are members of this class or its subclasses.
The results of multiple observations are typically assessed together in order to discover or detect a
pattern or signal.
Similarly, a single sample is usually insufficient to provide insight regarding the properties of its source
entity or population.
Collections (sets) that are useful for analysis will typically be homogeneous with respect to one or more
properties of the members.
For example, a collection of observations of the same observed property on the same feature of interest at a
series of different times.
A collection of actuations may act on different properties of the same feature of interest, but other cases
also apply.
A collection of samplings may use the same sampler.
A collection of samples may be of the same feature (entity) of interest.
The SSN Ontology supports the description of collections (sets) primarily through the provision of:
a property for membership of a collection, and its inverse, described in this section
the generic class ExecutionCollection and specializations for
actuations, observations and samplings
is member of collection —
link from an Execution or Sample or Collection of these, to a collection which that Execution or Sample or Collection is part of
Rules for the consistency of values of properties of collections and properties of their members are
given for each collection type.
Note that there is a single isMemberOf property. OWL or SHACL constraints may limit the range depending on
the context of different collection types.
Collections of other entities associated with sensing, actuation and sampling could use the same pattern.
For example, networks of sensors and platforms (sites and stations) are common in environmental monitoring.
Furthermore, higher level aggregations of both entities and activities, such as occur in the context of
projects, initiatives, and campaigns, might be described using similar patterns.
However, the details of these cases are currently beyond the scope of the SSN Ontology.
Note
The PROV Ontology provides a generic framework for describing and relating Activities and Entities
[prov-o].
An alignment of SSN with PROV is provided in this document.
A basic Project Ontology based on PROV has also been proposed [Project-PROV].
Higher level aggregations in SSN applications should consider the PROV framework along with the recursive
sosa:hasMember/sosa:isMemberOf pattern used for SSN collections.
5.4 Actuations
5.4.1 Overview
This section is non-normative.
Figure 17 provides an overview of the core classes
and properties that are specifically related to modeling Actuations.
5.4.2 Specification
This section introduces the following classes and properties:
ActuatingProcedure added in the 2023 Edition
This term is non-normative, pending further implementation experience
Actuating Procedure —
workflow, protocol, plan, algorithm, program, or computational method specifying how to make an Actuation
An Actuating Procedure is re-usable, and might be applied in many Actuations.
It explains the steps to be carried out to arrive at reproducible results.
Alternatively, applications may choose to encapsulate complexity by defining a complex property with
multiple individual components, and a corresponding complex result (e.g., a vector).
This approach is not prohibited by the SSN Ontology, but the details are beyond the scope of SSN.
Note
The different time-properties on a sosa:Actuation support the description of
plans, forecasts, and predictions, as well as descriptions of various historical scenarios.
See Temporal properties for patterns related to these.
Example
The activity of automatically closing a window if the temperature
in a room drops below 20 degrees Celsius.
The activity is the Actuation and the device that closes the
window is the Actuator.
The Procedure is the rule, plan, or specification that may
define the condition that triggers the
Actuation (a drop in temperature).
The following consistency rules apply to the Actuation properties listed above:
Where an individual ActuationCollectionomits a property, a member Actuation (direct or
transitive) MAY have any value for that property.
Where an individual ActuationCollection has a
single value for a property, each member Actuation (direct or
transitive) MUST have that same value for that property; i.e., the collection is
homogeneous
in that property.
That property MAY then be omitted in any member Actuation or
ActuationCollection.
Where an individual ActuationCollection has
more than one value for a property, each member Actuation (direct or
transitive) MUST have a value for that property that matches one of the values for the property in the
collection.
Where an individual ActuationCollectionhas a
value for a property that is a range or interval, each member
Actuation (direct or transitive) MUST have a value for that
property that matches or falls within that range or interval.
Where an individual ActuationCollectionhas
more than one value for a property that is a range or interval, each member
Actuation (direct or transitive) MUST have a value for that
property that matches or falls within one of those ranges or intervals.
The members of a collection do not necessarily share a common value for any
property.
Actuator —
System that implements an ActuatingProcedure to change the value of an actuatable Property
This may be a device, a piece of infrastructure, an agent (including humans), or a software-based system, including systems performing simulations.
Note
An Actuator may have a geographic location.
See Location and Geometry for patterns to describe this.
Note
Specific actuator types may be implemented as subclasses
of this class or its subclasses.
Their descriptions may capture the properties and characteristics of a whole class of actuators,
corresponding with the information typically found in a spec-sheet or
datasheet.
Individual actuator instances are members of this class or its subclasses.
See Systems Types and Individuals for patterns to describe this.
Example
A window actuator for automatic window control,
i.e., opening or closing the window.
The 2017 edition defined the term ActuatableProperty as the range of sosa:actsOnProperty.
That specialization of sosa:Property is deprecated in this 2023 edition.
acts on property —
relation from an Actuation to the Property it acted upon
Example
In the activity (Actuation) of automatically closing a window
if the temperature in a room drops below 20 degrees Celsius, the property upon which the
Actuator acts is the state of the window as it changes from
being open to being closed.
The 2017 edition defined the term ActuatableProperty as the domain of sosa:isActedOnBy.
That specialization of sosa:Property is deprecated in this 2023 edition.
is acted on by —
relation from a Property to an Actuator that may change its state
Observation —
act of carrying out an ObservingProcedure using a Sensor to estimate or calculate a value of an observable
Property of a FeatureOfInterest
Alternatively, applications may choose to encapsulate complexity by defining a complex property with
multiple individual components, and a corresponding complex result (e.g., a vector).
This approach is not prohibited by the SSN Ontology, but the details are beyond the scope of SSN.
When the FeatureOfInterest cannot be observed directly, a
Sample of it might be used in Observations as a proxy.
In such a case the Sample is the proximate
FeatureOfInterest of the Observation,
while the (ultimate) FeatureOfInterest of the act of Sampling (i.e.,
the entity that the Sample is ultimately isSampleOf) is the ultimate
FeatureOfInterest of the Observation.
Note
The different time-properties on a sosa:Observation support the description of plans, forecasts, and
predictions, as well as observations relating to various historical scenarios.
See Temporal properties for patterns related to these.
Examples
The activity of
- estimating the magnitude or intensity of an earthquake
- measuring the height of a tree
- determining the color of a leaf
- measuring the CO2 concentration in a gas
- finding the location of a car
- measuring the temperature of a room
- capturing an image of a scene
Observation Collection —
set of Observations or ObservationCollections; collections may be nested
Note
An instance of ObservationCollection represents a container for a
set of data derived from observations.
This broadly corresponds with the class
dcat:Dataset from the Data Catalog Vocabulary
[vocab-dcat-3].
The following consistency rules apply to the Observation properties listed above:
Where an individual ObservationCollectionomits a property, a member Observation (direct or
transitive) MAY have any value for that property.
Where an individual ObservationCollection has
a single value for a property, each member Observation (direct or
transitive) MUST have that same value for that property; i.e., the collection is homogeneous in
that
property.
That property MAY then be omitted in any member Observation or
ObservationCollection.
Where an individual ObservationCollection has
more than one value for a property, each member Observation
(direct or transitive) MUST have a value for that property that matches one of the values for the
property in the collection.
Where an individual ObservationCollectionhas a value for a property that is a range or interval, each member
Observation (direct or transitive) MUST have a value for
that property that matches or falls within that range or interval.
Where an individual ObservationCollectionhas more than one value for a property that is a range or interval, each member
Observation (direct or transitive) MUST have a value for
that property that matches or falls within one of those ranges or intervals.
The results of collections of observations are often packaged in a 'data cube' whose axes define the
range of properties of the set of observations.
The members of a collection do not necessarily share a common value for any
property.
ObservingProcedure added in the 2023 Edition
This term is non-normative, pending further implementation experience
Observing Procedure —
workflow, protocol, plan, algorithm, program, or computational method specifying how to make an Observation
An Observing Procedure is re-usable, and might be applied in many Observations.
It explains the steps to be carried out to arrive at reproducible results.
A workflow, protocol, plan, algorithm, program, or computational method specifying how to make an
observation; the description of the process used by an observer.
This could be a chemical analysis method, a protocol for measuring an object, or even
a checklist used by a human observer during a biodiversity campaign.
The Procedure could further describe the algorithms behind simulators or models used to
generate a result from other inputs.
Note
[ISO 19156:2023] An ObservingProcedure shall be defined as the description of steps performed in
order to determine the value of an observableProperty by an Observer.
Sensor or Observer —
System that implements an ObservingProcedure to determine the value of an observable Property
This may be a device, a piece of infrastructure, an agent (including humans), or a software-based system
(including systems performing simulations).
A Sensor responds to a Stimulus,
e.g., a change in the environment, or input data composed from the results of prior
Observations.
Note
A Sensor may have a geographic location.
See Location and Geometry for patterns to describe this.
Note
Specific sensor types may be implemented as subclasses
of this class or its subclasses.
Their descriptions may capture the properties and characteristics of a whole class of sensors, corresponding
with the information typically found in a spec-sheet or datasheet.
Individual sensor instances are members of this class or its subclasses.
See Systems Types and Individuals for patterns to describe this.
Note
The UML class 'Observer' from ISO 19156:2023 is implemented in SOSA by the OWL/RDFS class
'Sensor'.
The class name 'Sensor' is preferred for backward compatibility with existing SOSA deployments.
Examples
Accelerometers, gyroscopes, barometers, magnetometers, etc are Sensors
that
are typically mounted on a modern smart phone (which acts as
Platform).
Other examples of Sensors include the human eyes.
has proxy —
relation from a Property to a Stimulus that serves as its proxy
Examples
The expansion of mercury is a
Stimulus that serves as a
proxy for some temperature
Property.
An increase or decrease in the velocity of spinning cups on a wind
Sensor is serving as a proxy for the wind speed.
The 2017 edition defined the term ObservableProperty as the domain of sosa:isObservedBy.
That specialization of sosa:Property is deprecated in this 2023 edition.
is observed by —
relation from a Property to a Sensor that is able to observe that Property
The 2017 edition defined the term ObservableProperty as the range of sosa:isProxyFor.
That specialization of sosa:Property is deprecated in this 2023 edition.
isProxyFor —
relation from a Stimulus to the Property that it is serving as a proxy for
Example
For example, the expansion of quicksilver is a Stimulus that serves
as a proxy for some temperature Property.
An increase or decrease in the velocity of spinning cups on a wind
Sensor is serving as a proxy for the wind speed.
observationRelatedTo added in 2023 Edition.
This term is non-normative, pending further implementation experience
observation related to —
relation from an Observation or ObservationCollection to another Execution or ExecutionCollection
Note
This general relationship complements the specific predicates outbound from Observation. It is particularly
useful to relate Observations (and collections) to other Executions (and collections)
The 2017 edition defined the term ObservableProperty as the range of sosa:observedProperty.
That specialization of sosa:Property is deprecated in this 2023 edition.
observed property —
relation from an Observation or ObservationCollection to the property observed in that Observation or ObservationCollection
Note
'observed property' covers the concepts referred to in [VIM] as 'measurand' (quantitative values) and
'examinand' (categorical and nominal values — [VIM4]), as well as complex and structured properties
whose values may be represented as lists, vectors, arrays, rasters, geometries, etc.
More specific terms are used in other contexts for related concepts, such as 'analyte' (chemistry) and
'determinand' (water quality).
The Property MUST be a property of the FeatureOfInterest of this Observation.
The 2017 edition defined the term ObservableProperty as the range of sosa:observes.
That specialization of sosa:Property is deprecated in this 2023 edition.
observes —
relation from a Sensor to a Property that it is capable of sensing
relatedObservation added in 2023 Edition.
This term is non-normative, pending further implementation experience
related observation —
relation from an Execution or ExecutionCollection to an Observation or ObservationCollection
Note
This general relationship complements the specific predicates inbound to Observation. It is particularly
useful to relate Observations (and collections) to other Executions (and collections)
resultQuality added in 2023 Edition.
This term is non-normative, pending further implementation experience
observation result quality —
relation from an Observation or ObservationCollection to some information pertaining to the quality of
that result
Note
This instance-specific description complements the description of the observation Procedure,
which provides information concerning the quality of all observations using this procedure.
Multiple measures can be provided.
The quality of a result can be assessed following the procedures in the ISO 19157 series
[iso-19157-1].
Samples are typically subsets or extracts from an entity or feature.
Every sample is expected to (eventually) be the feature of interest of an Observation.
Samples are used in situations where observations cannot be made directly on the ultimate
feature of interest, either because the entire feature cannot be observed, or because it is
more convenient to use a proxy.
Samples are thus artifacts of an observational strategy, and have no significant function
outside of their role in the observation process.
The characteristics of the samples themselves are of little interest, except perhaps to the
manager of a sampling campaign.
A Sample is intended to represent some FeatureOfInterest, so there is an expectation of at least
one
isSampleOf property.
However, in some cases the identity, and even the exact type, of the sampled feature may not
be known when observations are made using the sample.
Physical samples are sometimes known as 'specimens'.
A transient sample, such as a ships-track or flight-line, might be identified and described, but
is unlikely to be revisited exactly.
Examples
A 'station' is a spatial sample, in the form of an identifiable locality where a
Sensor system or procedure may be deployed and an observation made.
In the context of the observation model, it connotes the 'world in the vicinity of the station',
so the observed properties relate to the physical medium at the station, and not to any physical
artifact such as a mooring, buoy, benchmark, monument, well, etc.
A statistical sample is often designed to be characteristic of an entire population, so that
Observations can be made regarding the sample that provide a good
estimate of the properties of the population.
MaterialSample added in the 2023 edition.
This term is non-normative, pending further implementation experience
Material Sample —
subset of a FeatureOfInterest that is physical (i.e., tangible)
Subclass of
sosa:Sample
Examples
A piece of rock, a blood sample, a water sample
Note
MaterialSamples that are curated and preserved are sometimes known as 'specimens'.
MaterialSamples may be destroyed in connexion with the observation act or a subsequent
preparation step.
SpatialSample added in the 2023 edition.
This term is non-normative, pending further implementation experience
Spatial Sample —
subset of a FeatureOfInterest defined by its location and shape in space
When observations are made to estimate properties of a geospatial feature, particularly where the value of
a property varies within the scope of the feature, a SpatialSample is used.
The following consistency rules apply to the Sample properties listed above:
Where an individual SampleCollectionomits a property, a
member Sample (direct or transitive) MAY have any value for that property.
Where an individual SampleCollection has a single value for a
property, each ember Sample (direct or transitive) MUST have that same
value for that property; i.e., the collection is homogeneous in that property. That property MAY
be omitted in any member Sample or
SampleCollection.
Where an individual SampleCollection has more than one value
for a property, each member Sample (direct or transitive) MUST have a
value for that property that matches one of the values for the property in the collection.
Where an individual SampleCollectionhas a value for a
property that is a range or interval, each member Sample (direct or
transitive) MUST have a value for that property that matches or falls within that range or interval.
Where an individual SampleCollectionhas more than one value
for a property that is a range or interval, each member Sample (direct
or transitive) MUST have a value for that property that matches or falls within one of those ranges or
intervals.
The members of a collection do not necessarily share a common value for any property.
Sampler —
System that implements a SamplingProcedure to generate a Sample
Note
A Sampler may have a geographic location.
See Location and Geometry for patterns to describe this.
Examples
A ball mill, diamond drill, hammer, hypodermic syringe and needle, image
Sensor or a soil auger can all act as
Samplers.
Sometimes the distinction between the Sampler and the
Sensor is not evident, if they are packaged as a unit.
Sampling —
act of carrying out a SamplingProcedure using a Sampler to create one or more Samples of a FeatureOfInterest
Note
The different time-properties on a sosa:Sampling support the description of plans, forecasts, and
predictions, as well as descriptions of various historical scenarios.
See Temporal properties for patterns related to these.
Examples
Drawing blood from a patient
Drilling a core from an ice sheet
Digging a pit through a soil sequence
Dividing a field site into quadrants
Drilling an observation well
Establishing a station for environmental monitoring
Registering an image of the landscape
Sieving a powder to separate the subset finer than 100-mesh
Selecting a subset of a population
Splitting a piece of drill-core to create two new samples
Taking a diamond-drill core from a rock outcrop
The following consistency rules apply to the Sampling properties listed above:
Where an individual SamplingCollectionomits a property, a
member Sampling (direct or transitive) MAY have any value for that property.
Where an individual SamplingCollection has a
single value for a property, each member Sampling (direct or
transitive) MUST have that same value for that property; i.e., the collection is
homogeneous in that property.
That property MAY then be omitted in any member Sampling or
SamplingCollection.
Where an individual SamplingCollection has more than one value
for a property, each member Sampling (direct or transitive) MUST
have a value for that property that matches one of the values for the property in the collection.
Where an individual SamplingCollectionhas a value for a
property that is a range or interval, each member Sampling (direct
or transitive) MUST have a value for that property that matches or falls within that range or interval.
Where an individual SamplingCollectionhas more than one value
for a property that is a range or interval, each member Sampling
(direct or transitive) MUST have a value for that property that matches or falls within one of those
ranges or intervals.
The members of a collection do not necessarily share a common value for any property.
spatial distribution of locations where to collect a sample (e.g., river segment)
instrument (or mode of use thereof) required to collect a sample (e.g., fish net, electric
stunner)
field work instructions (e.g., dig four boreholes in each cardinal direction 2 metre way from
the centre of the site; collect soil material from the 15-30 cm depth and mix it in a single
bag)
Note
[ISO 19156:2023] A SamplingProcedure shall be defined as the description of steps performed by a
Sampler in order to extract a Sample from its sampledFeature in the frame of a Sampling.
feature has ultimate sample —
relation from an ultimate FeatureOfInterest to a Sample or SampleCollection that is intended to be
representative of it; i.e., the end of a chain of hasSample relations
Note
Some examples of relationships between samples and features of interest within chains are
illustrated in Sample chains.
is sample of ultimate feature of interest —
relation from a Sample or SampleCollection to the ultimate FeatureOfInterest that it is intended to be
representative of; i.e., the end of a chain of isSampleOf relations
Note
Some examples of relationships between samples and features of interest within chains are
illustrated in Sample chains.
Note
isSampleOfUltimateFOI renames the property that was called hasSampledFeature in
Extensions to the Semantic Sensor Network Ontology [vocab-ssn-ext]
This section provides the specifications for modules that extend the scope and capabilities of SSN.
6.1 OMS Extension Module
6.1.1 OMS Requirement
This section introduces extensions to the SSN Ontology to provide a canonical RDF implementation of [OMS].
OMS is the 2023 Edition of the OGC and ISO standard previously known as Observations and Measurements [OandM],
which was a key influence and input in the development of SSN.
Note
OMS was published as ISO 19156:2023 [iso-19156-2023], but is freely available as OGC Abstract
Specification — Topic 20 [OMS].
This module provides (i) additional classes and properties required for an RDF implementation of OMS, (ii) a
detailed mapping of SOSA terms to discrete requirements in OMS.
Note that OMS is formalized using UML, which does not provide accessible global identifiers for terms in the
structure model.
The URI for each formal Requirement relating to a class or property in OMS denotes the UML class or
property.
The predicate ogc-ms:implements and its inverse ogc-ms:implementedBy link a SOSA term to
the corresponding OMS class or property, defined as follows:
ogc-ms:implements a owl:ObjectProperty ;
rdfs:subPropertyOf dcterms:source , prov:wasDerivedFrom .
ogc-ms:implementedBy a owl:ObjectProperty ;
owl:inverseOf ogc-ms:implements .
Note
The OMS Extension Module implements most, but not all, of the classes and properties defined in [OMS].
Furthermore, the axioms in this module do not capture the details of the ranges of all properties.
Future editions of SSN may provide a more complete implementation.
6.1.2 OMS modules
6.1.2.1 SOSA-OMS
SOSA-OMS describes the implementation of ISO 19156:2023 [OMS] using terms from the SSN Ontology.
SOSA-OMS imports SOSA Observation and SOSA Sampling and declares additional terms required for OMS.
SOSA-OMS is the canonical RDF implementation of OMS.
SSN-OMS describes the implementation of ISO 19156:2023 [OMS] using terms from the SSN Ontology, with RDFS/OWL
axiomatization.
SSN-OMS imports SOSA-OMS and SSN Observation and SSN Sampling.
SSN-OMS is the canonical OWL implementation of OMS.
makes observation collection —
relation from a Platform to an ObservationCollection arising from a Deployment on the Platform
Note
In order to indicate potential Observations at a Platform, an empty ObservationCollection can be provided.
This mimics the semantics of the OMS ObservingCapability class.
The underlying property chain is represented in Figure 21.
Samples are often related to other samples by sub-sampling, topological relationships
(e.g., stations along a traverse, pixels within an image, probe spots on a polished section, or
specimens retrieved within a borehole),
or as parts of sample processing chains
(e.g., crushing, splitting, dissecting, or dissolving).
There is an essentially unlimited set of relationships between samples,
so the nature of the relationship has its own class.
This section describes a flexible model to describe such relationships between samples.
The model is based on the
QualifiedRelation
pattern.
The Sample-Relations graph imports SOSA and contains additional definitions associated with relationships
between samples.
The namespace for Sample relationships
terms is http://www.w3.org/ns/sosa/sampling/
The suggested prefix for the sample relationships namespace is sosa-rel
Adjacent flight-line
Females
Juveniles
Pixel within image or scene
Probe spot on polished specimen
Specimen taken from borehole
Split of core sample
Station along a traverse
Sub-sample with grain size smaller than specified seive mesh
The underlying structure of PROV is based around a process-flow model, with three base classes:
Entity, which is the class of physical, digital, conceptual, or
other kinds of things with some fixed aspects;
Activity, which is the class of things that occur over a period
of time and act upon or with entities, and it may include consuming, processing, transforming, modifying,
relocating, using, or generating entities;
Agent, which is the class of things that bear some form of
responsibility for an activity taking place, for the existence of an entity, or for another agent's activity.
The SSN ontology conceives executions (acts of actuation, observation, and sampling) as activities or events,
which result in a change in the world, or information being produced, or the production or transformation of a sample.
Alignment of SSN with PROV is natural.
Compton et al. [SSN-PROV] and Cox [OM-Lite] have described alignments of the [SSNX] and [OandM] models with
[prov-o].
The alignment described below (see Figure 23) is based on that work, and also extended to
consider actuation and sampling.
This section introduces the alignment of SSN with SAREF V4.1.1 [SAREF] and SAREF4SYST [SAREF_Patterns]. The ETSI portal for SAREF exposes the SAREF ontologies and points to the
different SAREF-related deliverables, which are open ETSI standards.
This section introduces the alignment of SSN with the Extensible Observation Ontology [OBOE].
OBOE is used within the biodiversity community for semantic representation of
observation data.
The ontology is composed of multiple modules.
The core observation elements are in the module OBOE-core.
An oboe:Observation is composed of a collection of oboe:Measurements concerning a single
oboe:Entity.
Each individual oboe:Measurement concerns a distinct oboe:Characteristic and uses a
distinct oboe:Protocol.
This aligns to a sosa:ObservationCollection whose member sosa:Observations each concern a different
sosa:observedProperty of a single sosa:hasFeatureOfInterest.
The properties oboe:hasMember and oboe:hasMeasurement link an oboe:ObservationCollection to its member
oboe:Observations, and an oboe:Observation to its member oboe:Measurements, respectively.
These match sosa:hasMember links to a sosa:ObservationCollection (with a single
sosa:hasFeatureOfInterest) and to the sosa:Observations of the different properties, respectively.
This section introduces the alignment of SSN with the
Industrial Data Ontology (IDO),
which is standardized as [ISO23726-3-DIS].
This serves to axiomatically clarify the intended meaning of SSN terms in terms of IDO and enable usage of SSN and
SOSA with IDO-aligned ontologies.
The upper-level classes from SSN are aligned with the IDO classes as follows.
The alignment of subclasses of these upper-level classes follows logically from these correspondences.
The upper-level object properties from SSN are aligned with the IDO properties as follows.
The alignment of subproperties of these upper-level properties follows logically from these correspondences.
Note
The definition of each IDO property is displayed as a tooltip when hovering over the concept.
This section introduces the alignment of SSN with the DOLCE UltraLite upper ontology [DUL] which was the core
dependency of the original version of SSN.
This serves to axiomatically clarify the intended meaning of SSN terms and will assist SSN and SOSA users wishing to
interoperate with other DUL-aligned ontologies.
Note, however, that the DUL alignment can be used independently to align SSN with more generic concepts/properties of
DUL.
Note
DUL is no longer maintained, since DOLCE was issued as an ISO Standard [DOLCE].
An alignment of SSN with DOLCE is provided in this edition of the SSN Ontology.
Note
The SOSA-DUL alignment has been relaxed with respect to the previous edition, to account for the different usage of
terms reported in 8. Common Patterns.
Only classes are aligned.
The upper-level classes from SSN are aligned with the DUL classes as follows.
The alignment of subclasses of these upper-level classes follows logically from these correspondences.
Due to the disjunctive (or) nature of several class alignments,
SOSA object properties are not aligned to specific DUL properties.
Instead, they can be understood to be uniformly aligned to the most general property,
dul:associatedWith,
to ensure compatibility and enable flexible integration with DUL-aligned ontologies.
Note
The definition of dul:associatedWith
is displayed as a tooltip when hovering over the concept.
7.6 DOLCE Alignment Module
This section introduces the alignment of the SOSA subset of SSN with the DOLCE upper ontology [DOLCE].
This serves to axiomatically clarify the intended meaning of SSN terms and will assist SSN and SOSA users wishing to
interoperate with other DOLCE-aligned ontologies.
The DOLCE alignment can be used independently to align SOSA with more generic concepts/properties of DOLCE.
The upper-level classes from SSN are aligned with the DOLCE classes as follows.
The alignment of subclasses of these upper-level classes follows logically from these correspondences.
CCO is a 'mid level ontology', based on BFO.
CCO provides modules for several sets of common concepts that may then be used in many application domains.
This includes specializations of the BFO classes that align with classes from SSN.
7.7.1 Namespaces
The following namespace prefixes are used in the alignment of SSN with BFO and CCO.
Most of these alignments are straightforward, but a few merit some explanation.
sosa:Observation is a subclass of cco:Sensing Process, which is "A Process that realizes a
Sensor Function or Sensor Role" but does not require a procedure to be followed.
A sosa:Procedure is a re-usable recipe or protocol or system datasheet, thus it is purely information
content.
In particular it describes the actions and settings that a system must implement.
This section discusses how to handle some common modeling questions.
8.1 Quantity Values and Units of Measure
The result of a sosa:Observation or a sosa:Actuation can be a quantity value with a numeric value
and a unit of measure.
Recommending a single way of representing quantitative results is is out of scope for this Recommendation.
Several options from external vocabularies are available for expressing quantities as OWL individuals, or as
datatypes.
The examples in this section are based on the use of qudt:QuantityValue from the Quantities, Units, Dimensions,
and Data Types ontologies [QUDT].
Another option is cdt:ucum from Custom Datatypes [CDT], but use of custom datatypes requires an extension
to standard RDF and OWL processors.
8.1.1 Single values
The following examples show an encoding of a single observation with a scalar result, as shown in
Figure 25.
A quantitative result can be represented as a qudt:QuantityValue.
In the following example unit:DEG_C is an
individual from the QUDT catalogue of units of measurement.
In a collection of observations or actuations the members will often use a common unit of measurement.
This can be specified at the level of the collection using
qudt:hasUnit.
Actuations, Observations, Samplings, and Deployments can be made on any entity in any context.
For many applications a domain-model has been previously defined.
This will include names and definitions for classes of entities in the domain.
As an example, applications in hydrology might refer to types such as watercourse, stream, river, reach,
storage, aquifer, lake, reservoir, spring, water-table, etc.
A property of an instance of any domain type may be observed using a sensor, or changed using an actuator,
or the entity may be sampled following a sampling procedure.
When this occurs, the domain entity is the feature of interest of the Execution.
Does this therefore require that classes in the domain model are defined as subclasses of
sosa:FeatureOfInterest?
No, absolutely not.
RDF and OWL entailments do not work that way.
The way the SSN Ontology addresses this issue is described in the following subsections.
There are different implications depending on whether you are using the simple
SOSA module, or the more expressive SSN module.
8.2.1 FeatureOfInterest in SOSA
In SOSA the domain and range indications use the Schema.org [schema-org] predicates
schema:domainIncludes and
schema:rangeIncludes.
For feature of interest, SOSA has:
merely says that things of type sosa:FeatureOfInterestmight be found as the object of
hasFeatureOfInterest statements.
No more, no less.
8.2.2 FeatureOfInterest in SSN
In SSN there are local (guarded) constraints, which can fix the range of a property
when it appears in the context of a member of a specific class.
Related to the feature of interest, SSN has:
However, this does not mean that the object of the statement must be declared to have
rdf:type sosa:FeatureOfInterest in advance, nor that this is its only type.
Rather, it means that
when an individual appears as the object of a statement
then it is automatically inferred to be of type sosa:FeatureOfInterestin addition to any other information that was already available about it, including any pre-existing type.
This does not require the derivation of domain types as subclasses of sosa:FeatureOfInterest.
It merely means that when a domain individual participates in an Execution (e.g., an Observation), the individual
becomes a member of the class sosa:FeatureOfInterestin addition to any pre-existing domain class.
In the context of SSN axiomatization, membership in the class sosa:FeatureOfInterest does not need to be
asserted explicitly, and does not need to be assigned prior to the involvement of an entity in a
sosa:Execution (or one of its subclasses) or sosa:Deployment.
Consider the following scenario (Figure 26, Figure 27).
There is an entity typed with a class from a domain model:
The SSN constraint shown above entails:
ex:YarraAboveDightsFalls rdf:type sosa:FeatureOfInterest . in addition to the type hydro:RiverReach already asserted.
In terms of set theory, the class hydro:RiverReach has a non-empty intersection with the class
sosa:FeatureOfInterest when a member of hydro:RiverReach participates in a
sosa:Observation (or any other subclass of sosa:Execution).
Domain types are not features-of-interest unless they are involved in Executions or Deployments.
The additional typing happens to individual members of the class 'automatically', by entailment, but not to the
domain class as a whole.
In some cases the feature of interest of the execution is not the ultimate thing that the act of actuation,
observation, or sampling is concerned with, but is an intermediate thing.
This might be a sample of the ultimate feature of interest, or a sample of a sample, etc.
The relationship between the proximate and ultimate feature of interest might be specified, such as a
sampling-chain.
If this relationship is recorded, then an ultimate feature of interest might be inferred.
Nevertheless, it is often the ultimate feature of interest that really matters to the data user, particularly for
discovery purposes.
This requirement is met using the hasUltimateFeatureOfInterest
property as shown in Figure 29.
Many observation workflows rely on a chain of samples.
For such scenarios, understanding the provenance of the sample which is the (proximate) feature of interest for
observations is important.
Knowing either the original sample or the initial feature of interest at the base of the chain is useful for both
discovery and management purposes.
For example, gas bubbles from ice-cores are examined in climate research.
The ice-core is a sample of the ice-sheet, while the bubble taken from the core is a sample of an ancient
atmosphere (Figure 30).
The two samples have different values for the isSampleOf property, reflecting the
different hasFeatureOfInterest values for the separate acts of
Sampling.
The bubble is also a sample of the atmosphere, which is a feature of interest for the observations.
Figure 31 shows a more complex scenario.
This involves many samples derived from an initial one, with some relationships that may be useful in processing and
discovery of subsequent observations.
The intention of most of the observations is to characterize various aspects of the original sample,
which is representative of an ultimate feature of interest.
This is supported by two additional properties for relationships between samples and features of interest at
specific points in the chain:
hasOriginalSample and
isSampleOfUltimateFOI.
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 that was sampled allows discovery of many samples that
are intended to be representative of that feature, and the observations on them.
Note that the scenario in Figure 31 is simplified from real-life
scenarios, and also that the diagram only shows a subset of the full set of resources and relationships.
8.5 Time series
Many executions are made as parts of a time series.
There are a number of ways these may be modeled using the SSN Ontology.
The most explicit representation has each member of the series as an individual member of a Collection.
For example Figure 32 shows a Collection of
Observations that has a member for each time-step in the series.
Alternatively, the series may be represented as a single Observation whose result is
a complex value, such as a vector or array.
This may be indicated 'inline' as a complex literal, e.g. CSV:
@prefixex:<https://example.org/data/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefixskos:<http://www.w3.org/2004/02/skos/core#> .
@prefixsosa:<http://www.w3.org/ns/sosa/> .
@prefixtime:<http://www.w3.org/2006/time#>.
@prefixunit:<http://qudt.org/vocab/unit/> .
@prefixxsd:<http://www.w3.org/2001/XMLSchema#> .
@base<https://example.org/data/tsoi/> .
ex:ts159iasosa:Observation ;
sosa:hasFeatureOfInterestex:station223 ;
sosa:observedPropertyex:p1 ;
sosa:madeBySensorex:fooglemeter39 ;
sosa:phenomenonTime [
atime:Interval ;
time:hasBeginning [
atime:Instant ;
time:inXSDDateTime"2017-04-15T20:00:00+00:00"^^xsd:dateTime
] ;
time:hasEnd [
atime:Instant ;
time:inXSDDateTime"2017-04-15T20:03:00+00:00"^^xsd:dateTime
] ;
] ;
sosa:resultTime"2017-04-15T20:03:30+00:00"^^xsd:dateTime ;
sosa:hasSimpleResult"""2017-04-15T20:00:00+00:00,3.24
2017-04-15T20:01:00+00:00,3.21
2017-04-15T20:02:00+00:00,3.15
2017-04-15T20:03:00+00:00,3.15"""^^ex:SpeedObservationCSVRecord ;
rdfs:comment"""The result of this observation is encoded as a CSV literal.
The CSV has four rows each representing a member of the time-series.
The CSV structure is defined in the datatype definition."""@en ;
.
ex:station223asosa:FeatureOfInterest .
ex:p1asosa:Property .
ex:fooglemeter39asosa:Sensor .
ex:SpeedObservationCSVRecordardfs:Datatype ;
rdfs:comment"""Datatype definition for CSV-encoded data records conforming to the speed observation data model.
The speed observation data model is defined using the OGC SWE Data Model given as the object of ex:asSWEDataModel.
The formal definition of this datatype (a lexical space, value space, lexical-to-value mapping) is left unspecified in this example.""" ;
ex:asSWEDataModel"""{
"type": "DataRecord",
"label": "Speed Observation",
"fields": [
{
"name": "time",
"type": "Time",
"definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
"referenceFrame": "http://www.opengis.net/def/trs/BIPM/0/UTC",
"label": "Sampling Time",
"uom": {
"href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
}
},
{
"name": "speed",
"type": "Quantity",
"definition": "http://qudt.org/vocab/quantitykind/Speed",
"label": "Vehicle Speed",
"uom": {
"code": "m/s",
"href": "https://qudt.org/vocab/unit/M-PER-SEC"
}
}
]
}"""^^rdf:JSON ;
.
In this example, an OGC SWE Common DataRecord ([SWE-Common], [SWE-Common-JSON]) is used to
define an RDF Datatype that encodes data records encoded in CSV.
The result of a time series observation can also be 'linked' to an external resource:
@prefixex:<https://example.org/data/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#>.
@prefixsosa:<http://www.w3.org/ns/sosa/> .
@prefixtime:<http://www.w3.org/2006/time#>.
@prefixunit:<http://qudt.org/vocab/unit/> .
@prefixxsd:<http://www.w3.org/2001/XMLSchema#> .
@base<https://example.org/data/tsol/> .
ex:ts159lasosa:Observation ;
sosa:hasFeatureOfInterestex:station223 ;
sosa:observedPropertyex:p1 ;
sosa:madeBySensorex:fooglemeter39 ;
sosa:phenomenonTime [
atime:Interval ;
time:hasBeginning [
atime:Instant ;
time:inXSDDateTime"2017-04-15T20:00:00+00:00"^^xsd:dateTime
] ;
time:hasEnd [
atime:Instant ;
time:inXSDDateTime"2017-04-15T20:03:00+00:00"^^xsd:dateTime
] ;
] ;
sosa:resultTime"2017-04-15T20:03:30+00:00"^^xsd:dateTime ;
sosa:hasResult<https://example.org/data/tso/netcdf/ts159> ;
rdfs:comment"The result of the observation is accessed using the URI https://example.org/data/tso/netcdf/ts159 (notional)."@en ;
.
ex:station223asosa:FeatureOfInterest .
ex:p1asosa:Property .
ex:fooglemeter39asosa:Sensor .
In addition to the encodings shown above, terms from SOSA can be directly integrated into existing structures, such
as OGC Coverages [CoverageJSON].
In such cases, it is no longer necessary to provide a paired Observation.
8.6 Location and Geometry
8.6.1 Location
Many of the key classes provided by SOSA and SSN represent entities that can be located in space such as
sensors, features of interest, actuators, samples, and so forth, or activities that can be located via their
participating entities, e.g., platforms.
These entities will usually be described using models and ontologies defined for application domains,
including technical disciplines, social and business contexts.
In these contexts there are a number of implementations that support the expression of spatial properties,
including location.
These are discussed further in the Spatial Data on the Web Best Practices note [SDW-BP].
In particular, GeoSPARQL [GeoSPARQL] provides a flexible and relatively complete platform for geospatial
objects, that fosters interoperability between geo-datasets.
The property geo:hasGeometryMAY be used to attach a geometry or location to any entity.
Note that geo:hasGeometry has a global domain constraint which entails that any resource carrying this
property SHALL be inferred to be a geo:Feature
(GeoSPARQL 1.1,
clause 8.4.1).
In case of classes, e.g., specific types of features of interest such as rivers, these MAY be explicitly defined as
subclasses of geo:Feature.
8.6.1.1 Systems, Platforms, Deployments
A number of patterns may be used to characterize the location of a System, depending on
how much detail about Platforms and Deployments is useful.
For example, a System, such as a Sensor, might be permanently in one specific location,
described as follows:
Similarly, Location can be associated directly or indirectly with a Sample.
Observations of the atmosphere are necessarily made at a specific location.
The location of an air Sample might be recorded directly using the following pattern:
location of sensor and feature of interest are the same
remote sensing
location of sensor is remote from the feature of interest
ex situ observation (e.g., lab measurements)
location of sensor and location of the ultimate feature of interest are different; result-time later than
phenomenon-time
Note that in ex situ measurements, there will usually be a Sample and thus an act of
Sampling involved, whose properties determine the location and phenomenon-time.
8.6.3 Geometry results
Geometry may appear in other contexts.
For example, a determination of location using a GPS receiver can be described as an
Observation whose hasResult value is a geometry.
The following example illustrates this pattern, with the result being a GeoSPARQL Geometry object:
Multiple times are associated with an Execution.
Trivially, since an Execution is a time-bounded activity, there is a startTime and
endTime.
In the case of Observation and Sampling the end of the
Execution is the time that the result is generated so it is called resultTime.
In the case of Actuation and Observation the
phenomenonTime is the interval when the change or result applies to the actuated
or observed property.
In the simplest case, an Execution is instantaneous and all these times are the same.
More commonly, these times are different.
Different kinds of executions have different relationships between these times.
8.7.1 Forecasts
A forecast may be represented as an observation where the value of sosa:phenomenonTime is later in
time than the sosa:resultTime (Figure 39).
The time when the observation execution was completed is before the time that the result of the observation applies
to the FeatureOfInterest.
Other means to represent forecasts are reported, but not in the scope of this specification.
For example [Lefrancois-et-al-2017] adapt the SSN Sensing/Sensor/Observation
pattern to derive explicit Forecasting/Forecaster/Forecast classes.
Note
Describing a plan for some actuation or observation in the future is not covered by this
specification.
8.7.2 Historical observations
Observations in historical sciences, including geology and archeology, may be made to determine the state of the
world in the past.
8.7.2.1 Historical observations — simple cases
Consider a determination of the diet of past communities by examination of middens and other archaeological features
(Figure 40)
8.7.2.2 Historical observation — from combination of separate observation of time and property
The concentration of CO2 can be measured in bubbles in ice-cores that are assumed to sample the
atmosphere at some past time.
In this case, the concentration and age are the results of two initial observations (at the top of
Figure 42).
These provide input values to the final observation (at the bottom of Figure 42).
Where an individual Collection omits a property, a member (direct or transitive) MAY have any
value for that property.
The properties sosa:hasFeatureOfInterest, sosa:phenomenonTime,
sosa:hasSimpleResult are not specified on the collection, but are provided individually on each member.
@prefixex:<https://example.org/sosa/collection-rule-1/> .
@prefixqk:<http://qudt.org/vocab/quantitykind/> .
@prefixqudt:<http://qudt.org/schema/qudt/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefixsosa:<http://www.w3.org/ns/sosa/> .
@prefixtime:<http://www.w3.org/2006/time#>.
@prefixunit:<http://qudt.org/vocab/unit/> .
@prefixxsd:<http://www.w3.org/2001/XMLSchema#> .
ex:oc1asosa:ObservationCollection ;
sosa:hasMemberex:a11 ;
sosa:hasMemberex:a12 ;
sosa:madeBySensorex:T56 ;
sosa:observedPropertyqk:Temperature ;
qudt:hasUnitunit:DEG_C ;
rdfs:comment"""
The properties madeBySensor, observedProperty, and hasUnit are given for the collection.
""" ;
.
ex:a11asosa:Observation ;
sosa:hasFeatureOfInterestex:F1 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T20:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult24.1 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the values for the collection.
""" ;
.
ex:a12asosa:Observation ;
sosa:hasFeatureOfInterestex:F2 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T22:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult27.3 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the values for the collection.
""" ;
.
ex:F1asosa:FeatureOfInterest ;
rdfs:comment"Room #1" ;
.
ex:F2asosa:FeatureOfInterest ;
rdfs:comment"Room #2" ;
.
ex:T56asosa:Sensor ;
rdfs:comment"Thermometer #56" ;
.
qk:Temperatureasosa:Property ;
.
8.8.2 Rule 2 — single property value on the collection
Where an individual Collection has a single value for a property, each member (direct or
transitive) MUST have that same value for that property i.e., the collection (set) is homogeneous in
that property.
That property MAY then be omitted in any member.
The properties sosa:observedProperty, sosa:madeBySensor, qudt:hasUnit are
specified on the collection with single values, which apply to every member.
A member that also specifies sosa:observedProperty individually has the same value as the collection.
@prefixex:<https://example.org/sosa/collection-rule-2/> .
@prefixqk:<http://qudt.org/vocab/quantitykind/> .
@prefixqudt:<http://qudt.org/schema/qudt/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefixsosa:<http://www.w3.org/ns/sosa/> .
@prefixtime:<http://www.w3.org/2006/time#>.
@prefixunit:<http://qudt.org/vocab/unit/> .
@prefixxsd:<http://www.w3.org/2001/XMLSchema#> .
ex:oc2asosa:ObservationCollection ;
sosa:hasMemberex:a21 ;
sosa:hasMemberex:a22 ;
sosa:madeBySensorex:T56 ;
sosa:observedPropertyqk:Temperature ;
qudt:hasUnitunit:DEG_C ;
rdfs:comment"""
The properties madeBySensor, observedProperty, and hasUnit are given for the collection.
""" ;
.
ex:a21asosa:Observation ;
sosa:observedPropertyqk:Temperature ;
sosa:hasFeatureOfInterestex:F1 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T20:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult24.1 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The property observedProperty matches the value for the collection.
The properties madeBySensor and hasUnit are inferred from the value for the collection.
""" ;
.
ex:a22asosa:Observation ;
sosa:hasFeatureOfInterestex:F2 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T22:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult27.3 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The properties madeBySensor, observedProperty, and hasUnit are inferred from the value for the collection.
""" ;
.
ex:F1asosa:FeatureOfInterest ;
rdfs:comment"Room #1" ;
.
ex:F2asosa:FeatureOfInterest ;
rdfs:comment"Room #2" ;
.
ex:T56asosa:Sensor ;
rdfs:comment"Thermometer #56" ;
.
qk:Temperatureasosa:Property ;
.
8.8.3 Rule 3 — multiple property values on the collection
Where an individual Collection has more than one value for a property, each member (direct or
transitive) MUST have a value for that property that matches one of the values for the property in the
collection.
The collection specifies a multiple values for sosa:hasFeatureOfInterest.
Each member has a value for sosa:hasFeatureOfInterest taken from this set of values.
@prefixex:<https://example.org/sosa/collection-rule-3/> .
@prefixqk:<http://qudt.org/vocab/quantitykind/> .
@prefixqudt:<http://qudt.org/schema/qudt/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefixsosa:<http://www.w3.org/ns/sosa/> .
@prefixtime:<http://www.w3.org/2006/time#>.
@prefixunit:<http://qudt.org/vocab/unit/> .
@prefixxsd:<http://www.w3.org/2001/XMLSchema#> .
ex:oc3asosa:ObservationCollection ;
sosa:hasMemberex:a31 ;
sosa:hasMemberex:a32 ;
sosa:madeBySensorex:T56 ;
sosa:observedPropertyqk:Temperature ;
sosa:hasFeatureOfInterestex:F1 , ex:F2 ;
qudt:hasUnitunit:DEG_C ;
rdfs:comment"""
The properties madeBySensor, observedProperty, and hasUnit are given for the collection.
The property hasFeatureOfInterest has multiple values.
""" ;
.
ex:a31asosa:Observation ;
sosa:hasFeatureOfInterestex:F1 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T20:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult24.1 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The value of hasFeatureOfInterest matches one of the set of values for the collection.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the value for the collection.
""" ;
.
ex:a32asosa:Observation ;
sosa:hasFeatureOfInterestex:F2 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T22:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult27.3 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The value of hasFeatureOfInterest matches one of the set of values for the collection.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the value for the collection.
""" ;
.
ex:F1asosa:FeatureOfInterest ;
rdfs:comment"Room #1" ;
.
ex:F2asosa:FeatureOfInterest ;
rdfs:comment"Room #2" ;
.
ex:T56asosa:Sensor ;
rdfs:comment"Thermometer #56" ;
.
qk:Temperatureasosa:Property ;
.
8.8.4 Rule 4 — range property value on the collection
Where an individual Collection has a value for a property that is a range or interval, each
member (direct or transitive) MUST have a value for that property that matches or falls within that
range or interval.
The collection specifies a range of values for sosa:phenomenonTime.
Each member has a value for sosa:phenomenonTime that falls within the range.
@prefixex:<https://example.org/sosa/collection-rule-4/> .
@prefixqk:<http://qudt.org/vocab/quantitykind/> .
@prefixqudt:<http://qudt.org/schema/qudt/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefixsosa:<http://www.w3.org/ns/sosa/> .
@prefixtime:<http://www.w3.org/2006/time#>.
@prefixunit:<http://qudt.org/vocab/unit/> .
@prefixxsd:<http://www.w3.org/2001/XMLSchema#> .
ex:oc4asosa:ObservationCollection ;
sosa:hasMemberex:a41 ;
sosa:hasMemberex:a42 ;
sosa:madeBySensorex:T56 ;
sosa:observedPropertyqk:Temperature ;
sosa:phenomenonTime [
atime:Interval ;
time:hasBeginning [
atime:Instant ;
time:inXSDDateTime"2022-05-01T20:00:00+00:00"^^xsd:dateTime ;
] ;
time:hasEnd [
atime:Instant ;
time:inXSDDateTime"2022-05-01T23:00:00+00:00"^^xsd:dateTime ;
] ;
] ;
qudt:hasUnitunit:DEG_C ;
rdfs:comment"""
The properties madeBySensor, observedProperty, and hasUnit are given for the collection.
The property phenomenonTime has value range.
""" ;
.
ex:a41asosa:Observation ;
sosa:hasFeatureOfInterestex:F1 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T20:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult24.1 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The value of phenomenonTime falls within the value range for the collection.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the value for the collection.
""" ;
.
ex:a42asosa:Observation ;
sosa:hasFeatureOfInterestex:F2 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T22:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult27.3 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The value of phenomenonTime falls within the value range for the collection.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the value for the collection.
""" ;
.
ex:F1asosa:FeatureOfInterest ;
rdfs:comment"Room #1" ;
.
ex:F2asosa:FeatureOfInterest ;
rdfs:comment"Room #2" ;
.
ex:T56asosa:Sensor ;
rdfs:comment"Thermometer #56" ;
.
qk:Temperatureasosa:Property ;
.
8.8.5 Rule 5 — multiple ranges property value on the collection
Where an individual Collection has more than one value for a property that is a range or
interval, each member (direct or transitive) MUST have a value for that property that matches or
falls within one of those ranges or intervals.
The collection has two ranges of values for sosa:phenomenonTime.
Each member has a value for sosa:phenomenonTime that falls within one of the ranges.
@prefixex:<https://example.org/sosa/collection-rule-5/> .
@prefixqk:<http://qudt.org/vocab/quantitykind/> .
@prefixqudt:<http://qudt.org/schema/qudt/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefixsosa:<http://www.w3.org/ns/sosa/> .
@prefixtime:<http://www.w3.org/2006/time#>.
@prefixunit:<http://qudt.org/vocab/unit/> .
@prefixxsd:<http://www.w3.org/2001/XMLSchema#> .
ex:oc5asosa:ObservationCollection ;
sosa:hasMemberex:a51 ;
sosa:hasMemberex:a52 ;
sosa:madeBySensorex:T56 ;
sosa:observedPropertyqk:Temperature ;
sosa:phenomenonTime [
atime:Interval ;
time:hasBeginning [
atime:Instant ;
time:inXSDDateTime"2022-05-01T20:00:00+00:00"^^xsd:dateTime ;
] ;
time:hasEnd [
atime:Instant ;
time:inXSDDateTime"2022-05-01T21:00:00+00:00"^^xsd:dateTime ;
] ;
] , [
atime:Interval ;
time:hasBeginning [
atime:Instant ;
time:inXSDDateTime"2022-05-01T22:00:00+00:00"^^xsd:dateTime ;
] ;
time:hasEnd [
atime:Instant ;
time:inXSDDateTime"2022-05-01T23:00:00+00:00"^^xsd:dateTime ;
] ;
] ;
qudt:hasUnitunit:DEG_C ;
rdfs:comment"""
The properties madeBySensor, observedProperty, and hasUnit are given for the collection.
The property phenomenonTime has multiple value ranges.
""" ;
.
ex:a51asosa:Observation ;
sosa:hasFeatureOfInterestex:F1 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T20:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult24.1 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The value of phenomenonTime falls within one of the value ranges for the collection.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the value for the collection.
""" ;
.
ex:a52asosa:Observation ;
sosa:hasFeatureOfInterestex:F2 ;
sosa:phenomenonTime [
atime:Instant ;
time:inXSDDateTime"2022-05-01T22:33:40+00:00"^^xsd:dateTime ;
] ;
sosa:hasSimpleResult27.3 ;
rdfs:comment"""
The properties hasFeatureOfInterest, phenomenonTime, and hasSimpleResult are specific to this individual member
The value of phenomenonTime falls within one of the value ranges for the collection.
The properties madeBySensor, observedProperty, and hasUnit are inferred from the value for the collection.
""" ;
.
ex:F1asosa:FeatureOfInterest ;
rdfs:comment"Room #1" ;
.
ex:F2asosa:FeatureOfInterest ;
rdfs:comment"Room #2" ;
.
ex:T56asosa:Sensor ;
rdfs:comment"Thermometer #56" ;
.
qk:Temperatureasosa:Property ;
.
8.9 Homogeneous collection of observations
A collection of observations may share a common value for one or more of the characteristic observation
properties.
For example:
Many monitoring processes generate a stream of data.
Only the (phenomenon-) time changes between consecutive results for the same property on a single feature of
interest.
The property is observed using the same procedure, implemented using the same sensor.
A sensor network typically generates a set of results, over the same time interval, for the same
property(ies), over a suite of features-of-interest.
Imaging sensors are a special case of this, where the proximate features-of-interest
correspond with individual pixels in the result.
These patterns can be accommodated with the class ObservationCollection.
The value of the property(ies) of the collection that are present 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, Figure 43 describes a collection of remote sensing observations
using the same sensor on different scenes, while Figure 44 is a series of the
same scene on different days.
Figure 43A set of remote sensing observations of different scenes on the same dayFigure 44A 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 (Figure 45).
Figure 45Example 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 (Figure 46).
Figure 46Alternative 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.
Note
This feature might also apply to collections of Actuations but this application has not yet been
explored.
8.10 Planning executions and collections
Assets (Systems or Platforms) may be deployed with the intention of making Executions (Actuations, Observations, or
Sampling) at some future time.
Collections of Samples or Executions can be described ahead of their completion, to indicate the intention
to make collections with the given properties at a future date.
Here we describe patterns that may be used in this way.
For example, Figure 47 describes the deployment of a specific sosa:Sampler
(ex:SA56) on a specified sosa:Platform (ex:LOIRE_A_JARGEAU_WQ_Station) on the Loire River between
2026 and 2028.
This Sampler implements a nominated sosa:SamplingProcedure.
It may be associated with a potential set of Samples, packaged in an empty sosa:SampleCollection
(ex:SC-LaJ1).
The resulting SampleCollection has no members prior to the deployment, but can be characterized prospectively in
terms of
the SamplingProcedure and Platform (station) used.
For example, Figure 48 describes a potential set of samples (ex:SC-LaJ2) of
the Loire River, packaged in a sosa:SampleCollection, collected from a specified sosa:Platform,
using a given sosa:SamplingProcedure (ex:Sp-A56).
The actual sosa:Sampler is not specified, only that it must implement the nominated SamplingProcedure,
and be deployed at the nominated station.
Each of these uses a distinct ontology — or way of formalizing the definition of a property — suitable
for many applications.
8.11.2 New property definitions
Alternatively, the Parameter Usage Vocabulary or I-ADOPT [I-ADOPT] may be used to define a new sosa:Property.
For example, integrating I-ADOPT Variables may resolve legacy inconsistencies by decomposing complex properties into explicit, interoperable atomic components.
This may enrich SOSA observables with reusable, machine-actionable semantics, lowering barriers to cross-system data comparison and sharing.
Figure 50 and Figure 51 show the application of the I-ADOPT ontology for the properties used in two initial observations to provide input-values for the final observation (cmp. Example 20).
As demonstrated, the I-ADOPT Variable remains strictly decoupled from procedural metadata and value expressions. Methodological details, such as Radiocarbon (C-14) dating, are explicitly captured via the observation's measurement procedure (sosa:usedProcedure), preserving the reusable, context-independent structure of the variable itself.
The primary objective of the I-ADOPT framework is to represent a variable as an identifiable and reusable concept that is decomposed into its atomic components. By assigning specific descriptive roles, such as Object of Interest, Matrix, or Context Object, and mapping each component to URIs from domain-specific vocabularies, I-ADOPT ensures full semantic clarity.
The variable URI can then be used as the value of the sosa:actsOnProperty or sosa:observedProperty of an Execution.
8.11.3 Feature-specific properties
Most commonly an instance of sosa:Property is generic to many
features of interest (e.g., ex:Temperature, ex:Concentration, or ex:OnOffStatus).
These shared properties are then used across executions. For instance, thousands of observations about CO2 concentrations
all share the same ex:Concentration property, thereby ensuring scalability, indexing, interoperability, reuse,
and a concise semantics. Similarly, one could define ex:CO2Concentration as a subproperty of
ex:Concentration using a single axiom. This new property (and resulting hierarchy) can then be used to distinguish
CO2 concentration observations from more general concentration observations without giving up on their commonality
with other types of concentration observations. This improves structure and retrieval. The catalogs listed above support this usage.
Alternatively, an individual property may be made specific to an individual feature of interest using
sosa:isPropertyOf
(e.g., ex:SickChildATemperature, ex:Room34LightStatus).
Such specific properties of individual features would not usually appear in a catalogue of reusable properties and can potentially
lead to reduced reuse and performance (due to data size and indexing). However, this pattern has proven useful in some applications.
In that context, a key requirement is to relate the specific property to the general case for the underlying
quantity-kind and -dimension.
The [SAREF] ontologies address this requirement with separate classes:
saref:Property for the general case, and saref:PropertyOfInterest for the case where a
property is bound to a single feature of interest.
An instance of the latter may be connected to an instance of the former using the predicate
saref:hasPropertyKind, as shown in the following example:.
Where a property is defined as applying to a specific feature of interest, it cannot be used for an observation
concerning any other feature of interest.
Multiple sensors and actuators may be packaged in a complex device.
For example, the consumer grade Inkbird IBS-TH2-PLUS
has a temperature and relative-humidity sensor in a single package.
The sosa:System class provides for this using the sosa:hasSubSystem property.
Figure 52 shows how an instance and type of the IBS-TH2-PLUS may be modeled as a complex
sensor.
The following code snippet provides an outline of the details:
sosa:System is the class of systems, devices or entities that implements procedures to make actuations, observations, or samplings.
Members of the class are individual systems i.e., system-instances.
In the physical world these will typically carry a serial-number (devices) or proper-name (people).
Nevertheless, most individual systems share a primary description with other individuals of the same system
type or model number.
The characteristics and capabilities of the system type will often provide the key information
about a system involved in an execution.
Traditionally this information would appear in a specification or datasheet for a device type.
The SSN Ontology may be used to describe system types as OWL Classes, so that system instances can be typed
through them.
The recommended pattern is for
This approach is a clarification and adjustment relative to earlier editions of this Ontology, which suggested that
instances of sosa:System could represent either generic systems or instances
specific to a single execution.
More complex systems can be described using class definitions with OWL Restrictions to fix specific
properties of class members.
For example, the following code illustrates how a sensor package, such as an
Inkbird model IBS-TH2-PLUS, may be described.
sensor:IBS-TH2-Plus describes the IBS-TH2-PLUS system type.
Every IBS-TH2-PLUS package records at a frequency in the range 5.556e-4 — 0.1 Hertz.
Every IBS-TH2-PLUS has two subsystems, one temperature sensor, and one relative-humidity sensor.
sensor:IBS-TH2-Plus-H describes the humidity sensor type in the IBS-TH2-PLUS
package.
Every humidity sensor has a range 0—99 % RH with an accuracy of 4.5 %.
sensor:IBS-TH2-Plus-T describes the temperature sensor type in the
IBS-TH2-PLUS package.
Every temperature sensor has a range -40—60 °C with an accuracy of 4.5 %.
A. Wide review
This section is non-normative.
TBC
B. Tabulation of properties and their inverses
This section is non-normative.
To support interoperability across a range of applications, inverses are named for all SSN object properties.
Note
Terms added in the 2023 Edition are indicated with an asterisk*.
A set of extended examples of instances using the SSN ontology are available in the examples folder.
D. System Capabilities Module
This section is non-normative.
The System Capabilities Module imports SOSA and adds classes and properties required for the description of the
operating conditions and capabilities of systems, in particular Sensors and Actuators.
The complexity of the SSN/SOSA ontologies is directly due to the complexity of the use-cases that they are
meant to support. Previous standards and data formats have been limited by the constraints of their
underlying technologies often resulting in solutions that were simple to implement but that could only
handle real-life exceptions through the use of workarounds. The use of "fill
values" or "magic numbers" were a simple and common solution to data quality requirements or to
indicate equipment
failure. Unfortunately, these could later be inadvertently analyzed as actual instrument readings.
The richness of RDF/S and ontological approaches offer opportunities for the rich and deep recording of system
information and results. This perversely creates a new problem in that the ability to handle complexity can
make implementation difficult and costly for implementers that are simply
trying determine whether their ice cream is about to melt. The very richness of the semantic web
ecosystem also makes it tempting to over-specify data structures to an extents that it becomes inflexible.
The authors often wrestled with these issues when designing this standard and attempting to support the complexity
of real-life deployments: data quality constraints must ensure that the data is sensical while making allowanced
for the storage of out-of-bounds values that may indicate a problem with a deployed sensor.
The System Capabilities module has been downsized in this edition and its vocabulary extensively reworked with a
number of
classes deleted in favor of external vocabularies and property repositories. The module further suffered from under
specification
and lacked documentation over its intended use.
The usage of observations and
observation collections has been expanded
to capabilities and conditions through the enumeration of values and constraints on those values without assigning a
reporting sensor or timestamp.
This allows to reuse the same structure to report on sensor behavior.
This edition has also removed the notion of "Ranges" within its vocabulary due to the absence of an
appropriate datatype or vocabulary to
describe numerical ranges. xsd:minInclusive/xsd:maxInclusive are part of OWL reserved vocabulary, and
schema:minValue/schema:maxValue created additional
problems relating to the property of the feature. Instead, this edition recommends the specification of individual,
simple properties such as
MinMeasurableTemperature and MaxMeasurableTemperature. Apart from
hasValidityContext, this edition does not
provide means to relate properties or describe them further. External ontologies are expected to be complementary to
this module, such as the
I-ADOPT Framework ontology, and the
Ontology of Units of Measure.
The namespace for the System Capabilities Module is http://www.w3.org/ns/sosa/.
The suggested prefix for the System Capabilities Module namespace is sosa.
System Capabilities was a module in the 'Horizontal Segmentation' section of the previous edition of the SSN
Ontology [vocab-ssn-20171019].
This module has been heavily simplified and moved to Appendix in this edition.
D.1 Overview
This section is non-normative.
The System Capabilities Module comprises of two primary concepts: the system's capability to sense and the
conditions
under which it can do so. Both concepts are closely related and are often described as one and the same in
industrial
literature. The System Capabilities describes the properties of the measurement being performed by the system
while the
Operating Conditions describe the potentials environments in which the system is deployed. This separation is
needed in order
to account for the variability in the performance of the system under different environmental or operating
parameters.
Furthermore:
Some systems depend on unreported environmental measurements in order to produce results (e.g., temperature
is a component of
the relative humidity calculation)
Some systems have requirements for proper operation for properties that they are unable to sense themselves
(e.g., minimum power supply voltage)
The performance of some systems may vary depending on the environmental context (e.g., the accuracy of a
frequency counter
may be affected by ambient temperature.)
This information allows designers to communicate complex operating behavior to the consumer of the system results
and to
simplify procurement and system deployment decision by enabling searches for systems capable of fulfilling a
specific
requirement.
The reporting of operating conditions and capabilities is done through
observation collections that aggregate
observations.
Each observation gives a value for a system or environment property.
The information is typically provided by a system vendor, and in this context sensor, procedure, and timestamp
are generally not reported.
Reuse of sosa:Observation in this way ensures consistency in reporting values across the ontology,
which is particularly helpful when the same observation can be used for reporting both a capability and
operating condition.
Note that this is application dependent, and nuances may prevent reuse: for example, a thermometer's
capability is based on its ability to measure a medium while its survival conditions are based on its own
physical temperature.
For illustration purposes, this specification includes a
sample vocabulary consisting of a short
list of properties about the system environment.
It is possible with additional ontological statements to create conditions that are "latching", as
in the case of
damaged sensors with permanently degraded operating characteristics. It is also possible to describe
operating modes of systems
using all the expressivity of observations and observation collections. Implementers may define additional
sub-classes of
OperatingConditions to account for such use cases.
Note
The feature of interest of the operating conditions may be the
system itself, but this is not mandatory.
The sensor that made the observations can be left unspecified.
The following example describes that sensor ex:InkBird-IBS-TH2-0354313547 can survive from
-273.0 °C to 80.0 °C.
For illustration purposes, this specification includes a
sample vocabulary consisting of a short
list of properties about system capabilities.
Optionally, system capabilities may be linked through property
hasValidityContext to some
observations or
observation collections that model the context under
which the system capabilities are valid. These observations are typically about the system environment.
Validity contexts are especially useful to describe performance bands of systems.
Examples include environmental sensors that present different measurement accuracies in certain
concentration ranges or that offer
detection-only capabilities at very low concentrations.
Note
For illustration purposes, this specification includes a
sample vocabulary consisting of a short
list of properties about the system environment.
System Capabilities are properties that are relevant while the system is in operation. Operating Conditions
may be relevant irrespective of
the operating state; a sensor that exceeds its SurvivableConditions
will be rendered inoperable
irrespective of whether it was powered on or off at the time, as in the case of a deep water sensor reaching
its crush-depth.
The following example describes the system capabilities of sensor ex:IBS-TH2-Plus-T-687343 in
terms of its accuracy
and measurable temperature range, valid from 0.0 to 99.0 %R.H.
The object property hasValidityContext may be used to qualify the
context in which a SOSA Property is valid. This context is modelled as
individual observations or as grouped
observation collections. When the qualified
Property represents a system capability,
the observed properties in the validity context typically refer to aspects of the system's operating
environment.
For example, water heaters are characterized by nominal power and efficiency values under specified inlet
and outlet temperatures and flow rates, and their energy consumption at steady temperature is typically
expressed in kWh/24h in the context where the water temperature is maintained at 65 °C.
Note
Beyond the scope of the System Capabilities module, Properties may
also be further described with validity contexts.
For example standard meteorological practice defines reference measurement heights, such as 10 m for
wind and 2 m for air temperature.
The following example describes the humidity accuracy property ex:IBSTH2HumidityAccuracy, valid
at certain temperatures and relative humidities.
The advantage of this approach is that multiple statistical statements can be made about the property beyond
that of simple
maximum / minimum values, such as nominal or peak values.
The Observation structure can similarly be used to report on the quality of individual results using the Data
Quality Vocabulary. In some applications, the properties of individual measurements vary within the
operating conditions of the sensor.
The values of these properties can then be reported alongside the individual result entries.
The System Capabilities Module also introduced a Battery class to represent power
supply requirements for mobile sensors.
The illustrative sosa-cap:BatteryLifetime system
capability property allows to record expected battery
utilization either on a nominal basis or within different operating conditions.
Battery —
A Battery powering a System as its primary or secondary power source.
As this is a specialization of the System class, modeling of integrated battery
management systems is also possible.
has operating conditions —
Relation between a System and its Operating Conditions, modelled as ObservationCollection (or Observation)
describing
conditions under which the System can operate. A short but extensible list of sub-classes of
OperatingConditions is
provided in SSN-System, such as normal operating conditions, suboptimal operating conditions, and survivable
conditions.
has System Capability —
Relation between a System and an ObservationCollection (or Observation) describing
the capability of the system. A sensor or system may have more than one set
of system capabilities with different validity contexts.
has validity context —
Links an observation collection or observation (typically about the system capabilities) or a property
(typically about
the system capabilities) to its validity context, described as an observation collection or observation
(typically about the system environment)
Normal Operating Conditions —
Type of observation or
observation collection that describe the conditions under which a
system is expected to operate normally.
Suboptimal Operating Conditions —
Type of observation or
observation collection that describe the conditions under which a
system is expected to operate sub-optimally. Results will still be reported but the
performance of the sensor, in term of precision for example, will be impaired.
Survivable Conditions —
Type of observation or
observation collection that describe the conditions under which a
system is expected to survive, that is to continue to exist in its current form, even
if its future operations are impaired. A typical example is the temperature at which a sensor loses
physical
integrity and loses its shape. A system or sensor exposed to conditions outside of those reported by
SurvivableConditions
will no longer be serviceable.
For illustration purposes, this section describes sample vocabularies consisting of short lists of properties
about system capabilities and the system environment.
Warning
These vocabularies have been partially generated by a large language model and are intended for illustrative
purposes only.
The Spatio-temporal Data on the Web Working Group does not aim to maintain comprehensive or authoritative lists
of properties.
Users SHOULD instead adopt concepts defined by other organizations and published through appropriate vocabulary
portals.
D.3.1 Sample vocabulary of properties about system capabilities
SOSA/SSN includes a sample vocabulary consisting of a short list of properties about system capabilities.
The namespace for this sample vocabulary is
http://www.w3.org/ns/sosa/system-capability-properties#.
The suggested prefix for this sample vocabulary is sosa-cap.
Beginning in 2002, the OGC's Sensor Web Enablement initiative [SWE] developed a generic framework for delivering
sensor data, dealing with remote-sensing, moving platforms, and in-situ monitoring and sensing.
In particular, the key standards SensorML and O&M provided complementary viewpoints:
SensorML [SensorML] is 'provider-centric' and encodes details of the sensor along with raw observation
data
Observations and Measurements (O&M) [OandM] [iso-19156-2011] was designed to be more
'user-centric', with the target of the observation and the observed property as first-class objects.
O&M also provided a model for sampling, since almost all scientific observations are made on a subset of, or
proxy for, the ultimate feature of interest.
E.2 W3C Semantic Sensor Network Incubator
The initial Semantic Sensor Network ontology — now known as SSNX [SSNX] — was developed by the
W3C Semantic Sensor Network Incubator Group.
SSNX was influenced by SWE, but was primarily built around the Stimulus Sensor Observation (SSO)
ontology design pattern ([SSO-Pattern], [SSNX-Paper]).
The SSO was also aligned to the Dolce-Ultralite upper ontology [DUL].
E.3 SSN Ontology, including SOSA
The SSN Ontology [vocab-ssn-20171019] combined key elements of SWE and SSNX, and added Actuation and
Sampling as additional procedure execution types.
The core classes and properties comprised the Sensor, Observation, Sample, and Actuator (SOSA)
module.
SOSA acts as the central building block for the SSN and is packaged with very lightweight axiomatization so as to
support use by web-developers.
For details on the design philosophy and decisions around the SSN Ontology, please consult chapter "3. Origins of
SSN and SOSA" in Semantic Sensor Network Ontology.
E.4 New editions
Following experience with O&M since its publication as an ISO and OGC standard in 2011 [OandM]
[iso-19156-2011], a revised edition Observations, Measurements and Samples (OMS) was developed and
published in 2023 [OMS] [iso-19156-2023].
The new edition notably incorporated the Sampling class from SSN, as well as some features which had been proposed
in Extensions to the SSN [vocab-ssn-ext], in particular the notion of ultimate feature of interest, as well
as Sample and Observation collections.
Section 7 of [OMS] provides a comprehensive description of the characteristics of observations and samples.
Note
OMS was published as ISO 19156:2023 [iso-19156-2023] but is freely available as OGC Abstract
Specification — Topic 20 [OMS].
Production of the 2023 edition of the SSN Ontology has been primarily driven by a desire to align with [OMS].
SSN provides the official RDF implementation of OMS, as described in the OMS Extension Module.
In addition, developments in Internet of Things implementations, in particular [SAREF], [STA] and
[ConnectedSystems] have contributed some ideas particularly around actuation.
Finally, direct experience with SSN has uncovered a variety of more minor issues that have been addressed or
accommodated.
F. Acknowledgments
This section is non-normative.
The editors recognize the major contribution of the members of the original W3C Semantic Sensor Networks Incubator
Group.
The editors also gratefully acknowledge the contributions made by all members of the SSN subgroup of the original
Spatial Data on the Web working group.
For this new edition of SSN, in addition to the contributors listed at the top of the document, the editors
acknowledge the work of the editors of ISO 19156:2023 ([iso-19156-2023], [OMS]).
Ted Thibodeau Jr, Openlink Software, made many small grammatical improvements to the text.
Updated Abstract to reflect the revised graph and axiomatization design
Updated and streamlined Introduction; moved Origins section to an Annex.
Add conformance clause Chapter 3
Updated Chapter 4 and Chapter 5.1 to explain modularization and RDF implementation
OGC ModSpec explanation in Chapter 3. Conformance, and tabulations in Chapter 4 - Modularization
Refactored SOSA and SSN into modules - sosa-common sosa-actuation sosa-observation sosa-sampling sosa (all),
and matching ssn-* files (also ssn-deprecated).
Refactored HTML sources to match.
Moved basic rdfs:sub*Of axioms to the SOSA modules, reference RDFS-Plus
re-drafted all figures as SVG; added a clause on notation
Mark ssn:Input, ssn:Output, sosa:Result deprecated
Add 'abstract' superclasses Execution (superclass of Actuation, Observation and Sampling), Asset
(superclass of Platform and System)
The SSN ontology of the W3C semantic sensor network incubator group. Michael Compton; Payam Barnaghi; Luis Bermudez; Raúl García-Castro; Oscar Corcho; Simon Cox; John Graybeal; Manfred Hauswirth; Cory Henson; Arthur Herzog; Vincent Huang; Krzysztof Janowicz; W. David Kelsey; Danh Le Phuoc; Laurent Lefort; Myriam Leggieri; Holger Neuhaus; Andriy Nikolov; Kevin Page; Alexandre Passant; Amit Sheth; Kerry Taylor. Web Semantics: Science, Services and Agents on the World Wide Web, 17:25-32. December 2012. URL: http://www.sciencedirect.com/science/article/pii/S1570826812000571
