Abstract

The Semantic Sensor Network Ontology (commonly known as "SSN" or sometimes "SSNO") is an OWL-2 DL ontology for describing sensors and the observations they make. SSN is published in a modular architecture that supports the judicious use of "just enough" semantics for diverse applications, including satellite imagery, large scale scientific monitoring, industrial and household infrastructure, citizen observers, and the Web of Things. SSN is described and examples of its use are given.

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

The suggested prefix for the SSN namespace is ssn

The SSN ontology itself is available at http://www.w3.org/ns/ssn/

Status of This Document

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

This is the second published draft of the SSN since its original publication by the SSN-XG, the Semantic Sensor Network Incubator Group of the W3C. This is an incomplete draft to indicate the scope and style of changes proposed to be made to the original SSN. This document is both incomplete and inconsistent, but is being published at this stage to solicit comment from the community of SSN users and would-be users.

For OGC This is a Public Draft of a document prepared by the Spatial Data on the Web Working Group (SDWWG) — 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.

This document was published by the Spatial Data on the Web Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-sdw-comments@w3.org (subscribe, archives). All comments are welcome.

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

This document was produced by a group operating under the 5 February 2004 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 which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

1. Introduction

This section is non-normative.

Sensor observations are a major source of data published on the Web. Nonetheless, publishing, searching, reusing, and integrating these data requires more than just the observation values. Of equal importance is information about the studied feature of interest, such as a river, the observed property, such as flow velocity, and the sampling strategy, such as the specific locations at which the velocity was measured. The sampling location, instrumentation, and information about the deployment of the sensors on a platform may also be required for proper interpretation. OGC's Sensor Web Enablement standards [OandM], [ SensorML] provide a means to annotate sensors and their observations. However, these standards are not yet integrated and aligned with W3C Semantic Web technologies and Linked Data in particular, that are a key driver for creating and maintaining a global and densely interconnected graph of data. The W3C Semantic Sensor Network Incubator Group (SSN) addressed these issues by developing an ontology that spans multiple OGC standards and other specifications.

The SSN is designed to offer four identifiable and coherent perspectives or use cases for sensing, each of which may be used either independently or in concert with the others. These perspectives are

Sensors
with a focus on what senses, how it senses, and what is sensed;
Data
with a focus on observations and metadata;
Systems
with a focus on systems of sensors; and
Features
with a focus on physical features, properties of them, what can sense them, and what observations of them are made.

It would be worth clarifying that SWE evolving from way back in 2002 provides distinct provider- and consumer-focused standards; SensorML (dealing with sensors) and O&M (dealing with observations and data), as well as an explicit treatment of sampling and the relation with feature-of-interest.

Based on this initial work, the following document specifies a revised, modularized, and extended version of the SSN ontology [SSNO].

2. Developments since the initial 2009 publication of SSN

This section is non-normative.

Justify why we are changing SSN at all

Drawing on considerable implementation experience with SSN since it was first published, it is modified to solve some known problems and to reflect developments in the Linked Data environment. An important one of these developments is the growth of interest in Internet of Things, where SSN has been experimented with but has been observed to be too big, too dependent on OWL reasoning, and missing some key concepts such as Actuation. Specifically,
  1. The namespace has changed to a permanent W3C address.
  2. For the purpose of modularization, a new ontology derived from SSN has been developed. See section Modularization for a detailed description on how the parts relate.

    What is the new core ontology module to be called?

  3. The SSN previously imported the DOLCE ultralite ontology (DUL) and many SSN terms inherited from DUL terms. This has been redesigned into two separate ontology modules so that SSN can be used quite independently of DUL if desired. Some of the alignments have been reconsidered. Those parts of SSN that use DUL terms have been separated into the SSN Alignment with DUL ontology.

  4. Class Sensor has been moved up to become a direct subclass of dul:Object instead of dul:PhysicalObject. This is not expected to affect existing uses of SSN due to dul:Object being a direct parent class of dul:PhysicalObject. This corrects the dul alignment to match the intended scope of ssn:Sensor as it is described in the rdfs:comment property.
  5. Many rdfs:comment annotation properties have changed slightly to improve explanation or to correct minor errors.

    A thorough check and rewrite where necessary on annotation properties is yet to be made.

    A new annotation property is to be used to separate out embedded examples from other rdfs:comment elements

The reader is referred to the appendix for a complete change-log.

3. Modularization

This section is non-normative.

One of the major issue practitioners using the Semantic Sensor Network Ontology as defined in the XG is its complexity, partly due to the layering underneath the DOLCE UltraLite upper level ontology. In response to this, the new Semantic Sensor Network 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 ontology files that are similar in their domain of discourse, but with different ontological commitments, suitable to several use cases.

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 source ontology to a target ontology, and although it is transitive, it only supports knowledge propagation in one direction, i.e. the importing ontology captures all the meaning of the imported terms used, i.e., it includes all axioms relevant to the meaning of these terms, however, the imported ontology may 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.

In fact in [Cuenca-Grau-et-al-2009] it has been proven that in OWL DL, which is a syntactical variant of the Description Logic SHOIN, checking whether an ontology is in fact a module of an ontology given a vocabulary is an undecidable problem.

In order to ensure this property, a solution has to be found for concepts in the ontology module that inherit object properties from concepts that are not in the module. One solution proposed by Cuenca Grau et al is to include the bottom concept for all such missing concepts. Another solution is to change the domain and range of an object property. Our modularization approach uses two different methods depending on the directionality of the segmentation.

Ontology Modules
Fig. 1 Overview of the modules of the SSN ontology. The layering of the rings represents a vertical segmentation, as follows:

Vertical Segmentation

Vertical modules build upon each other, i.e. they directionally owl:import lower level modules. If a higher level module is used without importing its lower levels it may lead to inconsistencies or at least it will lead to different answers when reasoning over the module compared with reasoning over its complete stack of vertical ontology modules. However, lower level modules are independent of their higher level modules and logically consistent.

For example, the Dolce UltraLite Alignment ontology imports the SOSA ontology and the Semantic Sensor Network ontology. However, in reverse, neither SOSA nor SSN import the Dolce-UltraLite Alignment ontology. This makes SOSA, with its lightweight semantics, truly independent of vertical modules that add more expressivity and further ontological commitments.

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.

4. The SOSA ontology

4.1 Introduction

The Sensor, Observation, Sample, and Actuator (SOSA) ontology is one of the modules provided by the Semantic Sensor Network ontology. It acts as the core building block of SSN around which all other classes and relationships evolve. SOSA is designed in a way that supports standalone usage of the ontology, particularly for applications that merely require light-weight specifications such as many Linked Datasets, the Internet Of Things, citizen science, Schema.org-style semantic enrichment of data repositories, and so forth. At the same time, it acts as minimal interoperability fallback level between these applications and their resulting data and those that make use of the full SSN, i.e., SOSA defines those classes and properties for which data that can be safely exchanged across all uses of the SSN.

4.2 Background

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+DNS 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 7. SOSA is also more explicit in its support for virtual sensors and human sensors than SSO. 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.

4.3 SOSA specification: SOSA Classes and Properties

Example

A graphic of a simple example of an use case of the SOSA

....

This specification serves as the SOSA "namespace document".

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

The suggested prefix for the SOSA namespace is sosa

The SOSA ontology itself is available at: http://www.w3.org/ns/sosa/.

Specgen has lost comments if more than one was given. Thus the textual definitions below are incomplete. This needs to be checked closely.

sosa:madeObservation relates a Sensor with an Observation, while sosa:isObservedBy relates an ObservableProperty with a Sensor.
The naming needs to be consistent as this naming pattern is used with other properties for inverse properties.

Currently SOSA defines a xsd:dateTime datatype for resultTime, but no datatype for phenomenonTime. Should both be the same, or is there a difference, i.e. phenomenonTime could be an interval. Is there a need to align that with the Time ontology?

The SOSA introduces the following classes and properties.

Classes: | Actuation | Actuator | FeatureOfInterest | ObservableProperty | Observation | Platform | Procedure | Result | Sample | Sensor |

Properties: | hasFeatureOfInterest | hasResult | hasSample | hasValue | hostedBy | hosts | invokedBy | invokes | isFeatureOfInterestOf | isObservedBy | isResultOf | isSampleOf | madeObservation | observedProperty | observes | phenomenonTime | resultTime | usedProcedure |

Classes and Properties (full detail)


Classes

Class: sosa:Actuation

Actuation - An Actuation carries out an (Actuation) Procedure to change the state of the world using an Actuator.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:Actuator

Actuator - A device that is used by, or implements, an (Actuation) Procedure that changes the state of the world.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:FeatureOfInterest

Feature Of Interest - The feature whose ObservableProperty is being observed by a Sensor to arrive at a Result.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:ObservableProperty

Observable Property - An observable Quality of a Thing; typically of a FeatureOfInterest.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:Observation

Observation - Activity of carrying out an (Observation) Procedure to estimate or calculate a value of a Property of a FeatureOfInterest. Links to a Platform or Sensor to describe what made the Observation and how; links to an ObservableProperty to describe what the result is an estimate of, and to a FeatureOfInterest to detail what that property was associated with. The Result is the output of the observation.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:Platform

Platform - A device, (computational) system, or agent (including humans). A platform carries at least one Sensor, Actuator, or Sampling Device to produce observations, actuations, or samples, by following a Procedure. In case of virtual sensors, a platform can be a computing system which hosts software implementations, e.g., simulations.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:Procedure

Procedure - 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). A Procedure is re-usable, and might be involved in many observations, samplings, or actuations. It explains the steps to be carried out to arrive at reproducible results.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:Result

Result - The Result of an Observation, Actuation, or Sampling. Such result can, for instance, store an observation's value via the hasValue property, e.g., the value for an ObservedProperty of some FeatureOfInterest such as 20m for the height of a tree.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:Sample

Sample - Samples are 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 in an application domain, so there is an expectation of at least one sampledFeature 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 sampling features.
Status: unknown
OWL Class

[#] [back to top]


Class: sosa:Sensor

Sensor - Device, agent (including humans), or software (simulation) involved in, or implementing, a (Sensing) Procedure. Sensors respond to a stimulus, e.g., a change in the environment, and generate a Result. Sensors can be mounted on Platforms, e.g., a modern smart phone hosts multiple sensors.
Status: unknown
OWL Class

[#] [back to top]


Properties

Property: sosa:hasFeatureOfInterest

has feature of interest - A relation between an Observation and the entity whose quality was observed.
Status: unknown
Has inverse property is feature of interest of
Object Property

[#] [back to top]


Property: sosa:hasResult

has result - Relation linking an Observation and a Sensor or Actuator and a Result, which contains a value representing the value associated with the observed Property.
Status: unknown
Has inverse property is result of
Object Property

[#] [back to top]


Property: sosa:hasSample

has sample - Relation between a FeatureOfInterest and the Sample used to represent it.
Status: unknown
Inverse property of is sample of
Object Property

[#] [back to top]


Property: sosa:hasValue

has value - The value of a Result, e.g., 23 or true.
Status: unknown
Datatype Property

[#] [back to top]


Property: sosa:hostedBy

hosted by - Relation between a Sensor or Actuator and the Platform that it is mounted on or hosted by.
Status: unknown
Inverse property of hosts
Object Property

[#] [back to top]


Property: sosa:hosts

hosts - Relation between a Platform and a Sensor or Actuator hosted or mounted on it.
Status: unknown
Has inverse property hosted by
Object Property

[#] [back to top]


Property: sosa:invokedBy

invoked by - Relation linking an Actuation to the Actuator that made that Actuation.
Status: unknown
Inverse property of invokes
Object Property

[#] [back to top]


Property: sosa:invokes

invokes - Relation between an Actuator and the Actuation it has made.
Status: unknown
Has inverse property invoked by
Object Property

[#] [back to top]


Property: sosa:isFeatureOfInterestOf

is feature of interest of - A relation between a FeatureOfInterest and an Observation about it.
Status: unknown
Inverse property of has feature of interest
Object Property

[#] [back to top]


Property: sosa:isObservedBy

is observed by - Relation between an ObservableProperty and the Sensor able to observe it.
Status: unknown
Has inverse property observes
Object Property

[#] [back to top]


Property: sosa:isResultOf

is result of - Relation linking a Result to the Observation that created it.
Status: unknown
Inverse property of has result
Object Property

[#] [back to top]


Property: sosa:isSampleOf

is sample of - Relation from a Sample to the FeatureOfInterest that it is intended to be representative of.
Status: unknown
Has inverse property has sample
Object Property

[#] [back to top]


Property: sosa:madeObservation

made observation - Relation between a Sensor and an Observation it has made.
Status: unknown
Object Property

[#] [back to top]


Property: sosa:observedProperty

observed property - Relation linking an Observation to the Property that was observed. The observedProperty should be a Property (hasProperty) of the FeatureOfInterest (linked by featureOfInterest) of this observation.
Status: unknown
Object Property

[#] [back to top]


Property: sosa:observes

observes - Relation between a Sensor and an ObservableProperty that it is capable of sensing.
Status: unknown
Inverse property of is observed by
Object Property

[#] [back to top]


Property: sosa:phenomenonTime

phenomenon time - The time that the Result of an Observation/Actuation applies to the FeatureOfInterest. Not necessarily the same as the result-time. May be an interval or an instant, or some other compound temporal entity.
Status: unknown
Object Property

[#] [back to top]


Property: sosa:resultTime

result time - The result time is the time when the Observation or Actuation act was completed.
Status: unknown
Range: xsd:dateTime
Datatype Property

[#] [back to top]


Property: sosa:usedProcedure

used process - Relation to link to a re-usable Procedure used in making an Observation or Actuation. Typically a sensor or sensor-system, algorithm, computational Process.
Status: unknown
Object Property

[#] [back to top]


5. The SSN ontology

Note

Documentation in this section has been adapted from something generated by a modified version of Specgen 6 from the SSN ontology. There are known shortcomings of this presentation that will be improved for final form. In particular, annotation properties other than rdfs:comment and rdfs:isDefinedBy are missing throughout. dc:source annotations that identify the provenance of the terms are missing. rdfs:seeAlso annotations are also missing. If you notice any (non-annotation) axiom of SSN that is missing please inform the editors.

Here, ssn:Observation is described as a "situation" equivalent to the SSN-XG version of ssn. That is, a convenient concept that groups together all sorts of information that we identify as an observation. The working group made a decision to redfine ssn:Observation to behave as an act, action, or activity to be closer to the OGC O&M notion of observation. This is not as straightforward as was anticipated and remains an issue to be resolved here.

The SSN at a glance

An a-z index of SSN terms, by class (categories or types) and by property.

Classes: | Accuracy | BatteryLifetime | Condition | Deployment | DeploymentRelatedProcess | DetectionLimit | Device | Drift | FeatureOfInterest | Frequency | Input | Latency | MaintenanceSchedule | MeasurementCapability | MeasurementProperty | MeasurementRange | Observation | ObservationValue | OperatingPowerRange | OperatingProperty | OperatingRange | Output | Platform | Precision | Process | Property | Resolution | ResponseTime | Selectivity | Sensing | SensingDevice | Sensitivity | Sensor | SensorDataSheet | SensorInput | SensorOutput | Stimulus | SurvivalProperty | SurvivalRange | System | SystemLifetime |

Properties: | attachedSystem | deployedOnPlatform | deployedSystem | deploymentProcessPart | detects | featureOfInterest | forProperty | hasDeployment | hasMeasurementCapability | hasMeasurementProperty | hasOperatingProperty | hasOperatingRange | hasProperty | hasSubSystem | hasSurvivalProperty | hasSurvivalRange | implementedBy | implements | inCondition | inDeployment | isProducedBy | isPropertyOf | isProxyFor | madeObservation | observationResult | observationResultTime | observationSamplingTime | observedProperty | observes | ofFeature | onPlatform | qualityOfObservation | sensingMethodUsed |

Classes and Properties (full detail)


Classes

Class: ssn:Accuracy

Accuracy - The closeness of agreement between the value of an observation and the true value of the observed quality.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:BatteryLifetime

Battery Lifetime - Total useful life of a battery.
Sub class of Survival Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Condition

Condition - Used to specify ranges for qualities that act as conditions on a system/sensor's operation. For example, wind speed of 10-60m/s is expressed as a condition linking a quality, wind speed, a unit of measurement, metres per second, and a set of values, 10-60, and may be used as the condition on a MeasurementProperty, for example, to state that a sensor has a particular accuracy in that condition.
Sub class of Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Deployment

Deployment - The ongoing Process of Entities (for the purposes of this ontology, mainly sensors) deployed for a particular purpose. For example, a particular Sensor deployed on a Platform, or a whole network of Sensors deployed for an observation campaign. The deployment may have sub-processes, such as installation, maintenance, addition, and decomissioning and removal.
Sub class of Deployment-related Process
Restriction(s): The property ssn:deployedOnPlatform must be http://www.w3.org/ns/ssn/Platform
The property ssn:deployedSystem must be http://www.w3.org/ns/ssn/System
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:DeploymentRelatedProcess

Deployment-related Process - Class to group all the various Processes related to Deployment. For example, as well as Deployment, installation, maintenance, deployment of further sensors and the like would all be classified under DeploymentRelatedProcess.
Restriction(s): The property ssn:deploymentProcessPart must be http://www.w3.org/ns/ssn/DeploymentRelatedProcess
Has sub class Deployment ssn:Deployment
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:DetectionLimit

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 Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Device

Device - A device is a physical piece of technology - a system in a box. Devices may of course be built of smaller devices and software components (i.e. systems have components).
Sub class of System
Has sub class Sensing Device ssn:SensingDevice
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Drift

Drift - A continuous or incremental change in the reported values of observations over time for an unchanging quality.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:FeatureOfInterest

Feature of Interest - A feature is an abstraction of real world phenomena (thing, person, event, etc).
Restriction(s): The property ssn:hasProperty can be http://www.w3.org/ns/ssn/Property
The property ssn:hasProperty must be http://www.w3.org/ns/ssn/Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Frequency

Frequency - The smallest possible time between one observation and the next.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Input

Input - Any information that is provided to a process for its use [MMI OntDev]
is Defined By http://www.w3.org/ns/ssn/
Disjoint With: Output
OWL Class

[#] [back to top]


Class: ssn:Latency

Latency - The time between a request for an observation and the sensor providing a result.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:MaintenanceSchedule

Maintenance Schedule - Schedule of maintenance for a system or sensor in the specified conditions.
Sub class of Operating Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:MeasurementCapability

Measurement Capability - Collects together measurement properties (accuracy, range, precision, etc) and the environmental conditions in which those properties hold, representing a specification of a sensor's capability in those conditions. The conditions specified here are those that affect the measurement properties, while those in OperatingRange represent the sensor's standard operating conditions, including conditions that don't affect the observations.
Sub class of Property
Restriction(s): The property ssn:forProperty must be http://www.w3.org/ns/ssn/Property
The property ssn:hasMeasurementProperty must be http://www.w3.org/ns/ssn/MeasurementProperty
The property ssn:inCondition must be http://www.w3.org/ns/ssn/Condition
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:MeasurementProperty

Measurement Property - An identifiable and observable characteristic of a sensor's observations or ability to make observations.
Sub class of Property
Has sub class detection limit Selectivity Response time Precision Resolution Latency Frequency Drift Measurement Range Accuracy Sensitivity ssn:DetectionLimit ssn:Selectivity ssn:ResponseTime ssn:Precision ssn:Resolution ssn:Latency ssn:Frequency ssn:Drift ssn:MeasurementRange ssn:Accuracy ssn:Sensitivity
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:MeasurementRange

Measurement Range - The set of values that the sensor can return as the result of an observation under the defined conditions with the defined measurement properties. If no conditions are specified or the conditions do not specify a range for the observed qualities, the measurement range is to be taken as the condition for the observed qualities.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Observation

Observation - An Observation is a Situation in which a Sensing method has been used to estimate or calculate a value of a Property of a FeatureOfInterest. Links to Sensing and Sensor describe what made the Observation and how; links to Property and Feature detail what was sensed; the result is the output of a Sensor; other metadata details times etc.
Restriction(s): The property ssn:featureOfInterest must be http://www.w3.org/ns/ssn/FeatureOfInterest
The property ssn:featureOfInterest at least one http://www.w3.org/ns/ssn/FeatureOfInterest
The property ssn:observationResult must be http://www.w3.org/ns/ssn/SensorOutput
The property ssn:observedProperty must be http://www.w3.org/ns/ssn/Property
The property ssn:observedBy at least one http://www.w3.org/ns/ssn/Sensor
The property ssn:observedBy must be http://www.w3.org/ns/ssn/Sensor
The property ssn:sensingMethodUsed at least one http://www.w3.org/ns/ssn/Sensing
The property ssn:observationSamplingTime occurring at least 0 times
The property ssn:sensingMethodUsed must be http://www.w3.org/ns/ssn/Sensing
The property ssn:qualityOfObservation occurring at least 0 times
The property ssn:observationResultTime occurring at least 0 times
The property ssn:observedProperty must be 1 http://www.w3.org/ns/ssn/Property 1 time(s)
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:ObservationValue

Observation Value - The value of the result of an Observation. An Observation has a result which is the output of some sensor, the result is an information object that encodes some value for a Feature.
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:OperatingPowerRange

Operating Power Range - Power range in which system or sensor is expected to operate.
Sub class of Operating Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:OperatingProperty

Operating Property - An identifiable characteristic of the environmental and other conditions in which the sensor is intended to operate. May include power ranges, power sources, standard configurations, attachments and the like.
Sub class of Property
Has sub class Maintenance Schedule Operating Power Range ssn:MaintenanceSchedule ssn:OperatingPowerRange
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:OperatingRange

Operating Range - The environmental conditions and characteristics of a system or sensor's normal operating environment. Can be used to specify for example the standard environmental conditions in which the sensor is expected to operate (a Condition with no OperatingProperty), or how the environmental and other operating properties relate: i.e., that the maintenance schedule or power requirements differ according to the conditions.
Sub class of Property
Restriction(s): The property ssn:hasOperatingProperty must be http://www.w3.org/ns/ssn/OperatingProperty
The property ssn:inCondition must be http://www.w3.org/ns/ssn/Condition
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Output

Output - Any information that is reported from a process. [MMI OntDev]
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Platform

Platform - An Entity to which other Entities can be attached - particuarly Sensors and other Platforms. For example, a post might act as a Platform, a buoy might act as a Platform, or a fish might act as a Platform for an attached sensor.
Restriction(s): The property ssn:attachedSystem must be http://www.w3.org/ns/ssn/System
The property ssn:inDeployment must be http://www.w3.org/ns/ssn/Deployment
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Precision

Precision - 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.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Process

Process - A process has an output and possibly inputs and, for a composite process, describes the temporal and dataflow dependencies and relationships amongst its parts. [SSN XG]
Restriction(s): The property ssn:hasInput must be http://www.w3.org/ns/ssn/Input
The property ssn:hasOutput must be http://www.w3.org/ns/ssn/Output
The property ssn:hasOutput can be http://www.w3.org/ns/ssn/Output
Has sub class Sensing ssn:Sensing
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Property

Property - An observable Quality of an Event or Object. That is, not a Quality of an abstract entity, but rather an aspect of an entity that is intrinsic to and cannot exist without the entity and that is observable by a sensor.
Restriction(s): The property ssn:isPropertyOf can be http://www.w3.org/ns/ssn/FeatureOfInterest
Has sub class Survival Range Operating Range Measurement Property Survival Property Operating Property Condition Measurement Capability ssn:SurvivalRange ssn:OperatingRange ssn:MeasurementProperty ssn:SurvivalProperty ssn:OperatingProperty ssn:Condition ssn:MeasurementCapability
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Resolution

Resolution - The smallest difference in the value of a quality being observed that would result in perceptably different values of observation results.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:ResponseTime

Response time - The time between a (step) change in the value of an observed quality and a sensor (possibly with specified error) 'settling' on an observed value.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Selectivity

Selectivity - Selectivity is a property of a sensor whereby it provides observed values for one or more qualities such that the values of each quality are independent of other qualities in the phenomenon, body, or substance being investigated.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Sensing

Sensing - Sensing is a process that results in the estimation, or calculation, of the value of a phenomenon.
Sub class of Process
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:SensingDevice

Sensing Device - A sensing device is a device that implements sensing.
Sub class of Device Sensor
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Sensitivity

Sensitivity - Sensitivity is the quotient of the change in a result of sensor and the corresponding change in a value of a quality being observed.
Sub class of Measurement Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Sensor

Sensor - A sensor can do (implements) sensing: that is, a sensor is any entity that can follow a sensing method and thus observe some Property of a FeatureOfInterest. Sensors may be physical devices, computational methods, a laboratory setup with a person following a method, or any other thing that can follow a Sensing Method to observe a Property.
Restriction(s): The property ssn:hasMeasurementCapability must be http://www.w3.org/ns/ssn/MeasurementCapability
The property ssn:observes must be http://www.w3.org/ns/ssn/Property
The property ssn:detects must be http://www.w3.org/ns/ssn/Stimulus
The property ssn:implements can be http://www.w3.org/ns/ssn/Sensing
Has sub class Sensing Device ssn:SensingDevice
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:SensorDataSheet

Sensor Data Sheet - A data sheet records properties of a sensor. A data sheet might describe for example the accuracy in various conditions, the power use, the types of connectors that the sensor has, etc. Generally a sensor's properties are recorded directly (with hasMeasurementCapability, for example), but the data sheet can be used for example to record the manufacturers specifications versus observed capabilites, or if more is known than the manufacturer specifies, etc. The data sheet is an information object about the sensor's properties, rather than a direct link to the actual properties themselves.
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:SensorInput

Sensor Input - An Event in the real world that 'triggers' the sensor. The properties associated to the stimulus may be different to eventual observed property. The event, not the object, triggers the sensor.
Restriction(s): The property ssn:isProxyFor must be http://www.w3.org/ns/ssn/Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:SensorOutput

Sensor Output - A sensor outputs a piece of information (an observed value), the value itself being represented by an ObservationValue.
Restriction(s): The property ssn:hasValue can be http://www.w3.org/ns/ssn/ObservationValue
The property ssn:isProducedBy can be http://www.w3.org/ns/ssn/Sensor
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:Stimulus

Stimulus - An Event in the real world that 'triggers' the 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.
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:SurvivalProperty

Survival Property - An identifiable characteristic that represents the extent of the sensor's useful life. Might include 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 Property
Has sub class System Lifetime Battery Lifetime ssn:SystemLifetime ssn:BatteryLifetime
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:SurvivalRange

Survival Range - The conditions a sensor can be exposed to without damage: i.e., the sensor continues to operate as defined using MeasurementCapability. If, however, the SurvivalRange is violated, the sensor is 'damaged' and MeasurementCapability specifications may no longer hold.
Sub class of Property
Restriction(s): The property ssn:inCondition must be http://www.w3.org/ns/ssn/Condition
The property ssn:hasSurvivalProperty must be http://www.w3.org/ns/ssn/SurvivalProperty
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:System

System - System is a unit of abstraction for pieces of infrastructure for sensing. A system has components, its subsystems, which are other systems.
Restriction(s): The property ssn:hasDeployment must be http://www.w3.org/ns/ssn/Deployment
The property ssn:hasSurvivalRange must be http://www.w3.org/ns/ssn/SurvivalRange
The property ssn:onPlatform must be http://www.w3.org/ns/ssn/Platform
The property ssn:hasSubSystem must be http://www.w3.org/ns/ssn/System
The property ssn:hasSubSystem can be http://www.w3.org/ns/ssn/System
The property ssn:hasOperatingRange must be http://www.w3.org/ns/ssn/OperatingRange
Has sub class Device ssn:Device
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Class: ssn:SystemLifetime

System Lifetime - Total useful life of a sensor or system (expressed as total life since manufacture, time in use, number of operations, etc.).
Sub class of Survival Property
is Defined By http://www.w3.org/ns/ssn/
OWL Class

[#] [back to top]


Properties

Property: ssn:attachedSystem

attached system - Relation between a Platform and any Systems (e.g., Sensors) that are attached to the Platform.
Inverse property of on platform
is Defined By
Object Property

[#] [back to top]


Property: ssn:deployedOnPlatform

deployed on platform - Relation between a deployment and the platform on which the system is deployed.
Inverse property of in deployment
is Defined By
Object Property

[#] [back to top]


Property: ssn:deployedSystem

deployed system - Relation between a deployment and the deployed system.
Inverse property of has deployment
is Defined By
Object Property

[#] [back to top]


Property: ssn:deploymentProcessPart

deployment process part - Relation between a deployment process and its constituent processes (has-part).
is Defined By
Object Property

[#] [back to top]


Property: ssn:detects

detects - A relation from a sensor to the Stimulus that the sensor can detect. The Stimulus itself will be serving as a proxy for (see isProxyOf) some observable property.
is Defined By
Object Property

[#] [back to top]


Property: ssn:featureOfInterest

feature of interest - A relation between an observation and the entity whose quality was observed. For example, in an observation of the weight of a person, the feature of interest is the person and the quality is weight.
is Defined By
Object Property

[#] [back to top]


Property: ssn:forProperty

for property - A relation between some aspect of a sensing entity and a property. For example, from a sensor to the properties it can observe, or from a deployment to the properties it was installed to observe. Also from a measurement capability to the property the capability is described for. Used in conjunction with ofFeature.
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasDeployment

has deployment - Relation between a System and a Deployment, recording that the System or Sensor was deployed in that Deployment.
Has inverse property deployed system
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasMeasurementCapability

has measurement capability - Relation from a Sensor to a MeasurementCapability describing the measurement properties of the sensor.
Sub property of has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasMeasurementProperty

has measurement property - Relation from a MeasurementCapability to a MeasurementProperty such as accuracy (see notes for MeasurementCapability).
Sub property of has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasOperatingProperty

has operating property - Relation from an OperatingRange to a Property such as battery lifetime.
Sub property of has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasOperatingRange

has operating range - Relation from a System to an OperatingRange describing the normal operating environment of the System.
Sub property of has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasProperty

has property - Relation between a FeatureOfInterest and a Property of that feature.
Has sub property has measurement capability has operating property quality of observation has survival range has survival property has measurement property has operating range
Inverse property of is property of
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasSubSystem

has subsystem - Relation between a system and its component parts (has-part).
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasSurvivalProperty

has survival property - Relation from a SurvivalRange of a System to a Property describing the survival range of the system. For example, to the temperature range that a system can withstand before being considered damaged.
Sub property of has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasSurvivalRange

has survival range - Relation from a System to a SurvivalRange.
Sub property of has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:implementedBy

implemented by - Relation between the description of an algorithm, procedure or method and an entity that implements that method in some executable way. For example, between a scientific measuring method and a sensor that senses via that method.
Inverse property of implements
is Defined By
Object Property

[#] [back to top]


Property: ssn:implements

implements - Relation between an entity that implements a method in some executable way and the description of an algorithm, procedure or method. For example, between a Sensor and the scientific measuring method that the Sensor uses to observe a Property.
Has inverse property implemented by
is Defined By
Object Property

[#] [back to top]


Property: ssn:inCondition

in condition - Describes the prevailing environmental conditions for MeasurementCapabilites, OperatingConditions and SurvivalRanges. Used for example to say that a sensor has a particular accuracy in particular conditions. See also MeasurementCapability.
is Defined By
Object Property

[#] [back to top]


Property: ssn:inDeployment

in deployment - Relation between a Platform and a Deployment, meaning that the subject was used as a platform for a system or sensor in the particular deployment. For example, between a buoy and a deployment identifier.
Has inverse property deployed on platform
is Defined By
Object Property

[#] [back to top]


Property: ssn:isProducedBy

is produced by - Relation between a producer and a produced entity. For example, between a sensor and the produced output.
is Defined By
Object Property

[#] [back to top]


Property: ssn:isPropertyOf

is property of - Relation between a FeatureOfInterest and a Property (a Quality observable by a sensor) of that feature.
Has inverse property has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:isProxyFor

isProxyFor - A relation from a Stimulus to the Property that the Stimulus is serving as a proxy for. For example, the expansion of quicksilver is a stimulus that serves as a proxy for temperature. An increase or decrease in the velocity of spinning cups on a wind sensor is serving as a proxy for wind speed.
is Defined By
Object Property

[#] [back to top]


Property: ssn:madeObservation

made observation - Relation between a Sensor and Observations it has made.
is Defined By
Object Property

[#] [back to top]


Property: ssn:observationResult

observation result - Relation linking an Observation (i.e., a description of the context, the Situation, in which the observatioin was made) and a Result, which contains a value representing the value associated with the observed Property.
is Defined By
Object Property

[#] [back to top]


Property: ssn:observationResultTime

observation result time - The result time is the time when the procedure associated with the observation act was applied.
is Defined By
Object Property

[#] [back to top]


Property: ssn:observationSamplingTime

observation sampling time - Rebadged as phenomenon time in [O&M]. The phenomenon time shall describe the time that the result applies to the property of the feature-of-interest. This is often the time of interaction by a sampling procedure or observation procedure with a real-world feature.
is Defined By
Object Property

[#] [back to top]


Property: ssn:observedProperty

observed property - Relation linking an Observation to the Property that was observed. The observedProperty should be a Property (hasProperty) of the FeatureOfInterest (linked by featureOfInterest) of this observation.
is Defined By
Object Property

[#] [back to top]


Property: ssn:observes

observes - Relation between a Sensor and a Property that the sensor can observe. Note that, given the DUL modelling of Qualities, a sensor defined with 'observes only Windspeed' technically links the sensor to particular instances of Windspeed, not to the concept itself - OWL can't express concept-concept relations, only individual-individual. The property composition ensures that if an observation is made of a particular quality then one can infer that the sensor observes that quality.
is Defined By
has sub-property chains madeObservation o observedProperty
hasMeasurementCapability o forProperty
Object Property

[#] [back to top]


Property: ssn:ofFeature

of feature - A relation between some aspect of a sensing entity and a feature. For example, from a sensor to the features it can observe properties of, or from a deployment to the features it was installed to observe. Also from a measurement capability to the feature the capability is described for. (Used in conjunction with forProperty).
is Defined By
Object Property

[#] [back to top]


Property: ssn:onPlatform

on platform - Relation between a System (e.g., a Sensor) and a Platform. The relation locates the sensor relative to other described entities entities: i.e., the Sensor s1's location is Platform p1. More precise locations for sensors in space (relative to other entities, where attached to another entity, or in 3D space) are made using DOLCE's Regions (SpaceRegion).
Has inverse property attached system
is Defined By
Object Property

[#] [back to top]


Property: ssn:qualityOfObservation

quality of observation - Relation linking an Observation to the adjudged quality of the result. This is of course complimentary to the MeasurementCapability information recorded for the Sensor that made the Observation.
Sub property of has property
is Defined By
Object Property

[#] [back to top]


Property: ssn:sensingMethodUsed

sensing method used - A (measurement) procedure is a detailed description of a measurement according to one or more measurement principles and to a given measurement method, based on a measurement model and including any calculation to obtain a measurement result [VIM 2.6]
is Defined By
Object Property

[#] [back to top]


Property: ssn:observedBy

is Defined By
Object Property

[#] [back to top]


Property: ssn:hasValue

has value
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasInput

has input
is Defined By
Object Property

[#] [back to top]


Property: ssn:hasOutput

has output
is Defined By
Object Property

[#] [back to top]


6. Alignment to SSN of the SSN-XG, ssn-ssnx

How should the alignment be formally defined here? This presentation is experimental and rough at present.

This section formally relates the SSN to the previous version of SSN that was published by the SSN-XG ("old SSN"). This may be useful for backward-compatibility and transition purposes. While the namespaces for SSN and DUL have changed since the SSN-XG first published old SSN, every class and property term of SSN here is equivalent to the corresponding class and property term of old SSN with the only exceptions noted here.

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

There are no terms defined in the alignment, so no prefix is recommended.

The SSN alignment, known as "ssn-ssnx" is available at http://www.w3.org/2017/01/ssn-ssnx/.

The class ssn:Sensor has been redefined from the old SSN, so the assertion below holds in (approximately) RDF/XML syntax. 
 
&old = "http://purl.oclc.org/NET/ssnx/ssn#"
&ssn = "http://www.w3.org/ns/ssn/"
<owl:Class rdf:about="&old;Sensor">
    <rdfs:subClassOf rdf:resource="&ssn;Sensor"/>
</owl:Class>
All other SSN class and properties are declared to be equivalent. Therefore, the following pattern applies in (approximately) RDF/XML syntax. 
 
&old = "http://purl.oclc.org/NET/ssnx/ssn#"
&ssn = "http://www.w3.org/ns/ssn/"
For every owl:ObjectProperty O in SSN but not in {Sensor}, 
    assert the fragment:
        <owl:ObjectProperty rdf:about="&old;O">
            <owl:equivalentProperty rdf:resource="&ssn;O">
        </owl:ObjectProperty>
Endfor
For every owl:Class C in SSN but not in {Sensor}, 
    assert the fragment:
        <owl:Class rdf:about="&old;C">
            <owl:equivalentClass rdf:resource="&ssn;C">
        </owl:Class>
Endfor

7. Alignment to DOLCE+DNS Ultralite upper ontology (DUL)

This section introduces the alignment of SSN to DUL. This serves to axiomatically clarify the intended meaning of SSN terms and will assist SSN users wishing to interoperate with other DUL-aligned ontologies.

How should the alignment be formally defined here?

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

There are no terms defined in the alignment, so no prefix is recommended.

The Dolce alignment, known as "ssn-dul" is available at http://www.w3.org/ns/ssn/dul/.

7.1 Classes of DUL Alignment 

 

###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#InformationObject
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#InformationObject> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Method
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Method> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Object
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Object> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#PhysicalObject
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#PhysicalObject> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Process
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Process> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Quality
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Quality> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Region
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Region> rdf:type owl:Class .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Situation
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Situation> rdf:type owl:Class .


###  http://www.w3.org/ns/ssn/DeploymentRelatedProcess
<http://www.w3.org/ns/ssn/DeploymentRelatedProcess> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Process> .


###  http://www.w3.org/ns/ssn/Device
<http://www.w3.org/ns/ssn/Device> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact> .


###  http://www.w3.org/ns/ssn/FeatureOfInterest
<http://www.w3.org/ns/ssn/FeatureOfInterest> rdf:type owl:Class ;
rdfs:subClassOf 
    [ rdf:type owl:Class ;
        owl:unionOf ( <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event>
                      <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Object>
                    )
    ] .


###  http://www.w3.org/ns/ssn/Observation
<http://www.w3.org/ns/ssn/Observation> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Situation> ,
    [ rdf:type owl:Restriction ;
            owl:onProperty <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#includesEvent> ;
            owl:someValuesFrom <http://www.w3.org/ns/ssn/Stimulus>
    ] .


###  http://www.w3.org/ns/ssn/ObservationValue
<http://www.w3.org/ns/ssn/ObservationValue> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Region> ,
    [ rdf:type owl:Restriction ;
        owl:onProperty <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isRegionFor> ;
        owl:someValuesFrom <http://www.w3.org/ns/ssn/SensorOutput>
    ] .


###  http://www.w3.org/ns/ssn/Platform
<http://www.w3.org/ns/ssn/Platform> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#PhysicalObject> .


###  http://www.w3.org/ns/ssn/Process
<http://www.w3.org/ns/ssn/Process> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Method> .


###  http://www.w3.org/ns/ssn/Property
<http://www.w3.org/ns/ssn/Property> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Quality> .


###  http://www.w3.org/ns/ssn/Sensor
<http://www.w3.org/ns/ssn/Sensor> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Object> .


###  http://www.w3.org/ns/ssn/SensorDataSheet
<http://www.w3.org/ns/ssn/SensorDataSheet> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#InformationObject> .


###  http://www.w3.org/ns/ssn/SensorInput
<http://www.w3.org/ns/ssn/SensorInput> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event> .


###  http://www.w3.org/ns/ssn/SensorOutput
<http://www.w3.org/ns/ssn/SensorOutput> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Object> .


###  http://www.w3.org/ns/ssn/Stimulus
<http://www.w3.org/ns/ssn/Stimulus> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event> .


###  http://www.w3.org/ns/ssn/System
<http://www.w3.org/ns/ssn/System> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#PhysicalObject> .

7.2 Object Properties of DUL Alignment 

 

###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#describes
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#describes> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasLocation
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasLocation> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasPart
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasPart> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasParticipant
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasParticipant> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasQuality
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasQuality> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasRegion
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasRegion> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#includesEvent
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#includesEvent> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#includesObject
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#includesObject> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isDescribedBy
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isDescribedBy> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isLocationOf
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isLocationOf> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isObjectIncludedIn
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isObjectIncludedIn> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isParticipantIn
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isParticipantIn> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isQualityOf
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isQualityOf> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isRegionFor
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isRegionFor> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isSettingFor
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isSettingFor> rdf:type owl:ObjectProperty .


###  http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#satisfies
<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#satisfies> rdf:type owl:ObjectProperty .


###  http://www.w3.org/ns/ssn/attachedSystem
<http://www.w3.org/ns/ssn/attachedSystem> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isLocationOf> .


###  http://www.w3.org/ns/ssn/deployedOnPlatform
<http://www.w3.org/ns/ssn/deployedOnPlatform> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasParticipant> .


###  http://www.w3.org/ns/ssn/deployedSystem
<http://www.w3.org/ns/ssn/deployedSystem> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasParticipant> .


###  http://www.w3.org/ns/ssn/deploymentProcessPart
<http://www.w3.org/ns/ssn/deploymentProcessPart> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasPart> .


###  http://www.w3.org/ns/ssn/endTime
<http://www.w3.org/ns/ssn/endTime> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasRegion> .


###  http://www.w3.org/ns/ssn/featureOfInterest
<http://www.w3.org/ns/ssn/featureOfInterest> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isSettingFor> .


###  http://www.w3.org/ns/ssn/hasDeployment
<http://www.w3.org/ns/ssn/hasDeployment> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isParticipantIn> .


###  http://www.w3.org/ns/ssn/hasProperty
<http://www.w3.org/ns/ssn/hasProperty> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasQuality> .


###  http://www.w3.org/ns/ssn/hasSubSystem
<http://www.w3.org/ns/ssn/hasSubSystem> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasPart> .


###  http://www.w3.org/ns/ssn/hasValue
<http://www.w3.org/ns/ssn/hasValue> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasRegion> .


###  http://www.w3.org/ns/ssn/implementedBy
<http://www.w3.org/ns/ssn/implementedBy> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#describes> .


###  http://www.w3.org/ns/ssn/implements
<http://www.w3.org/ns/ssn/implements> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isDescribedBy> .


###  http://www.w3.org/ns/ssn/inDeployment
<http://www.w3.org/ns/ssn/inDeployment> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isParticipantIn> .


###  http://www.w3.org/ns/ssn/isPropertyOf
<http://www.w3.org/ns/ssn/isPropertyOf> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isQualityOf> .


###  http://www.w3.org/ns/ssn/madeObservation
<http://www.w3.org/ns/ssn/madeObservation> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isObjectIncludedIn> .


###  http://www.w3.org/ns/ssn/observationResult
<http://www.w3.org/ns/ssn/observationResult> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isSettingFor> .


###  http://www.w3.org/ns/ssn/observationResultTime
<http://www.w3.org/ns/ssn/observationResultTime> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasRegion> .


###  http://www.w3.org/ns/ssn/observationSamplingTime
<http://www.w3.org/ns/ssn/observationSamplingTime> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasRegion> .


###  http://www.w3.org/ns/ssn/observedBy
<http://www.w3.org/ns/ssn/observedBy> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#includesObject> .


###  http://www.w3.org/ns/ssn/observedProperty
<http://www.w3.org/ns/ssn/observedProperty> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isSettingFor> .


###  http://www.w3.org/ns/ssn/onPlatform
<http://www.w3.org/ns/ssn/onPlatform> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasLocation> .


###  http://www.w3.org/ns/ssn/sensingMethodUsed
<http://www.w3.org/ns/ssn/sensingMethodUsed> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#satisfies> .


###  http://www.w3.org/ns/ssn/startTime
<http://www.w3.org/ns/ssn/startTime> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasRegion> .

8. Alignment to OGC Observations and Measurements

This section introduces the alignment of SOSA/SSN to OGC Observations and Measurements [OandM].

O&M is specified as a UML model, following the patterns specified in ISO 19109 Geographic Information - Rules for Application Schema [ISO-19109]. This means that the classes represent concepts from the application domain, so can be approximately equated with classes in an ontology.

Two OWL implementations of O&M have been described: an explicit translation of the UML [OandM] following the rules specified in [ISO-19150-2]; and a handcrafted version in more idiomatic OWL [OM-Lite]. The advantage of the former is that it provides an RDF resource denoted by a URI and therefore a convenient identifier for every UML class, class attribute, and association-role from the original O&M model, but at a cost of including a large set of dependencies on similar OWL translations of several other UML models from the ISO 19100 series.

Complete SOSA/SSN to O&M mapping table should be included in the SSN document and an alignment ontology provided.

9. Work Plan

This section is non-normative.

This section identifies work that is planned to be done in the next iteration of the document. Comment on these topics and their priority is invited.

Check and reconsider or redesign modularization of SSN. See proposal in charter: noting the work to split the ontology into smaller sections to offer simplified access

Modularization of SSN might work like some of the following suggestions under discussion

  1. Clearly separate observation, sensor, and deployment parts.

    How do we align Observation to O&M, does it become a prov:Activity?

  2. What is the scope of SOSA and what classes/properties are included?

    Should sao:point and sao:segment be inside the core for time series analysis?

    What is the scope of the sosa:Platform class and how does it relate to the ssn:Platform?

    Is the sosa:Process class needed in the core and how is it different to ssn:Process?

    What are the implication of the new sosa:Result class, should that be changed in SSN too, i.e. collapse ssn:SensorOutput and ssn:ObservationValue into one class?

    Design for Actuation in sosa needs to be revisited and justified with best practices.

    Do we need Sampling in SOSA?

    What is the alignment between Sensor in SOSA and SSN?

  3. Disentangling SSN from DUL may require adding things to SSN that were otherwise needed from DUL, for example, measured values.

    How do we replace those components of dul that seem to be core to ssn if dul is not being used?

  4. Consider O&M alignment (see O&Mlite). Assuming the DUL separation above works well, the O&M alignment could be handled the same way. There is a known issue with incompatibility with SSN+DUL and O&M resulting from a difference in modelling observations.

What goes in SSN and what should be just a recommended profile/extract/extension? These could include e.g. WoT? Iot-lite? satellite sensors? samples? human sensors? Or do we just advise how to do this in general?

Are there additional properties needed for ssn:observation to represent forecasts as observations.

Given the distinction between records and events, ssn:Observation is not the same concept as om:Observation. This arises also in alignment with PROV-O

Align SSN with PROV-O

Two such alignments have already been published in the literature [SSN-PROV] and [OM-Lite]. One proposal functions mostly rather like the alignment to DUL as described above in form, but some rather useful SWRL is also used.

Is it ok to use SWRL, too, for this? Or would it be better to make some bigger changes to SSN to align with PROV-O?

Is the provenance requirement in scope?

Align SSN with RDF datacube

This alignment is necessary, at least, for the common use case of sensored time-series. There are a few examples in the literature, but it is suggested that some structural change to core SSN is needed to make this work. This needs to be considered in the context of the DUL disentanglement above because the encoding of measured values is important here. Observed properties also need to be checked.

SSN for IoT devices

This could be achieved by defining a small SSN module that is suitable for small devices; by adopting IoT-lite or some other IoT ontology with a well-defined relationship to SSN (ie a formalised alignment). There are suggestions to reduce memory by short uris and labels (and annotations?), too.

In this context actuation is a clear need and should be considered.

The user should be able to understand the network resource cost of proposed instructions (for example, power required per measurement, current battery life, latency before instructions can be executed). These qualities could be interpreted by the scientist user directly, or by an automated agent aiming to optimize network efficiency through resource scheduling and optimisation algorithms.

Align SSN with the ontology developed for the coverage deliverable

We would like to show that the sensors that observe coverage (commonly satellite, but could be in-situ ground-based sensors) can be described using SSN while their observations can be described via the SDW coverage deliverable.

Extend SSN to cover requirements identified in our UCR

These should be done by optional extensions to SSN, in the style of the optional DUL alignment above, so as to minimally impact existing users and to avoid overcrowding of the core. The requirements are recorded in the UCR document.

Align SSN to implement Best Practices as defined in our BP deliverable.

In particular, the modelling of time and space should concur. SSN should tighten its modelling of location. There are relevant UCR requirements for this.

Extend SSN to to cover requirements identified in our wish List. These requirements have not been discussed in the group and are subject to prioritisation and resources.

See the Wish list on the Group's wiki. Of those, what is not covered elsewhere in this document is reproduced briefly here. Refer to the wish list for more detail, rationale and possible implementations.
  1. CSV data encoding
  2. JSON data encoding
  3. More help for observed value encoding (although this overlaps somewhat with issues above)
  4. Activation
  5. Network Structure
  6. Systems, Platforms and Deployment
  7. Scope and Overlap
  8. Uncertainty
  9. Sampling Features and Specimens

Review annotation properties, including multilingual. Fix typos and spelling.

Issue 61

Extend SSN to cover these things https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Various_Sensor_Use_Cases_.28SSN.29 (Action-25)

10. Documentation

This section is non-normative.

This is a note of some proposed documentation, resources permitting.

  1. Success Stories (also called use cases) as a way to understand whether SSN is the right tool for the job
  2. Tutorial Introduction to SSN and documentation for new users in general. Make a video version of the tutorial. (Given the expected user group for all the outputs of this WG, this idea should really extend to all the deliverables of the WG)
  3. Reasoning and other Inference SSN uses lots of OWL that enables reasoning support for clever stuff. This should be explained (how to leverage it?).
  4. We have agreed to publish an accompanying Primer that will show how to use SSN tutorial-style and will include advice on how to use the DUL alignment.

A. Acknowledgements

The Editors recognise the major contribution of the members of the W3C Semantic Sensor Networks Incubator Group.

B. Change history

Changes since the original include
  1. The Dolce Ultra Lite ontology, that was imported in to ssn, is no longer imported and all axioms using terms from DUL have been removed from SSN and collected in the DUL-SSN alignment ontology.
  2. The namespace was changed to match the planned namespace for this publication.
  3. The modularization as presented here, including the core, is entirely new.

Changes since the FPWD include...

  1. Correction to include some ssn terms that were unintentionally dropped from the FPWD. Correction to remove an asserted subclass of owl:Thing that was introduced into FPWD (these were both by-products of Dolce removal).
  2. Correction to some https namespace usage that crept into the FPWD
  3. Transition to the new namespace used by the DUL ontology
  4. Inclusion of the DUL alignment and the old SSN (of the SSN-XG) alignment.
  5. ssn:Sensor has been changed to be a subclass of dul:Object instead of dul:Physical Object
  6. Various typography and spelling errors and consistency of expression in annotation properties have been improved. These do not induce any changes in the intended meaning of the terms.
  7. Specgen 6 has been used to generate the ontology documentation. The popular sketch of SSN structure has been removed.

  8. Object properties ssn:isValueOf, ssn:produces and ssn:featureinObservation, along with a propertychain subproperty of produces and another propertychain subproperty of hasProperty, were introduced unintentionally in the FPWD. These have been removed here but could be reinstated if there is demand.

C. References

C.1 Informative references

[Cuenca-Grau-et-al-2009]
Bernardo Cuenca Grau; Ian Horrocks; Yevgeny Kazakov ; Ulrike Sattler. Springer. Extracting Modules from Ontologies: A Logic−based Approach. 2009. URL: https://www.cs.ox.ac.uk/publications/publication779-abstract.html
[ISO-19109]
ISO. Geographic information -- Rules for application schema. December 2015. URL: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=59193
[ISO-19150-2]
ISO. Geographic information -- Ontology -- Part 2: Rules for developing ontologies in the Web Ontology Language (OWL). July 2015. URL: http://www.iso.org/iso/catalogue_detail.htm?csnumber=57466
[OM-Lite]
Simon Cox. IOS Press/Semantic Web. Ontology for observations and sampling features, with alignments to existing models. 6 December 2016. URL: http://content.iospress.com/articles/semantic-web/sw214
[OandM]
Simon Cox. Open Geospatial Consortium. Observations and Measurements (O&M). 2011. URL: http://www.opengeospatial.org/standards/om
[SSN-PROV]
Michael Compton; David Corsar; Kerry Taylor. CEUR: 7th International Conference on Semantic Sensor Networks. undefined. 2014. URL: http://ceur-ws.org/Vol-1401/paper-05.pdf
[SSNO]
Michael Compton; Payam Barnaghi; Luis Bermudez; Raúl García-Castro; Oscar Corcho; Simon Cox; John Graybeal; Manfred Hauswirth; Cory Henson; Arthur Herzog; Vincent Huang; Krzysztof Janowicz; W. David Kelsey; Danh Le Phuoc; Laurent Lefort; Myriam Leggieri; Holger Neuhaus; Andriy Nikolov; Kevin Page; Alexandre Passant; Amit Sheth; Kerry Taylor. Web Semantics: Science, Services and Agents on the World Wide Web, 17:25-32 . The SSN ontology of the W3C semantic sensor network incubator group. December 2012. URL: http://www.sciencedirect.com/science/article/pii/S1570826812000571
[SSO-Pattern]
Krzysztof Janowicz; Michael Compton. CEUR: Proceedings of the 3rd International Workshop on Semantic Sensor Networks (SSN10). The Stimulus-Sensor-Observation Ontology Design Pattern and its Integration into the Semantic Sensor Network Ontology. 2010. URL: http://ceur-ws.org/Vol-668/paper12.pdf
[SensorML]
Mike Botts; Alex Robin. OGC. SensorML: Model and XML Encoding Standard 2.0. 2014. Encoding Standard, OGC 12-000. URL: http://portal.opengeospatial.org/files/55939