Principled Question: Usage only of iri and label in encoding

[peio]

Dear OntoAligner Team,
I'm puzzled and curious about your thoughts and consideration in using only the IRI and label from the literals in the encoding and the subsequent alignment.

The structure from the GenericOntology class, which collects also comments and synonyms, made me expect that these additional literals would be also used in the subsequent encoding and matching. However, the preprocess method of the BaseEncoder class expects strings which make me believe that there is design consideration behind this?

The synonyms and the comment structure seems unutilized by the subsequent encoders and the point of extracting this very useful information is lost to me.

You have given much more thought on the overall process, so I would like to ask early why should we not concatenate maximum amount of litterers to the text?

Something like:

` def get_owl_items(self, owl: Dict) -> Any:
"""
Extracts the IRI and label of a concept from the given OWL item.

    Parameters:
        owl (Dict): A dictionary representing an OWL item, expected to contain 'iri', 'label', 'synonyms' and 'comments' keys.

    Returns:
        Dict: A dictionary containing the IRI and label, synonyms and comments of the concept.
    """
    synonyms = " ".join(owl['synonyms'])
    comments = " ".join(owl['comment'])
    return {"iri": owl["iri"], "text": owl["label"]+" has synonyms "+synonyms +" IS DEFINED AS "+comments}`

[HamedBabaei]

Dear @peio , thank you for pointing this out. You are absolutely right that the additional literals would also be used during matching. However, the models currently supported in OntoAligner operate on natural language text (for now). This perspective is based on our prior work, which you can read more about here: https://link.springer.com/chapter/10.1007/978-3-031-78952-6_3.

The parser and encoder are intended to be separate modules that can be adapted to specific requirements. We intentionally split these components because of the nature of alignment models: many approaches in the field rely on different parsing strategies and perform ontology structuring before feeding the data into the model. As a result, if multiple models operate at the text level (and you can enrich that text as needed—similar to the code you shared), they should all function seamlessly within the library. This separation is therefore deliberate, allowing different modeling approaches to co-exist while giving users the flexibility to design their own parsers (e.g., custom output formatting).

Given OntoAligner’s flexibility in accommodating user needs, you can inherit from the GenericOntology class and adjust the outputs as required by your model setup. I’m attaching an EnrichedGenericOntology (download by clicking here) class script (using the same function as you propose, but I made a few minor adjustments to make the variant options), which can be used in subsequent steps. You will also need to define your task as follows:

class EnrichedGenericOMDataset(OMDataset):
    """
    A dataset class for working with the Source-Target ontology.
    """
    track = "anything"
    ontology_name = "Source-Target"
    source_ontology = EnrichedGenericOntology()
    target_ontology = EnrichedGenericOntology()

Coming back to your main point—why we do not concentrate the maximum number of literals in the text—this is indeed possible, and there is no inherent reason not to do so, of course, IF given an ontology contains a sufficient number of high-quality synonyms.

In our initial experiments for the LLMs4OM paper,, we observed that adding more information often introduced bias and, in some cases, even degraded performance. Why did this happen? To explain, let me briefly outline the approach we followed in LLMs4OM. We adopted a RAG-based architecture, consisting of a retriever and an LLM module. In practice, increasing the amount of textual information exposed a key bottleneck: for some classes, the retriever would return a large amount of contextual information (which can be semantically overwhelming), while for others—especially in the target ontology—only a limited amount of context was available. This imbalance leads to inconsistencies in the semantic space. When one class is represented by a much longer context and another by a much shorter one, the resulting embeddings may distort relative distances, ultimately harming alignment quality. Of course, the observation was only on a few datasets, but a deeper analysis is required. This was the reason why we didn't add this in the first place, but as I mentioned, indeed, you can add more information to the play. The setup is not just considered LLMs4OM work but also provides flexibility for extension.

I hope I didn't miss anything. Thank you for the good observation. And I will add a tutorial on the parser with your thoughts; this can increase the quality of the documentation. I really appreciate the thought.

[peio]

Dear @HamedBabaei
Thank you very much about the detailed and considerate response explaining the rationale behind your decisions! This was new considerations, countering my intuition and I needed to put the effort to evaluate your observations in the cases which I work on.

I have taken the time to try various combinations and options and most importantly to try to measure the differences between these approaches. Couple of general notes which I find worth sharing from the process:

1. Use of rerankers. In my current understanding, this address is your main argument best. On a pipeline, using the the full-documents and most simple matching utilities (sbert/bm_25) to reduce the number of comparison pairs and then called the cohere re-ranker (4.0-fast), showed high level of precision on scores above 0.84
2. Sample data - use of owl:namedIndividual or data instances of the classes in addition to the full length description of concepts/classes. This real life type specifics have helped me illustrate the abstract concepts much better and seem to improve the overall quality of the matchings, also when using LLMs.
3. Richer Linkage - Working with semantics keeps the question of capturing broader than the equivalent (owl:equivalentClass) or exact (skos:exactMatch) matches. I find the presence of maximum additional context and data samples contributing to the better capturing of these relationships

Take this as mostly experiment observation from somebody who finds your work very valuable and helpful in tackling a key problem!

Thank you again for your your efforts!

[HamedBabaei]

Dear @peio,

Thank you for raising this thoughtful question and for your detailed exploration. Your observations are indeed valuable and well-articulated. I would be very interested to see how your proposed enhancement performs in wider domains. If you are willing to contribute a pull request to OntoAligner, we would be happy to review your approach and potentially integrate it into the codebase.

Please let me know if you would like to proceed with submitting a PR, and feel free to reach out if you have any questions about the contribution process.

Best regards,
Hamed

[peio]

Dear @HamedBabaei
It will be a honor and pleasure if any of my local adjustments are good to be a contribution to the library. My current barrier is my lack of skills with git/github collaboration practices, but I will put the efforts and will learn. You might see an attempt from me in the coming just to see how it works - so please be patient and understanding.

My wish list which I am slowly and partially implementing:

• GraphDB Integration - as natural storage of ontologies and instance data, which can be retrieved by a query. Also proper storage of the alignments as it might also trigger inference
• Inference - experiment if it would provide extra coverage
• Richer documents - FIBO Ontology and likely instance data
• Preselection/Blocking - either as a pipeline SBERT top N -> LLM or as a index, ala HNSW, which reduces the number of comparisons
• LLM Structured Output - OpenAI have json outputs, accoding to pydantic models, which I find a natural containers for the LLM responses
• Richer linkage - beyond yes/no match - using owl and skos alignment predicates. Somehow it combines well with the structured output from the "thinking" models.
• Fusion: Rank (RRF, Condorset, etc) and Score based
• Reranking (Cohere) - as mentioned I see a lot of promise there
• Evaluation and Annotation Tool - I need to measure better

[HamedBabaei]

Dear @peio, thanks for your comment and sorry for getting back to you late.

We really appreciate your kind gesture in contributing to the OntoAligner. If you need help with integration, don't hessitate contact me. I have seen your PR #78. I will just wait so you could finalze your work anytime that suits you, and please let me know once you want the integration, and I will jump into the review and fixes if it is required. You don't need to worry much about the technicalities with integration. Once your idea is there, I can revisit your modules to fix possible issues (if there are any).

Thanks again for your contribution!