Interoperable Knowledge Queries

Interoperable knowledge queries are Common Logic-based queries that allow (1) the retrieval of cross-domain arguments over known semantic mapping concepts and (2) the retrieval of semantic mapping concepts over known cross-domain arguments. These queries fall in the category of structured query processing of alignments supported by ontologies (Noy and Stuckenschmidt, 2005) and the explanation of matching results in ontology matching (Shvaiko and Euzenat, 2008). The integrity of results obtained from an interoperable knowledge query can be verified via logical proof. This proof is traced back from the source logic of the semantic mapping concepts, the cross-domain arguments in question and a breakdown of the conditions, as to why certain cross-domain arguments satisfy certain semantic mapping concepts, in order to provide a valid logical justification. The next sub-sections of this chapter explain, in an exemplified fashion, the relevant mechanisms involved in evaluating and verifying interoperable knowledge queries.

Interoperability Evaluation Layer

Interoperable Knowledge Queries

DomainX DomainY

Merged and Aligned Domain Models

Foundation Layer

DomainX DomainY

Figure 6-13 Interoperable Knowledge Queries in the Interoperability Evaluation Layer

6.3.1.1 Querying Cross-Domain Arguments over Known Semantic Mapping Relations

One possible way of formulating interoperable knowledge queries in the Interoperability Evaluation Layer is to create a general query over a known semantic mapping relation and deduce whether or not there are cross-domain arguments that have become bound to the semantic mapping relation during the semantic alignment process previously discussed. Consider the example illustrated in Figure 6-14 which is based on Figure 6-7.

In the diagram, the class “Locating_Hole”, defined in the “DomainX” context is a sub-class of “Round_Hole” and the class “Gate_Hole”, defined in “DomainY”

is another sub-class of the foundation class “Round_Hole”. During the semantic alignment process, based on the logical conditions that define the relation “classMappingRelation_018” (A), the classes “Locating_Hole” and

“Gate_Hole” are inferred as being valid ?x and ?y arguments to the

“classMappingRelation_018” respectively (refer to (A), (B) and (C) in the expression in Figure 6-14). Recall that this semantic mapping concept helps to establish a correspondence between cross-domain sub-classes of

“Round_Hole” and also increases awareness about possible class mismatches between these cross-domain sub-classes.

Assuming that the user is unaware of the semantic mapping relation between

“Locating_Hole” and “Gate_Hole”, the person could formulate a query by selecting “classMappingRelation_018” to find out whether or not there are

(forall (?x ?y)

Figure 6-14 Example of a Scenario to Be Queried which Returns a One-to-One Mapping Result

arguments bound by the relation. This query would be in the Common Logic statement of: (classMappingRelation_018 ?x ?y)

If the query transaction returns results, then the results would be in the form of a list of all the possible combinations under “classMappingRelation_018”. In the example depicted in Figure 6-14, the argument ?x would be

“Locating_Hole” while the argument ?y “Gate_Hole”, thereby returning a one-to-one mapping. In the event that there were two or more specialisations of

“Round_Hole” defined in the “DomainX” context and one specialisation of the same foundation class declared in the “DomainY” context as shown in Figure 6-15, then there would be a many-to-one mapping under the same logical conditions that define “classMappingRelation_018”. Many-to-many mappings would occur in the presence of a plurality of sub-classes of “Round_Hole” in both “DomainX” and “DomainY”.

The type of querying method mentioned in this section is highly useful when the user readily understands the implied semantics of the queried semantic mapping concept and wants to discern what cross-domain arguments are bound by the relation. However, not in all circumstances is the user expected to be an expert in interpreting semantic mapping concepts. For this reason, this querying method is not always preferred from a user perspective. The next sub-section explains an alternative direction to optimise interoperable knowledge querying procedures. Furthermore, a potential problem occurs when there is a large number of semantic mapping concepts that needs to be

sup

sup sup

Locating_

Hole

Round_

Hole

Gate_Hole classMappingRelation_018

Locating_

Hole

classMappingRelation_018

DomainX DomainY

Figure 6-15 Example of Many-to-One Mapping Results

managed. Section 6.3.2 suggests a method to facilitate the management of semantic mapping concepts for reusability.

6.3.1.2 Querying Semantic Mapping Relations over Known Cross-Domain Arguments

An alternative way of formulating queries, in the Interoperability Evaluation Layer, is to discover in a single querying transaction all the semantic mapping relations that hold between two chosen cross-domain arguments. Selecting cross-domain arguments can be performed by browsing through the merged domain models. It is to be noted that the selection of cross-domain arguments is dependent on the user‟s objectives and intentions during the querying procedure. Consider the example portrayed in Figure 6-16 which is based on Figure 6-8.

In the illustration, the instance “Hole_X”, defined in the “DomainX” context is an instance of “Round_Hole” and the instance “Hole_Y”, defined in “DomainY”

is another instance of the foundation class “Round_Hole”. Assuming that

“Hole_X” and “Hole_Y” both satisfy the given logical conditions for holding blind hole bottom parameters (according to (E), (F) and (G)), the relation

“instanceMappingRelation_041” (D) infers the instances “Hole_X” and

“Hole_Y” as being valid ?holex and ?holey arguments to the

Knowing that “Hole_X” and “Hole_Y” exist in the merged domain models, the user is able to write a query with the intention of retrieving all possible semantic mapping relations based on foundation semantics that bind these two instances together, where “Hole_X” is in the first argument position and

“Hole_Y” in the second argument position. The person would do so by stating a query in the form:

(and (BinaryRelation ?rel) (withinContext ?rel foundationMapping) (holdsArg

?rel 1 DomainX.Hole_X) (holdsArg ?rel 2 DomainY.Hole_Y))

When the query is run, the user is able to gather a list of all the semantic mapping relations based on foundation semantics, that apply to the instances

“Hole_X” and “Hole_Y”. The query should return the binary relation

“instanceMappingRelation_041” as a relation that binds “Hole_X” and

“Hole_Y”. The user is then able to browse “instanceMappingRelation_041” in order to view the informal remarks that are tagged to the relation for further interpretation of the correspondence. It is to be noted that the way to formulate queries is dependent on the expertise of the user in the use of KFL.

It is also possible to provide user interfaces for guiding the user through querying procedures as explained in sections 6.3.2 and Chapter 7 section 7.3.4. This helps to retrieve accurate queries that do not demand a solid knowledge of KFL on behalf of the user.

6.3.1.3 Verification of Reconciliation Correspondences

It has been acknowledged that the verification of alignment results (Lazenberger et al, 2008) forms an important facet of ontology alignment for knowledge sharing and reuse. In the research framework, by committing to the Foundation Layer, multiple KBs (in this case domain models) are enforced a common set of rules and constraints, which is particularly useful when attempting to verify the interactions of multiple KBs (Cochrane, 2006). Hence, following the framework approach, the verification of reconciliation correspondences between cross-domain arguments is the procedure by which the results obtained from a query action are checked for conformance

to (1) the logical conditions set in the query and (2) any inferred logical conditions based on semantic mapping concepts.

Based on the scenario in Figure 6-16 and Figure 6-17, the verification process entails the action of proving the reason why “instanceMappingRelation_041”

corresponds to the queried variable ?rel. The logical proof in this case reflects the fact that in the query:

 ?rel is a binary relation.

 ?rel has been defined in the “foundationMapping” context and is, therefore, a semantic mapping relation based on foundation semantics.

 ?rel holds the argument “Hole_X” in the first argument position.

 “Hole_X” is an argument defined in the “DomainX” context.

 ?rel holds the argument “Hole_Y” in the second argument position.

 “Hole_Y” is an argument defined in the “DomainY” context.

Since “instanceMappingRelation_041” satisfies all the above-mentioned conditions and “Hole_X” and “Hole_Y” also satisfy the criteria for the relation to bind them together (through inferred logical conditions), this implies that

“instanceMappingRelation_041” is in fact ?rel. Hence, the reconciliation correspondence is a verified semantic mapping relation that holds for

“Hole_X” and “Hole_Y”, since its occurrence can be proved.

Hole_X ¹ ?rel ² Hole_Y

Query: Find ?rel such that …

Result: ?rel is instanceMappingRelation_041

Verify: Why does “instanceMappingRelation_041”

correspond to the queried variable ?rel

Figure 6-17 Example of a Verification Procedure

Verification processes are particularly significant when different parties involved in multi-domain model reconciliation wish to become aware of the logical conditions pertaining to the reasons as to why certain semantic mapping concepts exist between cross-domain arguments. Therefore, automated verification through the exploitation of heavyweight logic is key to ensuring the integrity of sharable knowledge between systems.