The Semantic Sensor Network (SSN) ontology is an ontology for describing sensors and their observations, the procedures used, the features of interest and observed properties that are the subject of observation, samples used in the course of observations, as well as actuators.
This document describes some extensions to the SSN ontology to enable:
linking directly to the ultimate feature-of-interest for an act of observation, sampling, or actuation, alongside the link to the (proximate) feature-of-interest, which might be a sample
homogeneous collections of observations, in which one or more of the feature-of-interest, ultimate feature-of-interest, observed-property, procedure, sensor, phenomenon-time or result-time may be shared by all members of the collection
The namespace for SSN terms is http://www.w3.org/ns/ssn/
The namespace for SOSA terms is
http://www.w3.org/ns/sosa/
The suggested prefix for the SSN namespace
is ssn
The suggested prefix for the SOSA namespace is sosa
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/.
For OGC - This is a Public Draft of a document prepared by the Spatial Data on the Web Interest Group
(SDWIG)
— a joint W3C-OGC project (see charter).
The document is prepared following W3C conventions. This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
New classes and properties are introduced in this extension to SSN.
The new elements primarily relate to additional requirements for describing observations and collections of observations.
The ontology document <owl:imports> the SSN ontology, and adds the new elements and axioms in a new RDF namespace.
GitHub Issues are preferred for
discussion of this specification.
Alternatively, you can send comments to our mailing list.
Please send them to
public-sdwig@w3.org
(archives).
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
W3C Patent Policy.
The group does not expect this document to become a W3C Recommendation.
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.
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 [vocab-ssn].
The elements of the ontology are defined in two modules:
SOSA - which defines the basic classes and properties, with a weak axiomatization comparable to schema.org
SSN - which adds a full axiomatization to the SOSA classes and properties, and adds additional elements relating particularly to sensor descriptions and to support alignment to DOLCE Ultralite
However, a number of requirements for describing observations that have been described in the research literature ([OM-Lite], [OBOE]) are not supported directly by SSN.
In particular:
discovery and use of observation data typically depends on their relationship to an ultimate feature-of-interest, which is a known thing in the world (such as a geological formation, or a specific patient, or the state of the atmosphere). However, if the (proximate) feature-of-interest of the observation is a sample of the ultimate feature-of-interest (such as a rock specimen, a blood or biopsy sample, or a specific transect through the atmosphere), the identity of the ultimate feature-of-interest can be obtained only by following a chain of one or more sosa:isSampleOf relationships, if they are even recorded. This may not be possible in a single request on a data service
discovery and management of samples and sample data depends on the relationship of a sample to the actual feature of interest for which it is a proxy. The sosa:isSampleOf relationship is key, but in many cases there is a chain of samples, each sub-sampling another sample, so the link to the original feature-of-interest is indirect. Furthermore, in some cases (for example chemical analyses) multiple sub-samples are made and used to measure different characteristics, and it is helpful if these can all be related to the original sample that was taken immediately from the feature of interest.
observations are usually made as part of a set or collection, within which variations of the result are of interest. A collection is typically designed so that one or more of the key observation properties are shared by all members of the collection -
hasFeatureOfInterest,
observedProperty,
madeBySensor,
usedProcedure,
phenomenonTime,
resultTime
For efficient discovery and data transfer it is helpful if the set of observation descriptions is packaged in a standard way that captures the common properties at the collection level.
This document describes solutions these requirements.
2. Notation and namespaces
The classes and properties described in this document are denoted using Compact URIs [curie].
These classes and properties are put into the RDF namespace for SOSA, i.e. http://www.w3.org/ns/sosa/ which is used for the core elements of SSN [vocab-ssn], since the new classes and properties are expected to be used in the same context.
However, these extensions to SOSA/SSN are packaged in a separate graph (ontology file) which is denoted http://www.w3.org/ns/ssn/ext/, and is currently available from the GitHub repository.
The table below indicates the full list of namespaces and prefixes used in this document.
Prefix
Namespace
owl
http://www.w3.org/2002/07/owl#
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
sosa
http://www.w3.org/ns/sosa/
ssn
http://www.w3.org/ns/ssn/
xsd
http://www.w3.org/2001/XMLSchema#
Where class descriptions include local restrictions on properties, these are described using the OWL 2 Manchester Syntax [owl2-manchester-syntax].
Examples and other code fragments are serialized using RDF 1.1 Turtle notation [turtle].
All examples and tests are available from the GitHub repository.
3. Principles and vocabulary overview
This section is non-normative.
3.1 Ultimate feature of interest
The object of the original hasFeatureOfInterest property of an act of observation, sampling, or actuation is the immediate or proximateFeatureOfInterest.
In some cases this is not the the ultimate thing that the act of observation, sampling, or actuation is concerned with, but is an intermediate thing, often a sample of the ultimate feature of interest, or perhaps a sample of a sample, etc.
There will often be a specifiable relationship between the proximate and ultimate feature of interest, such as a sampling-chain.
If this relationship is recorded, then an ultimate feature of interest might be inferred.
Nevertheless, particularly for discovery purposes, it is usually the ultimate feature of interest that really matters to the data user.
This requirement is satisfied by an object property called hasUltimateFeatureOfInterest.
Some patterns for the relationship of the ultimate feature of interest to observations (Figure 1) and acts of sampling (Figure 2), and within sampling-chains, are illustrated below.
Figure 1 Patterns for observations that relate to the ultimate feature of interest directly (top),
or indirectly via one sample (middle) or a chain of samples (bottom) - new property shown in redFigure 2 Patterns for sampling that relate to the ultimate feature of interest directly (top),
or indirectly via one intermediate sample (middle) or a chain of intermediate samples (bottom) - new properties shown in red
Note
This requirement was described in OM-Lite [OM-Lite], but was addressed there using a different pattern in which the property oml:featureOfInterest always links to the ultimate feature-of-interest, and an additional property oml:samplingStrategy links to the sample or some other description of the sampling arrangements.
However, that approach allowed multiple possible interpretations of ‘featureOfInterest’, and only representated chains of sampling or observation events indirectly.
The solution described here is explicit, and also applies to acts of sampling and actuation.
3.2 Basis of a chain of samples
Many observation workflows rely on a chain of samples, each making a sub-sample of the predecessor sample.
Knowing either the original sample or the initial feature of interest at the base of the chain is often useful for both discovery and management purposes.
For example, Figure 3 shows a scenario from geology involving many samples derived from an initial one, with some relationships that may be useful in processing and discovery of subsequent observations, the intention of which will be to characterize various aspects of the original sample which is representative of an ultimate feature of interest.
This is supported by two further object properties for relationships between samples and features of interest, called hasOriginalSample and hasSampledFeature.
Figure 3 It is common to generate a chain of samples in a geology exploration scenario, with initial sample retrieval from the field followed by a sequence of sample preparation steps to generate a series of sub-samples.
Having a direct indication of an original sample allows multiple results to be combined to describe the sample.
Having a direct indication of the ultimate feature being sampled allows discovery of many samples that are intended to be representative of that feature.
Note that the scenario in Figure 3 is simplified from real-life scenarios, and also that the diagram only shows a subset of the full set of resources and relationships.
3.3 Homogeneous collection of observations
A collection of observations may share a common value for one or more of the characteristic observation properties.
For example:
many monitoring processes generate a stream of data in which only the (phenomenon-) time changes between consecutive results for the same property on a single feature of interest, observed using the same procedure implemented using the same sensor.
a sensor network typically generates a set of results, over the same time interval, for the same property(s), over a suite of features-of-interest.
Imaging sensors could be considered a special case of this, where the proximate features-of-interest correspond with individual pixels in the result.
These patterns can be accommodated with the class ObservationCollection individuals of which may hold one or more of the essential properties of an atomic observation, except for the result.
Where present, the value of the property(s) of the collection are shared by all member observations.
Of the essential properties of an observation, only the value of each actual hasResult is not potentially shared by all member observations, though at least one of the other properties would be expected to vary between members in a typical collection.
For example, Figure 4 describes a collection of remote sensing observations using the same sensor on different scenes, while Figure 5 is a series of the same scene on different days.
Figure 4 A set of remote sensing observations of different scenes on the same dayFigure 5 A series of remote sensing observations of the same scene on the different days
Collections may be nested.
For example, an outer observation-collection might share the observed-property, procedure and sensor, and contain inner observation-collections at different phenomenon-times, each of which contain a set of observations on different features-of-interest (Figure 6).
Figure 6 Example of a set of nested collections of four observations of the same property of two features-of-interest at two different times.
Observations can be factored into collections in more than one way, so more than one set of nested observation-collections can collect the same set of atomic results.
For example, the same outer collection may contain inner collections concerning different features-of-interests, each containing a set of observations at different phenomenon-times (Figure 7).
Figure 7 Alternative set of nested collections with the same results of the same property of two features-of-interest at two different times.
Effectively, the results of each observation-collection correspond to a slice in a data-cube which is composed of the results of the complete set of observations.
Note
This requirement was addressed in OM-Lite [OM-Lite] following the pattern described here.
Note
This feature might also apply to collections of Actuations but this application has not yet been explored.
4. Vocabulary specification
In this vocabulary specification, Manchester syntax [owl2-manchester-syntax] is used where the value of a field is not a simple term denoted by a URI or cURI [curie].
Figure 8 Model for an observation-collection, in which the collection may carry one or more of the properties of its members if they have a shared value for all members - new properties and classes shown in red
link to the ultimate feature of interest of an observation or act of sampling. This is useful when the proximate feature of interest is a sample of the ultimate feature of interest, directly or trasntitively.
This constraint says that at least one ultimate-feature-of-interest is expected for each individual observation.
Typically an observation concerns one ultimate feature-of-interest but in some cases the proximate feature-of-interest is a sample of more than one ultimate feature of interest.
The explanation of relationships between multiple ultimate features of interest are beyond the scope of this vocabulary.
This constraint says that at least one sampled feature is expected for each individual sample.
More than one sampled feature may apply when a single sample proxies for different ultimate features when used in multiple investigations.
4.3 Rules
4.3.1 Finding ultimate feature of interest of an Observation or Sampling from a sampling chain
If the ultimate feature-of-interest of an Observation, Sampling or Actuation, or ObservationCollection is not specified,
and the feature-of-interest is a Sample,
then the ultimate-feature-of-interest can be found by following a path from the feature-of-interest
to the end of a sequence of sosa:isSampleOf relations (see Figure 1, Figure 2).
The rule can be expressed formally as a SPARQL query expression [sparql11-query] as follows:
CONSTRUCT { ?this sosa:hasUltimateFeatureOfInterest ?f . }
WHERE {
{ ?this a sosa:Observation } UNION { ?this a sosa:ObservationCollection } UNION { ?this a sosa:Sampling } UNION { ?this a sosa:Actuation }
NOT EXISTS { ?this sosa:hasUltimateFeatureOfInterest ?x . } .
?this sosa:hasFeatureOfInterest/(sosa:isSampleOf)+ ?f .
NOT EXISTS { ?f sosa:isSampleOf ?y . } .
}
4.3.2 Finding the ultimate feature of interest that a Sample represents from a sampling chain
Sometimes it is useful to know what is the actual feature-of-interest that a sample represents.
If this is not asserted with a sosa:hasSampledFeature then a candidate feature may be found by following a path from the sample to the end of a sequence of sosa:isSampleOf relations (see Figure 2).
This rule can be expressed formally as a SPARQL query expression [sparql11-query] as follows:
CONSTRUCT { ?this sosa:hasSampledFeature ?f . }
WHERE {
?this a sosa:Sample
NOT EXISTS { ?this sosa:hasSampledFeature ?x . } .
?this (sosa:isSampleOf)+ ?f .
NOT EXISTS { ?f sosa:isSampleOf ?y . } .
}
Note that a sample might represent more than one feature of interest, different by scale or some other defining property.
4.3.3 Finding the original Sample from a sampling chain
Sometimes it is useful to know what was the original sample taken from the ultimate feature-of-interest that a sample represents.
If this is not asserted with a sosa:hasOriginalSample then a candidate sample may be found by following a path from the sample through a sequence of sosa:isSampleOf relations until the last sample (see Figure 2).
This rule can be expressed formally as a SPARQL query expression [sparql11-query] as follows:
Note that most important original sample might not be the one closest to the domain feature.
For example, in Figure 3 for many practical scenarios it will be a sample retrieved from the field that is of interest, and not the outcrop which is also modeled as a sample of the geologic unit.
In such a case an explicit assertion of the original sample will be more relevant than the computed one.
4.3.4 Inheriting observation properties from a collection
In the above expression, $property is replaced by any one of the seven properties listed
5. Alignments
5.1 RDF Data Cube vocabulary
The W3C RDF Data Cube vocabulary [vocab-data-cube] provides a means to describe multi-dimensional data according to a 'data cube' model inspired by SDMX, from which a 'slice' represents a collection of observations that is homogeneous in some property or dimension.
Hence, for a collection of observations the datacube (qb:) model may be used to express aspects of homogeneity - such as whether a set of observations are all related to the same ultimate feature of interest, or the same type of feature of interest etc. Feature of interest, phenomenon time, observation procedure will typically correspond to qb:dimension sub-properties, qb:measures will be the observed properties and qb:ComponentDescriptions for qb:measures may indicate result types. qb:attribute sub-properties may be used for qualifying and annotating information.
In future a general model for the inter-relation of dimensions, sensors, observed properties, phenomena, units of measure, sampling precision, procedures, etc. could use qb:dimension concepts to describe observation and sampling strategies.
Note
If the value of any of the properties such as the sosa:hasFeatureOfInterest, sosa:hasUltimateFeatureOfInterest, or sosa:phenomenonTime is locally specified, and is different to the value on the containing sosa:ObservationCollection, the results of the collection do not correspond with a slice from a data cube.
5.2 OBOE
The OBOE alignment module in SSN [vocab-ssn] provided an alignment for the atomic oboe:Measurement to sosa:Observation, but not for oboe:Observation.
The ObservationCollection supports the full encoding of an oboe:Observation, which is a collection of oboe:Measurements concerning a common oboe:Entity, with each oboe:Measurement reporting the value of a different oboe:Characteristic, as shown in Figure 9.
Figure 9
The OBOE core model (left), shown alongside the SSN-ext model (right) with comparable classes and properties aligned - new properties and classes shown in red.
