The Alignment API 4.0

Paper Title: 
The Alignment API 4.0
Jérôme David, Jérôme Euzenat, François Scharffe and Cássia Trojahn dos Santos
Alignments represent correspondences between entities of two ontologies. They are produced from the ontologies by ontology matchers. In order for matchers to exchange alignments and for applications to manipulate matchers and alignments, a minimal agreement is necessary. The Alignment API provides abstractions for the notions of network of ontologies, alignments and correspondences as well as building blocks for manipulating them such as matchers, evaluators, renderers and parsers. We recall the building blocks of this API and present here the version 4 of the Alignment API through some of its new features: ontology proxys, the expressive alignment language EDOAL and evaluation primitives.
Full PDF Version: 
Submission type: 
Tool/System Report
Responsible editor: 
Sören Auer

Note: This is the final version of the paper. The reviews below are for the initially submitted version.

Solicited review by Jens Lehmann:

The article presents version 4 of the Alignment API. The main purpose of this Java API is to describe, manipulate and compare alignments of ontologies. The article focuses mostly on differences to a previous publication of the API in 2004.

The paper fits the "Semantic Web Tools and Systems" call perfectly: The tool is mature, freely available on the Web and handles a relevant problem. My impression is that the API has been properly maintained for several years. There have been regular releases and several 3rd party tools use the API. There is plenty of documentation available online, which makes it straightforward to use the tool for several purposes. Documentation of the code itself through Javadoc exists, but should be further improved. We also performed some tests of the tool within our research group and found it easy to use. A nice feature would be support for (potentially very large) knowledge bases available via SPARQL endpoints (in contrast to local OWL files).

The describing paper is well-written and provides a good overview of the system. I have three suggestions for improvement (apart from minor problems listed below):

* Section 4 about the alignment language EDOAL should be more detailed in my opinion. It is not clear to me why EDOAL did not simply use OWL 2 class expressions [1] as base and add transformations as a feature on top of it. The syntax in the expression above Figure 4 is also quite unintuitive from my perspective. In my opinion it should either be closely related to predicated logic (e.g. replacing the >= sign with an implication arrow) or it should borrow from OWL 2 syntax, e.g. Manchester or DL Syntax. At least there should be a pointer to a syntax description of those expressions included in the article.

* The conclusion section lists several very important aspects regarding the impact of the tool. This should deserve a separate section and be described in more detail as I consider it highly relevant. For instance, Section 6, which is very short, could be renamed to "Availability and Impact", such that an extended version of the points mentioned in the conclusions could go there.

* The paper should contain a section about related systems and how they differ from the Alignment API, e.g. the COMA++, SILK, FOAM, Crosi frameworks/tools. An important part of a system paper should be a description how it fits into the landscape of existing systems. For instance, it is clear that SILK (purely SPARQL based) or COMA++ (strong relational database background) have a different focus.

- "citizens, has several" => remove comma
- "for alignment produced" => alignments
- "It makes easy" => "It makes it easy"
- "a library of wrapper" => wrappers
- "does not make any assumption about the fact that the ontology has been loaded" => "does not assume that the ontology has been loaded"
- "HeavyLoadedOntology" is not a really nice name. Maybe "FullyLoaded" is better?
- "problem with HeavyLoadedOntology" => "with the ..."
- "Direct superclasses ..." => sentence should be rephrased (not well explained)
- "as best as possible" => "as good as possible"
- "This is thus a measure" => "This is, thus, a measure"
- "a pair of ontology" => "a pair of ontologies"
- "Over the year many" => "Over the years many" (the sentence is probably not just about 2010)
- Footnote 2 is placed directly in the references part (not sure how this can happen)


Solicited review by Jun Zhao:

The major drawback of the paper is the lack of literature review. Little related work was mentioned in the paper. The authors should at least review other related ontology alignment management tools. The authors should also discuss their alignment expression language EDOAL, about its compatibility with other similar languages (if there are any).

It would also be nice to have an analysis of what the limitations of the current API are.

The paper is easy to read as a tool report. However, it is difficult to recognize their research contributions. One reason is the lack of reviews of related work. And as a tool report, the authors should also analyze in the introduction who the target users are, ontology engineers and developers? What the requirements are covered and not covered by the tools?

Some typos:

1/ "Considering ontology alignments as first class citizens, has several benefits", the comma should be removed

2/ "from a program to another", should be "from one program to another"

3/ " We insist especially on those new ..." should be "We emphasize ..."

4/ "describing the API by itself" should be "describing the API itself"

5/ The page numbers for references 1, 6, 7, 9, and 11 should be added.

Solicited review by Soeren Auer:

This submission describes the Alignment API. It is very relevant for this special issue and describes a software component, which was iteratively developed and maintained over a long period. While the general description of the implementation was clear and easy to understand the EDOAL language description leaves open questions, the most important one being: Why don't you use OWL or OWL2 class expressions directly instead of rebuilding similar functionality in EDOAL? This should be explained in more detail.

Another important piece of information I could not find in the paper is an assessment of the scalability. On the Data Web, which could be an important application area for the API, we have to deal with partially very large knowledge bases. Up to which size of the ontology can the API be reasonably used? How does the ontology size affect the performance? Are these rather issues related to individual implementations of interfaces adhering to the API or can the API itself turnout to be a performance bottleneck? I strongly advise the authors to answer these questions in a revision of the submission.

With regard to future work, I would encourage the developers of the API to think more about how the entrance barrier to using the API can be lowered. Does it e.g. make sense to offer plugins for popular ontology development environments (e.g. Protege), is it useful, to have a preconfigured REST/Webservice running, where potential users can test the API with their ontologies. I could also imagine, that a web user interface could dramatically simplify the usage of the tool.



Summary: The work presents an API for expressing and creating alignments between ontologies. The API provides a number of extensible functionalities such as creation, evaluation, processing ontologies and expression of alignments. It is perhaps the most well known tool available for ontology alignment and processing. The number of ontology alignment tools (over 30) using this API as a base system for various functions is a testament to the usefulness and help provided by the API.
I am especially impressed with EDOAL, as it provides very precise and detailed information about the relationships between the two entities. It can be very useful in situations requiring information beyond the relationship between two entities.

Comments: The paper is very well written and describes the various components of the system very nicely. I have personally used Alignment API and based on my experience I think it is fairly sturdy and robust system. However there are few comments, which can help in making the current draft stronger:

1. For a systems paper, in my personal opinion its helpful if the authors can present an example showing the various steps of processing of the input done by the Alignment API. It helps in understanding the tasks performed by various components of the systems.
2. Are there any thoughts about providing a GUI client for using the API for the non-technical users such as domain scientist who want to use it?
3. The work lacks a detailed discussion about the functionality of being able to specify threshold and how it filters results.
4. To what extent is the functionality for Evaluating Alignments supports alignments expressed using EDOAL?