OntoAligner: Modular Ontology Alignment Toolkit

• OntoAligner is an open-source Python toolkit for ontology alignment that unifies parsing, representation, and matching components using heuristic, retrieval, LLM, and RAG methods.
• Its modular architecture separates parsing, encoding, aligning, post-processing, evaluation, and export, ensuring scalability, robustness, and reproducibility across tasks.
• Benchmark results highlight competitive F1 scores and emphasize extensibility, enabling integrations with graph-embedding methods and customizable alignment strategies.

OntoAligner is an open-source Python toolkit for ontology alignment (OA), defined as the task of finding correspondences between entities in different ontologies so that heterogeneous knowledge systems can interoperate semantically. It is presented as a comprehensive, modular, and robust Python-native framework that unifies ontology parsing, representation, alignment, post-processing, evaluation, and export across a broad range of methods, from lightweight heuristic matching to retrieval-based methods, prompt-based LLMs, and retrieval-augmented generation (RAG) pipelines (Giglou et al., 27 Mar 2025).

1. Concept, scope, and design goals

OntoAligner is positioned as a response to practical limitations in prior ontology alignment tooling. The motivating claim is that many existing systems force trade-offs among scalability, modularity, robustness, reproducibility, and ease of integration with recent AI methods. In the description of related tools, DeepOnto is described as powerful but dependent on the Java OWL API via JPype; Matcha-DL as requiring substantial GPU resources and lacking pretrained models; OntoEMMA as hardware-accessible but limited in customization and recently unmaintained; the Alignment framework as lightweight and logic-oriented but lacking ML and hybrid methods; and IBM’s framework as enterprise-oriented but complex to set up and comparatively weaker in advanced documentation (Giglou et al., 27 Mar 2025).

The toolkit’s stated design emphasizes five properties. It is comprehensive because it covers lightweight heuristics, retrieval models, prompt-based LLM alignment, and RAG/ICL-style methods. It is modular because parsing, encoding, aligning, post-processing, evaluation, and export are separated into replaceable components. It is robust because it includes post-processing for alignment consistency, evaluation utilities, documentation, and support for reproducible experimentation. It is scalable because it is designed to handle ontologies with thousands of classes and properties while optimizing memory and computation. It is easy to integrate because it is implemented in Python, installable from PyPI, and usable either step-by-step or through a pipeline API (Giglou et al., 27 Mar 2025).

The current implementation satisfies 10 of 12 functional requirements and 8 of 9 non-functional requirements. Implemented capabilities include loading local OWL/RDF ontologies, selecting and configuring multiple predefined alignment algorithms, generating mappings between classes, post-processing outputs, exporting mappings to XML and JSON, computing evaluation metrics, comparing methods, extending the library with new algorithms, and documenting extensibility. The explicit current deficits are equally important: remote URL loading is planned rather than fully realized, property and individual alignment are not yet implemented, and graceful exception handling still needs further work (Giglou et al., 27 Mar 2025).

A plausible implication is that OntoAligner is strongest as a research and engineering framework for class alignment, with architectural provisions for extension beyond that scope but without full current support for all ontology entity types.

2. Modular architecture and ontology representations

OntoAligner is organized around a high-level modular workflow. The Parser Module contains an OntologyParser for OWL/RDF ontologies and an AlignmentsParser for loading reference alignments. The ontology parser extracts metadata needed downstream, including class and property names, IRIs, hierarchical structure, synonyms, and annotations. The paper also notes a limitation: highly expressive OWL axioms may require future processing extensions depending on the needs of the alignment algorithm (Giglou et al., 27 Mar 2025).

The Encoder Module transforms ontology content into model-specific representations. Three ontology metadata views are central:

• $C$: concept
• $CC$: concept-children
• $CP$: concept-parent

These are not formalized with equations in the paper, but they function as the core representational abstractions used throughout the toolkit. The Lightweight Encoder produces raw text inputs for inexpensive methods such as fuzzy matching and retrieval. The LLM Encoder formats text, including parent and child information, for prompt templates. The RAG Encoder constructs structured input for retrieval and generation, including support for few-shot and in-context learning settings. The paper explicitly mentions the in-context vectors (ICV) approach of Liu et al. as an aligner requiring this style of encoding (Giglou et al., 27 Mar 2025).

The architecture separates encoding from matching, which is significant because it allows the same ontology views to be reused across very different aligner families. This modularity also makes OntoAligner suitable as a framework for systematic ablation over ontology representations rather than only over model architectures.

A concise view of the main modules is as follows.

Module	Function	Key elements
Parser	Load ontologies and references	OntologyParser, AlignmentsParser
Encoder	Build method-specific representations	$C$, $CC$, $CP$; lightweight, LLM, RAG encoders
Aligner	Produce candidate mappings	lightweight, retrieval, LLM, RAG families

The post-alignment stages are also first-class. OntoAligner includes post-processing, evaluation, and exporter modules. Post-processing supports rule-based and heuristic filtering, thresholding, and mapping generated natural-language LLM outputs back to predefined alignment labels; a component named Mapper is especially used with LLM aligners. The evaluator computes standard OA metrics—precision, recall, and F-measure—and the exporter writes mappings to XML and JSON (Giglou et al., 27 Mar 2025).

3. Supported alignment families

OntoAligner is explicitly not tied to a single methodological paradigm. Its aligners are grouped into four families (Giglou et al., 27 Mar 2025).

Family	Representative methods	Intended use
Lightweight	fuzzy matching, token-set and weighted fuzzy models	fast, inexpensive baselines
Retrieval	TFIDF, SVM, sentence-transformers	semantic candidate generation and matching
LLM	prompt-based Hugging Face LLMs	direct pairwise semantic decisions
RAG	RAG, FewShot RAG, ICV RAG	retrieval-guided LLM reasoning

Lightweight aligners are threshold-based heuristic matchers intended for very fast baselines or settings with strong lexical similarity. The paper explicitly mentions simple token-set and weighted fuzzy matching models. Their role in OntoAligner is pragmatic rather than foundational: they provide inexpensive baselines and can remain useful when ontology labels are already strongly aligned lexically (Giglou et al., 27 Mar 2025).

Retrieval aligners treat alignment as retrieval or semantic similarity. The supported methods include sentence-transformer models, TFIDF, and SVM. The sentence-transformer component is designed to work with Hugging Face models, including both official and community-contributed sentence-transformers. These models are used both as standalone aligners and as retrievers inside the RAG family (Giglou et al., 27 Mar 2025).

LLM aligners use Hugging Face LLMs with predefined prompts to decide whether a source-target concept pair matches. The paper names Mistral, LLaMA, Falcon, and Qwen as representative supported families. A concrete practical limitation is stated clearly: because every candidate pair is queried directly, pure LLM aligners have quadratic time complexity in the number of source and target concepts, and thus remain practical mainly for smaller tasks with fewer than approximately 200 concepts in each ontology (Giglou et al., 27 Mar 2025).

RAG aligners combine retrieval and generation. A retriever narrows the candidate space, and an LLM makes the final alignment decision with additional context. OntoAligner includes standard RAG, FewShot RAG, and ICV RAG variants. An implementation detail singled out by the paper is that, instead of relying on full text generation, OntoAligner uses logit-based probability calculations to determine alignments, allowing operation in a single forward pass and reducing GPU usage (Giglou et al., 27 Mar 2025).

The paper is explicit that it does not provide explicit mathematical formulas for similarity computation, retrieval scoring, ranking objectives, or loss functions. The notation that appears in the paper is experimental and configuration-oriented rather than derivational: $T$ for threshold, $T_r$ for retriever threshold, $T_l$ for LLM threshold, $top_k$, batch size $CC$0, and number of few-shot examples $CC$1 (Giglou et al., 27 Mar 2025). This suggests a toolkit whose main novelty lies in software architecture and method unification rather than a new single optimization objective.

4. Empirical performance and benchmark behavior

OntoAligner is evaluated on tasks from OAEI and related benchmarks. The dataset statistics table in the paper includes: Anatomy / Mouse-Human with 2,737 source concepts, 3,298 target concepts, and 1,516 alignments; Biodiv / FISH-ZOOPLANKTON with 145 versus 56 concepts and 15 alignments; Biodiv / ALGAE-ZOOBENTHOS with 108 versus 128 concepts and 18 alignments; YAGO-Wikidata with 304 versus 304 concepts and 304 alignments; and MI-MatOnto with 545 versus 825 concepts and 302 alignments. The experimental discussion also mentions MI-EMMO, Nell-DBpedia, and HP-MP, with HP-MP highlighted as a large task with about 12.7k source and 11.9k target concepts (Giglou et al., 27 Mar 2025).

A focused experiment on MaterialInformation–MatOnto from the OAEI MSE track illustrates the framework’s method spectrum. The best OAEI 2023 system for that task, Matcha, achieved F1 33.9% with 15 seconds response time. OntoAligner reports SimpleFuzzy (C) at P 14.3, R 25.8, F1 18.4, time 0.13 s; retrieval variants with high recall but weak precision; pure LLM aligners with very small models such as Qwen2-0.5B and LLaMA-3.2-1B showing extremely low F1 and very high runtime; and much stronger results from RAG and FewShot RAG. The best reported configuration is FewShot RAG, SBERT(C) + Mistral-7B(CC) with $CC$2, $CC$3, $CC$4, $CC$5, $CC$6, achieving precision 64.7%, recall 33.4%, and F1 44.1% (Giglou et al., 27 Mar 2025).

Across eight tasks, the paper reports the following best OntoAligner outcomes: MI-MatOnto F1 44.5 with Mistral-7B-v0.3 (BERT retriever), surpassing OAEI 33.9; MI-EMMO F1 92.4 with Qwen2-0.5B (BERT), above OAEI 91.8; FISH-ZOOPLANKTON F1 89.6 with LLaMA-3.2-1B (BERT), above OAEI 64.0; Mouse-Human F1 86.4 with LLaMA-3.2-3B (BERT), below Matcha’s 94.1; ALGAE-ZOOBENTHOS F1 70.5 with Qwen2-0.5B (TFIDF), above OAEI 44.4; Nell-DBpedia F1 97.6 with Qwen2-0.5B (T5), above OLaLa’s 96.0; YAGO-Wikidata F1 96.0 with Ministral-3B-Instruct (T5), above Matcha’s 94.0; and HP-MP F1 83.5 with Qwen2-0.5 (BERT), above LogMap’s 81.8 (Giglou et al., 27 Mar 2025).

These results support two narrower claims rather than a universal superiority claim. First, OntoAligner’s modular combinations can outperform reported baselines on many tasks, especially when retrieval and LLM reasoning are combined. Second, performance remains task-dependent: Mouse-Human is a counterexample where Matcha remains better, and the paper attributes this plausibly to Matcha’s task-specific fine-tuned sequence model versus OntoAligner’s more generic RAG configuration (Giglou et al., 27 Mar 2025).

Subsequent work reinforces the interpretation of OntoAligner as a reusable framework rather than a single method. In “Homa at SemEval-2025 Task 5: Aligning Librarian Records with OntoAligner for Subject Tagging”, OntoAligner is repurposed as a modular retrieval-and-matching stack for aligning TIBKAT bibliographic records to the GND subject taxonomy. The implemented workflow uses title-based input representation, top-30 candidate retrieval with Nomic embeddings and cosine similarity, and a fine-tuned Qwen2.5-0.5B-Instruct model for match/non-match decisions (Tekanlou et al., 30 Apr 2025). The same paper also exposes limitations: on TIB-Core, the reported result is Avg Precision: 2.84, Avg Recall: 20.30, Avg F1: 4.66, indicating recall-oriented candidate surfacing but weak precision in that particular adaptation (Tekanlou et al., 30 Apr 2025).

5. Extensibility, APIs, and workflow patterns

The framework is designed for both direct experimentation and reusable pipelines. The paper describes two usage styles. In the step-by-step RAG workflow, the user loads an ontology dataset, encodes it with a RAG encoder using concept-parent or similar contextual representations, defines retriever and LLM configurations, loads the RAG model, generates matchings, applies threshold-based post-processing, evaluates against reference alignments, and exports matchings to XML. This is described as requiring about 30 lines of Python (Giglou et al., 27 Mar 2025).

The pipeline workflow wraps the same logic in a higher-level API. This is presented as a deliberate balance between modular control and integrated usability. The documentation reflects that architecture, with sections for Getting Started, How to Use?, Aligners, and Package Reference, covering pipeline workflow, base classes, encoders, post-processing, and utilities (Giglou et al., 27 Mar 2025).

OntoAligner is explicitly intended to be extensible. Users can add new alignment algorithms or modify existing ones through a documented API. Extension points exist at the level of parsers, encoders, aligners, post-processors, evaluators, and datasets. The toolkit is implemented in Python, published on PyPI, documented on Read the Docs, and released as open source under the Apache License 2.0 (Giglou et al., 27 Mar 2025).

Later work confirms that this extensibility is substantive rather than nominal. “OntoAligner Meets Knowledge Graph Embedding Aligners” adds a KGE-based ontology alignment capability to the library through a module named GraphEmbeddingAligner, built on top of PyKEEN and supporting 17 KGE models. The pipeline parses source and target ontologies into RDF-style triples, merges them into a triple factory, trains a KGE model with link prediction and negative sampling, and aligns entities via cosine similarity over normalized embeddings (Giglou et al., 30 Sep 2025). The empirical profile of this extension is distinctive: KGE aligners are generally high precision, moderate recall systems, with examples such as Mouse-Human / DistMult at 97.9 precision and 69.0 recall, and ENVO-SWEET / ConvE at 89.1 precision and 40.6 recall (Giglou et al., 30 Sep 2025).

A plausible implication is that OntoAligner’s architecture is broad enough to support not only LLM-oriented pipelines but also structurally biased graph-embedding aligners, making the toolkit closer to a methodological substrate than a fixed matching stack.

6. Position in the ontology alignment landscape

OntoAligner’s most distinctive characteristic is that its main innovation is not a single new matching algorithm but a unified software framework spanning ontology parsing, representation learning, heuristic matchers, retrieval methods, prompt-based LLM aligners, RAG-based aligners, post-processing, evaluation, and export (Giglou et al., 27 Mar 2025). In that respect it differs from systems centered on one technical core, such as BERT-based ontology matchers, seed-guided embedding methods, or zero-shot generative alignment systems.

The toolkit sits in a broader research trajectory. Earlier work on alignment maintenance, such as “RDF2Vec-based Classification of Ontology Alignment Changes”, showed that embeddings can support ontology alignment workflows not only during mapping discovery but also during alignment evolution and maintenance by classifying ontology changes as alignment-impacting or non-impacting (Jurisch et al., 2018). More recent work on embedding modules tailored to alignment, such as OWL2Vec4OA, argues that ontology embeddings should be made cross-ontology and alignment-aware through seed mappings and weighted random walks rather than learned separately for disconnected ontologies (Teymurova et al., 2024). OntoAligner’s modular encoder-and-aligner separation is compatible with this direction, though the OntoAligner paper itself does not present OWL2Vec4OA as an integrated module.

The framework also differs from end-to-end zero-shot systems such as Truveta Mapper, which formulates ontology alignment as translation from a source node to a target ontology path rather than as modular candidate generation plus scoring (Amir et al., 2023). OntoAligner instead remains explicitly modular, allowing retrieval, prompting, and post-processing components to be swapped independently. This suggests a trade-off: the framework is easier to repurpose and extend, while some end-to-end models may offer a more unified inductive bias for specific tasks.

The limitations stated in the OntoAligner paper are concrete and consequential. Remote URL loading is still planned; property and individual alignment are not implemented; graceful exception handling needs more work; advanced OWL axioms may require future parser extensions; pure LLM aligners have quadratic complexity and are therefore limited to small ontologies; and performance can remain below specialized systems on some tasks (Giglou et al., 27 Mar 2025). The Homa case study adds further practical cautions: multilingual performance depends heavily on the underlying retriever and LLM, and retrieval quality can dominate overall success (Tekanlou et al., 30 Apr 2025).

Taken together, these results suggest that OntoAligner is best understood as a research-grade and practitioner-oriented ontology alignment workbench. Its strongest contribution is a modular architecture that supports reproducible experimentation across lightweight, retrieval-based, LLM-based, RAG-based, and, in later extensions, KGE-based aligners, while leaving open a clear research agenda on richer OWL processing, broader entity coverage, calibration, repair, and hybrid symbolic-neural strategies (Giglou et al., 27 Mar 2025).