ALCOMO - Usage hints

If you want to use ALCOMO - for example - as component in a matching system, you should take a few things into account. This page gives some hints and explanations divided in the following sections.


Note first of all that in previos versions ontologies have been loaded as LocalOntology. In the new 2012 version it is highly recommended to use IOntology instead of that. The class IOntology extends the old class LocalOntology and makes many reasoning methods much more efficient.


The most efficient and stable setting is the following one. It might miss some conflicts, generates a local optimal diagnosis for the set of detected conflicts, and is for most pairs of ontologies the most efficient setting. By default it uses Pellet as reasoner.

ExtractionProblem ep = new ExtractionProblem(

This quality of the diagnosis is strongly affected by the quality of the incoming confidence values. It starts with the most confidential correspondences and adds step by step 'lower' corespondences, each time checking whether a conflict evolves. If the is the case the corespondences just added is removed. Thus, it is important that highly ranked correspondences are correct.

If you switch to ExtractionProblem.REASONING_COMPLETE, all conflicts are detected and the resulting alignment is always coherent. This has a strong impact on the runtimes. It still work for the ontologies of the OAEI conference track (some seconds up to some minutes, depending also on the size of the alignment that is debugged), but if you apply it on the OAEI anatomy, the runtimes are no longer acceptable. For larger ontologies complete reasoning should thus be turned off.

The following line of code (before defining the extraction problem) makes Alcomo switch to Hermit.

Settings.BLACKBOX_REASONER = Settings.BlackBoxReasoner.PELLET;

In my experiments Pellet was in most cases slightly faster than Hermit. However, there are also some counterexamples to the general trend.

Optimal solution

Whenever you apply the tool to some small (up to 500 concepts, maybe more) and expressive pair of ontologies, you might like to generate an optimal solution that is also complete in the reasoning sense (coherent alignment). Try this.

ExtractionProblem ep = new ExtractionProblem(
	ExtractionProblem.REASONING_COMPLETE // or EFFICIENT, if reasoning does not need to be complete

In average such a diagnosis is slightly (and sometimes not just slightly) better than using the above setting. However, this setting does full reasoning in the merged ontologies in a straight forward blackbox approach + it builts up a search tree that can grow pretty fast.

All possible combination

Its recommended not to change the parameter ENTITIES_CONCEPTSPROPERTIES. Beyond this, the following combinations are available

REASONING_EFFICIENT most efficient combination of parameters, result might be incoherent, tries to compute a local optimal diagnosis very efficient, result might be incoherent, approximates a global optimal diagnosis given there are no confidence differences (only recommended for specific problems) very efficient for small problems, will not terminate for larger problems, tries to compute a global optimal diagnosis by building up a search tree
REASONING_COMPLETE reasoning might be very costly, works for small to medium problems, computes a local optimal diagnosis --- not available --- reasoning might be very costly, optimization problem might be very costly, works for small problems, computes a global optimal diagnosis by building up a search tree


It is recommended to activate the extraction of a 1:1 alignment. Note that a 1:1 conflict is treated then in the same way as a logical conflict (default setting is false with respect to this parameter).

Settings.ONE_TO_ONE = true;

Large BioMed Setting

To run ALCOMO for repairing the reference alignments of the large biomed track, the following setting is recommended.

ExtractionProblem ep = new ExtractionProblem(

The parameter METHOD_GREEDY_MINIMIZE works only well for alignments that do not distinguish between different degrees of confidences. The algorithm tries to compute a diagnosis that is minimal in number of correspondences that are removed. For such alignments the result is thus an approximation of the algorithm activated by METHOD_OPTIMAL.

Note that ALCOMO with using Pellet fails for one of the Large BioMed tasks (might have been SNOMED-NCI). In this case its recommended to switch to Hermit as explained above.

Equivalence and Subsumption

ALCOMO can handle both equivalence and subsumption correspondences. However, it does not automatically interprete equivalence correspondences as pair of subsumptions. You have to give subsumption correspopndences explicitly as input to the system. You can use the following code.

Mapping mapping = ... 
// ... init mapping somehow

// ... do some extraction 

Mapping extracted = ep.getExtractedMapping();

The last line can be used to recombine those pairs of subsumption correspondences that are - taken together - an equivalence correspondence. This mapping will then consist of equivalence and subsumption correspondences.


(1) There is no guarantee that ALCOMO can cope with all pairs of input ontologies and alignments. Some ontologies are buggy or in some sense critical when it comes to reasoning. For such ontologies ALCOMO might break. We recommend to put a catch clause, that catches all those runtime problems. Alternatively, you can go for the second option that is more robust.

(2) The ALCOMO version of 2012 has become more efficient. However, some pairs of ontologies might still be critical to reason with in the sense that the systems needs much more time, than acceptable. In this case its recommended to start ALCOMO as new process and to kill this process after some time limit. A the matcher can return the originally generated and non debugged alignment in case of a failure or in after some timeout. If ALCMO finishes in a certain time-frame the debugged mapping can be returned.

Back to main page