# Are These Descriptions Referring to the Same Entity or Just to Similar Ones?

Péter Kardos, Richárd Farkas

<figure><img src="image_1.png" /></figure>

## To cite this version:

Péter Kardos, Richárd Farkas. Are These Descriptions Referring to the Same Entity or Just to Similar Ones?. 19th IFIP International Conference on Artificial Intelligence Applications and Innovations (AIAI), Jun 2023, León, Spain. pp.387-398, 10.1007/978-3-031-34107-6_31. hal-05498099

HAL Id: hal-05498099

https://inria.hal.science/hal-05498099v1

Submitted on 6 Feb 2026

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_3.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Are These Descriptions Referring to the Same Entity or Just to Similar Ones?

Péter Kardos¹(✉) and Richárd Farkas¹,²

¹ Institute of Informatics, University of Szeged, Szeged, Hungary
{kardos,rfarkas}@inf.u-szeged.hu

² ELKH-SzTE Research Group on Artificial Intelligence, Szeged, Hungary

**Abstract.** The Knowledge Graph matching task is to identify nodes in the two graphs that refer to the same concept. In this paper, we focus on the analysis of textual descriptions of the concepts. We employ neural language models as they can score well on text content similarity. On the other hand, we show that the text similarity of entity descriptions does not equal to referring to the exact same entity. Our text-based multi-step system was among the top participants at the Knowledge Graph matching track of the Ontology Alignment Evaluation Initiative.

**Keywords:** NLP · Language Models · Graph matching

## 1 Introduction

A Knowledge Graph (KG) is a unique data structure for representing entities in a structured and connected fashion. The number of publicly available knowledge graphs is increasing year by year both in the domain-specific and general contexts. These data structures may be used to provide background knowledge in order to solve a problem or used as a source to support the interpretation of an AI algorithm [1]. The most commonly used general KGs are YAGO [15], DBPedia [14] or WikiData [18] to name a few.

As more and more companies see the benefits of representing their data in a structured way they create KGs independently from any other publicly available KG. It is possible for there to be multiple KGs that share some of the same information. The focus of this research is to align these different KGs in a way where each entity shall be represented only once so that there are no duplicates. In these cases, the pairable nodes are just a fraction of all of the nodes as it is very unlikely that the information of the two graphs is completely overlapping. The names or labels of real-world entities in KGs are usually a good indicator of node matching, but there are several exceptions (e.g. *Darth Vader* - *Anakin Skywalker*) because the various KGs were created by different editors following different principles.

As most knowledge graphs have textual information about each concept these can give clues or support claims about matching nodes. In this paper, we focus on the analysis of textual descriptions of the concepts.

© IFIP International Federation for Information Processing 2023

Published by Springer Nature Switzerland AG 2023

I. Maglogiannis et al. (Eds.): AIAI 2023, IFIP AICT 676, pp. 387–398, 2023.

https://doi.org/10.1007/978-3-031-34107-6_31
In recent years the usage of pre-trained neural language models has dominated the field of Natural Language Processing (NLP). When approaching a new task it is now a standard to take a pre-trained neural language model, like BERT [2] or any variant of it [9, 10], and fine-tune it for the particular new task using a classification layer or prompt a generative model for the task [13]. Our proposal to solve the graph matching is a multi-step system starting with simple exact string matching steps, followed by a BERT-based step that filters upon the textual description similarity of nodes and ending with a bit more complex BERT-based classifier step that exploits an automatic training example generation method in order to discriminate similar descriptions from descriptions referring to the exact same entity.

We introduce empirical results achieved by various modules of our system on the Knowledge Graph matching track of the Ontology Alignment Evaluation Initiative in 2022. As a summary our contributions are the following:

- A novel multi-step system to find node pairs in the Graph Matching task

- An automatic training example generation process

- State of the Art results on the Ontology Alignment Evaluation Initiative 2022

- Graph matching track.

# 2 Dataset

## 2.1 Ontology Alignment Evaluation Initiative

The Ontology Alignment Evaluation Initiative (OAEI) [7] is a campaign organized annually in the field of ontology matching where given multiple ontologies the task is to find the nodes that represent the same concept between these ontologies. The campaign consists of multiple tracks where the most complex one is the Knowledge Graph track. Here we are given pairs of KGs from different fandom wiki sites (Start Trek, Star Wars, Marvel) and a gold set of correct matching pairs referring to the same concept. The OAEI organizers created a collection of 5 KG pairs and gold standard pairings in 2022. The task is to find all the matching pairs in the two given KGs without any supervision. The prediction is evaluated only on the gold set.

The graph is separated into instances, properties and classes. The instances are actual entities that exist in the universe for example *Anakin Skywalker*. The classes represent some grouping terms in which an instance can belong to, for example weapon or character. The properties represent some information about an instance for example name or gender. More information about the dataset sizes can be found in Table 1 and Table 2. The gold sets are somewhat special because all of the pairs are 1:1 (No 1:N pairs) and consequently as these graphs differ in size, not every node is pairable. Later on, we are going to focus on the description of the nodes, so we report what percentage of the nodes have this information in the last column.
<table><caption>**Table 1.** OAEI - Knowledge Graph track dataset sizes. The Desc. column shows what % of nodes have a description.</caption><thead><tr><th>Source URL</th><th>Instances</th><th>Properties</th><th>Classes</th><th>Desc.</th></tr></thead><tbody><tr><td>http://starwars.wikia.com</td><td>145 033</td><td>700</td><td>269</td><td>82%</td></tr><tr><td>http://swtor.wikia.com</td><td>4 180</td><td>368</td><td>101</td><td>88%</td></tr><tr><td>http://swg.wikia.com</td><td>9 634</td><td>148</td><td>67</td><td>70%</td></tr><tr><td>http://marvel.wikia.com</td><td>210 996</td><td>139</td><td>186</td><td>1%</td></tr><tr><td>http://marvelcinematicuniverse.wikia.com</td><td>17 187</td><td>147</td><td>55</td><td>90%</td></tr><tr><td>http://memory-alpha.wikia.com</td><td>45 828</td><td>325</td><td>181</td><td>89%</td></tr><tr><td>http://stexpanded.wikia.com</td><td>13 426</td><td>202</td><td>283</td><td>83%</td></tr><tr><td>http://memory-beta.wikia.com</td><td>51 323</td><td>423</td><td>240</td><td>83%</td></tr></tbody></table>

<table><caption>**Table 2.** OAEI - Knowledge Graph track gold pair sizes.</caption><thead><tr><th>starwars-swg</th><th>starwars-swtor</th><th>malpha-mbeta</th><th>malpha-stexp</th><th>mcu-marvel</th></tr></thead><tbody><tr><td>1 121</td><td>1 429</td><td>9 364</td><td>1 779</td><td>1 666</td></tr></tbody></table>

## 2.2 Evaluation

As the input KG sizes are quite large it would require a lot of manual effort to find all of the pairs with the same meaning. The given gold sets were constructed by manual annotation, but it is not guaranteed that all of the pairs have been found. However, it is guaranteed if one node is in this gold set then all of its pairs have been found. The official OAEI evaluation metrics are Precision, Recall and F1 Score with an extra step. Considering a competing system that predicts pairs we have 3 possibilities:

1. The pair is in the gold set, hence it is correct.

2. One of the elements of the pair can be found in the gold set but connected to a wrong element, then the pair is incorrect.

3. If none of the elements from the pair can be found in the gold set, we discard the pair as we cannot decide if the annotators didn't find it or if it is incorrect.

For the OAEI KG matching track, a whole framework is available for evaluating predictions called MELT [6]. We've evaluated all of our results using this official evaluation software.

## 3 Methods and Results

Based on the input data we have two types of information we can use, the graph structure and the textual information. In this paper, we focus on using only the latter to solve the graph matching problem.
In our previous work [8], we experimented with using the graph's structural information through RDF2VEC vectors [12], however the mapping of graph nodes to a common vector space for the entity matching problem achieved poor performance.

Our solution is a multi-step system. We started out with the most basic exact string similarity measures and worked our way to more complicated semantics-based steps involving language models. In the following sections, we describe this approach in detail.

## 3.1 Exact Matching

A first assumption would be if two nodes have the same name we can consider them to refer to the same entity as it is rare to have multiple entities in a universe, especially in a special domain, with the same name. Our baseline solution finds these so-called trivial pairs. To find matching pairs the step receives one or more textual properties and scans for nodes with the same textual value over them. If our assumption is correct then the resulting pair set should have very high precision. In the case of multiple given properties, the OR operator is applied so any match between the properties counts as a good pair.

<table><caption>**Table 3.** Exact matching results over the Label and Label+AltLabel properties. A Label can be interpreted as the name of the entity. The AltLabel is an additional name such as a nickname or a shortened form.</caption><thead><tr><th rowspan="2"></th><th colspan="3">mcu marvel</th><th colspan="3">memoryalpha memorybeta</th><th colspan="3">memoryalpha stexpanded</th><th colspan="3">starwars swg</th><th colspan="3">starwars swtor</th></tr><tr><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th></tr></thead><tbody><tr><th>Label</th><td>89.7</td><td>56.6</td><td>69.4</td><td>94.7</td><td>77.4</td><td>85.2</td><td>98.3</td><td>84.3</td><td>90.7</td><td>93.9</td><td>63.2</td><td>75.5</td><td>94.6</td><td>86.2</td><td>90.2</td></tr><tr><th>Label + AltLabel</th><td>88.7</td><td>66.6</td><td>76.1</td><td>94.1</td><td>88.6</td><td>91.3</td><td>96.7</td><td>91.8</td><td>94.2</td><td>92.8</td><td>72.1</td><td>81.1</td><td>93.9</td><td>89.8</td><td>91.8</td></tr></tbody></table>

We also tried replacing the exact similarity with fuzzy similarity matching while also adding a threshold value to filter the pairs. Even though the recall would increase the new pairs were too noisy resulting in a decrease of the overall F-score.

## 3.2 The SentenceBERT Step

Table 3 shows that exact label matching achieves high precision, but lower recall. This can be attributed to the gold pairs having Labels/AltLabels of different text values. We aimed to increase the recall by comparing the textual description of KG nodes. Our assumption here is that textual descriptions of entities have to reveal their equality even in cases when the labels of two entities do not have any string similarity. The best case scenario would be to increase the recall to 100% while also not degrading the precision too far so that we get an F score increase.

We utilize BERT-type neural language models for measuring content similarity between a pair of texts. BERT [2] is a transformer-based language model pre-trained on a large amount of text. It can be used to solve several tasks along with fine-tuning.
At first glance, we could approach the issue by comparing the descriptions of all pairs of texts and fine-tuning a BERT to classify whether these descriptions talk about the same entity or not. However, the sheer number of comparisons required for this approach may exceed our computing capability due to the computationally intensive nature of BERT. We follow a computationally lighter approach. First, we generate pairs that do not necessarily refer to the same entity but do have similar textual descriptions. This is computationally efficient and we can find top K similar texts easily and restrict computationally heavy special classification only to these top K candidates.

We employ SentenceBERT [11], which is an extension of BERT where given a document the model can convert it into a vector representing the meaning of the whole sentence. BERT assigns a vector for words aiming for a useful representation for a classification task, while SentenceBERT aims to provide a good sentence representation for similarity analysis. Between two SentenceBERT vectors, cosine similarity can be calculated to get a metric of how similar the documents really are.

We embedded all nodes of all KGs textual descriptions by a pre-trained English SentenceBERT model into a vector space. As all of the nodes have been granted a vector, we can select the most similar pair for each node using the cosine similarity measure. Then we also apply a threshold value and only predict pairs with SentenceBERT similarity over the threshold. We look for SentenceBERT pair only for nodes that the exact matching step has already not found any match, making it an extension set over the exact matching pairs.

To evaluate this step's results we used the Abstract property.

<table><caption>**Table 4.** SentenceBert (SB) results over the Abstract property. SB-2 means the abstracts are trimmed after the first 2 sentences</caption><thead><tr><th rowspan="2"></th><th colspan="3">mcu marvel</th><th colspan="3">memoryalpha memorybeta</th><th colspan="3">memoryalpha stexpanded</th><th colspan="3">starwars swg</th><th colspan="3">starwars swtor</th></tr><tr><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th></tr></thead><tbody><tr><td>Label +AltLabel</td><td>88.7</td><td>66.6</td><td>76.1</td><td>94.1</td><td>88.6</td><td>91.3</td><td>96.7</td><td>91.8</td><td>94.2</td><td>92.8</td><td>72.1</td><td>81.1</td><td>93.9</td><td>89.8</td><td>91.8</td></tr><tr><td>SB</td><td>88.0</td><td>66.7</td><td>75.9</td><td>91.1</td><td>90.4</td><td>90.8</td><td>94.1</td><td>93.8</td><td>94.0</td><td>88.3</td><td>78.9</td><td>83.3</td><td>91.9</td><td>90.9</td><td>91.4</td></tr><tr><td>SB-2</td><td>88.0</td><td>66.7</td><td>75.9</td><td>91.2</td><td>90.7</td><td>91.0</td><td>94.1</td><td>94.3</td><td>94.2</td><td>87.8</td><td>78.1</td><td>82.6</td><td>92.1</td><td>91.0</td><td>91.6</td></tr></tbody></table>

To better understand the behavior of SentenceBERT similarity, we calculated the top 10 similar pairs of the gold standard set. Fig. 1 depicts the frequency of position of gold pairs in the SentenceBERT ranking over the memoryalpha-stexpanded dataset. We noticed that the abstract texts contain more important information at the beginning - the quasi-definition of the concept - and not so much towards the end. Therefore we introduced a trimming of the abstract texts to the first 2 sentences. We can say that over 90% of the gold pairs are located at the first place and we can increase this percentage with trimming.

Based on the results in Table 4, taking only the first two sentences can give a slight boost confirming our observation that the main information is at the beginning.
<figure><img src="image_4.png" /><figcaption>**Fig. 1.** Based on the SentenceBert vector similarities at which rank gold pairs are located. The two different bars mean if the abstracts have been trimmed or not.</figcaption></figure>

## 3.3 The Same vs Similar (SvS) Step

Figure 1 shows that sometimes the correct pair is not the most similar text by SentenceBERT scores. Recall has been increased with the SentenceBERT step, however, it brings noise with itself degrading the F-score metric below the exact match baselines. These issues raise the need for an additional correction step.

We created a self-supervised approach for this correction step. As all of the provided pairs by the SentenceBERT step should be at least similar to each other, we can build a classifier over SentenceBERT top K candidates making a decision whether the pair represents the exact same concept or not. As the candidate set has been reduced to a reasonable size thanks to the previous step, it is now computationally feasible even employing a BERT model fine-tuned to our specific task.

We generate a training dataset automatically for a binary classifier with **positive=same** and **negative=similar** target classes. We consider the Label+AltLabel exactly match pairs as **same** since they already have high precision. We automatically generate negative (i.e. **similar**) training samples for each of the exact matching pairs. We pick one of the elements from a **positive** pair so that we can use the SentenceBERT step to get a similarity ranking to that node. A negative sample is going to be the pair with the highest similarity that is not the **positive** exact match pair itself. In the OAEI datasets, we can safely do this as only 1:1 gold pairs exist in the evaluation set, so by excluding the exact matching pair we cannot have false negatives. Additionally more
than 1 negative sample can be generated if the second-highest probability pair is included as well.

In Table 5. We demonstrate how we construct the positive and negative pairs over the Senator node of the memoryalpha graph and its SentenceBert Top 3 pairs from the stexpanded graph. Here the correct match would be the Senator-Senator found by the exact match step as their labels are the same so by looking at the SentenceBert similarity scores the third pair is the positive. From this ranking, we would exclude this positive pair and any other pair can be picked to be a negative pair, but we always choose the one with the highest score. If needed, more negative examples can be picked out from the list in descending order. Based on this the classifier that we train should be able to identify these clues where the SentenceBert similarities were not perfect.

Based on these positive and negative training examples we can fine-tune a pre-trained English BERT model to separate the two classes. The trained classifier can make a prediction for all of the candidate pairs we obtained from the SentenceBERT step and keep only pairs with **same** prediction. In case there are multiple **same** predictions in a candidate list, or a node appears in more than one list we can take the highest posterior probability pair to get 1:1 matches only.

<table><caption>**Table 5.** Same vs Similar positive-negative generation example. Most similar pairs to Senator with scores and the first sentence of their abstracts in the memoryalpha-stexpanded datasets.</caption><thead><tr><th>Pairs</th><th>SentenceBert Score</th><th>Abstract</th></tr></thead><tbody><tr><td>Senator</td><td></td><td>A senator was a member of a legislative or deliberative body known as a senate</td></tr><tr><td>Romulan_Senate ⊖</td><td>0.696855</td><td>The Romulan Senate was the governing body of the Romulan Star Empire and headed by the Praetor</td></tr><tr><td>Lyran_Senate ⊖</td><td>0.647295</td><td>The Lyran Senate was an executive body of the Lyran Star Empire, tasked with the day-to-day administration of the Empire</td></tr><tr><td>Senator ⊕</td><td>0.643694</td><td>A senator is an official who sits in a senate</td></tr></tbody></table>

Note that this step could also work without using the SentenceBERT step's output as candidates, but a prediction should be made for all of the possible node pairs between the two graphs, which would require a lot more computation power.

## 3.4 Pipeline

In this section, we describe how we use each of the steps in our pipeline. We start out by getting exact matches over the **Label** property and extend this set with the **AltLabel** property exact matches over the nodes where no pairs were found previously. This set can be considered the final alignment which we will
<table><caption>**Table 6.** SvS results over the Abstract property. SvS uses the whole abstract, SvS-2 uses only the first two sentences</caption><thead><tr><th rowspan="2"></th><th colspan="3">mcu marvel</th><th colspan="3">memoryalpha memorybeta</th><th colspan="3">memoryalpha stexpanded</th><th colspan="3">starwars swg</th><th colspan="3">starwars swtor</th></tr><tr><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th></tr></thead><tbody><tr><td>SB-2</td><td>88.0</td><td>66.7</td><td>75.9</td><td>91.2</td><td>90.7</td><td>91.0</td><td>94.1</td><td>94.3</td><td>94.2</td><td>87.8</td><td>78.1</td><td>82.6</td><td>92.1</td><td>91.0</td><td>91.6</td></tr><tr><td>SvS</td><td>87.7</td><td>66.3</td><td>75.5</td><td>93.6</td><td>89.5</td><td>91.5</td><td>96.0</td><td>93.7</td><td>94.8</td><td>92.6</td><td>72.1</td><td>81.0</td><td>93.4</td><td>90.6</td><td>92.0</td></tr><tr><td>SvS-2</td><td>87.7</td><td>66.3</td><td>75.5</td><td>93.2</td><td>89.9</td><td>91.5</td><td>96.8</td><td>94.0</td><td>95.4</td><td>87.2</td><td>77.5</td><td>82.1</td><td>93.0</td><td>90.6</td><td>91.8</td></tr></tbody></table>

<figure><img src="image_5.png" /><figcaption>**Fig. 2.** Pipeline's dataflow. The brackets indicate which property was used.</figcaption></figure>

extend in the next steps to improve the recall. Next up is the SentenceBERT step where we select the Abstract property's first two sentences. We select the X most similar pairs to each node based on the abstract property's embedding vector using cosine similarity and filtered further by a threshold value. We pass this set to the Same vs Similar (SvS) step as a candidate pool, still using the Abstracts as text. To train the model we use the pairs of the Exact match over the Labels. As a last step, we discard the 1:N pairs leaving only the ones with the highest confidence and add them to the final alignment, discarding any overlapping nodes with the exact matches. To simply put, if two nodes have been paired in previous steps, they cannot be paired anymore. In Fig. 2 we visualized the pipeline's dataflow. The code is available the github repository: https://github.com/kiscsonti/GraphMatching_SameVsSimilar.

## 3.5 Parameters

The selected SentenceBERT model was the all-MiniLM-L6-v2 [11] model. At maximum, the top 6 pairs were selected for each node and discarded all pairs
below 0.6 cosine similarity threshold. For the SvS step the selected Language Model was *albert-base* [9] pre-trained on the MRPC [3] task which is a sentence similarity task. As for the training process a batch size of 1 (due to GPU memory capacity) and a learning rate of 10⁻⁵ were used. The training process was allowed to run for 100 epochs, but an EarlyStop with 5 patience could shut it down before, which means that we split the generated dataset to train and evaluation sets.

# 4 Discussion

In this section, we analyze how well our pipeline’s steps perform and discuss how the results deviate from our expectations.

## 4.1 Exact Match

The best case scenario of the exact matching would be if all the pairs represent the same entity resulting in a 100% precision, completing the goal of the exact matching step’s purpose. However, the results show otherwise. This would mean that there are multiple nodes in a single KG with the same labels. We found that there are disambiguation pages that have the same Label property while the gold standard pair is the disambiguated actual node. Also, there are so-called “Legends” nodes which would be the correct pair based on the annotations. For example, *swg/Chef - starwars/Chef* is an incorrect pair, because *starwars/Chef/Legends* would be the correct one.

## 4.2 Language Model Steps

We noticed on the *marvel* dataset that the language model-based steps cannot increase the recall. This is due to the dataset having abstracts in only 1% of the nodes in the *marvel* KG, consequently these steps very rarely find any pairs. The recall increases at other datasets.

By looking at the false positives of the SentenceBERT step we could outline the main reason for the mistakes, which is wrong node type detection, such as confusion between race and a character or location and race. For actual examples for the starwars graph, it connected *starwars/Borgle_bat - swg/Borgle_Bat_Cave* or *starwars/Sayormi - swg/Sayormi_Queen*, but there are a lot more difficult pairs *starwars/Tortur - swg/Torton* where in one of the abstracts you can find *'Torturs were a close genetic cousin of the Torton.'* which can give a false clue to the Language Model of these being the same.

Activating the SvS step can successfully filter out the similar pairs resulting in a better F-score than the exact match baselines. Same as before, cutting the abstracts at the first 2 sentences gives a slight boost. We manually investigated some of the new matches introduced by the SvS step. For example, *Anakin Skywalker* could be correctly matched to *Darth Vader* which is supported by *Anakin's* abstract where we can find the information “he was known as *Darth*
Vader” which should be enough to consider them the same. The question is whether the fine-tuned language model can recognize these clues correctly in general.

The number of false negative matches of the Exact Matching steps is low. To get a better insight into the performance of the SvS approach and how well the fine-tuned model can differentiate between the same and similar descriptions, we also generated a dataset using all gold standard pairs’ abstract text. We used the same negative generation process as before. We split it into train and test sets for this evaluation exercise, just for getting a basic understanding of how hard this particular task is. The trained classifier could achieve a 97% accuracy on the test sets.

Investigating the incorrect pairs of the SvS step, we can conclude that the main sources of errors are the same as in the SentenceBERT step, i.e. different types of entities getting paired together. Some examples such as starwars/High_Inquisitor - swg/Inquisitor_Fa'Zoll which is a rank-character pair, but we can find confusion between the same type of entities as well such as starwars/Old War_bunker - swg/Naboo_Pirate_Bunker, both being on the same planet making them even more similar. All in all, thanks to the high precision of the learned model it can discard enough of these incorrect pairs so that the overall F-score increases.

# 5 Related Work

## 5.1 OAEI Competition

Each year the OAEI competition is held where several systems were submitted. We compared our results to the top 5 best performing systems on the OAEI KG track. You can see the results in Table 7. Overall our system performed the best on 2 out of 5 datasets and was close to the TOP 1 in other datasets as well considering the F-score. The ATMatcher [5] was the competitor who could perform the best on the other 3 datasets. This competitive system works in two steps. First, it tries to match the classes and properties based on their name/label information with synonym detection. It is just like our exact matching but extended with synonyms. As a second step, it moves onto the instances where only the instances with the same class/properties would be matched together based on string matching and similar neighbor filtering. On the OAEI 22 track the Graph-Matcher [4] was proposed which tried to solve the graph matching problem with the use of Graph Attention networks in a siamese network style, however, the system was not submitted on the Knowledge Graph track, therefore we cannot compare to its performance.

## 5.2 Complete Alignment

Another group of the graph-matching tasks is the one where a complete alignment of all nodes between the two graphs is expected. Not to be confused
<table><caption>**Table 7.** OAEI22 Knowledge Graph Track competing systems.</caption><thead><tr><th rowspan="2"></th><th colspan="3">mcu marvel</th><th colspan="3">memoryalpha memorybeta</th><th colspan="3">memoryalpha stexpanded</th><th colspan="3">starwars swg</th><th colspan="3">starwars swtor</th></tr><tr><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th><th>P</th><th>R</th><th>F-m</th></tr></thead><tbody><tr><td>Ours</td><td>87.7</td><td><b>66.3</b></td><td><b>75.5</b></td><td>93.2</td><td>89.9</td><td>91.5</td><td>96.8</td><td><b>94</b></td><td><b>95.4</b></td><td></td><td></td><td></td><td>87.2</td><td>77.5</td><td>82.1</td><td>93</td><td>90.6</td><td>91.8</td></tr><tr><td>ATMatcher</td><td>67</td><td>52</td><td>59</td><td><b>96</b></td><td><b>91</b></td><td><b>93</b></td><td>96</td><td>92</td><td>94</td><td></td><td></td><td></td><td>93</td><td>76</td><td><b>84</b></td><td><b>95</b></td><td><b>91</b></td><td><b>93</b></td></tr><tr><td>KGMatcher</td><td><b>89</b></td><td>56</td><td>69</td><td>94</td><td>77</td><td>85</td><td><b>98</b></td><td>82</td><td>89</td><td></td><td></td><td></td><td><b>94</b></td><td>62</td><td>75</td><td>94</td><td>83</td><td>88</td></tr><tr><td>LogMap</td><td>84</td><td>46</td><td>59</td><td>89</td><td>76</td><td>82</td><td>88</td><td>75</td><td>81</td><td></td><td></td><td></td><td><b>94</b></td><td>68</td><td>79</td><td>94</td><td>75</td><td>84</td></tr><tr><td>LSMatch</td><td>63</td><td>42</td><td>50</td><td>59</td><td>75</td><td>66</td><td>53</td><td>79</td><td>63</td><td></td><td></td><td></td><td>76</td><td>24</td><td>37</td><td>81</td><td>82</td><td>82</td></tr><tr><td>Matcha</td><td>0</td><td>0</td><td>0</td><td>56</td><td>90</td><td>69</td><td>67</td><td>93</td><td>78</td><td></td><td></td><td></td><td>70</td><td><b>80</b></td><td>74</td><td>73</td><td>89</td><td>80</td></tr></tbody></table>

with our main task, these are mainly graphs in different languages therefore the assumption that the same entity can be expressed in both languages [17] mainly holds. This variant of the graph matching can be considered as a multilinguality challenge where the focus is on how well you can translate a node to other languages based on their properties. There have been attempts to create so-called dangling cases in [16], resulting in a partial alignment, but the task is still different from our original.

## 6 Conclusion

This paper proposes a multi-step solution for the KG matching problem. It uses only the textual information of the graph by first focusing on the trivial pairs as an exact matching search is applied between the two KGs to produce high-precision pairs. Next, with the help of neural language models, a pool of similar textual descriptions are gathered. In the last phase, we automatically construct a training set and fine-tune a language model to differentiate the same and similar descriptions. Based upon our error analysis the analysis of descriptions are useful tools to find very similar descriptions, but can easily get confused about the entity types.

Our approach performed the best on 2 out of 5 tasks in the 2022 OAEI KG matching track. As other top systems put a special focus on aligning the classes first, in the future we would focus on adding this information to the language models as well.

**Acknowledgements.** This research has been supported by the European Union project RRF-2.3.1-21-2022-00004 within the framework of the Artificial Intelligence National Laboratory.

## References

1. Balogh, V., Berend, G., Diochnos, D.I., Turán, G.: Understanding the semantic content of sparse word embeddings using a commonsense knowledge base. In: Proceedings of the AAAI Conference on Artificial Intelligence, vol. 34, no. 05, pp. 7399–7406, April 2020. https://doi.org/10.1609/aaai.v34i05.6235, https://ojs.aaai.org/index.php/AAAI/article/view/6235
2. Devlin, J., Chang, M., Lee, K., Toutanova, K.: BERT: pre-training of deep bidirectional transformers for language understanding. CoRR abs/1810.04805 (2018). http://arxiv.org/abs/1810.04805

3. Dolan, W.B., Brockett, C.: Automatically constructing a corpus of sentential paraphrases. In: Proceedings of the Third International Workshop on Paraphrasing (IWP2005) (2005). https://aclanthology.org/I05-5002

4. Efeoglu, S.: Graphmatcher: a graph representation learning approach for ontology matching (2022)

5. Hertling, S., Paulheim, H.: Atbox results for oaei 2021. In: CEUR Workshop Proceedings, vol. 3063, pp. 137–143. RWTH Aachen (2021)

6. Hertling, S., Portisch, J., Paulheim, H.: MELT - matching evaluation toolkit. In: Acosta, M., Cudré-Mauroux, P., Maleshkova, M., Pellegrini, T., Sack, H., Sure-Vetter, Y. (eds.) SEMANTICS 2019. LNCS, vol. 11702, pp. 231–245. Springer, Cham (2019). https://doi.org/10.1007/978-3-030-33220-4_17

7. Euzenat, J., Meilicke, C., Stuckenschmidt, H., Shvaiko, P., Trojahn, C.: Ontology alignment evaluation initiative: six years of experience. In: Spaccapietra, S. (ed.) Journal on Data Semantics XV. LNCS, vol. 6720, pp. 158–192. Springer, Heidelberg (2011). https://doi.org/10.1007/978-3-642-22630-4_6

8. Kardos, P., Szántó, Z., Farkas, R.: Rdf2vec in the knowledge graph matching task. CSCS (2022). https://www.inf.u-szeged.hu/cscs/pdf/cscs2022.pdf

9. Lan, Z., Chen, M., Goodman, S., Gimpel, K., Sharma, P., Soricut, R.: ALBERT: a lite BERT for self-supervised learning of language representations. CoRR abs/1909.11942 (2019). http://arxiv.org/abs/1909.11942

10. Liu, Y., et al.: Roberta: a robustly optimized BERT pretraining approach. CoRR abs/1907.11692 (2019). http://arxiv.org/abs/1907.11692

11. Reimers, N., Gurevych, I.: Sentence-bert: Sentence embeddings using siamese bert-networks. CoRR abs/1908.10084 (2019). http://arxiv.org/abs/1908.10084

12. Ristoski, P., Rosati, J., Di Noia, T., De Leone, R., Paulheim, H.: Rdf2vec: RDF graph embeddings and their applications. Semantic Web 10(4), 721–752 (2019)

13. Schick, T., Schütze, H.: Exploiting cloze questions for few-shot text classification and natural language inference. CoRR abs/2001.07676 (2020). https://arxiv.org/abs/2001.07676

14. Auer, S., Bizer, C., Kobilarov, G., Lehmann, J., Cyganiak, R., Ives, Z.: DBpedia: a nucleus for a web of open data. In: Aberer, K., Choi, K.-S., Noy, N., Allemang, D., Lee, K.-I., Nixon, L., Golbeck, J., Mika, P., Maynard, D., Mizoguchi, R., Schreiber, G., Cudré-Mauroux, P. (eds.) ASWC/ISWC ’2007. LNCS, vol. 4825, pp. 722–735. Springer, Heidelberg (2007). https://doi.org/10.1007/978-3-540-76298-0_52

15. Suchanek, F.M., Kasneci, G., Weikum, G.: Yago: a core of semantic knowledge. In: Proceedings of the 16th International Conference on World Wide Web, pp. 697–706 (2007)

16. Sun, Z., Chen, M., Hu, W.: Knowing the no-match: entity alignment with dangling cases. CoRR abs/2106.02248 (2021). https://arxiv.org/abs/2106.02248

17. Sun, Z., Hu, W., Li, C.: Cross-lingual entity alignment via joint attribute-preserving embedding. CoRR abs/1708.05045 (2017). http://arxiv.org/abs/1708.05045

18. Vrandečić, D., Krötzsch, M.: Wikidata: a free collaborative knowledgebase. Commun. ACM 57(10), 78–85 (2014). https://doi.org/10.1145/2629489