This paper presents the results of the participation of MDMapper [1] in OAEI 2024. The tool MDMapper is a matching system under development, designed mainly for master data models, but it also supports simple ontology matching tasks. Master data models are typically simple hierarchical classification system, where basic concepts have rich descriptions involving types and units, for example.
CEUR
ceur-ws.org ( 1, 2, =) (reads: “ 1 and 2 are extent. The ultimate goal is to expand the capabilities to include matching of classes, properties, and instances for ontologies in general.
The tool takes a source and a target ontology denoted by s and t, respectively, as input. These
ontologies are processed in two phases called pre-processing and matching. The main structure
of MDMapper [
The outcome of the pre-processing are similarity matrices for classes and properties. These matrices are input to the matching phase that produces an alignment in the form of a set of correspondences, including relationships involving ≡, ≤ and ≥.
The main components of the pre-processing phase are:
Data extraction: We use owlready2 [
Similarity propagation: A so-called Heuristic overall similarity measure is applied to estimate the similarity between sets of entities, that is, sets containing classes or properties. This technique is used to combine the features of properties into the similarity of classes and to propagate similarities from subclasses to parent classes in a bottom-up manner. The main components of the matching phase are: Identifying anchors: High-confidence initial equivalences serve as anchors for the subsequent matching process. For an anchor ( , , =), where ∈ s and ∈ t, the following conditions must be met: 1. The similarity score between and must exceed a given threshold. 2. The classes and must mutually be most similar to each other, that is, • there is no ′ so that and ′ have a higher similarity than that of and , and • there is no ′ so that ′ and have a higher similarity than that of and . 3. There should be a margin between the similarity of and and other similarities for and .
Relation derivation: For a given pair of classes and , new relations between their respective subclasses are identified in a bottom-up manner. These subclass-level relations are then used to derive a relation between and . The possible relations are equivalence, specialization, generalization, disjoint and partial overlap.
Relation-based navigation: The derived relations are used in the search for new candidate equivalences. If, for example, we consider ( , ) and know that ( , , ≤), then the navigation step “moves to” (p ( ), ).
Matching space: During the matching phase, a matching space is maintained that keeps track the current alignment and the candidate correspondences that are consistent with the current alignment. The matching space works together with the navigation functions to enable local matching.
1https://huggingface.co/sentence-transformers/all-MiniLM-L12-v2 Local Matching: For a given candidate pair ( ′, ′) coming from the relation-based navigation, the local matching process exploits the matching space to narrow the matching scope as much as possible.
The MELT system [
For all OAEI tracks, we applied fixed parameters optimized for the Anatomy track. In the identify-anchor step: • the threshold was set at 0.865, • the margin gap to alternative candidates was set to 0.01, and • the step size was set to 0.05, where the step size controls the scale of threshold decay during the subsequent matching process. Specifically, if the parent entities of a mapping candidate are found to be equivalent, a lower threshold is applied to accept the equivalence of the candidate entities.
Conference ontologies include rich properties that were not parsed or utilized in this iteration of MDMapper.
Since MDMapper is designed specifically for MDM ontology matching, it only participated in OAEI tracks involving simple ontologies, see Table 1. The results for the Anatomy and Conference tracks were promising; however, the performance on the Multifarm track was not meaningful due to the current lack of support for multilingual inputs.
MDMapper delivered a solid performance in the 2024 OAEI anatomy track, ranking second in F-measure (0.903), just behind Matcha (0.941). It generated 1,441 correspondences, comparable to top systems like LogMapBio (1,549) and Matcha (1,485). Its precision (0.926) is decent, but not as highly competitive compared to other systems.
MDMapper’s recall (0.881) and recall+ (0.703) were strong, indicating its ability to capture a broad range of correspondences.
The MDMapper runtime of 121 seconds on the Anatomy dataset is longer than that of the fastest systems, but remains within a reasonable range. However, the process did not yield a coherent alignment as expected, with some inconsistencies still present within the correspondences. This incoherence may be due to shortcomings in the anchor identification step, which lacked verification through a consistency check.
Overall, MDMapper performed well in alignment quality, especially in recall and F-measure, making it a competitive system in the anatomy track. Future improvements could focus on ensuring coherent alignments and enhancing precision without compromising overall performance.
MDMapper achieved a competitive result in the 2024 OAEI conference track, ranking third in F-measure (0.59). Its recall (0.53) was the third highest among all systems, although its precision (0.66) was lower compared to several others. Conference ontologies include rich properties that were not parsed or utilized in this iteration of MDMapper. Future improvements should focus on incorporating these properties into the matching process, leveraging them as features and correspondences at the property level.
From the Results of Evaluation for the Conference track within OAEI 2024: “MAMapper exhibits stable recall across all metrics, from 0.55 in the sharp to 0.64 in both the discrete and continuous evaluations. However, its precision drops slightly from 0.71 in sharp to 0.66 in the discrete setting and 0.69 in the continuous setting. This suggests that while MAMapper is efective at recalling uncertain matches, it struggles to assign high confidence to them, which negatively impacts its precision.” Overall, MDMapper performed well in the conference track, with room for improvement by incorporating property-level matching.
MDMapper performed poorly on the Multifarm track, with results largely insignificant due to its current lack of support for multilingual inputs. This limitation severely impacted its efectiveness in this track.
MDMapper is specifically designed to address master data management (MDM) matching problems, where the structure is simple but rich in attributes. Therefore, its optimal use is in ontology matching tasks with similar straightforward structures. While participating in OAEI 2024, it was most suited for tracks with such characteristics, such as the Anatomy and Conference tracks.
As a new system and a first-time participant in OAEI, MDMapper currently lacks several implementations and adaptations tailored for the various OAEI tracks. Features such as support for properties and instances, which have not yet been incorporated, could significantly enhance its performance in future evaluations.
Despite these limitations, MDMapper achieved a commendable result, particularly in the Anatomy and Conference tracks, showing strong potential as it continues to evolve.
This study was funded by Innovation Fund Denmark (grant number 2050-00004B).