This paper presents the results of Clona in the Ontology Alignment Evaluation Initiative campaign (OAEI) 2015. We only participated in Multifarm track, since Clona develops speci c techniques for aligning multilingual ontologies. We rst give an overview of our alignment system; then we detail the techniques used in our contribution to deal with cross-lingual ontology alignment. Last, we present the results with a thorough analysis and discussion, then we conclude by listing some future work on Clona.
ontologies alignment is still a little investigated domain in spite of the multiplicity of the alignment methods which remain restricted to monolingual ontologies [36].
Clona as a few methods [710] meets challenges strictly bound at the linguistic level in the context of multilingual ontology alignment. The driven idea of our new method is to cross the natural language barrier. Clona presents a novel view to improve the alignment accuracy that draws on the information retrieval techniques. 1.1
Clona is an alignment system which aims through specic techniques to identify the correspondences between two ontologies dened in two dierent natural languages. Indeed, it starts with a pretreatment stage to model the input ontologies by a format for the rest of the process. The second phase is that of translation into a chosen pivot language and provided by the Microsoft Bing 1 translator.
Thereafter, our method continues with an indexing phase over the considered ontologies. Then these indexes are asked to supply the candidate mappings list to be aligned. Before generating the alignment le, Clona uses a ltering module for recovery and repair.
Parsing and Pretreatment : This phase is crucial for ontologies pretreatment. It is performed using the OWL API. Indeed, it transforms the considered ontologies represented initially as two OWL les in an adequate format for the rest of the treatments. In our case, the goal is to remove all the existing information in both OWL les so that each entity is represented by all its properties. Indeed, the parsing module begins by loading two ontologies to align described in OWL.
This module allows to extract the ontological entities initially represented by a primitive form of lists. In other words, at the parsing stage, we seek primarily to transform an OWL ontology in a well dened structure that preserves and highlight all the information contained in this ontology. Furthermore, in the resulting informative format, has a considerable impact on the results of the similarity computation thereafter. Thus, we get couples formed by the name of the entity and its associated label. In the next step we add an element to such couples to process these entities regardless of their native language.
Translation : The main goal of our approach is to solve the heterogeneity problem mainly due to multilingualism. This challenge brings us to choose between two alternatives, either we consider the translation path to one of the languages according to the two input ontologies, or we consider the translation path to a chosen pivot language. At this stage, we must have a vision of foreseeable rest of our approach. Specically, at the semantic alignment stage we use an external resource such as WordNet. The latter is a lexical database for the English language. Therefore, our choice is well taken, and we will prepare a translation of the two ontologies to the pivot language, which is English. To perform the translation phase we chose Bing Microsoft tool.
Indexation : Whether on the Internet, with many search engine or local access, we need to nd documents or simply sites. Such research is valuable to browse each le and the analysis thereafter. However, the full itinerary of all documents with the terms of a given query is expensive since there are too many documents and prohibitive response times. To enable faster searching, the idea is to execute the analysis in advance and store it in an optimized format for the search. Indexing is one of the novelties of our approach. It consists in reducing the search space through the use of eective search strategy on the built indexes. In fact, we no longer need the sequential scan because with the index structure, we can directly know what document contains a particular word. To ensure this indexing phase we use the Lucene 2 tool. Lucene is a Java API that allows developers to customize and deploy their own indexing and search engine. Lucene uses a suitable technology for all applications that require text search. Indeed, at the end of the indexing process, we get four dierent indexes to everyone of the two input ontologies depending on the type of the detected entities ( i.e., concepts, data types, relationships, and instances). The documents at the indexes represent the se
mantic information about the entity. These semantic information is obtained by means of an external resource ( i.e., WordNet). Indeed, for each entity, Clona keeps the entity name, the label, the label translated to English and its synonyms in English. So with Lucene, we created a set of indexes for the two ontologies, a search query is set up to return all the candidates. Candidate Mappings Identication : TermQuery is the most basic query type to search through an index. It can be built using one term. In our case, TermQuery’s role is to nd the entities in common between the indexes. Indeed, once the two indexes are set up, the querying step of the latter is activated. Thus, the query implementation satises the terminology search and semantic aspects at once as we are querying documents that contain a given ontological entity and its synonyms obtained via WordNet. The result of this process is a set of documents sorted by relevance according to the Lucene score assigned to each returned document. Thus, for each query, Clona keep the rst ve documents returned and considers them as candidate mappings for the next phase.
Filtering and Recovery : The ltering module consists of two complementary sub modules, each one is responsible of a specic task in order to rene the set of aligned candidates. Indeed, once the list of candidates is ready, Clona uses the rst lter. Indeed, we should note that indexes querying may includes a set of redundant mappings. This lter eliminate this redundancy. Indeed, it goes through the list of candidates and for each candidate, it checks if it still exists in the list. If this is the case, it removes the redundant element. At the end of ltering phase, we have a candidates list without redundancy, however, there is always the concern of false positives, indeed, there was the need to establish a second lter. Once the redundant candidates are deleted, Clona uses the second lter that eliminates false positives. This lter is applied to what we call to partially redundant entities. An entity is considered partially redundant if it belongs to two dierent mappings ( i.e., being given three ontological entities e1, e2 and e3. If on the one hand, e1 is aligned to e2, and secondly, e1 is aligned to e3, this last alignment is qualied as doubtful. We note that Clona generates (1 : 1) alignments. To overcome this challenge, Clona compares the topology of two suspicious entities ( e3 and its neighbor e4) with respect to the redundant entity e1 and retains the couple having the highest topological proximity. All candidates following the application of this lter is the subject of alignment le result.
Alignment Generation : The result of the alignment process provides a set of mappings, which are serialized in the RDF format. 1.2
Clona has implemented a technique for determining alignment candidates across the power of Lucene search engine. In addition, during the translation phase, we have set up a local translator that is built during the alignment process. This treatment reduces the translation time cost and access to the external resource.
Clona is an open source ontology matching system and is available through this link (http://www.mediafire.com/download/f6tacrt82sx316u/CLONA_OAEI_2015.zip ). 2
Our system Clona has been developed with a unique focus on multilingual ontologies the processing, through Multifarm test base. This dataset is composed of a subset of the Conference track, translated in nine dierent languages ( i.e., Chinese, Czech, Dutch, French, German, Portuguese, Russian, Spanish and Arabic). 3
Clona obtained an F-measure average of 43% and this, positions it in the second place among methods of the OAEI 2015 campaign. The translation treatment has been successful, especially with the technique of pivot language that reduces all ontological entities to one language, which is English. In addition, the enrichment with WordNet as an external resource, increased produced alignments accuracy. The evaluation was conducted according to two scenarios, as shown in Table 3. The rst scenario is signicantly better than the second, this is explained by the fact that ontologies share the same structure. Indeed, the structural similarity for ontological entities will be important. These values positioned Clona in the second place compared to OAEI 2015 participant methods. It should be emphasized that in the case Same Ontologies, and over 45 treated language pairs, Clona ranked rst out of 15 couples. This performance is achieved thanks to the Recall values, which reect the accuracy of the obtained alignments even in the cross-lingual context 3.
http://oaei.ontologymatching.org/2015/results/multifarm/index.html
Clona participation in OAEI 2015 was encouraging, as it supplies good Fmeasure values in the two considered scenarios. Results reects some strengths and some positive aspects.