This paper describes DESKMatcher, a label-based ontology matcher. It utilizes background knowledge from the financial services and enterprise domain to better find matches in these domains. The background knowledge utilized for the enterprise domain was in the form of documentation of terms used in SAP software (textual). Therefore, Word2Vec and GloVe were used for these corpora. The Financial Industries Business Ontology (FIBO) was used as more specific background knowledge for the financial services domain. Vector space embeddings for this corpus were trained using RDF2Vec and KGloVe. Individual matchers utilizing one set of embeddings (generated from a combination of method and corpus) are pipelined together after a string-based matchers, searching only for matches between entities that have not been assigned to a match in a previous step. Results on the OAEI tracks are expected to be sub-par, because low overlap between corpus and task vocabulary is expected.3 DESKMatcher (Enterprise Domain Specific K nowledge Matcher) is an elementlevel, label-based matcher which utilizes vector space embeddings trained by applying multiple techniques on three background knowledge datasets specific to the enterprise and financial services domain, namely the Financial Industry Business Ontology (FIBO), the SAP Glossary, as well as SAP Term. The matcher was implemented for domain-specific matching in the financial services domain where classic schema matching problems are common and can be modelled as ontology matching problems [11]. However, in this paper we evaluate in how far the matcher generalizes to non-business/other domains. The matcher has not been adapted for other tasks.
1.1
The DESKMatcher system is implemented as a matching pipeline of subsequent
matching steps using multiple domain-specific datasets that were embedded with
RDF2Vec or word2vec depending on their inherent structure. In the following a
quick introduction to the datasets used as well as to RDF2Vec will be given.
External Domain-Specific Datasets Below, we quickly introduce the sources of
background knowledge that have been used:
1. The Financial Services Business Ontology (FIBO) [
It is frequently updated. The resource is not available as ontology but instead in the form of a losely structured text corpus. For this work we used the version as of March 2020. The set contained definitions for roughly 62,000 terms using roughly 16,000 unique words.
Embedding Approaches Used In word2vec [
Configuration of Embedding approaches Skip-gram was chosen over CBOW. This
was based on Mikolov et al.’s results, that Skip-gram is better in semantic tasks
[8, p. 7], which has also been indicated in [16, p. 4]. Generally, higher dimensions
lead to higher performance, however the gain in performance per added dimension
seems to greatly decrease after 200 dimensions, wherever dimensions are reported.
Therefore the dimensions were fixed at 2009. Based on recommended parameter
settings from previous work, the window-size was fixed to 5, negative sampling
with 15 noise words and a smoothing exponent of 0.75 (as per Mikolov et al.’s
recommendation in the original paper) was used. The Skip-gram embeddings
were generated using the implementation in the gensim library [
The implementation by Cochez et al. 11, was used to generate the shufled cooccurrence files needed as input for the final step of GloVe.
Based on their results for best performance, the PageRank weighting scheme for context generation would have been chosen, which unfortunately did not execute without fatal errors, even after several attempts to tinker with the code. Therefore the uniform weighting was chosen, because it was reported to be the second best approach.
For the BCA, that is used to generate the “co-occurence probabilities”, parameters α (which probability fraction is retained on a node) and ϵ (minimum value of probability to be distributed, values below being discarded) were chosen identical to the number Cochez et al. chose (α = 0.1 and ϵ = 0.00001).
The output co-occurence matrix was then put into GloVe using the same parameters as above. 6 see https://github.com/dwslab/jrdf2vec 7 see https://radimrehurek.com/gensim/ 8 see https://nlp.stanford.edu/projects/glove/ 9 In order to add another level of consistency between the approaches, the dimensions were also fixed to 200 in all of the other embedding generation approaches. 10 available under https://github.com/stanfordnlp/GloVe 11 https://github.com/miselico/globalRDFEmbeddingsISWC Six embedding sets were therefore generated in total: two for each of the three corpora.
Matching Process Only the label and the entity type (class, datatype, property,
object property, or individual) are considered. The entity types are used as a
iflter to only be matched against each other so that a homogeneous alignment is
created, which proved to be a valuable heuristic in development. Matches are
mainly determined based on the entity label. In the first step of the pipeline,
simple matches are detected by a string matcher assuming n:m arity. Following
steps try to apply increasingly less specific background knowledge in the form of
embeddings trained on respectively less specific corpora, assuming only 1:1 arity
(by ignoring entities already appearing in predicted matches). The specificity was
assumed from the vocabulary size of a corpus. Per corpus, Word2Vec/RDF2Vec
were applied before GloVe/KGloVe embeddings12. So the embedding sets were
applied in the order FIBO-RDF2Vec, FIBO-KGloVe, SAP Glossary-Word2Vec,
SAP Glossary-Word2Vec, SAP Term-Word2Vec, SAP Term-GloVe.
Implementation The system has been implemented and packaged with the
Matching and Evaluation Toolkit (MELT), a framework for matcher development,
tuning, evaluation, and packaging [
For this track, DESKMatcher was barely able to exceed the StringEquiv baseline and heavily underperformed on Precision and in turn F1. Because the knowledge to train the embeddings was not taken from the same domain, these results are not surprising. 2.2
The Recall of 0.5 was rather below average compared to other matching systems, whereas Precision and F1 were far below that of the others. An overlap between the Conference vocabulary present in the track and Business vocabulary from the background knowledge might have been expected, which in turn would have caused DESKMatcher to perform better. 12 The decision whether to apply Word2Vec/RDF2Vec or GloVe/KGloVe embeddings ifrst was taken arbitrarily. An improvement would be to investigate which embedding approaches actually are most suited for matching tasks.
DESKMatcher was able to perform all test cases of the knowledge graph track [
This system uses very specific domain knowledge from the financial services and business domains, which are not exactly covered by any of the tracks. Therefore, it was expected, that it should not be able to perform well. Even though expectations were set low, the results appear to be even worse. The system’s strength lies in it being able to improve recall, which causes its greatest weakness: bad precision that in turn leads to bad F1. 3.2
The greatest weakpoint of bad precision needs to be removed. Possible solutions would be a more strict linking process. A very greedy linking approach was chosen, to be able to find any matches at all. Additionally, the embedding sets can be pre-evaluated in a diferent way and discarded or used accordingly; using multiple embedding sets for one corpus did not show any positive results in the datasets evaluated here. 4
In this paper, we presented the DESKMatcher, a matching system for the financial services domain. The inner workings of the systems have been explained and the performance numbers in the 2020 campaign of the OAEI have been discussed. The system did not perform competitively in the campaign due to low vocabulary overlap in the datasets that have been used. We strive to improve the system in the future.