1. Introduction

This section is non-normative.

Sensors are a major source of data available on the Web today. While sensor data may be published as mere values, searching, reusing, integrating, and interpreting these data requires more than just the observation results. Of equal importance for the proper interpretation of these values is information about the studied feature of interest, such as a river, the observed property, such as flow velocity, the utilized sampling strategy, such as the specific locations and times at which the velocity was measured, and a variety of other information. OGC's Sensor Web Enablement standards [ OandM], [SensorML] provide a means to annotate sensors and their observations. However, these standards are not integrated and aligned with W3C Semantic Web technologies and Linked Data in particular, which are key drivers for creating and maintaining a global and densely interconnected graph of data. With the rise of the Web of Things and smart cities and homes more generally, actuators and the data they produce also become first-class citizens of the Web. Given their close relation to sensors, observations, procedures, and features of interest, it is desirable to provide a common ontology that also includes actuators and actuation. Finally, with the increasing diversity of data and data providers, definitions such as those for sensors need to be broadened, e.g., to include social sensing. The following specifications introduce the new Semantic Sensor Network (SSN) and Sensor, Observation, Sample, and Actuator (SOSA) ontologies that are set out to provide flexible but coherent perspectives for representing the entities, relations, and activities involved in sensing, sampling, and actuation. SOSA provides a lightweight core for SSN and aims at broadening the target audience and application areas that can make use of Semantic Web ontologies. At the same time, SOSA acts as minimal interoperability fall-back level, i.e., it defines those common classes and properties for which data can be safely exchanged across all uses of SSN, its modules, and SOSA.

2. Modularization

This section is non-normative.

Practitioners using the original Semantic Sensor Network Ontology as defined in the W3C Semantic Sensor Network Incubator Group [SSNO] have identified a major issue in its complexity, partly due to the layering underneath the Dolce-UltraLite (DUL) upper level ontology. In response to this, the new Semantic Sensor Network (SSN) ontology offers several ontology subsets that are distinguished mainly through their ontological commitments. This section explains the rationale and method for modularizing SSN, i.e., offering several distinct ontologies that are similar in their domain of discourse, but with different ontological commitments, suitable to several use cases and target audiences. For example, SOSA is intended to provide Schema.org-style semantic enrichment capabilities for data repositories managed by an audience broader than typical ontology engineers, while still ensuring interoperability with SSN-based repositories.

Ontology modularization is a common method used in ontology engineering to segment an ontology into smaller parts. In general, ontology modularization aims at providing users of ontologies with the knowledge they require, reducing the scope as much as possible to what is strictly necessary in a given use case. Two main categories of ontology modularization can be distinguished.

The first category comprises those approaches that focus on the composition of existing ontologies by means of integrating and mapping ontologies, most commonly through owl:import statements. OWL import has a direction from a dependent ontology to a dependency ontology. Although import is transitive, knowledge is propagated in only one direction. The importing ontology assumes all the meaning of the imported terms used, by including all axioms relevant to the meaning of these terms. However, the imported ontology does not capture any of the semantics of the importing ontology.

The second category comprises of mapping approaches that aim to partition and extract parts of ontologies as modules. These mapping approaches are not necessarily directional, but most approaches of ontology extraction rely on the directionality of the imported modules. The main feature of an ontology module under the second category is that it is self-contained, i.e., the module captures the meaning of the imported terms used by including all axioms relevant to the meaning of these terms. This means, that the result of certain reasoning tasks such as subsumption or query answering within a single module should be possible and result in the same answers without the need to access other modules of the ontology.

Our modularization uses the first approach by composing the ontology into several modules that use owl:import statements, whereby we distinguish two methods depending on the directionality of the segmentation: a vertical segmentation and a horizontal segmentation.

Vertical Segmentation

Vertical modules build upon each other, i.e., they directionally owl:import lower level modules. Lower level modules are independent of their higher level modules and logically consistent on their own.

For example, the Dolce-UltraLite Alignment Module imports the SSN Ontology which itself imports the SOSA Ontology. However, in reverse, neither SOSA nor SSN import the Dolce-UltraLite Alignment Module. In fact, SOSA as the core, does not import any other ontologies, which makes it truly independent of vertical modules that add more expressivity and further ontological commitments to the lightweight semantics of SOSA.

Note that 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, whereas our definition of higher level ontologies here refers to an ontology that extends one or several ontology modules to capture a larger part of a knowledge domain and/or combine knowledge domains.

Horizontal Segmentation

Modules that are horizontally layered may depend on each other, i.e., they may rely on the directional import of another horizontal module. Only one horizontal module that is dependent on the SSN ontology is presented in this specification, the Sample Relations Module. Other ontologies that add domain-specific terms to SSN, but require the import of SSN, can be considered horizontal modules.

3. Origins of SSN and SOSA

This section is non-normative.

Here we briefly review the origins of SSN and SOSA, namely the initial SSN version published by the W3C Semantic Sensor Network Incubator Group [SSNO] and work on Sensor Web Enablement by the OGC. We also highlight the most substantial changes made since the initial release of the SSN ontology.

Starting in 2002, the OGC's Sensor Web Enablement initiative has developed a generic framework for delivering sensor data, dealing with remote-sensing, moving platforms, and in-situ monitoring and sensing. The Sensor Observation Service defines a standard query interface for sensor and observation data, following the pattern established by OGC for their Web Services. The returned XML data conforms with the Sensor Model Language [SensorML] and OMXML [OMXML], whereby the latter implements Observations and Measurements [OandM].

SensorML and O&M are complementary viewpoints. SensorML is 'provider-centric' and encodes details of the sensor along with raw observation data. SensorML is self-contained and highly flexible. This makes life easy for data producers but is demanding on consumers. SensorML provides extensive support for serialization of numeric data arrays and is particularly optimized for data that includes multiple parallel streams that must be processed together. For example, the data collected by cameras on airborne vehicles must be geo-referenced based on the instantaneous position of the platform and orientation of the camera. In contrast, O&M was designed to be more 'user-centric' with the target of the observation and the observed property as first-class objects. O&M works at a higher semantic level than SensorML, but only provides abstract classes for sensors, features of interest and observable properties, expecting the details to be provided by specific applications and domains. 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.

The initial W3C Semantic Sensor Network Incubator Group ontology (SSN) was built around an ontology design pattern called the Stimulus Sensor Observation (SSO) pattern [SSO-Pattern]. The SSO was developed as a minimal and common ground for heavy-weight ontologies for the use on the Semantic Sensor Web as well as to explicitly address the need for light-weight semantics requested by the Linked Data community. The SSO was also aligned to the Dolce-Ultralite upper ontology (DUL).

The new SSN described in this document is based on a revised and expanded version of this pattern, namely the Sensor, Observation, Sample, and Actuator (SOSA) ontology. Similar to the original SSO, SOSA acts as a central building block for the SSN but puts more emphasis on light-weight use and the ability to be used standalone. The axiomatization also changed to provide an experience more related to Schema.org. Notable differences include the usage of the Schema.org domainIncludes and rangeIncludes annotation properties that provide an informal semantics compared to the inferential semantics of their OWL 2 counterparts. In line with the changes implemented for the new SSN, SOSA also drops the direct DUL alignment although an optional alignment can be achieved via the SSN-DUL alignment provided in Section 6.1. SOSA is also more explicit than SSO in its support for virtual and human sensor. Finally, and most notably, SOSA extends SSO's original scope beyond sensors and their observations by including classes and properties for actuators and sampling. SOSA also distinguishes between phenomenonTime and resultTime.

Drawing on considerable implementation and application experience with SSN and sensor and observation ontologies more broadly, the new SSN and SOSA ontologies presented here are set out to address changes in scope and audience, shortcomings of the initial work, as well as new technical developments. The list below highlights the most important (but by far not exclusive) updates.

• Addressing changes in scope and audience
  • The initial SSN was developed with ontology engineers in mind as the primary audience. Due to the widespread adoption of SSN, the increasing role of citizen science, the strong focus on lightweight vocabularies by the Linked Data community, and vocabularies such as Schema.org, the ontology was streamlined. SOSA is added as a core, and is also useful as a standalone ontology targeting Web developers, citizen science, lightweight Linked Data publishing, resource-constraint IoT devices, data intensive applications (with the possibility of using lightweight reasoning), and so on. The new SSN introduces additional classes and relations on top of SOSA to model the capabilities of sensors and actuators, the compositionality of systems, and so forth to suit more complex needs or cases in which more provenance data is required, e.g., to improve reproducibility.
  • Almost all scientific observations make heavy use of sampling strategies, and, therefore, the Sampling, Sampler, and Sample classes, as well as their corresponding properties, have been added to SOSA and SSN.
  • Due to the increasing importance of the Web of Things and smart instrumentation and environments more generally, the classes Actuator and Actuation have been added to SOSA and SSN.
• Addressing shortcomings of the initial SSN
  • The new SSN streamlines the relations (and need for) the old Device, Platform, and Systems classes.
  • The old SSN was perceived as too heavyweight (on its axiomatization) and too dependent on OWL reasoning by some users. To strike a balance, DL expressivity of the new lightweight SOSA ontology is ALI(D) which is efficiently supported by modern triple stores, while the new SSN is ALRIN(D). In contrast, the old SSN is SRIQ.
  • The SSN previously imported DUL and many SSN terms inherited from DUL terms. Due to frequent user requests, this has been redesigned so that SSN (and SOSA) can be used entirely independently of DUL if desired. Some of the alignments with DUL have been reconsidered. Those parts of SSN that use DUL terms have been separated into the SSN Alignment with DUL ontology. This alignment and therefore the role of DUL in SSN have been declared non-normative.
  • The definitions for many classes and properties have changed slightly to improve explanation or to correct minor errors. Examples have been separated from the main definitions.
  • The initial SSN has been criticized for its partially inconsistent handling of virtual sensors (including software and simulations) and related classes and properties. The new SSN and SOSA address this issue by allowing all major classes to be virtual, and to better support humans and other animals as agents.
  • The notion of Procedure (formerly Plan) has been clarified to describe a workflow, protocol, plan, algorithm, or computational method specifying how to make an Observation, create a Sample, or make a change to the state of the world via an Actuator.
  • The Observation class in the initial SSN was conceptualized as a subclass of the DUL Situation class. To improve alignment with O&M and user expectations, as well as to follow a consistent modeling strategy for observations, sampling, and actuation, the Observation class defined in SOSA and the new SSN are now conceptualized as activities.
• Addressing technical developments
  • The initial SSN used local/guarded domain and range restrictions. The lightweight SOSA ontology uses an even more restrained axiomatization to foster wide reuse and adaptation among an audience that is not necessarily familiar with OWL. SOSA makes use of the domainIncludes and rangeIncludes annotation properties defined in Schema.org. These had not been available before.
  • Given the increased interest in using Semantic Web technologies directly on the level of individual sensors, actuators, or platforms, SOSA's axiomatization does not use many of the more complex language elements introduced by SSN.

5. Horizontal Segmentation

This section is non-normative.

5.1 System Capabilities Module

The namespace for system capabilities, operating ranges, and survival ranges terms is https://www.w3.org/ns/ssn/systems/

The suggested prefix for the system capabilities, operating ranges, and survival ranges terms is ssn-system

An ontology graph for this is available.

5.1.1 Overview and examples

This section is non-normative.

The following figure provides an overview on the core classes and properties that are specifically related to modeling System capabilities, operating ranges, and survival ranges, under given conditions.

The following examples illustrate how the terms related to System capabilities, operating ranges, and survival ranges can be used:

• DHT22 Description
• IP68 Smart Sensor

5.1.2 Specification

This section introduces the following classes and properties:

ssn-system:inCondition, ssn-system:Condition, ssn-system:hasSystemCapability, ssn-system:SystemCapability, ssn-system:hasSystemProperty, ssn-system:SystemProperty, ssn-system:MeasurementRange, ssn-system:ActuationRange, ssn-system:Accuracy, ssn-system:DetectionLimit, ssn-system:Drift, ssn-system:Frequency, ssn-system:Latency, ssn-system:Precision, ssn-system:Resolution, ssn-system:ResponseTime, ssn-system:Selectivity, ssn-system:Sensitivity, ssn-system:hasOperatingRange, ssn-system:OperatingRange, ssn-system:hasOperatingProperty, ssn-system:OperatingProperty, ssn-system:MaintenanceSchedule, ssn-system:OperatingPowerRange ssn-system:hasSurvivalRange, ssn-system:SurvivalRange, ssn-system:hasSurvivalProperty, ssn-system:SurvivalProperty ssn-system:SystemLifetime, ssn-system:BatteryLifetime ssn-system:qualityOfObservation

5.1.2.1 ssn:System

IRI: https://www.w3.org/ns/ssn/System

a OWL Class

System - System is a unit of abstraction for pieces of infrastructure that implement Procedures. A System may have components, its subsystems, which are other Systems.

Additional Restrictions	ssn-system:hasSystemCapability ONLY ssn-system:SystemCapability ssn-system:hasOperatingRange ONLY ssn-system:OperatingRange ssn-system:hasSurvivalRange ONLY ssn-system:SurvivalRange
is Defined By	https://www.w3.org/ns/ssn/

[Back to module overview and examples]

5.1.2.2 ssn-system:inCondition

IRI: https://www.w3.org/ns/ssn/systems/inCondition

a OWL Object Property

in condition - Describes the prevailing environmental Conditions for SystemCapabilites, OperatingRanges and SurvivalRanges.

Example	Used for example to say that a Sensor has a particular accuracy in particular Conditions.
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.3 ssn-system:Condition

IRI: https://www.w3.org/ns/ssn/systems/Condition

a OWL Class

Condition - Used to specify ranges for qualities that act as Conditions on a Systems' operation.

Example	For example, wind speed of 10-60m/s may be used as the Condition on a SystemProperty, for example, to state that a Sensor has a particular Accuracy under that Condition.
Sub class of	ssn:Property
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.4 ssn-system:hasSystemCapability

IRI: https://www.w3.org/ns/ssn/systems/hasSystemCapability

a OWL Object Property

has system capability - Relation from a System to a SystemCapability describing the capabilities of the System under certain Conditions.

Sub property of	ssn:hasProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.5 ssn-system:SystemCapability

IRI: https://www.w3.org/ns/ssn/systems/SystemCapability

a OWL Class

System Capability - Describes normal measurement, actuation, sampling properties such as accuracy, range, precision, etc. of a System under some specified Conditions such as a temperature range.
The capabilities specified here are those that affect the primary purpose of the System, while those in OperatingRange represent the system's normal operating environment, including Conditions that don't affect the Observations or the Actuations.

Sub class of	ssn:Property
Restrictions	ssn:forProperty ONLY ssn:Property ssn-system:hasSystemProperty ONLY ssn-system:SystemProperty ssn-system:inCondition ONLY ssn-system:Condition ssn-system:inCondition MIN 1 inverse Of ssn-system:hasSystemCapability ONLY ssn:System
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.6 ssn-system:hasSystemProperty

IRI: https://www.w3.org/ns/ssn/systems/hasSystemProperty

a OWL Object Property

has system property - Relation from an SystemCapability of a System to a SystemProperty describing the capabilities of the System.

Sub property of	ssn:hasProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.7 ssn-system:SystemProperty

IRI: https://www.w3.org/ns/ssn/systems/SystemProperty

a OWL Class

System Property - An identifiable and observable characteristic that represents the System's ability to operate its primary purpose: a Sensor to make Observations, an Actuator to make Actuations, or a Sampler to make Sampling.

Sub class of	ssn:Property
Restrictions	inverse Of ssn-system:hasSystemProperty ONLY ssn-system:SystemCapability inverse Of ssn-system:hasSystemProperty MIN 1
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.8 ssn-system:MeasurementRange

IRI: https://www.w3.org/ns/ssn/systems/MeasurementRange

a OWL Class

Measurement Range - The set of values that the Sensor can return as the Result of an Observation under the defined Conditions with the defined system properties.

Sub class of	ssn-system:SystemProperty
Restrictions	inverse Of ssn-system:hasSystemProperty ONLY inverse Of ssn-system:hasSystemCapability ONLY sosa:Sensor
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.9 ssn-system:ActuationRange

IRI: https://www.w3.org/ns/ssn/systems/ActuationRange

a OWL Class

Actuation Range - The range of Property values that can be the Result of an Actuation under the defined Conditions.

Sub class of	ssn-system:SystemProperty
Restriction	inverse Of ssn-system:hasSystemProperty ONLY inverse Of ssn-system:hasSystemCapability ONLY sosa:Actuator
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.10 ssn-system:Accuracy

IRI: https://www.w3.org/ns/ssn/systems/Accuracy

a OWL Class

Accuracy - The closeness of agreement between the Result of an Observation (resp. the command of an Actuation) and the true value of the observed ObservableProperty (resp. of the acted on ActuatableProperty) under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.11 ssn-system:DetectionLimit

IRI: https://www.w3.org/ns/ssn/systems/DetectionLimit

a OWL Class

Detection Limit - An observed value for which the probability of falsely claiming the absence of a component in a material is beta, given a probability alpha of falsely claiming its presence.

Sub class of	ssn-system:SystemProperty
Restriction	inverse Of ssn-system:hasSystemProperty ONLY inverse Of ssn-system:hasSystemCapability ONLY sosa:Sensor
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.12 ssn-system:Drift

IRI: https://www.w3.org/ns/ssn/systems/Drift

a OWL Class

Drift - As a Sensor Property: a continuous or incremental change in the reported values of Observations over time for an unchanging Property under the defined Conditions.
As an Actuator Property: a continuous or incremental change in the true value of the acted on ActuatableProperty over time for an unchanging command under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.13 ssn-system:Frequency

IRI: https://www.w3.org/ns/ssn/systems/Frequency

a OWL Class

Frequency - The smallest possible time between one Observation, Actuation, or Sampling and the next, under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.14 ssn-system:Latency

IRI: https://www.w3.org/ns/ssn/systems/Latency

a OWL Class

Latency - The time between a command for an Observation (resp. Actuation) and the Sensor providing a Result (resp. the Actuator operating the Actuation), under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.15 ssn-system:Precision

IRI: https://www.w3.org/ns/ssn/systems/Precision

a OWL Class

Precision - As a sensor capability: The closeness of agreement between replicate Observations on an unchanged or similar quality value: i.e., a measure of a Sensor's ability to consistently reproduce an Observation, under the defined Conditions.
As an actuator capability: The closeness of agreement between replicate Actuations for an unchanged or similar command: i.e., a measure of an Actuator's ability to consistently reproduce an Actuations, under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.16 ssn-system:Resolution

IRI: https://www.w3.org/ns/ssn/systems/Resolution

a OWL Class

Resolution - As a Sensor Property: the smallest difference in the value of a ObservableProperty being observed that would result in perceptably different values of Observation Results, under the defined Conditions.
As an Actuator Property: the smallest difference in the value of an Actuation command that would result in a value change of the ActuatableProperty being acted on, under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.17 ssn-system:ResponseTime

IRI: https://www.w3.org/ns/ssn/systems/ResponseTime

a OWL Class

Response time - As a Sensor Property: the time between a (step) change in the value of an observed ObservableProperty and a Sensor (possibly with specified error) 'settling' on an observed value, under the defined Conditions.
As an Actuator Property: the time between a (step) change in the command of an Actuator and the 'settling' of the value of the acted on ActuatableProperty, under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.18 ssn-system:Selectivity

IRI: https://www.w3.org/ns/ssn/systems/Selectivity

a OWL Class

Selectivity - As a Sensor Property: Selectivity is a Property of a Sensor whereby it provides observed values for one or more ObservableProperties such that the Result for each ObservableProperty are independent of other Properties in the FeatureOfInterest being investigated, under the defined Conditions.
As an Actuator Property: Selectivity is a Property of an Actuator whereby it acts on one or more ActuatableProperties such as the Results for each ActuatableProperty are independent of other Properties in the FeatureOfInterest being acted on, under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.19 ssn-system:Sensitivity

IRI: https://www.w3.org/ns/ssn/systems/Sensitivity

a OWL Class

Sensitivity - As a Sensor Property: Sensitivity is the quotient of the change in a Result of Observations and the corresponding change in a value of an ObservableProperty being observed, under the defined Conditions.
As an Actuator Property: Sensitivity is the quotient of the change in a command of Actuation and the corresponding change in a value of an ActuatableProperty being acted on, under the defined Conditions.

Sub class of	ssn-system:SystemProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.20 ssn-system:hasOperatingRange

IRI: https://www.w3.org/ns/ssn/systems/hasOperatingRange

a OWL Object Property

has operating range - Relation from a System to an OperatingRange describing the normal operating environment of the System.

Sub property of	ssn:hasProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.21 ssn-system:OperatingRange

IRI: https://www.w3.org/ns/ssn/systems/OperatingRange

a OWL Class

Operating Range - Describes normal OperatingProperties of a System under some specified Conditions. For example, to the power requirement or maintenance schedule of a System under a specified temperature range.
In the absence of OperatingProperties, it simply describes the Conditions in which a System is expected to operate.
The System continues to operate as defined using SystemCapability. If, however, the OperatingProperty is violated, the System is operating 'out of operating range' and SystemCapability specifications may no longer hold.

Sub class of	ssn:Property
Restrictions:	ssn-system:hasOperatingProperty ONLY ssn-system:OperatingProperty ssn-system:inCondition ONLY ssn-system:Condition ssn-system:inCondition MIN 1 inverse Of ssn-system:hasOperatingRange ONLY ssn:System
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.22 ssn-system:hasOperatingProperty

IRI: https://www.w3.org/ns/ssn/systems/hasOperatingProperty

a OWL Object Property

has operating property - Relation from an OperatingRange of a System to an OperatingProperty describing the operating range of the System.

Sub property of	ssn:hasProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.23 ssn-system:OperatingProperty

IRI: https://www.w3.org/ns/ssn/systems/OperatingProperty

a OWL Class

Operating Property - An identifiable characteristic that represents how the System operates under the specified Conditions. May describe power ranges, power sources, standard configurations, attachments and the like.

Sub class of	ssn:Property
Restrictions	inverse Of ssn-system:hasOperatingProperty ONLY ssn-system:OperatingRange inverse Of ssn-system:hasOperatingProperty MIN 1
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.24 ssn-system:MaintenanceSchedule

IRI: https://www.w3.org/ns/ssn/systems/MaintenanceSchedule

a OWL Class

Maintenance Schedule - Schedule of maintenance for a System in the specified Conditions.

Sub class of	ssn-system:OperatingProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.25 ssn-system:OperatingPowerRange

IRI: https://www.w3.org/ns/ssn/systems/OperatingPowerRange

a OWL Class

Operating Power Range - Power range in which System is expected to operate in the specified Conditions.

Sub class of	ssn-system:OperatingProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.26 ssn-system:hasSurvivalRange

IRI: https://www.w3.org/ns/ssn/systems/hasSurvivalRange

a OWL Object Property

has survival range - Relation from a System to a SurvivalRange.

Sub property of	ssn:hasProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.27 ssn-system:SurvivalRange

IRI: https://www.w3.org/ns/ssn/systems/SurvivalRange

a OWL Class

Survival Range - Describes SurvivalProperties of a System under some specified Conditions. For example, the lifetime of a System under a specified temperature range.
In the absence of SurvivalProperties, simply describes the Conditions a System can be exposed to without damage. For example, the temperature range a System can withstand before being considered damaged.
The System continues to operate as defined using SystemCapability. If, however, the SurvivalRange is violated, the System is 'damaged' and SystemCapability specifications may no longer hold.

Sub class of	ssn:Property
Restrictions	ssn-system:hasSurvivalProperty ONLY ssn-system:SurvivalProperty ssn-system:inCondition ONLY ssn-system:Condition ssn-system:inCondition MIN 1 inverse Of ssn-system:hasSurvivalRange ONLY ssn:System
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.28 ssn-system:hasSurvivalProperty

IRI: https://www.w3.org/ns/ssn/systems/hasSurvivalProperty

a OWL Object Property

has survival property - Relation from a SurvivalRange of a System to a SurvivalProperty describing the survival range of the System.

Sub property of	ssn:hasProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.29 ssn-system:SurvivalProperty

IRI: https://www.w3.org/ns/ssn/systems/SurvivalProperty

a OWL Class

Survival Property - An identifiable characteristic that represents the extent of the System's useful life under the specified Conditions. May describe for example total battery life or number of recharges, or, for Sensors that are used only a fixed number of times, the number of Observations that can be made before the sensing capability is depleted.

Sub class of	ssn:Property
Restrictions	inverse Of ssn-system:hasSurvivalProperty ONLY ssn-system:SurvivalRange inverse Of ssn-system:hasSurvivalProperty MIN 1
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.30 ssn-system:SystemLifetime

IRI: https://www.w3.org/ns/ssn/systems/SystemLifetime

a OWL Class

System Lifetime - Total useful life of a System (expressed as total life since manufacture, time in use, number of operations, etc.) in the specified Conditions.

Sub class of	ssn-system:SurvivalProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.31 ssn-system:BatteryLifetime

IRI: https://www.w3.org/ns/ssn/systems/BatteryLifetime

a OWL Class

Battery Lifetime - Total useful life of a System's battery in the specified Conditions.

Sub class of	ssn-system:SurvivalProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.1.2.32 ssn-system:qualityOfObservation

IRI: https://www.w3.org/ns/ssn/systems/qualityOfObservation

a OWL Object Property

quality of observation - Relation linking an Observation to the adjudged quality of the Result. This is complementary to the SystemCapability information recorded for the Sensor that made the Observation.

Sub property of	ssn:hasProperty
is Defined By	https://www.w3.org/ns/ssn/systems/

[Back to module overview and examples]

5.2 Sample Relations Module

This section is non-normative.

Samples are often related to other samples, by sub-sampling, topological relationships (stations along a traverse, pixels within an image, probe spots on a polished section, specimens retrieved within a borehole) or as parts of sample processing chains (crushing, splitting, dissecting, disolving). There are 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 namespace for Sample relationships terms is https://www.w3.org/ns/sosa/sampling/

The suggested prefix for the sample relationships namespace is sampling

An ontology graph for this is available.

The following figure provides an overview on the classes and properties that are specifically related to modeling Sample relationships.

5.2.1 Sample Relationships Specification

This section introduces the following classes and properties:

sampling:RelationshipNature, sampling:hasSampleRelationship, sampling:natureOfRelationship, sampling:relatedSample

5.2.1.1 sampling:RelationshipNature

IRI: https://www.w3.org/ns/sosa/sampling/RelationshipNature

a OWL Class

Nature of relationship (between samples) - Members of this class indicate the nature of a relationship between two Samples.

Sub class of	skos:Concept
Examples	Adjacent flight-line Females Juveniles Males 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
is Defined By	https://www.w3.org/ns/sosa/sampling/

[Back to module overview]

5.2.1.2 sampling:SampleRelationship

IRI: https://www.w3.org/ns/sosa/sampling/SampleRelationship

a OWL Class

Sample relationship - Members of this class represent a relationship between a Sample and another.

is Defined By	https://www.w3.org/ns/sosa/sampling/

[Back to module overview]

5.2.1.3 sampling:hasSampleRelationship

IRI: https://www.w3.org/ns/sosa/sampling/hasSampleRelationship

a OWL Object Property

has sample relationship - Links a sample to a Sample Relationship (which links to a related Sample).

Domain Includes	sosa:Sample
Range Includes	sampling:SampleRelationship
is Defined By	https://www.w3.org/ns/sosa/sampling/

[Back to module overview]

5.2.1.4 sampling:natureOfRelationship

IRI: https://www.w3.org/ns/sosa/sampling/natureOfRelationship

a OWL Object Property

nature of (sample) relationship - Links a Sample Relationship to an indication of the nature of the relationship.

Domain Includes	sampling:SampleRelationship
Range Includes	sampling:SampleRelationship
is Defined By	https://www.w3.org/ns/sosa/sampling/

[Back to module overview]

5.2.1.5 sampling:relatedSample

IRI: https://www.w3.org/ns/sosa/sampling/relatedSample

a OWL Object Property

related sample - Links a Sample Relationship to the related Sample.

Domain Includes	sampling:SampleRelationship
Range Includes	sosa:Sample
is Defined By	https://www.w3.org/ns/sosa/sampling/

[Back to module overview]

7. Common Modeling Questions

This section is non-normative.

@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix qudt-1-1: <http://qudt.org/1.1/schema/qudt#> .
@prefix qudt-unit-1-1: <http://qudt.org/1.1/vocab/unit#> .
<Observation/234534> a sosa:Observation ;
   rdfs:comment "Observation of the difference between 
                    the outside temperature and the inside temperature."@en ;
   sosa:hasFeatureOfInterest <apartment/134> ;
   sosa:hasResult [
      a qudt-1-1:QuantityValue ;
      qudt-1-1:unit qudt-unit-1-1:DegreeCelsius ;
      qudt-1-1:numericValue "-29.9"^^xsd:double ] .
<Observation/83985> a sosa:Observation ;
   rdfs:comment "Observation of the temperature inside apartment #134."@en ;
   sosa:hasFeatureOfInterest <apartment/134> ;
   sosa:hasResult [
      a qudt-1-1:QuantityValue ;
      qudt-1-1:unit qudt-unit-1-1:DegreeCelsius ;
      qudt-1-1:numericValue "22.4"^^xsd:double ] .

@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix om: <http://www.ontology-of-units-of-measure.org/resource/om-2/> .
<Observation/234534> a sosa:Observation ;
   rdfs:comment "Observation of the difference between
                    the outside temperature and the inside temperature."@en ;
   sosa:hasFeatureOfInterest <apartment/134> ;
   sosa:hasResult [
      a om:Measure ;
      om:hasUnit om:degreeCelsius ;
      om:hasNumericalValue "-29.9"^^xsd:double ] .
<Observation/83985> a sosa:Observation ;
   rdfs:comment "Observation of the temperature inside apartment #134."@en ;
   sosa:hasFeatureOfInterest <apartment/134> ;
   sosa:hasResult [
      a om:Point ;
      om:hasScale om:CelsiusScale ;
      om:hasNumericalValue "22.4"^^xsd:double ] .

@prefix cdt: <https://w3id.org/lindt/custom_datatypes#> .
@prefix sosa: <https://www.w3.org/ns/sosa/> .
<observation/123> a sosa:Observation ;
  sosa:hasSimpleResult "12.4 m"^^cdt:length .

ex:Temperature a ssn:Property .
<office/1> a sosa:FeatureOfInterest;
  ssn:hasProperty ex:Temperature . 
<Observation/1> a sosa:Observation ;
  sosa:observedProperty ex:Temperature ;
  sosa:hasFeatureOfInterest <office/1> .
<office/2> a sosa:FeatureOfInterest;
  ssn:hasProperty ex:Temperature . 
<Observation/2> a sosa:Observation ;
  sosa:observedProperty ex:Temperature ;
  sosa:hasFeatureOfInterest <office/2> .

ex:Temperature a owl:Class ;
  rdfs:subClassOf ssn:Property .
<office/1> a sosa:FeatureOfInterest;
  ssn:hasProperty <office/1/temperature> . 
<office/1/temperature> a ex:Temperature , ssn:Property .
<Observation/1> a sosa:Observation ;
  sosa:observedProperty <office/1/temperature> ;
  sosa:hasFeatureOfInterest <office/1> .
<office/2> a sosa:FeatureOfInterest;
  ssn:hasProperty <office/2/temperature> . 
<office/2/temperature> a ex:Temperature , ssn:Property .
<Observation/2> a sosa:Observation ;
  sosa:observedProperty <office/2/temperature> ;
  sosa:hasFeatureOfInterest <office/2> .

ex:TemperatureSensor a ssn:System .
<Observation/1> a sosa:Observation ;
  sosa:madeBySensor ex:TemperatureSensor .
<Observation/2> a sosa:Observation ;
  sosa:madeBySensor ex:TemperatureSensor .
# describing the system capabilities and operating/survival range can be done generically 
# with this modeling choice:
ex:TemperatureSensor ssn-system:hasOperatingRange ex:TemperatureSensorOperatingRange .
ex:TemperatureSensorOperatingRange a ssn-system:OperatingRange ;
  ssn-system:inCondition ex:NormalTemperatureCondition , ex:NormalHumidityCondition .

ex:TemperatureSensor a owl:Class ;
  rdfs:subClassOf ssn:System .
<TemperatureSensor/1> a ex:TemperatureSensor , ssn:System .
<Observation/1> a sosa:Observation ;
  sosa:madeBySensor <TemperatureSensor/1> .
<TemperatureSensor/2> a ex:TemperatureSensor , ssn:System .
<Observation/2> a sosa:Observation ;
  sosa:madeBySensor <TemperatureSensor/2> .
# describing the system capabilities and operating/survival range can be done at the level of 
# the class or at the level of each instance with this modeling choice:
ex:TemperatureSensor  rdfs:subClassOf [
    owl:onProperty ssn-system:hasOperatingRange ;
    owl:hasValue ex:TemperatureSensorOperatingRange ] .
<TemperatureSensor/1> 
  ssn-system:hasOperatingRange ex:TemperatureSensorOperatingRange ; # this axiom can be inferred
  ssn-system:hasOperatingRange <moreSpecificTemperatureSensorOperatingRange> .
<moreSpecificTemperatureSensorOperatingRange> a ssn-system:OperatingRange ;
  ssn-system:inCondition <modeSpecificTemperatureCondition> , <modeSpecificHumidityCondition> .