Finding correspondences between di erent ontologies is a crucial task in the Semantic Web. Ontology matching tools are capable of solving that task in an automated manner, some even dealing with ontologies in di erent natural languages. Most state of the art matching tools use internal element and structure based techniques, while the use of large-scale external knowledge resources, especially internet resources, is still rare. In this paper, we introduce WikiMatch, a matching tool that exploits Wikipedia as an external knowledge source. We show that using Wikipedia is a feasible way of performing ontology matching, especially if di erent natural languages are involved.
Ontologies are an essential building block of the Semantic Web. They formally describe the vocabulary used in a domain in a machine-interpretable way. Thus, ontologies can be used to unambiguously exchange information between machines. If multiple ontologies are used in parallel in a domain, e.g., when integrating two data sets, mappings between those ontologies are required.
Approaches for nding such mappings or alignments automatically are called
ontology matching approaches [
Many state of the art matchers are based on internal techniques, i.e., they only use the knowledge contained in the ontologies to match, but no external knowledge sources. Such matchers compare local names and labels of elements contained in the ontologies, and use structural features. In contrast, external techniques make use of external resources, such as synonym lists, dictionaries, or linguistic resources such as wordnet. In many cases, e.g., for recognizing synonyms, they produce useful results.
On the other hand, such matchers are restricted to the domain of the resources they use, and most of the resources are limited and outdated if not maintained by the tool developer.
In this paper, we present WikiMatch, an ontology matching approach based on Wikipedia as an external resource. The knowledge in Wikipedia is based on 23 million articles written by volunteers around the world, covering almost every possible domain at least to a certain depth. Wikipedia pages exist in 285 languages with links between articles in di erent languages1, hence, it is also usable for matching ontologies in di erent languages.
The goal of our approach is to make this large knowledge source usable for ontology matching. To that end, we present an approach that exploits Wikipedia's search functionality and inter-language links for nding mappings between ontologies.
The rest of this paper is structured as follows. Section 2 introduces the state of the art and discussed related matching approaches. Section 3 describes our approach and two di erent variants, and section 4 shows the evaluation results for both variants, using ontologies and reference alignments from the Ontology Alignment Evaluation Initiative (OAEI)2. This paper is then summarized by a conclusion and an outlook on future work. 2
Discovering and using relevant sources of background knowledge has been named
as one of the ten main challenges to ontology matching [
Most approaches employing upper ontologies only use a small set of xed
comprehensive ontologies, such as Proton in BLOOMS+ [
Apart from upper-level ontologies, another widely used external knowledge
source are linguistic resources such as thesauri, e.g. WordNet [
ogy matching in speci c domains, but it requires the availability and pre-selection of such documents.
Web data is rarely used in ontology matching. One of the few approaches is
COMS, which uses the online source Wiktionary 4 as lexical background
knowledge, and employs the Google Translation API5 for addressing multi-lingual
ontologies [
Gligorov et al. have discussed the use of the Google search engine for
ontology matching [
Wikipedia, despite being one of the largest cross-domain knowledge
collections, and also one of the best-known, has been rarely explored as a source
of background knowledge in ontology matching so far. BLOOMS uses only
Wikipedia's category tree and employs it as an upper ontology (see above), rather
than exploiting Wikipedia as a whole. In [
The basic idea of our approach is to use Wikipedia's search engine to retrieve a result set of Wikipedia articles describing the term. To support multilingual scenarios, we retrieve all language links per article in a second translation step. Since the article titles are unique for every Wikipedia in one language, we compare the sets of retrieved titles to compute the similarity between two concepts.
Wikipedia is based on a software platform called MediaWiki, written in PHP. This framework is used to run Wikipedia, Wiktionary, Wikinews, and so on. MediaWiki o ers an API6 for all pages which run on this software. That API o ers two di erent search engines which vary in their purpose. The traditional search engine performs a full text search, while OpenSearch is used to assist users with suggestions when typing their search.
The standard search engine7 performs a full text search in all articles. If a term is misspelled, the response contains a suggestion with for the correctly spelled word. The goal of the search engine is to nd Wikipedia articles that contain all words from the input.
O1 read ontology Fragment
Label
Comment O2
Fragment
Label read ontology Comment
query wikipedia titles
Lang=x
Lang=a query wikipedia titles
query translated titles Lang=x
Fragment Label Comment Fragment Label Comment Lang=a
Lang=y Fragment Label Comment Fragment Label Comment
Lang=y query translated titles
Lang=z translated titles translated titles
Lang=z Fragment Label Comment Fragment Label
Comment Lang=y comparison
Lang=z
The other search engine is Opensearch8. It is used for suggesting some terms while the user is typing in the search box on Wikipedia. This search is not applicable for our task, because we already have the full term and hence do not need any hint on possible completions. In our preliminary experiments, that search engine did not work well. Often, labels and comments are composed of many words (tokens), and in that case, the reply of Opensearch is empty9. Thus, we use Wikipedia's standard search engine.
For performing searches, we use the URI fragments, labels, and comments of each concept as input strings to the search input. Since the search engine tries to 8 http://www.mediawiki.org/wiki/API:Opensearch 9 See this example taken from the OAEI conference track: http://en.wikipedia.org/ w/api.php?action=opensearch&search=Subject%20Area&limit=10&namespace= 0&format=jsonfm nd all the words in the input query in a Wikipedia article and does not ignore stop words, we remove stop words in a preprocessing step. After preprocessing, our approach uses two di erent variants for performing the search: taking the preprocessed strings as search input, or searching for each individual token in the input string.
For example, from the label member of the program committee, the stop words of and the would be removed in a rst step. Our standard search approach then searches for member program committee, while the individual token search approach would trigger three searches for member, program, and committee.
In both search variants, we divide the ontology elements to match into three sets: classes, datatype properties, and object properties. We match only concepts of the same part. This yields on the one hand in better performance and higher precision and on the other hand all mappings are consistent with OWL Lite/DL. Additionally, we can adjust individual threshold values for every type of mapping, like class-class or property-property mappings.
For every ontology concept we extract the fragment, labels and comments, and compare each combination of concepts from both ontologies. Each fragment, label, and comment (or in the individual token search approach, each token thereof) is sought via the Wikipedia search engine. The result is a set of documents per fragment, label, and comment. From those sets, the similarity of two concepts is computed. We compare only titles with the same language. Given that the search for a term t { which can be a label, URI fragment, or comment { returns a set S(t) of Wikipedia article titles (which can be in any language), the similarity between two concepts (i.e., classes and properties) c1 and c2 from two ontologies O1 and O2 is de ned as If the similarity exceeds a certain threshold, we return a mapping element for the two concepts.
The sets of Wikipedia articles are retrieved by rst searching for the Wikipedia article, and then retrieving all translations to other articles in a second step. Thus, our approach treats both single-language and multi-language ontology matching problems the same.
To address the correct search engine, we extract the ontologies' language tags and create a URL like http://(lang-tag).wikipedia.org/w/api.php. To this URL we send a request for n titles10. The results are all in the language we extracted from the ontology. To compare titles from other languages, we add all language-links appear on the requested wikipedia pages. If the answer contains a suggestion for a spelling correction, we make another query in order to get better result for misspelled words. Figure 1 depicts the matching process in a schematic way.
As the simple search approach uses the Wikimedia search interface in a trivial way, requesting articles for whole strings such as Member of the Program 10 For the evaluations in this paper, we have set n = 50 float getsimilarity(term1, term2) { titlesForTerm1 = getAllTitles(term1); titlesForTerm2 = getAllTitles(term2); commonTitles = intersectionOf(titlesForTerm1, titlesForTerm2); allTitles = unionOf(titlesForTerm1, titlesForTerm2); return #(commonTitles) / #(allTitles); List<WikipediaPage> getAllTitles(searchTerm) { removeStopwords(searchTerm); removePunctuation(searchTerm); if(simpleSearch) {
resultList = searchWikipedia(searchTerm); if(individualTokenSearch) { tokens = tokenize(searchTerm); for each token in tokens
resultList = resultList + searchWikipedia(searchTerm); } } } for each page in results
resultList = resultList + getLanguageLinks(page); } return resultList; Committee. Since especially comments can be fairly long, we have also implemented an alternative variant searching for individual tokens in the names, such as member, program, committee. This approach is expected to increase the recall, but maybe yield lower precision. Figure 2 shows the algorithm for both search approaches in pseudo code. 4
We have evaluated our tool with benchmarks from the OAEI matching campaign11. In this paper, we will focus on the real-world use case from the conference domain (conference), as well as the multi-lingual dataset (multifarm). 11 http://oaei.ontologymatching.org/ 0,900 0,800 re 0,700 u sa 0,600 e /-Fm 0,500 n llii/rpo 00,,340000 s c e a rce 0,200 0,100 0,0000,05 0,10 0,15 0,20 0,25 0,30 0,35 0,40 0,45 0,50 0,55 0,60 0,65 0,70 0,75 0,80 0,85 0,90 0,95 1,00 threshold The conference track consists of 16 ontologies about the domain of conferences. Each of those ontologies are compared in a pairwise setting. For self-evaluation, a subset of seven ontologies is given with reference alignments, thus resulting in 21 possible test cases combinations. The following results are based on those 21 test cases and show average values over all 21 cases.
All the following diagrams are organized as follows: On the x-axis, we use di erent values for the threshold t, and depict recall, precision, and f-measure for those di erent values.
Figure 3 shows the results for the Simple Search Approach. The maximum f-measure of 0:610 is reached when using a threshold of 0:5. In general, for threshold values above 0:25, there are only small variations in f-measure.
Figure 4 shows the results achieved with Individual Token Search. There is a signi cant leap between 0:5 and 0:55. With a threshold of 0:5 we only get a f-measure of 0:208, while ith a threshold of 0:55, the f-measure rises to 0:582. The maximum f-measure that can be reached with this approach is 0:611, using a threshold of 0:7.
F-Measure Recall Precision F-Measure Recall Precision
These results show that for the conference track, both approaches converge to about the same maximum f-measure when setting an appropriate threshold. If we compare our result to the OAEI 2011.5 results12, WikiMatch is on the fourth rank, between CODI and Hertuda, and in particular performs signi cantly better than the baseline comparing concepts based on string similarity and stop word ltering.
Our matching time for the Simple Search Approach is 1340 seconds, which is 22 minutes and 20 seconds. Individual Token Search Approach takes a little bit longer. It was about 1454 seconds (24 minutes and 14 seconds). 4.2
The multifarm dataset is designed for multilingual ontology matching. It is based
on the conference dataset described above, which is translated into eight di erent
languages, i.e., Chinese, Czech, Dutch, French, German, Portuguese, Russian,
and Spanish [
The evaluation of Simple Search Approach is depicted in gure 5. It shows that the maximum f-measure of 0:210 is reached for a threshold of 0:06, with recall decreasing at a great pace. The maximum recall is only 0:35.
Figure 6 shows the results that can be achieved on the multifarm track with individual token search. The maximum f-measure that can be achieved is 0:179 at a threshold of 0:06, with recall and precision behaving similarly to simple search. Thus, for multi-lingual problems, simple search yields slightly better results. The results are competitive with the top 5 tools at the recent OAEI 2011.5 evaluation13.
Table 1 depicts results on the multifarm track, showing those language pairs that were part of the OAEI evaluation 2011.5 (i.e., excluding Chinese and Russian). 4.3
Requesting web resources at run-time usually generates run times that are not competitive internal matching approaches or external matching approaches using only local resources. On the conference and multifarm datasets, a pair of ontologies takes about 360 seconds with simple search and 450 seconds14 with individual token search to process.
However, in contrast to approaches using co-occurence analysis on Wikipedia
[
In the multi-lingual case, simple translations such as Stadt(de) and city(en) and close translations such as Bankett(de) and dinner banquet(en) can be handled by WikiMatch, as well as property names such as hat E-Mailadresse(de) and has email(en). Cases where the translated terms are di erent, e.g., Autor von(de) and has written(en), are equally problematic as in the single language case.
For the multi-lingual case, we have further analyzed the relation between the di erent language Wikipedia's sizes and the F-Measure achieved. F-Measure and recall are strongly correlated with the Wikipedia's sizes; the best results are achieved with the biggest Wikipedias (English, French, German and Dutch are larger than 1,000,000 entries, and the results between those four languages are the best ones). Conversely, the worst result is achieved for Czech and Portuguese, where the Czech and the Portuguese Wikipedia are the smallest ones among the languages used in multifarm. 5
In this paper, we have presented WikiMatch as a matching approach based on a large external resource, namely Wikipedia. We use this information to handle synonyms and determine a score describing the equality of two concepts. This paper showed that a matcher using only one external resource without respect to structural information within the ontologies can also yield good results in OAEI benchmarks.
We can handle all domains which Wikipedia covers. Since Wikipedia is community project, it is maintained by many volunteers around the world and grows to more domains each day. Thus, we do not have to take care about updates of the external resources used in in our matcher.
Moreover, we use language links to match ontologies in di erent languages. Since these links are maintained by humans and not created by bots, we can heavily rely on these links for translation. In this case it is also possible to cope with matching multilingual ontologies.
The aim of this paper was to explore the possibilities of exploiting Wikipedia as an external resource for ontology matching. Since the results are promising and the approach is capable of tackling many hard-to-handle cases, especially in the multi-lingual area, combining the WikiMatch approach with other techniques, such as structure-based matching algorithms, would be a natural step to further exploit the approach's potential.
In our experiments, we have compared two di erent variants for searching contents in Wikipedia, which lead to similar maximum f-measure values, but behave di erently in detail. A suitable combination of both approaches could help generating better overall results.
At the moment, despite using various caches, our approach is not very fast.
The most time consuming operation is querying Wikipedia. On the other hand,
our approach is purely element based, which allows for e cient distribution of
the matching problem to many computers [
While Wikipedia is for sure one of the largest and encompassing online resource, implementing our approach with other such resources, such as answers.com, or exploiting even general web search engines, would be an interesting experiment to further assess the value of Wikipedia as a knowledge resource in ontology matching.
In summary, we have shown that a simple approach with Wikipedia as an external resource can handle many di erent problems in the ontology matching area. Especially, the matching of multilingual ontologies are covered with this approach. The external resource is never outdated and can be used for all domains covered by Wikipedia. We hope that our work will improve future ontology matcher to get better results in monolingual as well as multilingual matching.