Startup

Load and Examine ontologies

Suggestions

Suggested mapping rules

User Mappings

User defined mapping rules

Exporting

Saving mapping rules specified.





Ontologies Alignment Tool

The Ontologies Alignment Tool (OAT) enables end users to easily specify mapping rules through the user friendly interface provided.

The system developed supports the whole alignment process, including:

  • Loading Ontologies
  • Manage Candidate Mapping Rules
  • Manually specified Mapping Rules
  • Saving Mapping Rules

A video presenting the OAT is available at the following Link: Open-OAT-Video.

Mapping Rules

The system enables users to provide mappings among their elements based on an "extended" / "adapted" version of Correspondence Patterns. More precisely it enables end users to:

Easily specify the elements participating at each side of a mapping rule, by instantiating the appropriate Ontological Patterns.

Precisely determine correspondence among elements providing all the rest mapping parameters required, such as data transformation, if required

Capture additional information for each mapping rule, such as its origin.

Correspondence Detection

The system automatically produces candidate correspondences among elements.

It based on their labels incorporating a variety of string-based techniques for similarity detection, including tokenization, elimination, stemming, edit distance, among others.

It also take into account the formal description of ontological elements, such as domain and range or classification of terms for producing not only 1 to 1 correspondences but also more complex ones.

Correspondences automatically produced by system are being updated taking into account those specified or those rejected.

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:
  1. JSON
  2. XML–EDOAL
  3. HTML

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
  1. an existing ontological element
    (e.g., an existing class)
  2. a new one implied by the restriction of meaning and/or usage of an existing ontological element
    (e.g., restricting the domain of a property within a specific class) or generally
  3. any combination of existing ones
    (e.g., union of classes)
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:

  1. Produce possible ontological patterns instances

  2. 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.

  3. Find similarity among ontological patterns instances

  4. 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.

  5. Keep only those ones with similarity above a predefined threshold.

  6. 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.

  7. In case of conflicts, keep those mapping rule with best similarity

  8. 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).

You can download the current version (v.0.6.1) from the following link: OAT-Source-Code

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 ).

You can download the corresponding WAR file from the following link: OAT-WAR

The OAT provides the functionality mentioned in our web site. However, it is still under development, which means that it has a few weaknesses (including bugs), some of which may be resolved in the future releases of the tool.

We suggest using Internet Explorer as a Web Browser, since some jQuery-1.8.2 functions (e.g., form submission using AJAX) do not properly work in Chrome, in the current version of the OAT.

In case of using the OAT, please cite the following paper:
Chondrogiannis, E., Andronikou, V., Karanastasis, E., Varvarigou, T.: An intelligent ontology alignment tool dealing with complicated mismatches. In: Proceedings of the 7th International Workshop on Semantic Web Applications and Tools for Life Sciences, Berlin, Germany (2014).


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


Site updated on Friday 19/09/2014.