This paper presents the results obtained by LPHOM (Linear Program for Holistic Ontology Matching) system in the OAEI 2016 campaign. This is the first participation of our system in the OAEI campaigns. It has participated in four tracks (Benchmark, Anatomy, Conference, and Multifarm). We report here a general discussion on the results and on the future improvements. Presentation of the system LPHOM (Linear Program for Holistic Ontology Matching) is a holistic ontology matching system [2], participating for the first time in the OAEI campaign. Altough the system has been designed to deal with holistic ontology matching [3] (i.e., matching multiple ontologies simultaneously), it is able as well to deal with pairwise ontology mathing, as described here. The reader can refer to [2] for a detailed description of the system. LPHOM treats the ontology matching problem, at schema-level, as a combinatorial optimization problem. The problem is modeled through a linear program extending the maximum-weighted graph matching problem with linear constraints (matching cardinality, structural, and coherence constraints). LPHOM follows the execution workflow as depicted in Figure 1. This workflow is composed of four main steps : 1. The first step consists in ontology loading, flattening and translating. After loading the N different ontologies (two ontologies in the case of OAEI) we flatten every ontology entity (classes, object properties and data properties) in a same structure, named Node. As shown in Figure 1, classes, object properties and data properties inherit from Node. The idea behind flattening the ontologies is to simplify the access to all information about each entity, which can be seen near to the structure of document-oriented NoSql databases. But actually, as duplication and treatment are done in memory, pre-processing is not very performant. This step also includes the translation of the labels of entities in case of the non-English ontologies. For that, we have used the Microsoft-translation Java API1. 2. The second step consists of similarity matrices construction. For a set of N ontologies, we compute N (N − 1)/2 similarity matrices representing the average results of different element-level matchers. These matrices are computed between each pair of ontologies and for each type of entity (classes, object properties and data 1 https://www.microsoft.com/en-us/translator/translatorapi.aspx
properties). For OAEI, similarity matrices have been constructed with
characterbased metrics [
The algorithm was developed in Java by the mean of the methods proposed by the Java API of the CPLEX Solver2. For constructing the linear program, we consider only the pairs of correspondences (our decision variables), which similarity measure is higher than 0.65 (this threshold is equals to 0 for the Multifarm track). We highlight also that the used threshold is the same for each type of entity (classes, object properties and data properties). 4. The fourth step consists of resolving the linear program using the CPLEX solver.
The solution represents the set of final correspondences, which will be flushed to the RDF file (output alignments). 2 http://www.ibm.com/support/knowledgecenter/SSSA5P_12.6.2/ilog. odms.cplex.help/refjavacplex/html/index.html
LPHOM is actually not an open-source system. This system is in its beta version and several improvements and refactoring have to be implemented to LPHOM before opening its source code. However, it can be dowloaded at https://drive.google. com/drive/folders/0B5j4YFThSEQkTWxKRzRMWFlVQ2M, together with the instructions on how to install all the dependencies (in particular CPLEX solver). 3
The reader can refer to the OAEI web pages3 for the results of LPHOM in the tasks Anatomy, Benchmark, Conference and Multifarm. In the following, we provide a complementary discussion on these results.
It is important to note that some results on the Conference and Anatomy tracks have
been reported in [
First, we can observe that our tool is quite slow to perform the Anatomy track, and
takes about 26 min (the faster system took 20 seconds). The non-scalability of our tool
is closely dependant on the non-optimised pre-processing steps (in particular, first and
second ones) in the execution workflow (Figure 1). In fact, flattening the structure of
ontologies entails performance problems which also depend on the type of the executed
similarity measure. To illustrate this problem, when using only Jaccard metric, LPHOM
spent about 36 sec to run the Anatomy task (as reported in [
Furthermore, we report that the chosen threshold (0.65) reveals to be very low for this track. That is why we get a higher number of generated alignments, in particular false positive ones.
Finally, we observed that some incoherent results have been obtained for this track.
In fact, the constraints we have proposed in the LPHOM approach [
Megdiche et al.
The organizers of this track faced some problems to execute our package due to the external call of CPLEX. Hence, in the OAEI web pages4 our results were not reported. Locally, we get quite interesting results (Table 2) for the biblio data set of this track.
For the film data set, our system has launched some exceptions when pre-processing the ontologies and no alignments have been generated. 3.3
The whole results of LPHOM for the tasks RA1, RA2, RAR2 are reported in the Conference web page results5.
We discuss in this section the differences between the results of LPHOM for OAEI
2015 (reported in [
We can observe a slight difference between OAEI 2016 and OAEI 2015 results. This is mainly due to the fact that we did not use any semantic measure in the OAEI 2016 version (as reported above, due to some packaging problems).
Furthermore, compared to the results of OAEI 2015, the results of OAEI 2016 are filtered according to a different threshold computed by the organizers (and applied to the final alignments), which gives the better results on F-Measure.
Finally, we stress a very interesting aspect on our results, which concerns conservativity and consistency violation. In OAEI 2016, our approach have no conservativity principle violation nor consistency violation. This was also observed in OAEI 2015 4 http://oaei.ontologymatching.org/2016/ 5 http://oaei.ontologymatching.org/2016/conference/eval.html evaluations. In fact, we have removed ∼ 1 alignment which does not respect consistency violation. These results check the efficiency of the proposed linear constraints. 3.4
For this track, we have used a threshold equals to 0 (when filtering out the correspondences from the similarity matrices), which explains the important number of generated alignments (in average, 84.22 for the tests cases involving matching different ontologies in different languages, and 127.91 for the test cases involving matching same ontologies in different languages).
Although using a basic cross-lingual strategy based on translation, we obtained better results when matching the same ontologies, once our system takes advantage of the structure of the ontologies. However, matching different ontologies in different languages requires an improvement in the translation step and similarity metrics.
Finally, we have encountered problems when translating Chinese language, due to problems when accessing the translation server and its Chinese enconding, what will be corrected in the future version. In fact, the translation worked well on our local machine but did not correctly worked when accesing remotely via the SEALS platform. 4
In the current version of LPHOM, we have been almost focused on modeling and expressing the matching problem through a set of constraints (cardinality, structural, and coherence constraints) applied on similarity matrices. The similarity matrices have been calculated from a set of (few) lexical similarities with a same filtering threshold for most tracks (0.65 for Anatomy, Benchmark and Conference and 0 for Multifarm). However, the choice of similarity metrics or the choice of threshold are also important to success the OAEI tracks. In this regard, we plan to improve the criteria of selection of similarity measures and thresholds for our future participation.
As stated above, LPHOM is a system designed to deal with holistic ontology matching at schema-level. Hence, LPHOM was not able to generated alignments for the tasks involving instance matching (Instance Matching and Process Model tracks). We plan to implement instance matching strategies in future versions of the system.
Finally, our system was not able to deal at all with the large ontologies in the LargeBio and Phenotype tasks. In fact, it consumes a large amount of memory space on the pre-processing steps (first and second steps according to Figure 1), we plan to address these points by in the future.
Megdiche et al.
This paper briefly introduced the LPHOM system and discussed the main points on the results of its first participation in OAEI campaigns. We have as well pointed out some directions for future improvements.