AgreementMakerLight

This paper describes the Ontology Alignment Tool AgreementMakerLight, a well-known and well-performing ontology matching tool.
The paper is well-written and the explanations clear.

Section 2 defines ontology and instance matching, the matching and filtering strategies, and the storage of ontology alignments.
Section 3 describes the AML tool, starting by a global schema of its architecture, then detailing each module.
Section 4 summarizes AML participation in the OAEI campaigns from 2013-2021.
Section 5 describes a literature review on the impact of AML. It is interesting to see how what kind of relation the papers have to AML (mere mention, comparison, etc.).

---

Comments

The matching problem is profiled and AML choses based on this profiling which matching strategy it will perform. The way the profiling is done can be configured in a config.ini file in the store folder.
This config.ini file can also configure match settings.
At the time of the review, I could not find an example of this configuration file in the GitHub repository nor a documentation on how to create it, what possible options can be configured, etc.
This would be a useful addition to your repository.

AML can use of a background ontology in some matching strategies. Is there a default background ontology for AML ? Is it something the user has to input and configure to use these matching strategies ? Perhaps clarify this information in the paper.

Given the description in the literature review, the title of Fig. 3 is not well-suited.
If 122 papers focus on a specific application domain (number from which Figure 3 was created), "only" 34 (still a nice figure in my opinion) have applied it to a real-world matching problem.

---

Typos:
- P5 L34: are only considering as part --> are only considered ?
- P6 L51: classification of which mapping --> classification of each mapping ?
- P8 L43: 141 publications are **domain** agnostic

The submission proposes a report on the AgreementMakerLight system. The paper is well written and is clearly presented. The system architecture is discussed in sufficient details and is supported by relevant references to its participation in the OAEI campaigns. It is also available as open source, which is commendable.

Several shortcomings exist.

1.
The use of terminology needs to be made more coherent. For example, on p. 1 the authors state “Ontology matching (or alignment) is the process of finding mappings between entities of ontologies that overlap in domain [3]”. It is not how it is defined in [3]. Alignment is defined as a result of the matching process. In turn, mapping is the oriented version of an alignment. Thus, as things stand the current use of terms is misleading.

2.
Section 2, which is called ‘Problem definition’, actually surveys the state of the art, so content-wise it is not about the problem statement, but rather about structuring the solution space.

3.
To support the exposition of the material in Section 3 it would be helpful to have examples. The suggestion is to introduce a motivating example in Section 2, thus also explaining more intuitively the problem definition, and later (in Section 3) use it as a running example to explain the key algorithms.

4.
Section 4, the authors state that AML “was the ontology matching system that participated in the most total OAEI tracks since 2013 (83)” it is not clear how close or far the other OAEI participants are positioned in terms of OAEI track participation.

5.
Section 5, having additional details on “the AML’s greatest impact in research and beyond”, especially on what is meant by “beyond” would strengthen the practical significance of work. For example, is there an active community around, are the usages in pre-production environments, if so, in what domains and what are the promises?

This paper presents the AgreementMakerLight (AML) ontology matching system. AML is in continuous development since 2013 and has participated in all OAEI evaluation campaigns since there. It appears as one of the best ontology matching systems, with the specificity of being able to deal with a large number of OAEI tracks. It has also been applied in several real-world applications. The system has been cited in a high number of related work. The paper presents a synthesis on all before mentioned topics. The system is fully available under Apache License 2.0 on Git.

While the paper is well-organised and written, there are some points that deserve to be revised, as detailed in the following.

First, the terminology employed in the paper has to be homogenized. "Ontology matching (or alignment)". It seems that "ontology matching" is the "process" and "alignment" (set of correspondences), the result of this process. "Mapping" is rather a function than the result of the matching process. There are in fact incoherent passages: "Ontology matching (or alignment)", "outputs a set of mappings between their entities, called an alignment".

Second, some choices could be better justified and/or clarified. Why, for instance, labels are considered more precise than exact synonyms? More importantly, the use of background knowledge, what is a key element in AML (allowing for good performance in domain-specific ontologies) is superficially introduced. How background knowledge resources are selected? How they are used within the matching process (it is assumed that the ontologies to be matched are already linked to those resources? etc.).

Third, a discussion on how AML fits domain-specific tasks (in the sense of the comment above) should be included. Some words (a better overview) on the AML extensions (such as AMLC) could also be included (besides the words in the conclusion).

Minor comments:
- Booma Sowkarthiga Balasubramani => Booma S. Balasubramani
- "granularity and/or organization" => granularity and/or structure
- "complex matching [6,7]" => Please refer to a recent survey on complex matching

@article{DBLP:journals/semweb/ThieblinHHT20,
author = {{\'{E}}lodie Thi{\'{e}}blin and
Ollivier Haemmerl{\'{e}} and
Nathalie Hernandez and
C{\'{a}}ssia Trojahn},
title = {Survey on complex ontology matching},
journal = {Semantic Web},
volume = {11},
number = {4},
pages = {689--727},
year = {2020},
url = {https://doi.org/10.3233/SW-190366},
doi = {10.3233/SW-190366},
timestamp = {Fri, 28 Aug 2020 15:32:46 +0200},
biburl = {https://dblp.org/rec/journals/semweb/ThieblinHHT20.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}

- "Conservativity filters exclude mappings that cause new logical inferences within either of the matched ontologies when they are considered together with the alignment, such as two classes being inferred as equivalent if they are mapped to the same class of the other ontology [10]". This statement is not clear, please rephrase.

- Add the date of access to the web pages (footnotes 1 and 2, for instance).

- \emph{URIMap}

- "a label ending on name or title"?

- "storing all mappings between classes" => or between "entities"?

- LogMap[20]

- "its impact and real-world applications"