Report Work on Mappings

From Semantic Sensor Network Incubator Group
Revision as of 00:41, 15 June 2011 by Llefort (Talk | contribs)

Jump to: navigation, search



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.

Annotation method

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:

  • dc:title
  • dc:date
  • dc:created
  • dc:modified
  • dc:creator
  • dc:author
  • dc:contributor
  • dc:description
  • rdfs:comment
  • dc:rights
  • cc:license

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.

Table 7.1: Summary of Term Mappings
Module Term Name Mapping
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:Sensing [SSN XG]
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:SensorInput [SSN XG]
Skeleton ssn:SensorOutput [SSN XG]

skos:closeMatch 'observation result' [O&M] See comments at ObservationValue.

Skeleton ssn:Stimulus [SSN XG]
Skeleton ssn:detects
Skeleton ssn:featureOfInterest skos:exactMatch 'featureOfInterest' [O&M - ISO/DIS 19156]
Skeleton ssn:forProperty
Skeleton ssn:hasProperty
Skeleton ssn:implementedBy
Skeleton ssn:implements
Skeleton ssn:isPropertyOf
Skeleton ssn:isProxyFor
Skeleton ssn:observationResult skos:closeMatch 'result' [O&M - ISO/DIS 19156]
Skeleton ssn:observedBy
Skeleton ssn:observedProperty skos:exactMatch 'observedProperty' [O&M - ISO/DIS 19156]
Skeleton ssn:ofFeature
Skeleton ssn:sensingMethodUsed [VIM]
System ssn:System [SSN XG]
System ssn:hasSubSystem
Process ssn:Input [MMI Dev]
Process ssn:Output [MMI Dev]
Process ssn:Process [SSN XG]
Process ssn:hasInput
Process ssn:hasOutput
Process ssn:isProducedBy
Measuring ssn:SensingDevice [SSN XG]
Measuring ssn:SensorDataSheet [SSN XG]
Measuring ssn:observes
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:Frequency
MeasuringCapability ssn:Latency
MeasuringCapability ssn:MeasurementCapability Similar idea to MeasurementCapability in MMI Device Ontology 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]
MeasuringCapability ssn:MeasurementProperty
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]
MeasuringCapability ssn:hasMeasurementCapability
MeasuringCapability ssn:hasMeasurementProperty
Observation ssn:madeObservation
Observation ssn:observationResultTime [O&M]
Observation ssn:observationSamplingTime [O&M]
Observation ssn:qualityOfObservation skos:exactMatch 'resultQuality' [O&M - ISO/DIS 19156]
Deployment ssn:Deployment skos:closeMatch 'Deployment' [MMI Dev]
Deployment ssn:DeploymentRelatedProcess [SSN XG]
Deployment ssn:deployedOnPlatform
Deployment ssn:deployedSystem
Deployment ssn:deploymentProcessPart
Deployment ssn:hasDeployment
Deployment ssn:inDeployment
PlatformSite ssn:Platform skos:exactMatch 'platform' [SensorML OGC-0700]
PlatformSite ssn:attachedSystem
PlatformSite ssn:onPlatform
OperatingRestriction ssn:MaintenanceSchedule
OperatingRestriction ssn:OperatingProperty
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:SurvivalProperty
OperatingRestriction ssn:SurvivalRange skos:narrowerMatch 'limiting operating condition' [VIM 4.10]
OperatingRestriction ssn:SystemLifetime
OperatingRestriction ssn:hasOperatingProperty
OperatingRestriction ssn:hasOperatingRange
OperatingRestriction ssn:hasSurvivalProperty
OperatingRestriction ssn:hasSurvivalRange
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.

Data ssn:hasValue
Time ssn:endTime
Time ssn:startTime
ConstraintBlock ssn:Condition
ConstraintBlock ssn:inCondition
Device ssn:Device [SSN XG]
EnergyRestriction ssn:BatteryLifetime
EnergyRestriction ssn:OperatingPowerRange

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 another 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 for Incubator_Report#Semantic_Markup 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.