The Alignment API 4.0

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.

Minors:
- "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)

[1] http://www.w3.org/TR/owl2-syntax/#Class_Expressions

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.