Report Work on Mappings
From Semantic Sensor Network Incubator Group
At the 2010-02-02 teleconf the Group resolved to amend the second deliverable of the Charter, from How mappings can be constructed both from these ontologies to existing standards and from suitably annotated documents complying with existing standards to the ontologies.
This is now replaced by Illustrate [the SSN ontology's] relationship to OGC Sensor Web Enablement standards. The relationship is illustrated in two ways:
- Lineage of terms: Reference sources of SSN vocabulary terms are identified in the ontology as annotations of the terms, and also (more readably) on our SSN-XG wiki.
- Relationships to OGC standards: Worked examples are provided that show the application of our recommended markup technique to SWE technologies (especially Sensor ML and SOS).
In addition, we have aligned the SSN ontology with the Dolce Ultra-Lite upper ontology to support the integration of the SSN ontology with others. This alignment is documented elsewhere and summarised below.
- See also 2010-06-02 teleconf
Lineage of terms
Reference sources of SSN vocabulary terms are identified in the ontology as annotations of the terms, and are also presented on our SSN-XG wiki and summarised in this section.
The Group developed the following principles for annotation of terms in the ontology.
1. Every class and property definition is supported by the annotation property "rdfs:comment" which contains a textual string explaining the intended meaning of the class or property in English. This would not generally be a rewritten form of the formal class definition, but should support that definition by placing it in a real-world context, using words drawn from the ontology where appropriate.
2. Every class and property definition is supported by the annotation property "dc:source" which contains a textual string that identifies the source of the term and the corresponding "rdfs:comment" annotation property. This can be done informally e.g. it might contain "This is similar to MMI, but the notion of system that it depends on is different", or "This is new for this ontology -- we haven't seen this concept before". In most cases URLs are given to reference the sources. In some cases a term from the W3C SKOS vocabulary (Simple Knowledge Organization System (SKOS) is embedded in the "dc:source" annotation to relate the term to its use in an external vocabulary referenced by a URL.
3. Each class and property definition is supported by an annotation property "rdfs:seeAlso" which contains a URL pointing to a page on our SSN-XG wiki. This identifies the term as belonging to a module of the ontology and also points to its English explanation. This URL is used to generate the wiki presentation of the explanations, organised by module, from the original explanation that is maintained in the "rdfs:comment" of the ontology.
- See also 2010-06-08 teleconf-
Sources of term definitions
SSN definitions have been sourced from existing resources like OGC (SWE_terms) and VIM (VIM_terms) or from other lists of definitions previously developed e.g. MMI_OntDev_terms or MINET_Glossary. Relevant Wikipedia definitions (Wikipedia_terms) were also collected: the rationale was to identify terms which can be interpreted in multiple ways in different contexts which Wikipedia handles with its "disambiguation" mechanism.
In some cases, e.g. for the Issue 2 "All processes are systems" discussion, it was not possible to find applicable definitions from the resources listed above and the group opted to develop new definitions.
Documentation generation solution
We use an XSLT tool to generate the ontology documentation adapted from the tool chain developed by Ian Davis . The tool uses some Dublin Core, RDFS, and Creative Commons vocabulary terms for the ontology header:
The output is an HTML file which can be converted into a wiki page (using Open Office to do the transformation from HTML to MediaWiki syntax) and uploaded to the wiki. Our XSLT tool also exploits the rdfs:seeAlso annotations to split the OWL content into thematic modules and isolates important information such as the dc:source annotations included for term lineage and the links to external ontologies like DOLCE Ultra Lite.
See also Issue-7 Doc format/generation Documentation format - Generation of documentation derived from the OWL file
Summary of Term Mappings
This table presents the a summary of the sources of terms used in the SSN ontology. It is extracted from the "rdfs:seeAlso" annotation of the respective classes and properties in the SSN ontology. Those terms without a corresponding entry in the Mapping column of the table are original in the SSN ontology.
|Skeleton||ssn:FeatureOfInterest||skos:exactMatch 'feature' [O&M]|
|Skeleton||ssn:Observation|| skos:closeMatch 'observation' [O&M] Observation in this ontology and O&M are described differently (O&M records an observation as an act/event), but they record the same thing and are essentially interchangeable. The difference is in the ontological structure of the two, not the data or use. Observation here records a Situation (the estimation of the value of a Property) and a description of the method that was used (along with the participants), while O&M interprets an Observation as the event itself; there must, however, have been an event that lead to our situation, so both are records of events. The distinction is between the event itself and the record of what happened in that event.
skos:closeMatch 'measurement result' [Measurement VIM 2.9] result in VIM is the measured value plus any other relevant information, which means that measurement result and observation will often be associated to the same data (a value, a time, a property, etc.).
|Skeleton||ssn:Property||skos:exactMatch 'property' [O&M]|
|Skeleton||ssn:Sensor|| skos:exactMatch 'sensor' [SensorML OGC-0700]
skos:closeMatch 'observation procedure' [O&M] O&M allows sensors, methods, instruments, systems, algorithms and process chains as the processUsed of an observation; this ontology allows a similar range of things (any thing that can do sensing), just they are all grouped under the term sensor (which is thus wider than the O&M concept).
|Skeleton||ssn:SensorOutput|| [SSN XG]
skos:closeMatch 'observation result' [O&M] See comments at ObservationValue.
|Skeleton||ssn:featureOfInterest||skos:exactMatch 'featureOfInterest' [O&M - ISO/DIS 19156]|
|Skeleton||ssn:observationResult||skos:closeMatch 'result' [O&M - ISO/DIS 19156]|
|Skeleton||ssn:observedProperty||skos:exactMatch 'observedProperty' [O&M - ISO/DIS 19156]|
|MeasuringCapability||ssn:Accuracy||skos:exactMatch 'measurement accuracy/accuracy' [VIM 2.13]|
|MeasuringCapability||ssn:DetectionLimit||skos:exactMatch 'detection limit' [VIM 4.18]|
|MeasuringCapability||ssn:Drift||skos:exactMatch 'instrumental drift' [VIM 4.21]|
|MeasuringCapability||ssn:MeasurementCapability||Similar idea to MeasurementCapability in MMI Device Ontology http://marinemetadata.org/community/teams/ontdevices But the the two express the relationship between constraints and multiple measurement properties differently. The conditions linked to a MeasurementCapability are skos:exactMatch to 'influence quantity' [VIM 2.52] http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf|
|MeasuringCapability||ssn:MeasurementRange||skos:exactMatch 'measuring interval/measurement range' [VIM 4.7]|
|MeasuringCapability||ssn:Precision||skos:exactMatch 'measurement precision/precision' [VIM 2.15]|
|MeasuringCapability||ssn:Resolution||skos:exactMatch 'resolution' [VIM 4.14]|
|MeasuringCapability||ssn:ResponseTime||skos:exactMatch 'step response time' [VIM 4.23]|
|MeasuringCapability||ssn:Selectivity||skos:exactMatch 'selectivity' [VIM 4.13]|
|MeasuringCapability||ssn:Sensitivity||skos:exactMatch 'sensitivity' [VIM 4.12]|
|Observation||ssn:qualityOfObservation||skos:exactMatch 'resultQuality' [O&M - ISO/DIS 19156]|
|Deployment||ssn:Deployment||skos:closeMatch 'Deployment' [MMI Dev]|
|PlatformSite||ssn:Platform||skos:exactMatch 'platform' [SensorML OGC-0700]|
|OperatingRestriction||ssn:OperatingRange||skos:broaderMatch 'reference operating condition' [The VIM 4.11] difference is that here we also allow for qualities that aren't VIM influence quantities [VIM 2.52] - for example, a quantity that alters the power requirements, but doesn't affect the measurement properties - conditions specified in MeasurementCapability should be influence quantities.|
|OperatingRestriction||ssn:SurvivalRange||skos:narrowerMatch 'limiting operating condition' [VIM 4.10]|
|Data||ssn:ObservationValue|| skos:exactMatch 'measured quantity value' [VIM 2.10]
skos:exactMatch 'observed value' [SensorML OGC-0700]
skos:closeMatch 'observation result' [O&M] O&M conflates what we have as SensorOutput and ObservationValue into observation result, though the OGC standard does say "result contains a value" and "a result which has a value", which fits naturally with the model here.
Relationships to OGC standards
As a major deliverable of the XG, the Group has developed a proposal for Semantic Markup (also known as Semantic annotation) that suggests how the SSN ontology can be used in conjunction with OGC standards such as Observations and Measurements (O&M) and the Sensor Web Enablement (SWE) services. This is documented in the Semantic Markup section of this report. The proposal relies on embedding ontology references within XML attributes in a style that is consistent with OGC recommendations and some community practice. In order to illustrate the SSN ontology's relationship to OGC Sensor Web Enablement standards, worked examples are provided that show the application of our recommended markup technique to SWE technologies (especially Sensor ML and the Sensor Observation Service). See the examples in the Semantic Markup section and also see Linked Sensor Data for a description of an application for the SSN ontology in combination with OGC SWE.
Although not an OGC standard, the DOLCE foundational ontology is well known in the OGC research community, and is sometimes used for representing spatial and temporal concepts. We have aligned the SSN ontology to the DOLCE-derived OWL DL ontology known as DOLCE Ultra Lite, or DUL (see Skeleton module). This is intended to support integration with other domain ontologies as illustrated by the Agriculture Meteorology example.