Copyright © 2018 OGC & W3C ® (MIT, ERCIM, Keio, Beihang), W3C liability, trademark and 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. This note describes some extensions to the SSN ontology to enable:
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 namespace for SSN Extension terms is
http://www.w3.org/ns/ssn/ext/
The suggested prefix for the SSN namespace
is ssn
The suggested prefix for the SOSA namespace is sosa
The suggested prefix for the SSN Extension namespace is ssn-ext
The SSN ontology is available at http://www.w3.org/ns/ssn/.
The SOSA ontology is available at http://www.w3.org/ns/sosa/.
The SSN-Extensions ontology is available at https://github.com/w3c/sdw/tree/gh-pages/proposals/ssn-extensions/rdf.
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.
This document was published by the Spatial Data on the Web Interest Group as a First Public Working Draft.
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 First Public 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.
This document is governed by the 1 February 2018 W3C Process Document.
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:
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:
This Note describes solutions to these requirements.
Classes and properties from the are denoted in this specification using Compact URIs [curie].
The namespace for the SSN-Extensions graph is http://www.w3.org/ns/ssn/ext/.
SSN-Extension re-uses elements from SSN and SOSA [vocab-ssn].
The table below indicates the full list of namespaces and prefixes used in this document.
| Prefix | Namespace |
|---|---|
ex |
http://example.org/ssn/ |
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/ |
ssn-ext |
http://www.w3.org/ns/ssn/ext/ |
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].
This section is non-normative.
The object of the hasFeatureOfInterest property of an observation, act of sampling or actuation is the immediate or proximate FeatureOfInterest.
In some cases this is not the the ultimate thing that the observation, act of 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.
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.
The relationship of the ultimate feature of interest to observations and acts of sampling is illustrated in the figures below.
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.
That approach was unnecessarily coy about satisfying the principle requirement, which is to know the ultimate feature of interest.
The solution described here is explicit, and also applies to acts of sampling and actuation.
A collection of observations may share a common value for one or more of the characteristic observation properties. For example:
oboe:Observation is a collection of oboe:Measurements concerning a common oboe:Entity, with each oboe:Measurement reporting the value of a different oboe:Characteristic.
An alignment module in SSN [vocab-ssn] provided an alignment for the atomic oboe:Measurement to sosa:Observation, but not for oboe:Observation.
These patterns can be accommodated with a new class ObservationCollection which may hold one or more of the properties hasFeatureOfInterest, observedProperty, madeBySensor, usedProcedure, phenomenonTime, or resultTime.
Where present, the value of the property(s) of the collection are shared by all member observations.
Only the value of each actual hasResult is not potentially shared by all member observations.
Collections may be nested. For example, an outer observation-collection may share an observed-property, procedure and sensor, and contain inner observation-collections at different phenomenon-times, each containing a set of observations on different features-of-interest. An observation may be a member of more than one observation-collection, so more than one sequence of nested observation-collections can collect the same set of observations. 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.
Effectively, the results of each observation-collection correspond to a slice in a data-cube composed of the results of the complete set of observations (as long as the values of properties inherited from the collection are not overridden on the nested collections or terminal observations).
This requirement was addressed in OM-Lite [OM-Lite] following the pattern described here.
This feature might also apply to collections of Actuations but has not yet been properly explored.
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.
An ObservationCollection has at least one member, and may have one of any of the other seven properties mentioned in restrictions.
| Class: | ssn-ext:ObservationCollection |
|---|---|
| IRI: |
http://www.w3.org/ns/ssn/ext/ObservationCollection
|
| Definition: | Collection of one or more observations, typically with one or more property shared by all of its members |
| Restrictions: |
ssn-ext:hasMember min 1
sosa:hasFeatureOfInterest max 1
ssn-ext:hasUltimateFeatureOfInterest max 1
sosa:madeBySensor max 1
sosa:observedProperty max 1
sosa:phenomenonTime max 1
sosa:resultTime max 1
sosa:usedProcedure max 1
|
If present, the value of any of sosa:hasFeatureOfInterest,
ssn-ext:hasUltimateFeatureOfInterest,
sosa:madeBySensor,
sosa:observedProperty,
sosa:phenomenonTime,
sosa:resultTime, or
sosa:usedProcedure
apply to all member observations, unless overridden by a value attached directly to the member observation.
See Inheriting observation properties from a collection for a formal definition of the rule.
:hasMember |
:hasUltimateFeatureOfInterest
| Property: | ssn-ext:hasMember |
|---|---|
| IRI: |
http://www.w3.org/ns/ssn/ext/hasMember
|
| Definition: | Link to a member of a collection of observations that share the same value for one or more of the characteristic properties |
| Instance of: | owl:ObjectProperty |
| Sub-property of: | rdfs:member |
| Domain: | ssn-ext:ObservationCollection |
| Range: | sosa:Observation or ssn-ext:ObservationCollection |
The global domain and range constraints mean that any appearance of ssn-ext:hasMember
in a dataset entails that the subject of the statement is a ssn-ext:ObservationCollection
and the object of the statement is a sosa:Observation or ssn-ext:ObservationCollection.
| Property: | ssn-ext:hasUltimateFeatureOfInterest |
|---|---|
| IRI: |
http://www.w3.org/ns/ssn/ext/hasUltimateFeatureOfInterest
|
| Definition: | 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. |
| Instance of: | owl:ObjectProperty |
| Range: | sosa:FeatureOfInterest |
No global domain constraints are specified for this property, so its appearance in a data set does not entail that the subject is a member of any particular class.
However, the ssn-ext vocabulary adds the following guarded constraint to the sosa:Observation class:
| Class: | sosa:Observation |
|---|---|
| Restrictions: |
ssn-ext:hasUltimateFeatureOfInterest min 1
|
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.
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:
| Property | Rule |
|---|---|
ssn-ext:hasUltimateFeatureOfInterest
|
CONSTRUCT { ?this ssn-ext:hasUltimateFeatureOfInterest ?f . }
WHERE {
NOT EXISTS { ?this ssn-ext:hasUltimateFeatureOfInterest ?x . } .
?this sosa:hasFeatureOfInterest/(sosa:isSampleOf)+ ?f .
NOT EXISTS { ?f sosa:isSampleOf ?y . } .
}
|
This is included as a SPIN rule [SPIN] in the RDF representation of the SSN extensions ontology.
If a sosa:Observation or ssn-ext:ObservationCollection is a member of an ssn-ext:ObservationCollection,
the properties of the collection as a whole are associated with all member observations or collections, unless locally specified.
Associating properties with the collection provides for efficiencies in both discovery and encoding.
The rules may be defined formally as SPARQL query expressions [sparql11-query] as follows:
Rules currently only allow for one level of nesting. Update to chase up a chain of observation collections.
| Property | Rule |
|---|---|
sosa:hasFeatureOfInterest
|
CONSTRUCT { ?this sosa:hasFeatureOfInterest ?foi . }
WHERE {
NOT EXISTS { ?this sosa:hasFeatureOfInterest ?x . } .
?oc ssn-ext:hasMember ?this .
?oc sosa:hasFeatureOfInterest ?foi .
}
|
sosa:madeBySensor
|
CONSTRUCT { ?this sosa:madeBySensor ?se . }
WHERE {
NOT EXISTS { ?this sosa:madeBySensor ?x . } .
?oc ssn-ext:hasMember ?this .
?oc sosa:madeBySensor ?se .
}
|
sosa:observedProperty
|
CONSTRUCT { ?this sosa:observedProperty ?op . }
WHERE {
NOT EXISTS { ?this sosa:observedProperty ?x . } .
?oc ssn-ext:hasMember ?this .
?oc sosa:observedProperty ?op .
}
|
sosa:phenomenonTime
|
CONSTRUCT { ?this sosa:phenomenonTime ?pt . }
WHERE {
NOT EXISTS { ?this sosa:phenomenonTime ?x . } .
?oc ssn-ext:hasMember ?this .
?oc sosa:phenomenonTime ?pt .
}
|
sosa:resultTime
|
CONSTRUCT { ?this sosa:resultTime ?rt . }
WHERE {
NOT EXISTS { ?this sosa:resultTime ?x . } .
?oc ssn-ext:hasMember ?this .
?oc sosa:resultTime ?rt .
}
|
sosa:usedProcedure
|
CONSTRUCT { ?this sosa:usedProcedure ?pr . }
WHERE {
NOT EXISTS { ?this sosa:usedProcedure ?x . } .
?oc ssn-ext:hasMember ?this .
?oc sosa:usedProcedure ?pr .
}
|
ssn-ext:hasUltimateFeatureOfInterest
This rule combines the sampling-chain rule and the look-on-the-container rule used in the rest of this section, with the following order of precedence: 1. the (proximate) feature-of-interest of the observation, or the end of its sampling-chain; 2. the explicit ultimate-feature-of-interest of the container collections 3. the (proximate) feature-of-interest of the container collection, or the end of its sampling-chain; |
CONSTRUCT { ?this ssn-ext:hasUltimateFeatureOfInterest ?foi . }
WHERE {
?this a sosa:Observation .
NOT EXISTS { ?this ssn-ext:hasUltimateFeatureOfInterest ?x . } .
OPTIONAL {
?this sosa:hasFeatureOfInterest/(sosa:isSampleOf)* ?foi1 .
NOT EXISTS { ?foi1 sosa:isSampleOf ?y3 . } .
} .
OPTIONAL {
?oc ssn-ext:hasMember ?this .
?oc ssn-ext:hasUltimateFeatureOfInterest ?foi2 .
} .
OPTIONAL {
?oc ssn-ext:hasMember ?this .
?oc sosa:hasFeatureOfInterest/(sosa:isSampleOf)* ?foi3 .
NOT EXISTS { ?foi3 sosa:isSampleOf ?y3 . } .
} .
BIND (COALESCE(?foi1, ?foi2, ?foi3) AS ?foi) .
}
|
Implementation of these as SPIN rules [SPIN] are provided in the ssn-ext.spin.ttl alongside the RDF representation of the SSN extensions ontology.
TBD
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. The RDF Data Cube vocabulary uses the term observation for the results, and the dimensions of a data cube indicate the features of interest and phenomenon times of the results, the measures correspond to the observed properties, and the attributes accommodate information about the procedures and sensors.
A slice selects a subset of the 'observations' by fixing a subset of the dimensions, and thus delivers the set of results of an observation-collection with fixed features-of-interest or phenomenon-times or both.
If the value of the sosa:hasFeatureOfInerest, ssn-ext:hasUltimateFeatureOfInterest, or sosa:phenomenonTime is locally specified, and is different to the value on the containing ssn-ext:ObservationCollection, the results of the collection do not correspond with a splice from a data cube.
The editor would like to thank the members of the W3C/OGC Spatial Data on the Web Interest Group for their contributions during the development of this document.