Using the Alignment API: a small tutorial on the Alignment API

This version:

https://moex.gitlabpages.inria.fr/alignapi/tutorial/tutorial1/

Author:

Jérôme Euzenat, INRIA & Univ. Grenoble Alpes

Here is a small tutorial for the alignment API. Most of the tutorial is based on command-lines invocations. Of course, it is not the natural way to use this API: it is made for being embedded in some application programme and we are working towards implementing an alignment server that can help programmes to use the API remotely. The complete tutorial is also available as a self-contained script.sh or script.bat. We make no garantee on the MS-DOS script, it is only here for helping.

A companion tutorial has been designed for the Alignment Server. It follows, as much as possible, the reasoning of this tutorial but provides input and output through a web browser.

Preparation

First you must download the Alignment API and check that it works as indicated here.

You can modify the Alignment API and its implementation. In this tutorial, we will simply learn how to use it.

You will then go to the directory of this tutorial by doing:

You can clean up previous trials by:

The goal of this tutorial is only to help you realize the possibilities of the Alignment API and implementation. It can be played by invoking each command line from the command-line interpreter. In this example we use the sh syntax (which only affects the export VARIABLE=VALUE command which can be rewritten as setenv VARIABLE VALUE with c-shells).

The data

Your mission, if you accept it, will be to find the best alignment between two bibliographic ontologies. They can be seen here:

edu.mit.visus.bibtex.owl

is a relatively faithfull transcription of BibTeX as an ontology. It can be seen here in RDF/XML or HTML.

myOnto.owl

is an extension of the previous one that contains a number of supplementary concepts. It can be seen here in RDF/XML or HTML.

These two ontologies have been used for a few years in the Ontology Alignment Evaluation Initiative.

Matching

For demonstrating the use of our implementation of the Alignment API, we implemented a particular processor (fr.inrialpes.exmo.align.cli.Procalign) which:

• Reads two OWL/RDF ontologies;
• Creates an alignment object;
• Computes the alignment between these ontologies;
• Displays the result.

Let's try to match these two ontologies ($CWD is a variable that has been set up to the directory just above this one):

The result is displayed on the standard output. Since the output is too long we send it to a file by using the -o switch:

Additional options are available:

• displaying debug information (-d);
• controling the way of rendering the output (-r);
• deciding the implementation of the alignment method (-i);
• providing an input alignment (-a) [implemented but not used by most methods].

Hence, it is possible to display the alignment in HTML by using the adequate renderer:

See the output in RDF/XML or HTML.

The result is expressed in the Alignment format. This format, in RDF/XML, is made of a header containing "metadata" about the alignment:

and the corresponding set of correspondences:

each correspondence is made of two references to the aligned entities, the relation holding between the entities (=) and a confidence measure (1.0) in this correspondence. Here, because the default method that has been used for aligning the ontologies is so simple (it only compares the labels of the entities and find that there is a correspondence if their labels are equal), the correspondences are always that simple. But it is too simple so we will use a more sophisticated method based on an edit distance:

See the output in RDF/XML or HTML (if rendered as before).

This is achieved by specifying the class of Alignment to be used (through the -i switch) and the distance function to be used (-DstringFunction=levenshteinDistance).

Look at the results: how are they different from before?

We do the same with another measure (smoaDistance):

Manipulating

As can be seen there are some correspondences that do not really make sense. Fortunately, they also have very low confidence values. It is thus interesting to use a threshold for eliminating these values. Let's try a threshold of .33 over the alignment (with the -t switch):

See the output in RDF/XML or HTML (if rendered as before).

As expected we have suppressed some of these inaccurate correspondences. But did we also suppressed accurate ones?

We can also apply this treatment to other methods available:

See the output in RDF/XML or HTML (if rendered as before).

Other manipulations: It is possible to invert an alignment with the following command:

See the output in RDF/XML or HTML (if rendered as before). The results is an alignment from the source to the target. Inverting alignment is only the exchange of the order of the elements in the alignment file. This can be useful when you have an alignment of A to B, an alignment from C to B and you want to go from A to C. The solution is then to invert the second alignment and to compose them.

Output

Once a good alignment has been found, only half of the work has been done. In order to actually use our result it is necessary to transform it into some processable format. For instance, if one wants to merge two OWL ontologies, the alignment can be changed into set of OWL "bridging" axioms. This is achieved by "rendering" the alignment in OWL (through the -r switch):

The result is a set of OWL assertions of the form:

If one wants to use the alignments only for infering on instances without actually merging the classes, she can generate SWRL rules:

which brings for the same assertions:

Exchanging data can also be achieved more simply through XSLT transformations which will transform the OWL instance files from one ontology to another:

this transformation can be applied to the data of data.xml:

for giving the results/data.xml file.

Evaluating

We will evaluate alignments by comparing them to some reference alignment which is supposed to express what is expected from an alignment of these two ontologies. The reference alignment is refalign.rdf (or HTML, if rendered as before).

For evaluating we use another class than Procalign. It is called EvalAlign we should specify this to java. By default, it computes precision, recall and associated measures. It can be invoked this way:

The first argument is always the reference alignment, the second one is the alignment to be evaluated. The result is given here:

Of course, since that method only match objects with the same name, it is accurate, yielding a high precision. However, it has poor recall.

We can now evaluate the edit distance. What to expect from the evaluation of this alignment?

We can see the results of:

It is possible to summarize these results by comparing them to each others. This can be achieved by the GroupEval class. This class can output several formats (by default html) and takes all the alignments in the subdirectories of the current directory. Here we only have the results directory:

The results are displayed in the results/eval.html file whose main content is the table:

n/a: result alignment not provided or not readable
NaN: division per zero, likely due to empty alignment.

Further exercises

More info: https://moex.gitlabpages.inria.fr/alignapi/tutorial/