In this paper, we introduce Wiktionary Matcher, an ontology matching tool that exploits Wiktionary as external background knowledge source. Wiktionary is a large lexical knowledge resource that is collaboratively built online. Multiple current language versions of Wiktionary are merged and used for monolingual ontology matching by exploiting synonymy relations and for multilingual matching by exploiting the translations given in the resource. We show that Wiktionary can be used as external background knowledge source for the task of ontology matching with reasonable matching and runtime performance.3 The Wiktionary Matcher is an element-level, label-based matcher which uses an online lexical resource, namely Wiktionary. The latter is "[a] collaborative project run by the Wikimedia Foundation to produce a free and complete dictionary in every language"4. The dictionary is organized similarly to Wikipedia: Everybody can contribute to the project and the content is reviewed in a community process. Compared to WordNet [4], Wiktionary is signi cantly larger and also available in other languages than English. This matcher uses DBnary [15], an RDF version of Wiktionary that is publicly available5. The DBnary data set makes use of an extended LEMON model [11] to describe the data. For this matcher, DBnary data sets for 8 Wiktionary languages6 have been downloaded 3 Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 4 see https://web.archive.org/web/20190806080601/https://en.wiktionary. org/wiki/Wiktionary 5 see http://kaiko.getalp.org/about-dbnary/download/ 6 Namely: Dutch, English, French, Italian, German, Portugese, Russian, and Spanish.
1.1
and merged into one RDF graph. Triples not required for the matching
algorithm, such as glosses, were removed in order to increase the performance of the
matcher and to lower its memory requirements. As Wiktionary contains
translations, this matcher can work on monolingual and multilingual matching tasks.
The matcher has been implemented and packaged using the MELT framework7,
a Java framework for matcher development, tuning, evaluation, and packaging
[
Monolingual Matching For monolingual ontologies, the matching system rst
links labels to concepts in Wiktionary, and then checks whether the concepts are
synonymous in the external data set. This approach is conceptually similar to
an upper ontology matching approach. Concerning the usage of a collaboratively
built knowledge source, the approach is similar to WikiMatch [
Wiktionary Matcher adds a correspondence to the nal alignment purely
based on the synonymy relation independently of the actual word sense. This
is done in order to avoid word sense disambiguation on the ontology side but
also on Wiktionary side: Versions for some countries do not annotate synonyms
and translations for senses but rather on the level of the lemma. Hence, many
synonyms are given independently of the word sense. In such cases,
word-sensedisambiguation would have to be performed also on Wiktionary [
The linking process is similar to the one presented for the ALOD2Vec
matching system [
For multi-linked concepts (such as conference dinner ), a match is only annotated if every linked component of the label is synonymous to a component in the other label. Therefore, lens (http://mouse.owl#MA 0000275) is not mapped to crystalline lens (http://human.owl#NCI C12743) due to a missing synonymous partner for crystalline whereas urinary bladder neck (http://mouse.owl#MA 0002491) is matched to bladder neck (http://human.owl#NCI C12336) because urinary bladder is synonymous to bladder.
Multilingual Matching The multilingual capabilities of the matcher presented
in this paper are similar to the work of Lin and Krizhanovsky [
data of the English Wiktionary (as of 2010) to allow for multilangual matching
of the COMS matching system [
The matcher rst determines the language distributions in the ontologies. If the ontologies appear to be in di erent languages, Wiktionary translations are exploited: A match is created, if one label can be translated to the other one according to at least one Wiktionary language version { such as the Spanish label ciudad and the French label ville (both meaning city ). This process is depicted in gure 1: The Spanish label is linked to the entry in the Spanish Wiktionary and from the entry the translation is derived.
If there is no Wiktionary version for the languages to be matched or the approach described above yields very few results, it is checked whether the two labels appear as a translation for the same word. The Chinese label 决定 (jued ng), for instance, is matched to the Arabic label P@Q ¯ (qrar) because both appear as a translation of the English word decision on Wiktionary. This (less precise) approach is particularly important for language pairs for which no Wiktionary data set is available to the matcher (such as Chinese and Arabic). The process is depicted in gure 2: The Arabic and Chinese labels cannot be linked to Wiktionary entries but, instead, appear as translation for the same concept. Instance Matching The matcher presented in this paper can be also used for combined schema and instance matching tasks. If instances are available in the given data sets, the matcher applies a two step strategy: After aligning the schemas, instances are matched using a string index. If there are many instances, Wiktionary is not used for the instance matching task in order to increase the matching runtime performance. Moreover, the coverage of schema level concepts in Wiktionary is much higher than for instance level concepts: For example, there is a sophisticated representation of the concept movie8, but hardly any individual movies in Wiktionary.
For correspondences where the instances belong to classes that were matched before, a higher con dence is assigned. If one instance matches multiple other instances, the correspondence is preferred where both their classes were matched before.
Explainability Unlike many other ontology matchers, this matcher uses the
extension capabilities of the alignment format [
explanations can help to interpret and to trust a matching system's decision. Similarly, explanations also allow to comprehend why a correspondence was falsely added to the nal alignment: The explanation for the false positive match (http://confOf#Contribution, http://iasted#Tax), for instance, is given as follows: "The rst concept was mapped to dictionary entry [contribution] and the second concept was mapped to dictionary entry [tax]. According to Wiktionary, those two concepts are synonymous." Here, it can be seen that the matcher was successful in linking the labels to Wiktionary but failed due to the missing word sense disambiguation. In order to explain a correspondence, the description property9 of the Dublin Core Metadata Initiative is used. 2 2.1
On the Anatomy track [
The matching system consistently ranks 4th on all reference alignments given
F1 scores in the Conference track [
The multilingual approach of the Wiktionary Matcher is di erent from most
multilingual ontology matching approaches that use a translation API: Instead
of an external function call, multiple multilingual resources are merged and used.
Out of the matchers that participated in the MultiFarm track [
On the Knowledge Graph (KG) Track [
The matcher performs better in terms of F1 on classes and properties compared to instances. This might be due to the fact that the matcher is optimized to match schemas and that the Wiktionary background source is only used for the schema matching task. 3
The current version of DBnary does not extract alternative forms of words such as (color, colour). This is a limitation by the data set used for this matcher and not by Wiktionary. An addition of this relation between lemmas to the data set would likely improve results.
Furthermore, the matching system presented here only uses synonymy and translation relations even though more information is available in the background knowledge source. An extension to other relations that exist between words would help to increase the performance. The false negative match between intestine secretion and intestinal secretion of classes http://mouse.owl#MA 0002515 and http://human.owl#NCI C32875, respectively, could be found if the system would exploit the fact that intestinal is derived from intestine (an information that is available in the data set).
The runtime performance could be improved by loading the background knowledge data (or aggregates) in specialized data structures that allow for a faster data access at runtime, such as key-value stores (rather than querying an RDF graph). This approach could particularly improve the performance on the MultiFarm track which has a comparatively slow runtime performance due to complex SPARQL queries. 4
In this paper, we presented the Wiktionary Matcher, a matcher utilizing a collaboratively built lexical resource. Given Wiktionary 's continuous growth, it can be expected that the matching results will improve over time { for example when additional translations are added. In addition, improvements to the DBnary data set, such as the addition of alternative word forms, may also improve the overall matcher performance.