This paper introduces a matching framework tailored for master data model matching, incorporating techniques from the field of ontology matching. We present a new quantitative approach for heuristic similarity estimation between hierarchical data structures, which involves heterogeneous data. We also introduce a relation-based navigation technique and an availability management method based on restrictions that support eficient and progressive matching processes. This integration of ontology matching techniques into master data model matching not only improves alignment consistency and quality, but also facilitates more automatic data exchange solutions. The experiments on OAEI Anatomy and Conference tracks indicate that our approach may be competitive, while an experiment on industrial classification standards shows that our approach performs significantly better than the considered baseline approaches.
CEUR ceur-ws.org
The digital information supply chain refers to the comprehensive process through which digital data is generated, processed, stored, transmitted, and ultimately utilized. Unlike the physical supply chain, which deals with tangible goods, the digital information supply chain deals with intangible data flows, requiring robust infrastructure and sophisticated protocols to ensure eficiency and security. The key actors in the digital information supply chain are data producers such as manufacturers, distributors and retail chains, and data consumers such as end users, consumers, and online shoppers. In addition, regulatory bodies often oversee the flow of information to ensure compliance with legal, ethical, and security standards, or simply require businesses to adhere to regulatory compliance standards.
Actors within the digital information supply chain often operate a so-called Master Data Management (MDM) platform as a central hub for data exchange. However, they predominantly use diverse data models to categorize their products. To ensure accurate, consistent, and efective data exchange, it is essential to align data between the actors.
Master data models are, typically, hierarchical concept classifications [
A scenario: Ontology Matching in MDM: Consider three businesses, , and , that
exchange data described by diferent industrial classification standards: ETIM [
• uses a custom made classification to classify and manage the product data For this example, let us assume that manufactures coaxial cables, distributes electrical and electronic products, including cables, and is an online store that sells audio gear to musicians. Table 1 is the partial data fields (attributes) of a coaxial cable in diferent ontologies.
What can be noticed is that the data itself, for instance the color of the cable is the same (as it is one and the same physical cable), but the name of the data fields are diferent across the three representations.
In this simple information supply chain, → → , we already face two problems: • Either needs to have information about how expects to receive data and map the data from its own representation to that of , or will have to receive ’s representation of data and then map to its own ontology. • is faced with the same problem as - either map from ECLASS to that of the recipient , which implies that needs to know about ’s representation of data, or needs to map from ’s representation to its own.
In addition to this, even before being able to map the data fields, the correct category/classification must be determined for each product sent from and received by (and from , received by ). A specific data record of the coax cable product may be classified as Table 2. Notice that the custom hierarchy for focuses more on the selling aspects of a product.
In a typical information supply chain, these two problems multiply; will receive data from many data providers, and needs to send data to many data consumers, and all may operate diferent data standards.
We present a framework for ontology matching tailored to MDM systems, which typically are simple classification hierarchies with rich attributes of concepts with data types and units. In Section 2, we model typical MDM matching tasks, including key properties that narrow the matching scope and enhance eficiency and quality. We also introduce a heuristic similarity measure that incorporates descendants and attributes. The framework is detailed in Section 3. Section 4 covers experiments using OAEI tracks, Anatomy and Conference, as well as the industrial classification standards, ETIM and ECLASS.
Related Work: Eine et al. [
Euzenat et al. [
LogMap [
We use a matching space maintaining a pool of correspondences that are not in conflict with the current alignments. That pool shrinks when new correspondences are added. The manner in which this pool is maintained gives fewer false negatives compared to LogMap for the considered data sets.
Hansen et al. [
COMA/COMA++ [
Background knowledge is another important factor to improve the accuracy of similarity
estimation and has been widely used [
We now present the basic relations we shall use, the definition of an MDM ontology and the basic properties of , and some fundamental properties of consistent alignment. 2.1. Relating concepts A correspondence is defined as a triple ( 1, 2, ) , where 1 and 2 are concepts, and represents one of the following relations: • isEqual (=): Indicates that two concepts are equivalent. • lessEqual (≤): Indicates that the first concept is a specialization of the second one. • largerEqual (≥): Indicates that the first concept is a generalization of the second one. • disjoint (∅): Indicates that two concepts are disjoint (or exclusive). • partialOverlap (≠∪∩): Indicates that two concepts overlap but are not equal, and neither is a subset of the other. 2.2. MDM ontology An MDM ontology is a hierarchical classification of concepts, that is, a tree , where the nodes are concepts. Furthermore, the concepts in satisfy certain properties (making a classification).
Let 1 and 2 be concepts (nodes) of : • If 1 is a child of 2, then ( 1, 2, ≤).
• If 1 and 2 are siblings in , then ( 1, 2, ∅).
That is, a child is a specialization of its parent and siblings are mutually exclusive concepts.
The following properties are consequences of above properties: • If 1 is a descendant of 2, then ( 1, 2, ≤). (This property can also be expressed in terms of ancestor and ≥.) • If 1 and 2 are diferent concepts in and neither is a descendant of the other, then ( 1, 2, ∅).
Furthermore, we have
• If 1 and 2 are diferent concepts in , then ¬( 1, 2, =).
That is, cannot contain two diferent equivalent concepts. 2.3. Conflict-based Restriction When a set of correspondences is established between two MDM ontologies and , it is easy to reach an inconsistent situation. We shall now formulate some consistency constraints on . These constraints will later be exploited in order to prune the space that is explored when searching for new correspondences.
A correspondence between and is a relation ( , , ) , where is a concept in and is a concept in .
Let be the alignment that contains only correspondences with relations. is conflict free if the following restrictions are satisfied for every correspondence ( , , =) ∈ : 1. for every ′ in , where ′ is not : ( ′, , =) ∉ , 2. for every ′ in , where ′ is not : ( , ′, =) ∉ , 3. for every ancestor ′ of in and for every descendant ′ of in : ( ′, ′, =) ∉ , 4. for every descendant ′ of in and for every ancestor ′ of in : ( ′, ′, =) ∉ , 5. for every linear relative ′ of in and for every non-linear relative ′ of in : ( ′, ′, =) ∉ , and 6. for every non-linear relative ′ of in and for every linear relative ′ of in : ( ′, ′, =) ∉ , where linear relatives of a concept in a hierarchy are the ancestors and descendants of , while non-linear relatives of a concept in a hierarchy are all other concepts in that are neither ancestors nor descendants of . 2.4. Heuristic Similarity Between Hierarchies We propose a heuristic approach to estimate the overall similarity between two hierarchies by evaluating potential correspondences based on their similarity matrix between entities, where an entity can be either a concept or an attribute.
- Let denote the set of source entities. - Let denote the set of target entities.
- (, ′) presents the similarity score between a source entity ∈ and a target entity ′ ∈ , the value falls within the range of 0 to 1.
Using a specified threshold , we filter out entities whose highest similarity score to their counterparts exceeds this threshold, calling them prominent entities. The set of prominent entities of source and target are denoted as and : = { ∈ ∣ m′∈a x (, ′) > }, = { ′ ∈ ∣ max (, ′) > } ∈ (1) is the set of source entities that are considered compatible with at least one target entity. Similarly, is the set of target entities that are considered to be compatible with at least one source entity. Both identify key entities in their respective hierarchies as potential candidates for alignment.
The highest similarity scores associated with these prominent entities are referred to as
prominent scores and are collectively denoted by , with the type ∶ ( ∪ ) → [
For each entity in or , the prominent score [] is given by:
max {(, ′) ∣ (, ′) > } if ∈ , [] = { ′∈ (2) max {( ′, ) ∣ ( ′, ) > } if ∈ .
′∈
The sequence thus consists of these maximum similarity scores corresponding to the entities in and . Each entity in and has a corresponding value in , therefore, | | = | | + | |.
The ratio of the size of prominent entities to the total number of entities is used to represent the scale of potential mappings: = | | + | | (3)
| | + | | The mean value of the prominent scores represents the quality of these potential mappings: =̄ 1
∑ [] | | ∈( ∪ ) (4)
The final heuristic value ℎ is determined by combining the ratio and the mean prominent score :̄ ℎ = × =̄ 1 ∑ [] (5)
| | + | | ∈( ∪ )
The heuristic score ℎ, defined as the product of the of prominent entities and the mean prominent score ,̄ ranges from 0 to 1 due to their individual constraints. represents the proportion of prominent entities (0 to 1), while ̄ is the average of normalized similarity scores above a threshold (0 to 1). Thus, ℎ provides a normalized score indicating the extent and quality of potential correspondence, from no correspondence (0) to perfect correspondence (1). Table 5 demonstrates the impact of this method on enhancing the classification-level similarity matrix with attribute-level similarity.
We propose MDMapper, which is a framework specifically designed for MDM matching tasks. The architecture of MDMapper is shown in Figure 1.
In the Pre-processing phase, we initiate with Data Extraction, which parses both source and target ontologies into internal representations ( ℎ and ). The next step involves the Similarity Measure module, which employs a variety of methods to estimate the pairwise similarity of source-target concepts. 3.1. Similarity Measure We employ similarity measurement approaches to estimate the similarity scores of pairwise source-target concepts to capture diferent characteristics. The final similarity matrix is a linear combination of multiple similarity matrices.
We use the iSUB [
Additionally, we enhance our similarity matrix with our heuristic approach (see Section 2.4) via bottom-up similarity propagation, efectively augmenting the direct comparisons with inherited similarities across the data hierarchy. (1) This part comprises two hierarchies ( and ) and a correspondence ( (2) For this part, the table on the left represents the updated matching space according to the correspondence ( , , =); some cells are blocked with status -1 according to the restrictions in Section 2.3; blue cells are blocked according to Restriction 1 and 2, yellow cells are blocked according to Restriction 3 and 4, and green cells are blocked according to Restriction 5 and 6. The tables on the right display the narrowed matching spaces for further matching process 3.2. Matching Throughout the matching process, the framework maintains a Matching Space to manage discovered correspondences and prevent potential conflicting matches, thereby preserving the consistency of the alignment and enhancing the eficiency of matching.
The Matching Space is initialized as a matrix of size | | × | |, with all cells set to open (0) status. For each newly discovered correspondence, the corresponding cell in the Matching Space is marked as aligned (1). Restrictions are added by blocking cells, which are set to blocked (-1) status. These cells correspond to potential correspondences that conflict with the accepted ones, as described in Section 2.3. It is illustrated with a simple case in Figure 2 how the matching space maintains alignment and restrictions.
Initial Matching:
During an initial matching phase, high-confidence correspondences, known as anchors, are identified. They are added to the matching space and will never be removed.
An entity matching framework CollaborEM [
Our approach employs a significantly mutually most similar rule to identify anchors based on the similarity matrix. Each identified anchor (, , =) , ∈ , ∈ , must satisfy: 1. Their similarity score must exceed the given threshold. 2. They must be mutually the most similar to each other.
3. There should be a margin between their similarity and the second most similar pair. Matching phase: The matching phase performs a local matching for each candidate in the candidate pool, which is initially populated with anchors. Candidates at lower levels are prioritized for extraction from the pool. For each candidate (, , ) , the first step is to decide the pair of concepts ( ′, ′) to explore in the following local matching.
The navigation function determines ( ′, ′) based on the hierarchical positions of (, ) and their relation , as follows:
⎧(parent(), parent()) ( ′, ′) = (parent(), ) ⎨ ⎩(, parent()) if ∈ {" = ", " ≠∩∪ ", "∅"} and parent(), parent() exist, if = " ≤ " and parent() exists, if = " ≥ " and parent() exists.
The basic ideology of the function design: On the one hand, valid correspondences increase the likelihood of relations existing between their hierarchical neighbors; ‘=’, ‘≤’, and ‘≥’ suggest possible matches among parents or siblings. On the other hand, ‘≠∪∩’ and ‘∅’ indicate the need to expand the matching scope.
Since only correspondences with an ‘=’ relation can be identified via similarity score, for a given (, ) with unknown relation, we determine its relation by evaluating the overlap of the descendants of them, using the following criteria: (6) (7) =
=∶ ⎧ ⎪ ≤∶
≥∶ ⎨⎪ ∅ ∶
∪ ⎩ ≠∩∶ (∀ ∈ (), ∃ ∈ () ∶ = (∀ ∈ (), ∃ ∈ () ∶ = (∀ ∈ (), ∃ ∈ () ∶ = (∀ ∈ (), ∀ ∈ () ∶ ≠ Otherwise ) ∧ (∀ ∈ (), ∃ ∈ () ∶ = ) ∧ (∃ ∈ (), ∀ ∈ () ∶ ≠ ) ∧ (∃ ∈ (), ∀ ∈ () ∶ ≠ ) ) ) ) denotes all descendant concepts of the given concept.
Local matching: This phase identifies new correspondences within a narrower matching scope tailored to the suggested pair of concepts ( ′, ′). For the given pair of concepts ( ′, ′), we identify the correspondences between their descendants and the concepts themselves. A local similarity matrix is constructed, related to the sub-hierarchies of ′ and ′, which is then ifltered through the matching space to delineate the matching scope.
Furthermore, depending on the relations between their linear relatives, we apply varying thresholds to improve the matching quality. For example, for a pair of concepts ( ″, ″) in the local matching scope, if ( ( ″), ( ″), =) exists, a lower threshold should be applied for matching ″ and ″, since the equivalence in their parents indicates a higher likelihood of an ‘=’ relation between them.
Local matching may find new correspondences that are added to the candidate pool. Furthermore, the matching space is updated accordingly. This iterative process continues until no further correspondences can be identified.
Although MDMapper is designed primarily to address MDM matching tasks, it is also capable of handling simple ontology matching tasks. To compare it with other ontology matching systems, we apply our framework to the OAEI Anatomy and Conference tracks. Furthermore, to evaluate our performance in solving real-world MDM matching problem, we applied our framework to match ETIM and ECLASS in various versions: with and without attributes. Both versions showed outperforming results compared to the baseline approaches. All experiments were conducted on a MacBook with an Apple M2 Max chip and 64GB of RAM. 4.1. OAEI Tracks We applied our approach to the OAEI Anatomy and Conference tracks. Table 3 shows that our approach achieves an F1 measure of 0.905, which ranks 4th based on the anatomy track (2023). Table 4 shows that our F1 measure is 0.65 on the conference track (2023), which ranks 3rd. Our approach is eficient, with runtimes of 58 seconds on the Anatomy track and 97 seconds on the Conference track. In addition, our approach ensures coherent alignment. 4.2. Industry Classification Standards Matching Data Description: ETIM-7 has 4,878 classifications across 3 layers, while ECLASS-11 includes 86,468 classifications in 6 layers. ETIM Germany is working on aligning ETIM to ECLASS, but the current reference alignment is incomplete. It includes 2,762 ETIM categories mapped to
The attribute features we use include name, datatype, and unit. 2,435 ECLASS categories, totaling 2,875 mappings. All correspondences are between the ETIM leaf nodes and the parent nodes of the ECLASS leaf nodes.
We extracted subtrees from both ETIM and ECLASS on the basis of these mappings, preserving root-to-leaf paths. The resulting Sub-ETIM subtree consists of 2,873 categories in 3 layers, with 10,745 attributes aligned with leaf nodes. The Sub-ECLASS subtree contains 5,561 categories in 6 layers, with 8,928 attributes aligned with leaf nodes.
Given the incomplete alignment, we evaluated the matching results using the filtered correspondences within specific layers of the classification hierarchies. While valid correspondences may exist beyond this scope, they cannot be assessed without complete reference mappings. Analysis: To benchmark our approach, we used StringEquiv and Optimal Threshold (the best achievable results based on the threshold applied to the similarity matrix) for matching tasks between Sub-ETIM and Sub-ECLASS. These techniques are among the most commonly used in current MDM matching solutions. Since the ETIM and ECLASS datasets are not available in OWL or RDF format, we were unable to directly apply other Ontology Matching Systems.
We conducted two experimental variants with our approach (see Table 5): one excludes attributes, while the other incorporates them into the similarity matrix using the heuristic method described in Section 2.4. Our approach, both with and without attributes, significantly outperforms the baseline methods. The improvement achieved by incorporating attributes demonstrates the efectiveness of using attribute features in category similarity measurements. Excluding pre-processing, the matching process takes 5.73 seconds.
We have introduced a framework for ontology matching geared towards the Master Data Management domain. In addition to known ontology matching techniques, we developed a relation-based navigation approach that narrows the matching scope using existing correspondences. Furthermore, a heuristic approach is proposed to estimate the overall similarity between subtrees, integrating heterogeneous entities into a unified measure.
Experiments on data from OAEI tracks indicate that our approach may be competitive, while the experiment on industrial classification standards shows outperforming results in solving real-world MDM matching problems compared to selected baseline techniques.
The framework is in a prototype stage and under development for further enhancements. Future work includes integrating domain-specific external knowledge resources to refine matching quality, incorporating global optimization and callback mechanisms to resolve conflicts, and developing a user interface to select diferent conflict-based alignment versions. Acknowledgement This study was funded by Innovation Fund Denmark (grant number 2050-00004B).