Copyright © 2024 OGC & W3C ® (MIT, ERCIM, Keio, Beihang), W3C liability, trademark, W3C and OGC document use rules apply.

The Semantic Sensor Network (SSN) ontology is an ontology for describing sensors and their observations, the involved procedures, the studied features of interest, the samples used to do so, and the observed properties, as well as actuators. SSN follows a horizontal and vertical modularization architecture, with the core classes and properties defined using minimal axiomatization in a graph called SOSA (Sensor, Observation, Sample, and Actuator) supplemented with additional axiomatization and terms in further graphs. These allow SSN to support a wide range of applications and use cases, including satellite imagery, large-scale scientific monitoring, industrial and household infrastructures, social sensing, citizen science, observation-driven ontology engineering, and the Web of Things.

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

The suggested prefix for the SOSA namespace is sosa.

The SOSA graph containing the core definitions is available at http://www.w3.org/ns/sosa/.
The SSN graph with the full axiomatization of the core terms is available at http://www.w3.org/ns/ssn/.

General Information

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.

Specification

This section introduces the specifications for the RDF implementation of the Semantic Sensor Network Ontology.

RDF implementation

Namespaces

The namespace for the core terms is http://www.w3.org/ns/sosa/
The suggested prefix for the SOSA namespace is sosa:.

Dependencies

Each module of the SSN Ontology is packaged as an RDF file. The RDF representations use owl:imports statements to implement the dependencies. Within each graph, where further information (axioms and annotations) is added to an existing term, rdfs:isDefinedBy indicates the module where the term was originally defined.

Expressivity

The SOSA modules contains the basic definitions of the core terms with minimal axiomatization - only rdf:type and owl:inverseOf - together with key annotations rdfs:label , skos:definition , schema:domainIncludes , schema:rangeIncludes, plus other annotations as required.

The SSN modules contains the full axiomatization of the core terms, importing SOSA modules and using rdfs:subClassOf, rdfs:subPropertyOf, owl:Restriction with the various associated RDFS and OWL structures.

Distribution

SOSA

SOSA Common is available at http://www.w3.org/ns/sosa/common/.

SOSA Actuation is available at http://www.w3.org/ns/sosa/act/.

SOSA Observation is available at http://www.w3.org/ns/sosa/obs/.

SOSA Sampling is available at http://www.w3.org/ns/sosa/sam/.

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

SSN

SSN Common is available at http://www.w3.org/ns/ssn/common/.

SSN Actuation is available at http://www.w3.org/ns/ssn/act/.

SSN Observation is available at http://www.w3.org/ns/ssn/obs/.

SSN Sampling is available at http://www.w3.org/ns/ssn/sam/.

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

Overview of Classes and Properties

The following figures show the key classes and properties in the ontology modules, from the perspectives of Actuation, Observation, and Sampling.

SSN ontology modules - Actuation
Overview of the key classes and properties (actuation perspective)
Explanation of the notation used in class diagrams.
SSN ontology modules - Observation
Overview of the key classes and properties (observation perspective)
Explanation of the notation used in class diagrams.
SSN ontology modules - Sampling
Overview of the key classes and properties (sampling perspective)
Explanation of the notation used in class diagrams.

The following are alphabetical lists of the classes and properties in the SSN Ontology.

Classes: sosa:ActuatableProperty , sosa:Actuation , sosa:ActuatingProcedure , sosa:ActuationCollection , sosa:Actuator , sosa:Deployment , sosa:FeatureOfInterest , sosa:MaterialSample , sosa:ObservableProperty , sosa:Observation , sosa:ObservationCollection , sosa:ObservingProcedure , sosa:Platform , sosa:Procedure , sosa:Property , sosa:PropertyOfInterest , sosa:Sample , sosa:SampleCollection , sosa:Sampler , sosa:Sampling , sosa:SamplingProcedure , sosa:Sensor , sosa:SpatialSample , sosa:StatisticalSample , sosa:Stimulus , sosa:System

Object Properties: sosa:actsOnProperty , sosa:deployedOnPlatform , sosa:deployedSystem , sosa:detects , sosa:forProperty , sosa:hasDeployment , sosa:hasFeatureOfInterest , sosa:hasInput , sosa:hasInputValue , sosa:hasMember , sosa:hasOriginalSample , sosa:hasOutput , sosa:hasOutputValue , sosa:hasProperty , sosa:hasResult , sosa:hasSample , sosa:hasSampledFeature , sosa:hasSubSystem , sosa:hasUltimateFeatureOfInterest , sosa:hosts , sosa:implementedBy , sosa:implements , sosa:inDeployment , sosa:isActedOnBy , sosa:isFeatureOfInterestOf , sosa:isHostedBy , sosa:isObservedBy , sosa:isPropertyOf , sosa:isProxyFor , sosa:isResultOf , sosa:isResultOfMadeBySampler , sosa:isResultOfUsedProcedure , sosa:isSampleOf , sosa:madeActuation , sosa:madeByActuator , sosa:madeBySampler , sosa:madeBySensor , sosa:madeObservation , sosa:madeSampling , sosa:observedProperty , sosa:observes , sosa:phenomenonTime , sosa:relatedObservation , sosa:resultQuality , sosa:usedProcedure , sosa:wasOriginatedBy

Datatype Properties: sosa:hasSimpleResult , sosa:resultTime , sosa:startTime

The SSN classes and properties are described in the following sections, organized by module as described in Modularization above.

SSN Extensions

This section provides details on modules that extend the scope and capabilities of SSN.

Alignments

This section introduces the specifications for the modules that align SOSA and SSN to a variety of related ontologies and specifications.

Common Modeling Questions

This section informally discusses how to handle common modeling questions such as locations, forecasts, and quantity values with a unit of measure.

Location

Many of the key classes provided by SOSA and SSN represent entities that can be located in space such as sensors, features of interest, actuators, samples, and so forth, or activities that can be located via their participating entities, e.g., platforms. These entities will usually be described using models and ontologies defined for application domains, including technical disciplines, social and business contexts. In these contexts there are a number of implementations that support the expression of spatial properties, including location. These are discussed further in the Spatial Data on the Web Best Practices note [[SDW-BP]].

In particular, GeoSPARQL [[GeoSPARQL]] provides a flexible and relatively complete platform for geospatial objects, that fosters interoperability between geo-datasets. To do so, these entities can be declared as instances of geo:Feature and geometries can be assigned to them via the geo:hasGeometry property. In case of classes, e.g., specific features of interests such as rivers, these can be defined as subclasses of geo:Feature.

For example, if observations are made of the atmosphere at a specific location, it might be described as a Sample using the following pattern:



    


    

      
Forecasts

      
One MAY also represent forecasts as observations if the value of sosa:phenomenonTime is later in
        time than the sosa:resultTime.
        Given the definition of these terms, it means that: The time when the Observation act was completed is
          before the time that the Result of the observation applies to the FeatureOfInterest.

      
 Other means to represent forecasts are reported, but not in the scope of this specification.
        For example [[Lefrancois-et-al-2017]] derives the SSN Sensing/Sensor/Observation
        pattern and define Forecasting/Forecaster/Forecast classes.

      
Describing a plan for some actuation or observation in the future is not covered by this
        specification.

    


    

      
Quantity Values and Unit of Measures

      
The result of an sosa:Observation or an sosa:Actuation can be a quantity value with a numeric value and a unit
        of measure.

      
It is not in the scope of this specification to recommend any particular way of expressing results
        as quantity values.
        There exist external vocabularies that are specifically designed for modeling quantity values as OWL
        individuals, or as datatypes.
        Examples include the Quantities, Units, Dimensions and Data Types Ontologies (QUDT, [[QUDT]]) the Ontology of
        Units of Measure (OM, [[Rijgersberg-et-al-2013]]), and the St Etienne School of Mines Custom Datatypes
        (CDT, [[CDT]]). 

      
      
Custom datatypes are not strictly compatible with OWL, which restricts the set of datatypes that
        can be used. See sec. 5.2 in [[owl2-syntax]] for more details.

      

      

      

    


    

      
Generic or Specific Instances of sosa:Property

      
The previous version of SOSA/SSN left an ambiguity on whether an instance of sosa:Property should be generic to all features of interest (e.g.,
        ex:Temperature,
        ex:OnOffStatus), or specific to a single feature of interest (e.g.,
        <myBodyTemperature>, <LightStatus>). This version solves the ambiguity by
        differentiating:
      

      
    



    

      
Generic or Specific Instances of sosa:System

      
This specification does not specify whether an instance of sosa:System
        should be generic (e.g., ex:TemperatureSensor, ex:LightActuator), or specific to a
        single feature of interest (e.g.,
        <temperatureSensor/84>, <light/112>).
        Implementers are free to choose one way of modeling things or the other.
      

      
On the other hand, one SHOULD NOT use OWL
          punning to make ex:Temperature denote both a subclass of
        sosa:Property and an instance of sosa:Property.
        In fact, merging the two examples below in a single RDF Graph would make an OWL reasoner infer that
        ex:TemperatureSensor,
        <TemperatureSensor/1>, and <TemperatureSensor/2>, denote the same
        individual.
      

      
This also holds for subclasses of sosa:System: sosa:Sensor, sosa:Actuator, and
        sosa:Sampler.
      

      
This first example is modeling instances of sosa:System as generic:
      

      

      
This second example is modeling instances of sosa:System as specific:
      

      

    


  


  

    
Wide review

    
Results of the wide review of SOSA and SSN is summarized here.

  


  

    
Complete Examples

    

      
iPhone Barometer

      

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

    

    

      
Coal Oil Point Reserve

      

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

    

    

      
apartment 134

      

        
          
          [Show
              only core SOSA terms]
        
      

      

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

      
      

        
          
          [Show
              only core SOSA terms]
        
      

    


    

      
Tree height measurement

      

        
          
          [Show
              only core SOSA terms]
        
      

      

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

      
      

        
          
          [Show
              only core SOSA terms]
        
      

    


    

      
Seismographs

      

        
          
          [Show
              only core SOSA terms]
        
      

      

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

      
      

        
          
          [Show
              only core SOSA terms]
        
      

    


    

      
Number of sunspots

      
An RDF file containing a graph
          corresponding to
          this example is available. 

      

    


    

      
Wind sensor spinning cups

      

        
          
          [Show
              only core SOSA terms]
        
      

      

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

      
      

        
          
          [Show
              only core SOSA terms]
        
      

    


    

      
Ice Core

      

        
          
          [Show
              only core SOSA terms]
        
      

      

        
In order to characterize a thing with a large extent, or which is not directly accessible, the usual
          observational strategy is to obtain one or more samples. Observations can then be made more conveniently on
          the samples, with the intention of characterizing the larger thing. This intentionality is captured using
          the property sosa:isSampleOf. 

        
In the following example, the ice core is a sample of the Antarctic ice sheet, and observations are made on
          the ice core. 

        
A convenient side effect of this feature is that all observations related to the larger thing (the ice
          sheet) can be found, and then potentially joined together in a meta-analysis in order to characterize that.
        

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

      
      

        
          
          [Show
              only core SOSA terms]
        
      

    


    

      
DHT22 Description

      

        
          
          [Show
              only core SOSA terms]
        
      

      

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

      
      

        
          
          [Show
              only core SOSA terms]
        
      

    



    

      
DHT22 Deployment

      

        
          
          [Show
              only core SOSA terms]
        
      

      

        
This example shows how the conditions (temperature and humidity) in a room can be measured using one or
          more sensors.
          Each sensor observes the conditions in its immediate vicinity, and the values are then used to characterize
          the room. 

        
In Room 145 one of the walls is external in the building, so there is expected to be a temperature gradient
          across the room, and there are two sensors on different walls. In room 245 there is one sensor on the south
          wall.
          Each of these locations corresponds to a sosa:Sample of the entire room.
          The wall also serves as a sosa:Platform on which the sensors are mounted. 

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

      
    

    

      
IP68 Smart Sensor

      

        
This example describes the IP68 Smart Sensor that and some of its capabilities and operating ranges.
          A specific IP68 Smart Sensor observes the air temperature, and its own battery state.

        
An RDF file containing a graph
            corresponding to this example is available. 

        

      

    

  


  


  

    
Acknowledgments

    

      The editors recognize the major contribution of the members of the
      original W3C Semantic Sensor Networks Incubator Group. The editors also
      gratefully acknowledge the contributions made to this document by all
      members of the SSN subgroup of the Spatial Data on the Web working
      group.
    

    

      For this new edition of SSN, in addition to the contributors listed at the top of the document, the editors
      acknowledge the work of the editors of ISO 19156:2023 [[OMS]].
    

  


  

    
Change History

    
A full change-log is available on GitHub.
    

    
Changes since W3C Recommendation 19 October 2017 
        (https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/)

    
    
      
  1. Updated Abstract to reflect the revised graph and axiomatization design
    2. 
      
  2. Updated Chapter 2 'Modularization' to simplify and to reflect the revised graph arrangement
    3. 
      
  3. Changed title of Chapter 4 from 'Axiomatization' to 'RDF Implementation' and updated the summary of
        namespaces
        and graphs
    4. 
      
  4. Adjust namespace of terms previously in sosa:
    5. 
      
  5. Added OMS alignment modules to section 6. 'Vertical Segmentation'
    6. 
      
  6. Added ObservationCollection, SampleCollection, hasMember
    7. 
      
  7. Retire O&Mv2 alignment - superseded by OMS alignment
    8. 
      
  8. Retire SSNX alignment - leave behind a stub giving links to the previous edition of the recommendation and
        to
        the RDF alignment file
    9. 
      
  9. Remove sosa:Input, sosa:Output ; mark ssn:Input, ssn:Output deprecated
    10. 
      
  10. Mark ssn-system:Condition deprecated
    11. 
      
  11. Mark sosa:Result deprecated
    12. 
      
  12. Update OBOE alignment - using ObservationCollection, SampleCollection, hasMember
    13. 
      
  13. remove rdfs:range on sosa:resultTime
    14. 
      
  14. Add content model for Execution, including hasInputValue and hasOutputValue
    15. 
      
  15. Add ActuationCollection to provide basic support for sets of actuations on multiple properties with multiple
        results; clarify meaning of Actuation result
    16. 
      
  16. Clarify meaning of hasResult, resultTime, phenomenonTime in the context of Actuations
    17. 
      
  17. introduced startTime property
    18. 
      
  18. added ActuatingProcedure ObservingProcedure SamplingProcedure MaterialSample SpatialSample StatisticalSample
        relatedObservation resultQuality to SOSA graph and sosa: namespace, removed from SOSA-OMS graph and sosa:oms:
        ns
      
    19. 
      
  19. Refactored SOSA and SSN into modules - sosa-common sosa-actuation sosa-observation sosa-sampling sosa (all),
        and matching ssn-* files (also ssn-deprecated). Refactored HTML sources to match. 
    20. 
      
  20. Add conformance clause
    21. 
      
  21. Update and streamline Introduction; move Origins section to an Annex. 
    22. 
      
  22. re-drafted all figures; added a clause on notation
    23. 
      
  23. retire ssn-system:qualityOfObservation - functionally equivalent to sosa:resultQuality
    24.