7.12 Ontology Mapping

7.12.1 Introduction

There are already many standardized or proprietary ontologies defined for various vertical domains or cross-domain scenarios. Each ontology specifies the common vocabulary and relationships between concepts within its own namespace, but may sometimes overlap conceptually with other ontologies due to the independent design. This is often true if two ontologies are designed for the same knowledge domain or under a common high level domain. Different terminologies may mean the same or similar concept (e.g. lamp vs. light), or one is the actually the sub-class of another (e.g. device vs. thing).

To enable the semantic interoperability between different ontologies, ontology mapping is a prerequisite. It's an important ontology management method to identify the commonality, similarity as well as inclusion relationships between ontologies, so that the data described in one ontology can be consumed meaningfully by the application who understand only another ontology. Ontology mapping can also help to build a global knowledge base and enhance the system intelligence by linking together a collection of ontologies via the anchors of equal/similar/inclusive concepts.

Ontology mapping can be implemented by either manual approaches or automatic approaches. For example, in Annex B.1 of oneM2M TS-0012 [5], the ontology mapping between Base Ontology and SAREF is specified by manually configured mapping rules (in the format of mapping tables) according to the experts' common understanding on both ontologies.

However, discovering proper mapping relationships manually is often too labour-intensive, error-prone, and impractical for large ontologies, especially for non-standardized and unstable ones. Therefore, oneM2M provides automatic means of ontology mapping to discover, create and save the mapped relationships between semantically related ontologies by using industry-proven mapping algorithms, e.g. the edit distance, language-based similarity, structural-based similarity, or external- resources-based similarity etc.

The solution is based on the <ontologyMapping> resource to configure the input parameters for executing the ontology mapping task and to store the mapping result. Meanwhile, the <ontologyMappingAlgorithmRepository> resource and its child resources <ontologyMappingAlgorithm> are used to host a collection of algorithms for automatic ontology mapping that can be selected for individual ontology mapping tasks. The detailed procedures related to ontology mapping are specified in clause 6.10, 6.11 and 6.12.

Based on the generated ontology mapping result contained in the <ontologyMapping> resource, semantically equivalent operations such as semantic resource discovery and semantic query can be realized in multi-ontology scenarios as specified in clause 7.12.2.

7.12.2 Semantic query and semantic resource discovery based on the ontology mapping result

7.12.2.1 Introduction

Semantic query and semantic resource discovery operations can be enhanced by leveraging the ontology mapping result stored in the <ontologyMapping> resource, so that an application which understands only one ontology (e.g. Ontology-A) can get the resulting content or resource described in another (e.g. Ontology-B).

This feature requires the issuer to provide an additional request parameter - Ontology Mapping Resources as specified in [1] in a normal semantic query and semantic resource discovery request. This request parameter contains a list of resource identifiers of existing <ontologyMapping> resources that are used as the base of converting the query statement or the semantic description of the target resources into their equivalents.

The following clause describes the detailed procedures using the example ontology mapping result in clause 6.10.2.

Note

There is no difference between the semantic query operation and the semantic resource discovery operation in terms of applying the feature of ontology mapping in addition to the respective original procedures. So the following procedures combine the two operations in to one message flow.

7.12.2.2 Procedures

Figure 7.12.2.2-1: The semantic query (or semantic resource discovery) procedure with ontology mapping

Editor's Note: Replace with PlantUML Diagram

The detailed message flow is depicted in Figure 7.12.2.2-1 and explained as follows:

The hosting CSE (e.g. an oneM2M platform) receives a semantic query (or semantic resource discovery) request from an Originator (e.g. an oneM2M application). The request shall carry a semanticsFilter request parameter that contains the original query statement described in the first ontology (e.g. Ontology-A), as well as an Ontology Mapping Resources request parameter that contains the resource identifiers of one or multiple <ontologyMapping> resources.

Note

that the originator may or may not be the one who created the <ontologyMapping> resources. The use of the <ontologyMapping> resources is subject to the associated access control policy against the originator.

For example, the original query statement may be:

SELECT ?device 
WHERE { 
?device rdf:type Ontology-A:LightSensor.
}

The hosting CSE shall locate the <ontologyMapping> resources according to the resource identifiers in the Ontology Mapping Resources request parameter, and retrieves the mapping results between the first ontology (Ontology-A) and the second ontology (Ontology-B) from the mappingResult attribute of the <ontologyMapping> resources.

For example, the mappingResult may contain the following triple (mapping relationship):
```
Ontology-A:LightSensor  owl:equivalentClass Ontology-B:Light_Sensor
```
3. The hosting CSE shall perform the semantic query (or semantic resource discovery) upon the semantic description of the target resources which reference the first ontology (Ontology-A) or the second ontology (Ontology-B), according to the ontology mapping result and the original query statement. The result shall contain both the original outcome of a normal semantic query (or semantic resource discovery) operation as well as additional outcome of the semantic query (or semantic resource discovery) by using the ontology mapping result. This step comprises the following sub-steps: - a) The hosting CSE shall perform the semantic query (or semantic resource discovery) procedure upon the semantic description of the target resources that reference the first ontology (Ontology-A) using the original query statement, and collect the outcome.
For example, a <container-x> resource may have a <semanticDescriptor> child resource that references Ontology-A (by the ontologyRef attribute) and contains the following triple that matches the original query statement:
```
dev-x rdf:type Ontology-A:LightSensor.
```
- b) The hosting CSE shall perform the semantic query (or semantic resource discovery) procedure upon the semantic description of the target resources that reference the second ontology (Ontology-B) using the ontology mapping result (provided in the <ontologyMapping> resources), and get the additional outcome. This step may be performed in two different approaches that are implementation specific (non-normative):
  - Approach-1: converting the semantic query statement using the ontology mapping result.
    
    The hosting CSE can determine the equivalent query statement described in the second ontology (Ontology-B) by converting from the original query statement described in the first ontology (Ontology-A), according to the ontology mapping result between the first ontology (Ontology-A) and the second ontology (Ontology-B). This can be done by replacing all the ontology class and properties of the first ontology (Ontology-A) in the query statement with the corresponding equivalents of the second ontology (Ontology-B).
    
    According to the examples above, the equivalent query statement becomes:
```
SELECT ?device
WHERE { 
?device rdf:type Ontology-B:Light_Sensor.
}
```
    The hosting CSE then performs the semantic query (or semantic resource discovery) procedure upon the semantic description of the target resources that reference the second ontology (Ontology-B) using the equivalent query statement, and collect the second query (or semantic resource discovery) result.
    
    For example, a <container-y> resource may have a <semanticDescriptor> child resource that references Ontology-B (by the ontologyRef attribute) and contains the following triple that matches the converted equivalent query statement:
```
dev-y rdf:type Ontology-B:Light_Sensor.
```
  - Approach-2: converting the semantic description of the target resources according to the <ontologyMapping> resources.
    
    The hosting CSE can determine the equivalent semantic description in the first ontology (Ontology-A) for the target resources which reference the second ontology (Ontology-B), by converting from the original semantic description in the second ontology (Ontology-B) according to the ontology mapping result. This can be done by replacing all the ontology class and properties of the second ontology (Ontology-B) in the related <semanticDescriptor> resources of the target resources into the equivalents of the first ontology (Ontology-A).
    
    For example, a <container-y> resource may have a <semanticDescriptor> child resource that references Ontology-B (by the ontologyRef attribute) and contains the following triple:
```
dev-y rdf:type Ontology-B:Light_Sensor.
```
    This triple is then converted into the equivalent triple in Ontology-A that matches the original query statement:
```
dev-y rdf:type Ontology-A:Light_Sensor.
```
    The hosting CSE then performs the semantic query (or semantic resource discovery) procedure upon the converted equivalent semantic description using the original query statement, and collect the second query (or semantic resource discovery) result.
The hosting CSE shall combine the query (or semantic resource discovery) results from both step 3a and step 3b, and return the combined results to the originator.

For example, in the case of semantic query, the results are the IRIs of dev-x and dev-y. In the case of semantic resource discovery, the results are the resource identifiers of <container-x> and <container-y>.