This paper presents the results of RiMOM in the Ontology Alignment Evaluation Initiative (OAEI) 2010. We participate in three tracks of the campaign: Benchmark, IM@OAEI2010 (IMEI), and Very Large Crosslingual Resources (VLCR). We first describe the basic alignment process and alignment strategies in RiMOM, and then we present specific techniques used for different tracks. At last we give some comments on our results and discuss some future work on RiMOM.
1.1
Currently, RiMOM is developed with a flexible framework for ontology alignment, where different kinds of alignment strategies can be plugged and configured easily. Fig 1 shows the architecture of RiMOM system.
The whole system consists of three layers: interface layer, task layer and component layer. In the interface layer, RiMOM provides a graphical user interface to allow users to customize the matching procedure: including selecting preferred components, setting the parameters for the system, etc. In semi-automatic ontology matching, user can also get involved in the matching process via the user interface. The task layer stores parameters of the alignment tasks, and controls the execution process of components in the component layer. In component layer, we define five groups of executable components, including preprocessor, matcher, aggregator, postprocessor and evaluator. In each group, there are several instantiated components. For a certain alignment task, user can select appropriate components and execute them in desired sequence.
rrrJsseaeecnpooP IrrrssecepooPPLAOW rrrssecepooP liiitlirayoodngSFm trachoM liitilirayoondgSFm tititrsaceacddnhoEM ttrreacdohoNMW ttrrsaeceacodhoBVM trachoM iirseecaaaenhnngdLBM trreagggoA itreaeeegvghdAW trreagggoA ititsseceeennoghdCW trreagggoA iiiteegodghdSmW trreagggoA ittirIecacdnhngM ltraavuoFPER
G trsssceopoP isscaanunuF llitrseedhohFT ro iton r
Fig 1. Architecture of RiMOM system 1.2
This year we participate in three tracks of the campaign: Benchmark, IM@OAEI2010 (IMEI), and Very Large Crosslingual Resources (VLCR). We describe specific techniques used in different tracks as follows:
For benchmark track, we use three matching strategies:
(
(
(
When combining the results of different matching strategies, we use a different method from which we used in OAEI 2008 and 2009. Instead of aggregating similarity values before extracting final alignment, we first extract alignment based on each individual strategy by threshold filtering method, and then combine alignments of different strategies together. A similarity propagation procedure based on structure information is performed to find more mappings. The similarity propagation procedure is implemented in iteration; in each iteration, the similarity is propagated from already found mappings to the rest candidate mappings, candidate mappings which get high similarity are then added to found mappings; this process is repeated until no more mapping is found. This combination method can generate alignments with very high precision with acceptable recall.
The DI (Data Interlinking) track is designed to test the ontology matching systems’ ability on link generation of LinkedData. There are five datasets, i.e. DailyMed, Diseasome, DrugBank, Sider and LinkedMDB, requested to be matched to related datasets in the LinkedData respectively. These data sets are all comes from the real world data and in relatively larger scale than the generated dataset. We choose four datasets in the domain of medicine to test our algorithm while exclude the linkedMDB dataset. According to our observations on the instance data, we split the information in the instance into six categories: the URL, the Meta Information, the Name, the string type information, the non-string type information and the neighboring information. Among the six categories the Name, which usually comes from the rdfs:label property or other ontology specific property such as foaf:name) is the most distinguishing feature to identify an instance. In addition, the natural language information and the neighboring instances are very useful, too. Thus we propose a vector based method for the DI track. We build two vectors referred to as Name Vector and Virtual Document for each instance. The Name Vector is constructed by accumulating the terms in the Name property values and setting the occurrence of each term as its weight. For Virtual Document, we first collect the terms of the each instance’s descriptions and annotations then fetch the local information of its neighboring instances to construct a comprehensive vector. Because the Virtual Document Space is much larger, we compute the tf-idf value of each term as its weight. The similarity between two instances is calculated as the weighted sum of their similarity (Cosine Distance) on two kinds of vectors respectively. However, this method is infeasible on large scale input because pair-wise comparisons on instances are too costly. Thus we introduce a candidate selection process. Only the instance pairs which are selected as candidate mappings are compared. Generally we use two rules for candidate selection: 1) instances with common terms in their Name Vectors; 2) instances with common top weighted terms in their Virtual Documents. To utilize the functionality, we build inverted index of instances for terms in Name Vector and top weighted terms in the Virtual Document. Consequently our algorithm can generate the candidates very quickly and eliminate the meaningless comparisons between unrelated instances. Several experiment results show that the candidate selection will not eliminate the possible alignments in most of the cases. In the following phase of the algorithm, we may use the Meta Information and non-string type values as restrictions to filter the results according to the instance characteristics. For example, a common one is that those instances whose classes are not matched will be filtered out. At last a threshold is used on similarity for the final result. Totally speaking, this method is a generic and efficient method for instance matching.
Traditionally, information of individuals in an ontology is frequently utilized in supporting of schema matching. Inversely, information of schema is of equal importance in alignment of individuals that are sharing the same ontology structure. Thus, for the Instance Matching Track of this year, we take more about schema information, especially classes and properties, into consideration in aligning individuals.
For Instance Matching, our main idea is that we classify individuals by their classes, complete information of each individual as complete as possible, run matching algorithm for each class respectively, and compute similarity of two candidates based on weight-mean of properties assigned with specified weights. And the algorithm can be generalized as four consecutive phase:
Preprocessing: Read and store the schema information for further use. Build a local schema that connects properties and classes and implement it by learning information of individuals.
Information Complementation: Modify the information of each individual, aiming at making them as complete as possible. We defined some rules for judging the validity of values, as well as for solving the transformations in value, structure and logical. Reclassify individuals by recognizing and comparing properties they carry with those in classes, based on our local schema implemented in the previous phase.
Matching: Given the facts that different properties of individuals play quite different roles, and that every individual has its unique characteristic(s), for each property, we assign it with a specified weight and combine this weight with stringbased similarity value computed under Edit Distance or Vector based algorithm. We assign the weight-mean of properties as the final similarity value.
Spread Similarity: In order to fully utilize the connection of individuals, we apply a similarity-flooding-like algorithm to spread the similarity. 1.3
In order to deal with large scale data sets, we use an inverted index technique to accelerate the speed of locating and reading data. 1.4
The RiMOM System can be found at http://keg.cs.tsinghua.edu.cn/project/RiMOM/ 1.5
http://keg.cs.tsinghua.edu.cn/project/RiMOM/OAEI2010/ are available at 2
As introduced above, RiMOM participates in three tracks in OAEI 2010; we present the results and related analysis below.
There are 111 alignment tasks in benchmark data set; we divide these tasks into three groups: 1xx, 2xx, and 3xx. We compare the results of RiMOM in OAEI 2010 and OAEI 2009 [5] in Table 1. It can be observed that the performance of RiMOM in 1xx task continues to be perfect as last year; as for the 2xx task, the result of this year is better than that of last year, with regard to both precision and recall; the precision of 3xx increases this year, but the recall decreases, while the F1-measure is almost the same as last year. Overall, the precision, recall and F1-measure for the entire benchmark data set of RiMOM this year achieve 99% precision, 84% recall and an F1-measure of 91%. Compared with last year’s result, there are 6% improvement on precision, 2% improvement on recall and 4% improvement on F1-measure.
We generate results for four of five datasets in the track except the LinkedMDB dataset. Since we are requested to mapping each dataset to several related datasets in LinkedData and these datasets not provided in the track, we download these datasets and transfer them into RDF format using Jena. As a result we cannot get some datasets such as STITCH because there is only a SPARQL endpoint for it. We also found there are many duplicate entries in the reference alignment of Sider and the namespace for DBpedia in the reference alignment of Drugbank is not uniform, we adjust these reference files to get the final result of our algorithm. We set the parameter of our algorithm as NameWeight = 0.6 and threshold = 0.55. The result of Sider dataset is shown in Table 2. From the result we can see that according to the different characteristics of the instance file, the results may be very different: some are high in precision and some are high in recall. For those high in recall but low in precision, more careful filter may be added to the algorithm by studying the data. On the other hand, for those low in recall, the threshold may be cut down.
DataSet Precision
Recall F-Measure
DBpedia
The result of DailyMed dataset is shown in Table 3. The result of our algorithm is extremely bad in the LinkedCT dataset. It generates a lot of results (up to 100,000) so that the precision is very low. Because of the dominance of LinkedCT results in the reference, our result in total is not good, too. According to our observation on the reference alignment of LinkedCT, they are automatically generated from the owl:SeeAlso property in the file. After reviewing some of our results, we found that many of our results are reasonable but some of the references are not, we think the reference alignment is not very complete and sound. However, our algorithm cannot generate good results from DBpedia means we need much more improvement on it. The other two datasets with LinkedCT reference, Diseasome and DrugBank are similar in results.
DataSet Precision
Recall F-Measure
The result for IIMB_SMALL and IIMB_LARGE is shown in Table 4. As the number of datasets increases, the text-based information the dataset contains decrease while complex combination of modifications increase, thus the performance of our algorithm decreases since it is anyway fundamentally based on string comparison. We can also see that with the amount of instances grows, the influences brought by the noise increase, which do nothing but harm to effect of our algorithm.
PR track consists of three subtasks; the results for these tasks are shown in Table 5. It can be observed that RiMOM gets perfect performance on the first task; for the second task, RiMOM gets really good recall and the precision is 95.2%; for the last task, the precision and recall both decrease compared to the former two tasks.
The purpose of VLCR task is to match three resources to each other, namely, the Thesaurus of the Netherlands Institute for Sound and Vision (called GTAA), the New York Times subject headings and DBpedia. Each resource consists of lots of instances: 142,000 in GTAA, 12,000 in NYT and 7,500,000 in DBpedia. Table 6 lists the number of the mapping we found.
Due to the lack of information, sometimes it is very difficult to match two instances in NYT and GTAA directly. Since we have mapped the two relatively small instance sets to DBpedia, it is possible to use the map results to get more maps between the two small one. Instances in NYT and GTAA matches to the same instance in DBpedia will be added to the final results.As shown in the table, NYT– DBpedia, GTAA-DBpedia and NYT-GTAA are three subtasks of VLCR task. Indirect matching find 163(rise by 3.7% ) new mappings in NYT-GTAA task.
By far instance matching, especially matching on real world instance is still a very challenging problem. Instance Matching is of great importance for bringing the ontology matching into practical use with its wide range of application scenarios. Instance matching shows its special characteristics compared with the conventional schema matching and the large scale nature of instance matching is a big obstacle to employ the existing methods. A relatively generic and efficient method for instance matching is in great need. The IMEI track of OAEI 2010 provides a good platform to test the instance matching algorithms and this area will attract more attention in the community. 4
In this paper, we present the results of RiMOM in OAEI 2010 Campaign. We participate in three tracks this year, including Benchmark, IMEI, and VLCR. We have presented the architecture of RiMOM system and described specific techniques used in this campaign. In this campaign, we design a new strategy combination method for benchmark tracks, and get better performance than last year. We particularly focus on the instance matching task; propose some new strategies for these tasks. The results illustrates that our system RiMOM can achieve good performance in both schema matching and instance matching tracks.
The work is supported by the National Natural Science Foundation of China (No. 60973102), the National Basic Research Program of China (973 Program) (No. 2007CB310803), the National High-tech R&D Program (No. 2009AA01Z138), it is also supported by IBM SUR joint project.