The Semantic Sensor Network ontology (SSN) describes actuators and their actuations, sensors and their
observations, samplers and their samplings, the procedures implemented, the features of interest and samples
changed or studied, and the actuated and observed properties.
The core SSN classes and properties are defined using minimal axiomatization in a module called SOSA (Sensor,
Observation, Sample, and Actuator) supplemented with additional axiomatization and terms in further 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 OGC this is a Public Draft of a document prepared by the Spatio-temporal 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 First Public 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 standards [SWE], [SensorML], [OandM], [OMS], [STA] provide
conceptual models and some encodings for the annotation of sensors and their observations.
[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 Internet of Things (IoT), 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.
This specification defines the Semantic Sensor Network (SSN) ontology.
It provides flexible but coherent perspectives for representing the entities, relations, and activities
involved in actuation, observation, and sampling.
A lightweight core for SSN, 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 fall-back 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.
The previous edition of the SSN Ontology [vocab-ssn-20171019] harmonised earlier work from OGC ([OandM]) and W3C
([SSNX]).
A new edition of the OGC/ISO standard [iso-19156-2023],Observations, measurements and samples (OMS) has updated Observations and Measurements (O&M) v2 with a number of additional features arising
from more than 10 years implementation experience.
This new edition of the SSN Ontology provides a canonical RDF implementation of OMS (the OMS
Extension Module).
In addition, [SAREF] and SSN have common contributors who work on the convergence of these reference ontologies.
This new edition of the SSN Ontology provides an alignement to [SAREF] (the
SSN-SAREF Alignment Module).
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.
This allows a W3C document name and id to be established regardless of the final publication date.
It also 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.
This describes the changes since the 2017 edition [vocab-ssn-20171019].
Backward compatibility is maintained since descriptions of Actuations, Observations, Samplings, and Samples using the
SSN Ontology from the 2017 edition are compatible with the SSN Ontology provided by this 2023 Edition.
Note
An account of the Origins of SSN and SOSA through various OGC and W3C initiatives is provided
in an Appendix to this document.
There are several RDF serializations available.
The choice of RDF serialization is NOT prescribed by this specification.
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 Diagram notation
This section is non-normative.
2.2.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.2.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 a diagrams showing examples, appear as boxes with a dotted-outline.
Properties of instances are shown as dashed connectors.
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 coloured grey are included in a diagram for context,
but are described in a different section of the document
Connectors with open arrowheads indicate sub-class relationships,
however it should be noted that these are not defined in the SOSA modules
— see Expressivity for more explanation.
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.
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.
Data conforms to SSN if:
Access to data is organized around Actuations, Observations, and Samplings, which respectively represent
executions of Actuating, Observing, and Sampling procedures, which are in turn respectively implemented by
Actuators, Sensors, and Samplers
The contents of all data fields are expressed using the appropriate RDF classes and properties from SSN. Where no
such class or property exists, sub-classes or sub-properties specializing SSN in a domain-specific web ontology are
employed.
All classes and properties from SSN are used in a way consistent with the semantics declared in this
specification, as so any SSN sub-classes or sub-properties specialised in domain-specific ontologies used to express
the concerned data.
SSN-compliant knowledge graphs MAY include additional non-SSN class instances, object and data properties, and
additional RDF data.
4. SSN Ontology Modularization
This section is non-normative.
The SSN Ontology is 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.
Upper level ontologies are general knowledge ontologies that can be directionally 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.
Some semantic enrichment is provided using Schema.org [schema-org] properties, but there is no formal
axiomatization.
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:
SOSA Common defines classes and properties that are shared across
Actuation, Observation and Sampling applications, documented in section 5.3 Common terms
SOSA Actuation imports SOSA Common and defines classes and properties used in Actuations, documented in section 5.4 Actuations
SOSA Observation imports SOSA Common and defines classes and properties used in Observations, documented in section 5.5 Observations
SOSA Sampling imports SOSA Common and defines classes and properties used in Samplings, documented in section 5.6 Sampling
Finally, SOSA imports SOSA Actuation, SOSA Observation and SOSA Sampling.
SOSA as the core, does not import any other ontologies, so it is truly independent of modules that add
more expressivity and further ontological commitments to the lightweight semantics of SOSA.
4.1.2 SSN
The SSN Module adds axioms that formally indicate how properties relate to classes, and how classes relate to each other. SSN may be used in semantic web systems that use inferencing and reasoning, and consistency checking
for datasets.
The modularization of SSN mirrors SOSA.
SSN is composed of four lower level modules:
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
SSN Sampling imports SSN Common and SOSA Sampling, and axiomatizes classes and
properties used in Samplings, as documented in section 5.6 Sampling
Finally, SSN imports SSN Actuation, SSN Observation and SSN Sampling.
4.2 Extension modules
Figure 4 summarizes the extension modules described in this document and their
dependencies on the SSN Ontology.
4.2.1 OMS
The SOSA-OMS module 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 SSN-OMS module imports SOSA-OMS and SSN Observation and SSN Sampling and adds
OWL/RDFS axiomatization to the RDF implementation of [OMS].
SSN-OMS may be used by audiences for whom full conformance to [OMS] (also known as ISO 19156:2023)
is a requirement, with reasoning support
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-DUL module imports SOSA, and adds axioms that position SOSA within DOLCE UltraLite.
SOSA-DUL may be used to integrate data designed using SOSA into systems otherwise built in the
DOLCE UltraLite framework.
This section introduces the specifications for the RDF implementation of the Semantic Sensor Network Ontology.
5.1 RDF implementation
5.1.1 Namespaces
The namespace for the core terms is http://www.w3.org/ns/sosa/
The suggested prefix for the SOSA namespace is sosa:.
Note
5.1.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.1.3 Expressivity
The SOSA modules contain the basic definitions of the core terms with minimal axiomatization — only
rdf:type and owl:inverseOf — together with key annotations
rdfs:label , skos:definition , schema:domainIncludes, and/or
schema:rangeIncludes, plus other annotations as required.
Inverses are named for all object properties.
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 ObjectSomeValuesFrom and
ObjectAllValuesFrom, and using axioms such as SubClassOf and
SubObjectPropertyOf.
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 x 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
(Procedure, System, Execution).
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 or Deployment
i.e., the entity whose property is being estimated by an Observation,
or whose property is being manipulated by an Actuation,
or which is being sampled or transformed by an act of Sampling,
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 an
Actuator to the properties it can act on;
from a
Procedure to the properties it can observe or act
on.
isUltimateFeatureOfInterestOf added in 2023 Edition.
This term is non-normative, pending further implementation experience
is ultimate feature of interest of —
relation from an ultimate FeatureOfInterest to an Execution, ExecutionCollection, or Deployment, for
which it is the ultimate subject
Procedure —
workflow, protocol, plan, algorithm, or computational method specifying how to make an 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 MUST be considered to be abstract, so any individual Execution SHOULD be
declared to be an instance of one of the concrete sub-classes, and not of the Execution
class.
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 MUST be considered to be abstract, so any individual
ExecutionCollection SHOULD be declared to be an instance of one of the concrete
sub-classes, and not of the ExecutionCollection
class.
has feature of interest —
relation from an Execution or Deployment to its subject entity
i.e., from an Actuation to the entity whose property was modified;
from an Observation to the entity whose quality was observed;
from an act of Sampling 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.
hasUltimateFeatureOfInterest added in 2023 edition.
This term is non-normative, pending further implementation experience
has ultimate feature of interest —
relation from a Deployment or Execution to its ultimate subject entity
i.e., from an Actuation to the ultimate entity whose property was modified;
from an Observation to the ultimate entity whose property was observed;
from an act of Sampling to the ultimate entity that was sampled;
or from a Deployment to its ultimate target
madeBySystem added in the 2023 edition.
This term is non-normative, pending further implementation experience
made by system —
relation from an Execution to the System that made it
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 MUST be considered to be abstract, so SHOULD NOT appear in data instances.
Applications can use concrete sub-properties of madeBySystem.
The different time-properties on a sosa:Execution support the description of plans, forecasts and
predictions as well as descriptions of arious 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: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 sub-systems.
A sosa:Platform hosts one or more sosa:Systems.
Stationary platforms include stations, or fixtures.
Mobile platforms include vehicles, marine- and air-craft, satellites, mobile phones, etc.
A sosa:Deployment is an arrangement of assets (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.
5.3.5.2 Specification
This section introduces the following classes and properties:
Deployment —
arrangement of one or more assets (Systems or Platforms) 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.
Platform —
entity that hosts other entities, particularly Systems, and other Platforms.
Note
A Platform may have a geographic location.
See Location and Geometry for patterns to describe this.
Scope note
The INSPIRE 'Environmental Monitoring Facility' may be implemented using SOSA by the OWL/RDFS class
'Platform'.
Example
A post, buoy, vehicle, ship, aircraft, satellite, cell-phone, human or animal may act as
Platforms for (technical or biological)
Sensors or
Actuators.
An environmental monitoring facility.
A platform that hosts a set of sensors.
A team performing a survey, where each team member would be modeled as an Observer.
A System may have a geographic location.
See Location and Geometry for patterns to describe this.
Scope note
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 MUST be considered to be abstract, so any individual System SHOULD be declared to be an
instance of a concrete sub-class, and not of the System class.
Scope note
Specific system types may be implemented as sub-classes
of this class or its sub-classes.
Their descriptions may capture the properties and characteristics of a
whole class of systems, corresponding with the information typically found
in a data-sheet. Individual system instances are members
of this class or its sub-classes.
madeExecution MUST be considered to be abstract, so SHOULD NOT appear in data instances.
Applications can use concrete sub-properties of madeExecution.
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
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 to 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 15 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, 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 degree 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 software (simulation).
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 sub-classes
of this class or its sub-classes.
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
data-sheet.
Individual actuator instances are members of this class or its sub-classes.
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
ObservationCollection added in the 2023 Edition
This term is non-normative, pending further implementation experience
Observation Collection —
set of one or more 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, 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, 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 software (simulation).
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 sub-classes
of this class or its sub-classes.
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 data-sheet.
Individual sensor instances are members of this class or its sub-classes.
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.
Stimulus —
event in the real world that triggers a Sensor
The properties associated to the Stimulus may be different to the eventual observed Property.
It is the event, not the object, that triggers the Sensor.
has proxy —
relation from an Property to a Stimulus that serves as its proxy
Examples
For example, 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 it
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 that was observed
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
the 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 sample some FatureOfInterest, 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)
Sub class 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.
featureHasUltimateSample added in 2023 edition.
This term is non-normative, pending further implementation experience
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.
isSampleOfUltimateFOI added in 2023 edition.
This term is non-normative, pending further implementation experience
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 links a SOSA term to the corresponding OMS class or property,
and ogc-ms:implementedBy its inverse, 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
Some classes and properties from OMS are not yet represented in the OMS Extension Module.
It is intended to resolve this before the 2023 edition of the SSN Ontology is finalized.
This is likely to be through additional patterns for the use of SSN,
and additional terms in the sosa-oms: namespace.
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.
The SOSA-OMS graph is available at http://www.w3.org/ns/sosa-oms/.
6.1.2.2 SSN-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.
The SSN-OMS graph is available at http://www.w3.org/ns/ssn-oms/.
6.1.2.3 Namespaces
The following namespace prefixes are used in the RDF implementation of OMS:
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; and
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 SOSA/SSN ontologies conceive executions (actuations, observations, and acts of 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.
An alignment of SOSA to 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 here (see Figure 20) is based on that work, also extended to consider actuation and sampling.
This section uses a combination of [Description-Logics] notation (see also the [Description-Logics-Home-Page]) and the Manchester Syntax [owl2-manchester-syntax].
⊑ denotes either SubClassOf or SubObjectPropertyOf, depending on the context.
≡ indicates equivalence, corresponding to either EquivalentClasses or EquivalentObjectProperties, depending on the context.
The expression OP1 o OP2 ⊑ OP3 represents a subproperty chain axiom.
7.1.1 Namespaces
The following namespace prefixes are used in the alignment of SOSA to PROV.
This section introduces the alignment of SOSA to 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 uses [Description-Logics] notation (see also the [Description-Logics-Home-Page]).
⊑ denotes either SubClassOf or SubObjectPropertyOf, depending on the context.
⊒ represents the inverse relation.
≡ indicates equivalence, corresponding to either EquivalentClasses or EquivalentObjectProperties, depending on the context.
The expression OP1 ⊒ OP2 o OP3 represents a subproperty chain axiom.
7.2.1 Namespaces
The following namespace prefixes are used in the alignment of SOSA to SAREF.
This section introduces the alignment of SOSA to [OBOE].
OBOE, the Extensible Observation Ontology, 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.
This section uses a combination of [Description-Logics] notation (see also the [Description-Logics-Home-Page]) and the Manchester Syntax [owl2-manchester-syntax].
⊑ denotes either SubClassOf or SubObjectPropertyOf, depending on the context.
≡ indicates equivalence, corresponding to either EquivalentClasses or EquivalentObjectProperties, depending on the context.
The expression OP ONLY C represents an ObjectAllValuesFrom restriction.
The expression OP EXACTLY 1 represents an ObjectExactCardinality restriction.
7.3.1 Namespaces
The following namespace prefixes are used in the alignment to SOSA.
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 SOSA to the DOLCE UltraLite upper ontology (DUL) which is the core
dependency of the previous version of SSN. This serves to axiomatically clarify the intended meaning of SOSA terms
and will assist SOSA users wishing to interoperate with other DUL-aligned ontologies.
Note, however, that the DUL alignment can be used independently to align SOSA with more generic concepts/properties of DUL.
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 SOSA are aligned with the DUL classes as follows.
The alignment of subclasses of these upper-level classes follows logically from these correspondences.
Note
This section uses a combination of [Description-Logics] notation (see also the [Description-Logics-Home-Page]) and the Manchester Syntax [owl2-manchester-syntax].
The expression C1 ⊑ C2 represents a SubClassOf axiom.
The expression C1 or C2 represents an ObjectUnionOf class expression.
The expression OP ONLY C represents an ObjectAllValuesFrom restriction.
Note
The definition of each DUL concept is displayed as a tooltip when hovering over the concept.
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.
8. Common Patterns
This section is non-normative.
This section discusses how to handle some common modeling questions.
8.1 Quantity Values and Units of Measure
The result of an sosa:Observation or an
sosa:Actuation can be a quantity value with a numeric value and a unit
of measure.
It is out of the scope of this specification to recommend a particular way of representing quantitative results.
Several options from external vocabularies are available for expressing quantities as OWL individuals, or as
datatypes.
Examples include:
qudt:QuantityValue from the Quantities, Units, Dimensions, and Data Types ontologies [QUDT];
cdt:ucum from Custom Datatypes [CDT].
8.1.1 Single values
The following examples show alternative encodings of a single observation with a scalar result, as shown in Figure 22.
With QUDT, 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.
With CDT, the value of sosa:hasSimpleResult is a literal structured
as space-separated quantiy-value using the UCUM code for the unit of measurement [UCUM].
The type designator is
cdt:ucum taken from [CDT].
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.
For example: applications in hydrology will refer to types such as water-course, 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 sub-classes of
sosa:FeatureOfInterest?
No, absolutely not.
RDF and OWL entailments do not work that way.
The way the SSN Ontology addresses this is described in the following sub-sections.
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:
these have no formal entailments, they are just hints
'Includes' means these types are non-exclusive, so any other type is acceptable, including types from
application-domains
So the 'domain and range' indications in SOSA are functionally harmless.
The fact that
sosa:hasFeatureOfInterest schema:rangeIncludes sosa:FeatureOfInterest .
merely says that things of type
sosa:FeatureOfInterest might 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 (i) the object of the statement must be declared to have
rdf:type sosa:FeatureOfInterest in advance, or (ii) 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 you to derive domain types as sub-classes of
sosa:FeatureOfInterest.
It merely says that when a domain individual participates in an Execution (e.g., an Observation)
it 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 sub-classes) or sosa:Deployment.
Consider the following scenario (Figure 23, Figure 24).
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 an
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 26.
Many observation workflows rely on a chain of samples, where it is important to understand the provenance of the
sample which is the (proximate) feature of interest for observations.
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 27).
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 28 shows a more complex scenario involving many samples
derived from an initial one, with some relationships that may be useful in processing and discovery of
subsequent observations, the intention of which will be to characterize various aspects of the original sample
which is representative of an ultimate feature of interest.
This is supported by 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.
Note that the scenario in Figure 28 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 29 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, e.g.
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 36).
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 37)
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 39).
These provide input-values to the final observation (at the bottom of Figure 39).
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 in which only the (phenomenon-) time changes between
consecutive results for the same property on a single feature of interest, 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(s), over a suite of features-of-interest.
Imaging sensors could be considered 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 individuals of which may
hold one or more of the essential properties of an atomic observation, except for the result.
Where present, the value of the property(s) of the collection are shared by all member observations.
Of the essential properties of an observation, only the value of each actual hasResult is not potentially shared by all member
observations, though at least one of the other properties would be expected to vary between members in a typical
collection.
For example, Figure 40 describes a collection of remote sensing observations
using the same sensor on different scenes, while Figure 41 is a series of the
same scene on different days.
Figure 40A set of remote sensing observations of different scenes on the same dayFigure 41A 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 42).
Figure 42Example 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 43).
Figure 43Alternative 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 44 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 45 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 may be used to define a new observable or actuatable
property.
For example, using the I-ADOPT terminology, the property Temperature may be specialized to apply to a sick
child as follows:
The key point is that an individual property, whether taken from a catalogue or defined using a specialist
vocabaulary, is denoted by a URI.
This 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 sub-property 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.
Sensors and actuators may be packaged with other sensors and actuators 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 48 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,
i.e., 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 data-sheet 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
a generic system or system type is represented as an OWL Class, specifically as a sub-class of
sosa:System (specifically: one of its sub-classes
sosa:Actuator,
sosa:Sensor,
sosa:Sampler), while
an individual system or system instance is represented as an OWL Individual, specifically as an
instance of the class describing the system type.
Figure 49 illustrates an example of a sensor type and instance modeled this way.
The following code snippet provides an outline of the details:
@prefixcdt:<http://w3id.org/lindt/custom_datatypes#> .
@prefixex:<https://example.org/data/> .
@prefixowl:<http://www.w3.org/2002/07/owl#> .
@prefixqk:<http://qudt.org/vocab/quantitykind/> .
@prefixrdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefixrdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefixsensor:<https://example.org/sensor/> .
@prefixsosa:<http://www.w3.org/ns/sosa/> .
qk:Temperatureasosa:Property ;
.
sensor:TemperatureSensoraowl:Class ;
rdfs:label"A generic temperature sensor" ;
rdfs:subClassOfsosa:Sensor ;
rdfs:subClassOf [
aowl:Restriction ;
owl:hasValueqk:Temperature ;
owl:onPropertysosa:observes ;
] ;
.
sensor:Mercury-in-glass-thermometeraowl:Class ;
rdfs:label"Mercury in glass thermometer" ;
rdfs:comment"Temperature sensor based on the expansion of a column of mercury inside a glass tube" ;
rdfs:subClassOfsensor:TemperatureSensor ;
.
ex:Mums-clinical-thermometerasosa:Sensor ;
asensor:TemperatureSensor ;
asensor:Mercury-in-glass-thermometer ;
.
ex:SickChildAasosa:FeatureOfInterest ;
.
ex:SickChildATempObsasosa:Observation ;
sosa:hasFeatureOfInterestex:SickChildA ;
sosa:hasSimpleResult"38.2 Cel"^^cdt:ucum ;
sosa:madeBySensorex:Mums-clinical-thermometer ;
sosa:observedPropertyqk:Temperature ;
.
Note
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.
Inverses are named for all SSN object properties, in order to support interoperability across a range of
applications.
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. Origins of SSN and SOSA
This section is non-normative.
D.1 OGC Sensor Web Enablement
Starting 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.
D.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].
D.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.
D.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 this new 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 the
OGC Connected Systems project 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.
E. 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.
E.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 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 a 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 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 looses physical
integrity and looses 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.
E.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.
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.
Updated Chapter 2 'Modularization' to simplify and to reflect the revised graph arrangement
Add conformance clause Chapter 3
Updated Chapter 4 and Chapter 5.1 to explain modularization and RDF implementation
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.
re-drafted all figures as SVG; added a clause on notation
Mark ssn:Input, ssn:Output, sosa:Result deprecated
