


A. The Ontologies Alignment Tool
The OAT is available at the following Link: Go-To-OAT. A video presenting the OAT is also available at the following Link: Open-OAT-Video.
When user entering in our site his page looks like the following one:
A.1 Loading ontologies in the Left & Right panels
In the LEFT and RIGHT panels of OAT the end users can load ontologies either uploading their OWL File(s) (i) or providing their URI (ii).
In case another file in being imported, the user will be also requested to upload this file.
When both ontologies loaded, the page looks like the following one.
Then using the 4-tabs being enabled the can map ontologies.
A.2 The 4 tabs presented in the middle screen
1. Exploring Ontological | In this screen the user can simultaneously examine both ontologies description along with their elements. In this screen the user can further examine any other element being involved in their formal description by clicking on it while the availble data are being presented in a new pop-up window. |
---|---|
2. Handle Suggestions |
In this screen the end user can examine correspondences which have been automatically detected based on the definition of corresponding elements. The system enable users to accept or reject the suggested ones.
Users can also massive accept or reject the suggested correspondence based on their confidence value. |
3. Manually define a new Mapping Rule | In this screen the end user can specify a new correspondence among the terms of the ontologies loaded on the two sides of the screen. Using the elements of this screen, the end user can easily define entities 1 and 2 by instantiating the appropriate ontological pattern along with the rest parameters of the mapping rule. |
4. Exploring Mapping Rules specified |
In this screen, the user can further examine the elements aligned (with their definition being presented in a popup window) and delete a mapping rule in case they detect an error. Furthermore, the user can export the correspondences specified in the following formats:
|
B. Mapping Rules
Mapping ontologies involves the specification of one or more mapping rules. Each Mapping Rule specifies the correspondence among the elements of the ontologies.
B.1 Mapping Rule Parameters
In the following table the (M)andatory and (O)ptional parameters of a mapping rule are presented, along with a short description for each one.
Entity 1 and Entity 2 (M) |
Specifies the elements participating in the left and right side of a mapping rule. Entities may refer to
|
---|---|
Transformation (O) |
Specifies the transformation that should take place while moving from one ontology to the other so that the entities being involved are properly aligned |
Relation (M) |
Specifies the relation of Entity 1 towards Entity 2
(e.g., equivalent terms) |
Direction (O) |
Specifies the direction for which the correspondence is valid.
(e.g., from ontology 1 to ontology 2) |
Origin (O) |
Indicates the way the mapping rule has been produced
(e.g., manually specified by the end user through our interface) |
Comments (O) |
Provides a human readable description of the mapping rule along with any other information required
(e.g. confidence value if correspondence arose by accepting a suggested one) |
B.2 Ontological Patterns
Ontological Patterns are being used (instantiated) to determine the elements participating at each side of a mapping rule along with the role of each one.
B.2.1. Ontology Class Patterns
Simple Class Pattern | SCP | An owl Class described by a URI. |
---|---|---|
Class Union Pattern | CUP | A class implied by the union of two or more owl Classes. |
Class Intersection Pattern | CIP | A class implied by the intersection of two or more owl Classes. |
Class By Attribute Occurence Pattern | CAOP | An owl Class any instances of which have a specific Attribute. |
Class By Attribute Value Restriction Pattern | CAVRP | An owl Class any instances of which have a specific Attribute the value of which is within a specific Range. |
B.2.2. Ontology Relation Patterns
Simple Relation Pattern | SRP | An owl Object Property described by a URI. |
---|---|---|
Inverse Relation Pattern | IRP | The inverse relation implied by the owl Object Property given. |
Relation Domain Restriction Pattern | RDRP | An owl Object Property which can be applied (Domain) in those instances which belong to a specific owl Class. |
Relation Range Restriction Pattern | RRRP | An owl Object Property which can point (Range) to those instances which belong to a specific owl Class. |
Relation Path Pattern | RPP | A relation implied by the path formed by two or more owl Object Properties |
B.2.3. Ontology Property Patterns
Simple Property Pattern | SPP | An owl Datatype Property described by a URI. |
---|---|---|
Property Domain Restriction Pattern | PDRP | An owl Datatype Property which can be applied (Domain) in those instances which belong to a specific owl Class. |
Property Range Restriction Pattern | PRRP | An owl Datatype Property the value of which is restricted to be within a specific datatype. |
Property Value Restriction Pattern | PVRP | An owl Datatype Property which can point (Range) to those resources which belong to a specific owl Class. |
Relation Property Path Pattern | RPPP | A property implied by the path formed by one or more owl Object Properties followed by an owl Datatype Property. |
B.2.4. Ontology Individuals Patterns
Simple Instance Pattern | SIP | An owl Individual described by a URI. |
---|
B.2.5. Other Ontological Patterns
Property Collection Pattern | PCP | A collection of Properties (e.g. age and date-recorded) being used to capture the meaning of data. |
---|
B.3 Transformations
Transformations (e.g. Web Services) define the relation of properties from ontology with the other one(s) specified in the other ontology.
Transformations determined in mapping process are utilized for implementing relevant tasks such as query and results translation. Consequently, when mapping ontologies domain experts should describe the transformation that should take place while its implementation in a procedural language can takes place at a later stage (e.g. by an IT expert).
B.3.1. Data Transformations
The "direct"
data transformation is responsible to produce the values of data provided from properties specified in entity 1 to the corresponding one(s) for properties defined in entity 2.
For example, in case the income of a person captured by a different currency, a data/money transformation will be necessary.
B.3.2. Elements Transformations
The "direct"
elements transformation define the relation of elements specified within entity 1 with the other ones specified in entity 2.
For instance, the current age of a person is related (at least being the most appropriate one) with the latest age of person recorded, on condition that date or year of birth is not available.
C. Correspondence Detection
This process intends to automatically produce candidate mapping rules based on the definition of elements in the ontology. The OAT goes one step further from existing approaches focusing on similarity among elements defined to more complex one such as similarity among ontological pattern instances in general.
C.1 Similarity among Labels
The similarity among labels calculated using a variety of techniques including tokenization, elimination, edit distance, N-Gram and best assignment algorithm.
For instance, the similarity of Labels "Person Unique ID" and "Patient Unique ID" is 0.7247
The similarity arises using Hungarian Algorithm so that we can find the best matching of phrases' main tokens ( stop words such as articles are being removed, if presented) divided by their tokens number (3 in this example). In the following table we present the similarity of token along with the best matching selected ( with magenta color )
patient | unique | id | |
---|---|---|---|
person | 0.1741 | 0 | 0 |
unique | 0.0714 | 1 | 0.1 |
id | 0.0714 | 0.1 | 1 |
So, the similarity of labels is: ( 0.1741 + 1 + 1 ) / 3 = 0.7247
C.1.1 Similarity among Tokens
Initially we retrieve the stem of token based on Porter Stemming Algorithm.
The similarity of tokens arises based on the average value of their stems-similarity using Levenshtein distance and N-3-Gram. Follows the similarity of elements presented in the above table.
- "person" , "patient": ( 0.2857 + 0.0625 ) / 2 = 0.1741
- "person" , "unique": ( 0 + 0 ) / 2 = 0
- "person" , "id": ( 0 + 0 ) / 2 = 0
- "unique" , "patient": ( 0.1429 + 0 ) / 2 = 0.0714
- "unique" , "unique": 1 , since tokens are the same.
- "unique" , "id": ( 0.2 + 0 ) / 2 = 0.1
- "id" , "patient": ( 0.1429 + 0 ) / 2 = 0.0714
- "id" , "unique": ( 0.2 + 0 ) / 2 = 0.1
- "id" , "id": 1 , since tokens are the same.
C.2 Candidate Mapping Rules Detection
C.2.1 The algorithm
The algorithm for detecting candidate mapping rules involves the following 3 steps:
- Produce possible ontological patterns instances
- Find similarity among ontological patterns instances
- Keep only those ones with similarity above a predefined threshold.
- In case of conflicts, keep those mapping rule with best similarity
In this process we generate both simple patterns (e.g. SimplePropertyInstance) along with more complex ones (e.g. Property Domain Restriction Patterns). In the latter case, the definition of ontological elements (e.g. in our case the domain class, if defined) is important.
This step involves the calculation of the similarity among object properties based on their name/label along with their domain and range classes, according to the following expression:
( Domain-Class-Similarity + K * Property-Name-Similarity + Range-Class-Similarity ) / ( 2 + K ) , where K = 2
The similarity among ontological patterns takes into account the elements which participate along with the role of each one. For instance, the similarity of a Property Domain Restriction pattern with a Simple one is determined using the expression above, but we use the restricted domain (a sub-class of properties’ domain class) class rather than the initial one (properties’ domain class) specified in their definition.
In order to filter out the ontological patterns instances of low similarity, their calculated similarity is compared against a pre-defined threshold. Given that this threshold is expected to vary depending on the ontologies being aligned as well as their domain, it has been set as part of tool configuration. In our case, for testing and presentation purposes, the threshold has been set to 0.5.
There is a conflict among ontological patterns when they have at least one critical element common. The critical elements are different for each pattern. For example, in a property domain restriction pattern, the property is a critical element, but the domain class not.
C.3 Handle suggested Mapping Rules
C.3.1 Accepting / Rejecting a Mapping Rule
The suggestions found presented in the end user in the second tab like the following figure. In this screen they can easily examine elements participating in candidate mapping rules along with the origin of their similarity (presented in a pop-up window)
The user can easily accept or reject a suggested mapping rule using corresponding buttons on the right side.

The user can also massively accept or reject suggestions based on their similarity.
C.3.2 Reloading Suggestions
Candidate Mapping Rules are automatically updated based on those specified (either by accepting a suggested one or manually specified by the user) or rejected (from those suggested)
For instance, the similarity of aforementioned properties for capturing the Unique ID of a person/patient is updated to 0.8624 (initially was 0.7247) when user specify that their domain classes are equivalent.
D. User defined Mapping Rules
The user can easily define mapping rules missing along with complex ones using the elements presented in the 3rd tab. Based on an interactive environment developed we can easily instanciate the appropriate ontological patterns, specify the entities involved along with the rest parameters of a mapping rule.
When user presses one of entities 1 and 2 buttons a pop-up window presented where they can select the ontological pattern they would like to use / instanciate.
Based on pattern selected, their main screen is being updated. For instance, in the figure follows, the user has selected to instanciate the Property Domain Restriction Pattern. Accordingly they can further define entities involved.
For specifying the entities involved in each pattern, system provides both auto-complete and copy-paste functionalities.
E. Saving Mapping Rules
When all mapping rules specified or part of them, the user can export them in the appropriate format.
The OAT supports the following 3 formats:
F. Source and Binary Code
The source code will be available in the future so that you can further develop application or adjust it in your needs (e.g. use a different correspondence detection algorithm).
The binary code (WAR FILE) will be also available so that you can download and use the application developed locally ( deploy in e.g., Tomcat Server ).
G. Evaluation
The Ontologies Alignment Tool (OAT) has been primarily designed so that it can be used by human beings rather than software agents. Hence user friendliness and satisfaction are two crucial parameters we should examine. For this purpose, we have prepared the following form so that you can provide your experience from using the OAT according to Nielsen Heuristics. More precisely for each one of the functionalities specified, answer to which level it is being provided by OAT (0: not provided, 10: adequately provided), justifying your answers.
In advance, we would like to thank you for your contribution in the evaluation and further development / improvement of OAT.
H. Contact Us
In case you have any question don’t hesitate to contact us in the following email(s): {chondrog, vandro, ekaranas}@mail.ntua.gr