Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to upgrade your browser.

Log In
Sign Up

Figure 37 – uploaded by Mark Musen

See full PDF downloadDownload figure

Table 2. The performance of SOBOM on the anatomy test (834 leaf node alignments). The experiment result shows in Table 2. — Table 2 The performance of SOBOM on the anatomy test (834 leaf node alignments). The experiment result shows in Table 2.

Related Figures (106)

Fig. 1. Applying matching conditions to detect instances of correspondence patterns in order to generate a complex alignment. ~ ~ 4 ~ In the following we will talk about matching conditions and correspondence patterns. A correspondence pattern describes a special type of complex corre- spondence. Suppose, for example, that our algorithms detects a correspondence (dearlyRegistered.{ true}, EarlyRegisteredParticipant, =). This correspondence is a concrete instantiation of the general correspondence pattern (SP.{ true}, C, =), where P and C denote variables. A correspondence pattern can coincide with one of the con- struction rules listed above, but can also be compounded of several rules and might contain constants, as shown in the example.

Table 1. Sets of ontologies that we used in mapping composition and their characteristics.

Table 2. Input mappings that we used for mapping composition for the three sets of ontologies.

Fig. 1. Methods for composing mappings between concepts in three different ontologies (C1 € O1, C2 € O2, C3 € Os) using mappings between preferred labels (P) and synonyms (5). Figure A illustrates the PPP mappings: a composition of a mapping from a preferred name of C; to preferred name of C2 with the mapping between preferred names of C’'z and C3. Figure B illustrates PSP mappings: a match of C1 preferred name to C2 synonym with a match of C2 synonym to C’3 preferred name. Figures C-F illustrate the remaining possible cases. Figure 2A shows the results for the overall precision of composed mappings. Using 575,642 input mappings with precision 0.94, we generated 599,625 composed map-

Fig. 2. Mapping composition results for BioPortal ontologies. O1, Oz2 and Og represent any three ontologies linked through mappings from Bioportal. Figure A (the shaded diagram) shows the overall precision of the input mappings and their number in parentheses on the solid lines. It shows the precision of composed mappings and their number above the dotted line. Figures B, C, and D provide details for the precision of composed mappings, grouped by the precision of input mappings. Figure B contains the mappings that used only Preferred—Synonym mappings as in- put; Figure C contains the mappings that composed Preferred—Preferred mappings; and Figure D provides the data for the composition of Preferred—Preferred mappings and Preferred-Synonym mappings.

Fig. 3. Mapping composition results for BioPortal ontologies. The bar graph shows precision for composed mappings. The (lighter) left bar shows precision of exact and close matches, the (darker) right bar shows the precision if we include broader, narrower, and related matches. Num- bers in parentheses indicate the total number of mappings

Fig. 4. Mapping composition results for cultural heritage domain (Figure A) and OAEI library track (Figure B). The numbers in bold outside the triangle show the precision and the number of composed mappings in parentheses. The numbers inside the triangle show the precision and number of input mappings

Fig. 5. Mapping composition results for cultural heritage and library-track ontologies. The bar graph shows precision for composed mappings. The (lighter) left bar shows precision of exact and close matches, the (darker) right bar shows the precision if we include broader, narrower, and related matches. Numbers in parentheses indicate the total number of mappings

Notion such as polysemy, however, are typically understood to relate terms that have a different, but related meaning, and can thus not be dealt with by simply identifying symbols or keeping them apart.” Similarly, [13] raise the criticism that V-Alignments do not cover the case where a concept Woman in QO, is aligned with a concept Person in Og: here, the merged ontology should turn Woman into a subconcept of Person. Fig. 1. V-alignment: merge through interface (dashed arrows are automatically computed via colimits)

Fig. 2. The number of non-isomorphic matching configurations for k = 2,3 NE ,/ rs oo i” Playing chinese whispers on with k < N players now means to pick a connected subgraph of the hyperontology graph (to ensure that each ontology ‘talks’ to at least one other), which we call a matching configuration . Note that, by assumption, matching configurations contain no loops (i.e. reflexive vertices), are undirected (because of the assumed symmetry of the matching results), and contain at most one edge between two vertices. Therefore, matching configurations are connected simple graphs.

Fig. 3. Modules as subsets vs. modules as image under translation. We continue with introducing a general notion of a module in the sense that a module of an ontology is not restricted to be a subset of the ontology. It is crucial, however, that the module says everything (expressible in its signature) that is said by the ontology itself (i.e. the ontology is required to be a conservative extension of the module)—see Fig. 3 .

Fig. 4. Propagation of modular structure through one matching (a ‘c’ denotes conservativity) We next generalise this result to the case of arbitrary matching configurations.

Fig. 1. Fragments of ontologies o and o’ with alignment A.

Fig. 2. SVAF with str = 1 and fallout-based str: objective consolidation (O) - intersection of objectively acceptable arguments for all audiences, without consistency-checking - and maximal consistent sub-consolidation (5) - consistent subset of objectively acceptable arguments; and individual results for each matcher. Using fallout-based str (Figure 2), we have an opposite behaviour. Argumentation is not able to filter out all inconsistent correspondences. We have low precision and high recall. This occurs because negative arguments are not strong enough for successfully attacking all positive arguments (including the incorrect ones). As a result, many cor- respondences are selected, what increases the probability for selecting inconsistent cor- respondences. When applying consistency checking, S, in average, precision slightly increases, while recall decreases. This effect is due the way the algorithm for removing the inconsistencies works. An incorrect (but consistent) correspondence might cause the removal of all conflicting correspondences with lower confidence, and thus some correct correspondences are filtered out.

with the concept D in the ontology O2, and this mapping has a score confidence Score (between 0 and 1). Our goal here is to determine the potentially common parts of two ontologies. To do that, we use existing tools to align the ontologies we want to compare and then we determine the parts of each ontology where the mappings are concentrated. Indeed, we believe that if two ontologies describe a common sub-domain then the concepts describing this sub-domain in both ontologies should generally be mapped together. We do not try here to improve the quality of the alignment, which is out of the scope of this paper. We suppose that the quality of the produced alignment is pretty good and the mappings it contains could be transformed into the following form: <C, Do, ,Score>, which means that the concept C in the ontology O/ is mapped with the concept D in the ontology O2, and this mapping has a score confidence Score (between 0 and 1). Fig. 1. The decision tree determining the important concepts of two aligned ontologies.

2(c2), we keep only the important concepts 2 and 3 since they are the deepest ones. These concepts should be roots of two different themes described by the ontology. Fig. 2. Possible cases for determining the important concepts.

Fig. 3. Difference of levels of detail and structures between ontologies.

In order to give a sense to the cost returned by the Tree Edit Distance method, we need to normalize it. To do this, we use the normalization formula proposed in [4] (formula (2)), where NC is the normalized cost considered as the distance between the two trees, C is the value returned by the Tree Edit Distance method, and |tree /| and |tree 2| are the respective sizes (number of nodes) of the ordered trees tree/ and tree2. Fig. 4. Example of minimum operation number required to transform a tree into another one.

Fig. 5. Transforming two aligned ontologies into two ordered trees.

Fig. 8 shows that there are some ontology parts that have more similar structures than other ones. For example, the structure of the part of the Buildings and Places ontology whose the root is the important concept Topographic Object is very close to the structure of the part of the Hydrology ontology that has Topographic Object as a root. This is due to the fact that both ontologies are produced by the same institution, so with same conceptualization. The structure of the part of the Buildings and Places ontology whose the root is the important concept Place is, however, different from the structure of the part of the JGN ontology that has Artificial Topographic Feature as a root. In fact, in the metadata associated with Building and Places ontology, it is said that “... The rationale behind the Buildings and Places module is to provide a minimal set of definitions to maximise the abiliuty to reuse. As a result it contains a shallow hierarchy and minimal property restrictions’. This explains the difference in structures between its parts and parts of the JGN ontology which is very structured. Finally, we compared the levels of detail (LD) of our ontologies using the method The next step is the comparison phase. In order to obtain significant results we consider only mappings with a score higher than 0.90. We first computed the distance between the ontology parts structures. The obtained results are shown on Fig. 8.

Fig. 9. Result of the comparison of the ontology parts levels of detail (LD). The results on the Fig. 9 are significant. For example, the Hydrology ontology is more detailed than the JGN ontology regarding the hydrographic features, and this can

Fig. 2. SPARQL query construction for FactForge datasets. It gathers 8 datasets from the LOD cloud - general knowledge (DBPedia, Freebase, UMBEL, CIA World Factbook, MusicBrainz), linguistic knowledge (Wordnet, Lingvoj), geographical knowledge (Geonames). FactForge is the biggest and most heterogeneous body of factual knowledge on which inference has been performed. It comprises an overall of 1.4 billion loaded statements, 2.2 billion stored statements and 10 billion retrievable statements. Fac European research project LarKC [8] reasoning experiments like WebPIE http://factforge.com, offering the fo auto-suggest; (b) one-node-at-a-time data browsers; (c) RDF Search: retrieve ranked list of URIs by keywords; (d SPARQL end-point. One can com tForge is developed as an evaluation case in the and is used as a testbed for different large scale [11]. It is available as a free public service at lowing access facilities: (a) incremental UR exploration through Forest and tabulator linked pose SPARQL queries with predicates from multiple datasets, as shown in figure 2. For example, the query

Fig. 1. Linking Open Data cloud (LOD), [9]. approach for reasoning and management of linked data. A reason-able view (RAV) is an assembly of independent datasets, which can be used as a single body of knowledge with respect to reasoning and query evaluation. FactForge is such a reason-able view of the web of data.

Fig. 3. SPARQL query construction for FactForge datasets in the proposed approach. is why we envisaged a simplified way to access the data by providing an intermediary layer - a single ontology, as shown in figure 3. To do this, we chose to align the separate schemata of FactForge with the upper-level ontology - PROTON (the Base upper-level ontology (BULO)) [14].

Fig. 3. Mapping of concepts in ontologies designed according to different principles (PROTON, DBPedia). model with this respect. To perform the alignment we have adapted the DBPedia model to PROTON’s model in the mapping rule, as shown in figure 3. Technically, the mapping rule looks like this:

Table 1. Statistics of FactForge The outcomes of this work can be summarized as follows: (1) a new layer of unified semantic knowledge over FactForge was created by matching PROTON to FactForge schemata (2) we produced an original approach to providing similar layers to other datasets; (3) and developed a new version of PROTON ontology, which will be used in other projects. The extension of PROTON was governed by two main principles: 1) to provide coverage for the available data; and (2) to reflect the best approaches in the design of ontologies such as OntoClean methodology [5]. Table 1 shows statistics about the datasets of FactForge before and after the matching rules have been added to the semantic repository with full materialization performed. The alignment brought close to 800 million more statements and 50 million new entities available for exploration, while the matching rules cover 554 mapped classes and 103 mapped properties. The biggest number of mapped classes comes from the mapping of PROTON to Geonames’ feature codes (368). As far as PROTON enrichment is concerned, 166 new classes and 73 new properties have been introduced. They cover the classes which were identified during the analysis of the instance data in FactForge and their ontologies as described in section 4.

The adopted method was tested on 27 evaluation different domains, e.g. public administration, mili SPARQL queries selected to cover tary conflicts, art and entertainment, business, medicine and to use multiple datasets from FactForge. Table 2 presents an example of an evaluation query. It is about ci ties around the world which have “Modigliani art works”. This query is considered the ultimate test for the Semantic Web [10]. To our knowledge FactForge is the only engine capable of passing this test. The right column of the table gives the query wri tten with PROTON predicates only. It is simpler and more intuitive than the FactForge standard one as the mapping has put all FactForge location predicates into one P results returned with PROTON query and with ROTON predicate. The number of FactForge standard query are the same, presented in a slightly different way. This proves the validity of the approach.

Fig. 1. Convergence of the PSO algorithm for different population sizes using test case 101 of the OAEI benchmarks. Alignment quality is represented as the fitness of the global best particle, where a smaller value represents better alignment quality.

Fig. 2. Synchronous vs. asynchronous particle updates using 1 and 16 workers with 1 particle per worker. Bars denote an average of 10 runs (individual runs denoted left of the bars). Depicted is the total runtime for an alignment of the mouse ontology from the OAEI anatomy track with itself.

Table 1. Characteristics of test cases (open evaluation is made with already published reference alignments and blind evaluation is made by organizers from reference alignments unknown to the participants). Table 1 summarizes the variation in the results expected from these tests.

Fig. 1. Using OLAP for results visualization. Furthermore, organizers have a tool for accessing the results registered for the cam- paign as well as all evaluations being carried out in the evaluation service (even the evaluation executed for testing purposes). Manipulation of results can be done via an OLAP application (Figure 1).

The list of participants is summarized in Table 2. Similar to previous years not all participants provided results for all tests. They usually did those which are easier to run, such as benchmark, directory and conference. The variety of tests and the short time given to provide results have certainly prevented participants from considering more tests. Table 2. Participants and the state of their submissions. Confidence stands for the type of result returned by a system: it is ticked when the confidence has been measured as non boolean value.

Table 3. Means of results obtained by participants on the benchmark test case (corresponding to harmonic means). The symmetric relaxed measure corresponds to the relaxed precision and recall measures of [4].

While the number of participants is nearly stable over four years, we find in 2010 more systems that participated for the first time (5 systems) than in the previous years (in average 2 systems). See Table 4 for an overview. Four of the newcomers participate also in other tracks, while NBJLM participates only in the Anatomy track. NBJLM is thus together with AgreementMaker (AgrMaker) a system that uses a track-specific pa- rameter setting. Taking part in several tracks with a standard setting makes it obviously much harder to obtain good results in a specific track. Table 4. Overview on anatomy participants from 2007 to 2010, a ,/-symbol indicates that the system participated, + indicates that the system achieved an F-measure > 0.8 in subtask #1.

Table 7. Recall, precision and F-measure for three different confidence thresholds.

In Table 7, there are traditional precision, recall, and F-measure computed for three different thresholds of confidence values (0.2, 0.5, and 0.7).!° Table 8. Confidence threshold, precision and recall for optimal F-measure for each matcher.

F-measures for each threshold of confidence value Fig. 3. F-measures depending on confidence.

Table 9. Approximated precision for 100 best correspondences for each matcher.

Fig. 4. Matching quality results. Precision, recall and F-measure results of the systems are shown in Figure 4. These indicators have been computed following the TaxMe2 [10] methodology, with the help of the Alignment API [5], version 3.4.

Table 10. Summary of submissions by year (no precision was computed in 2005). The Prior line covers Prior+ as well and the OLA line covers OLAg as well. total of 15 systems have participated only one time in the evaluation, 5 systems have participated 3 times (DSSIM, Falcon, Lily, RIMOM and TaxoMap), and only 1 system has participated 4 times (ASMOV).

reasons. The quality of the best F-measure result of 2010 (0.63) achieved by ASMOV is equal to the best F-measure of 2009 by the same system, higher than the best F-measure of 2007 by DSSim (0.49) and than that of 2006 by Falcon (0.43), but still lower than the best F-measure of 2007 (0.71) by OLAg. All three participating systems have achieved the same precision in 2010 (0.61), but this precision is lower than the best values of 2009 (0.62) by kosimap, in 2008 (0.64) by ASMOV and in 2007 by both OLAg and X-SOM. Finally, for what concerns recall, the best result of 2010 achieved by ASMOV (0.65) is equal to the best value of 2009 (0.65) also achieved by ASMOV, higher than the best value of 2008 (0.41) demonstrated by DSSim and the best value in 2006 (0.45) by Falcon, but still lower than the best result obtained in 2007 (0.84) obtained by OLAg. Fig. 6. Comparison of matching quality results in 2006 - 2009.

Fig. 7. Average results of the top-3 systems per year.

Fig. 8. Partition of the system results on positive correspondences. Partitions of positive and negative correspondences, according to the system results, are presented in Figure 8 and Figure 9, respectively. Figure 8 shows that the systems managed to discover only 67% of the total number of positive correspondences (Nobody = 33%). Only 27% of positive correspondences were found by all three participating systems. The percentage of positive correspondences found by the systems this year is slightly lower than the values of 2009, when 68% of the positive correspondences where found [6], but still higher than the values of 2008, when 54% of the positive correspondences where found [3]. Figure 9 shows that more than half (59%) of the negatives correspondences were not found by the systems (correctly) in comparison to 56% not found in 2009). Figure 9 also shows that all participating systems found 16% of the negative correspondences, i.e., mistakenly returned them as positive, in comparison to 17% in 2009. These two observations explain the small increase in precision in Figure 5 and Figure 7. The last two observations also suggest that the discrimination ability of the dataset remains still high as in previous years.

Fig. 9. Partition of the system results on negative correspondences.

Fig. 10. Comparison of partitions of the system results on positive correspondences in 2006 - 2009.

Fig. 11. Comparison of partitions of the system results on negative correspondences in 2006 - 2010.

same real-world entity. With the development of the Linked Data initiative, the grow- ing amount of semantic data published on the Web and the need to discover identity links between instances from different repositories, this problem particularly gained importance in the recent years. Unlike in the other tracks, the instance matching tests specifically focus on ontology ABox. However, the problems which have to be resolved in order to match instances correctly can originate at the schema level (use of different properties and classification schemas) as well as at the data level (e.g., different format of values). This year, the track includes two subtracks. The first subtrack (data inter- inking - DI) aims at testing the performance of tools on large-scale real-world datasets published according to the Linked Data principles. The second one (IMB & PR) rep- resents a set of artificially generated and real test cases respectively. They are designed to illustrate all common cases of discrepancies between individual descriptions (dif- ferent value formats, modified properties, different classification schemas). The list of participants to the Instance Matching track is shown in Table 11. Table 11. Participants in the instance matching track.

Only two systems participated the data interlinking track, probably due to the diffi- culties of matching large collections of data: ObjectCoref and RiMOM. The results of these systems are shown in Figure 12. Fig. 12. Results of the DI subtrack.

1416 individuals. In Figures 13 and 14 we report the results over the large version that are quite similar to the small one. The participation in IIMB was limited to ASMOV, CODI and RiMOM systems. All the systems obtained very good results when dealing with data value transformations and logical transformations, both in terms of precision and in terms of recall. Instead, in case of structural transformations (e.g., property value deletion of addition, property hierarchy modification) and of the combination of different kinds of transformations we have worst results, especially concerning recall. Looking at the results, it seems that the combination of different kinds of heterogeneity in data descriptions is still an open problem for instance matching systems. The three matching systems seems comparable in terms of quality of results.

Fig. 14. Precision/recall of tools participating in the ITMB subtrack.

Fig. 1. AgreementMaker OAEI 2010 matcher stack. AgreementMaker comprises several matching algorithms or matchers that can be used for matching (or aligning) the source and target ontologies. The matchers are not re- stricted to any particular domain. The architecture of AgreementMaker relies on a stack of matchers that belong to three different layers (see Figure 1). Specific configurations of the stack have been used for the benchmarks, anatomy, and conference tracks, as discussed in what follows. However, we describe first the different components in the stack: the matchers, the combination and evaluation modules, and the final alignment module.

AgreementMaker OAEI 2010 matcher stack considers only two ontologies at a time, we compute 120 alignment files, in total containing 2070 individual alignments. The results obtained are summarized in Table 3. Here we show how precision, recall, and F-measure vary depending on the threshold used for the selection of the mappings.

Table 4. Comparison of the results achieved by AgreementMaker in the 2009 and 2010 OAE] benchmarks track. Benchmarks In the OAEI 2009 competition, AgreementMaker was first in terms o the precision of discovered mappings. However, in terms of recall, AgreementMaker was outperformed by six other systems (thirteen systems competed). The new matchers used in the OAEI 2010 competition address specifically the issue of the alignment of concepts that are not lexically similar. The results of this effort increased the recall by 18% at a cost of 3% in precision in comparison with last year’s results. An important contribution to this result comes from the IISM matcher, which exploits instances and structural properties of the ontologies and makes the alignment process less sensitive to lexical differences. A detailed comparison between the results achieved in the 2009 and 2010 competitions in terms of the obtained change in precision, recall, and F-measure for each group of test cases, and the overall H-mean is shown in Table 4.

Table 5. Comparison of the results achieved by AgreementMaker in the 2009 and 2010 OAEI anatomy track. string-based and vector-based matchers. A comparison between the results achieved in the two competitions in terms of precision, recall, and F-measure for Subtrack 1 is shown in Table 5.

Fig. 2. F-measure comparison for the 2009 and 2010 OAEI conference track results. Conference In comparison with the results achieved in OAEI 2009, AgreementMaker significantly improved on precision, recall, and F-measure for thresh- olds above 0.75 as shown in the graph represented of Figure 2.4, providing more stable results. Remarkably, the new matchers used for the conference track, namely ASM and GFM, can be used on real-world ontologies, since they are based on generic lexical and structural features. Moreover, ASM can be easily adapted to different string-based similarity metrics, and can be extended by adopting a lexicon.

Fig. 1. The ASMOV Mapping Process

Table 1. Benchmark test results for ASMOV version 2009 and version 2008

Figure 1. Diagram of BLOOMS architecture. BLOOMS has a sequential architecture composed of three distinct matchers: Exact Match, Partial Match and Semantic Broadcast. While the first two matchers are based on lexical similarity, the final one is based on the propagation of previously calculatec similarities throughout the ontology graph. Figure 1 depicts the the general structure of BLOOMS.

Table 1. Benchmark results Conference Track On the real-world conference dataset CODI achieves very good results since it employs logical reasoning to avoid incoherences. The execution time is between 2 and 4 minutes per test case’. Table 2 summarizes the overall results.

Table 2. Conference results Anatomy Track The results on the anatomy track are also convincing. The results shown in Table 3 are en par with the 2009 results of state-of-the-art matching applica- tions. The F, scores are between 0.79 and 0.73 for all subtasks, even for the two tasks Focus on Precision and Focus on Recall. Thus, our algorithm achieves satisfiable pre- cision and recall values without sacrifices on the F, score. For the last task, where a partial reference alignment was given, we could gain almost 5 % on the F; score. This is because incorporating a partial reference alignment in our system is straight-forward. The reference alignment becomes a direct part of the optimization problem, enforcing good correspondences while ruling out contradicting ones. However, since our algo- rithm uses logical reasoning and has to solve an NP-hard optimization problem, the execution times are quite high’.

? All experiments are executed on a Desktop PC with 2 GB RAM and a Intel Core2 Duo 2.4 GHz processor. 3 This forces us to submit the solutions without the seals platform because of a timeout after 45 minutes. Table 3. Anatomy results

Table 4. IIMB results PR Track For this track consisting of small files about persons and restaurants, we used a simple one to one alignment only based on lexical similarity scores since no significant structural information is available. Thus, the runtime was with less than 5 seconds per test case very short. The results of the CODI system are depicted in Table 5.

Table 5. PR results

Anchor Generation In the Anchor Generation stage, matching entities are identified ising an exact string matching technique. Local names and labels of entities e2; in the arget ontology are first preprocessed through camel case conversion, case-normalization and removal of delimiters. A hash-table is then used to map the preprocessed local 1ames and labels to their corresponding entities. After that, we preprocess the local 1ame and label for each entity el; in the source ontology and look them up in the 1ash-table. If either a matching local name or label can be found in the hash-table, we consider the corresponding entity e2,; in the target ontology to be equivalent to the source entity. This method is significantly faster than a pairwise comparison of local ames and labels as it takes only O(n,) + O(n2) time compared to the latter which equires O(n, X nz) where n, and ng are the number of entities in the source ontology O, and target ontology O2 respectively.

Fig. 2. Anchor Expansion Flow Chart Iterative Boosting In the final stage of the matching process, an iterative boosting (Iter- Boost) process is used to identify more pairs of equivalent concepts using the expanded anchor set A;,,. In this stage, the algorithm attempts to match the source concepts that have not been matched with their candidates iteratively. In each iteration, the source concepts are ranked based on the sum of their ancestors and descendants with matches in Acy». The top K source concepts are then selected and a formula is used to boost the score of their candidates based on the number of common ancestors and descendants that they share. Given a source concept C’'l; and a candidate concept C'2;, the structural overlap SO(C1,,C2,;) between them is calculated using:

Table 1. Results for benchmark dataset

Table 3. Results for conference dataset

Fig. 1. Self-training process source. ObjectCoref and Falcon-AO together help better enable interoperability be- tween applications that use heterogeneous Semantic Web data.

Table 1. Property discriminability on the DI track With these discriminant property pairs, ObjectCoref finds a number of coreferent URIs for each pair of datasets. As shown in Table 2, the precision and recall is moderate. Without considering the type of each object, the precision is not very good, so furthet inference-based debugging on coreferent URIs is needed for future work.

Table 2. Performance of ObjectCoref on the DI track

Table 3. Property discriminability on the PR track

Table 4. Performance of ObjectCoref on the PR track

Table 5. Performance of Falcon-AO (2010) on the benchmark and conference tracks

The role matcher is a special matcher which compares the roles of model elements in our generic role-based metamodel. In principle, this results in matching only elements of the same type, e.g., classes with classes only and properties with properties only. On a technical level, we implemented a command line interface for the match- ing component, as the matching component is normally used from within the GUI of GeRoMeSuite. The command line interface can work in a batch mode in which several matching tasks and configurations can be processed and compared. The existence of this tool enabled also an easy integration with the OAEI web service interface.

A first check, whether a match configuration is suitable at all are the 1xx ontologies. A configuration should produce the perfect result for these tracks, which is the case for the configuration, we have finally chosen.

Fig. 1. Procedure of the matching of heterogeneous ontologies.

Fig. 2. Get the optimal Synsets to describe the concept of a phrase

Fig. 4. Parallelization of the algorithm implemented by multi-threads

component layer. In the interface layer, RIMOM provides a graphical user interface tc 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. 1.2 Specific techniques used

2.2 DI track of IM@OAEI2010 There are 111 alignment tasks 1 n benchmark data set; we divide these tasks into three groups: Ixx, 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 ast 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 Fl-measure is almost the same as last year. Overall, the precision, recall and Fl-measure for the entire benchmark data set of RIMOM thi Fl-measure of 91%. Compared wit precision, 2% improvement on reca s year achieve 99% precision, 84% recall and an h last year’s result, there are 6% improvement on 1 and 4% improvement on Fl-measure.

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.

Table 3. The result of DailyMed dataset

PR track consists of three subtasks; the results for these tasks are shown in Table 5. It can be observed that RiIMOM 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. 2.5 VLCR track

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. 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.

Fig. 1. Two views of an ontology in SOBOM For simplicity, we define some notations used in the report.

Table 1. The performance on the benchmark references. SOBOM can only find equivalence alignment relations.

Table 1. Mapping results for the three different methods on 28 French terms. A trans- lation is found if an expression is returned. The expressions are evaluated manually. The CUIs are concepts in UMLS found by string matching, and the NCI terms are linked to CUIs. The correctness of the NCI terms is checked manually.

Fig. 1. The process of identifying modules using mappings between ontologies. A: mappings between a source ontology and a modularization target. B: two clusters returned by clustering the mappings. One cluster is light gray in color while the other is dark gray. When determining a module based on these clusters, we discard the light gray cluster since the mapping targets within that cluster are too sparse. C: the process of pruning the ontology subtree for the remaining cluster, which we use to create the module. We begin at each leaf and traverse the tree toward the root, removing all classes that are not mapping targets or direct children of mapping targets. Once we reach such a class, we stop pruning along that branch. D: the final module. evaluation in general: how do we know that an ontology is useful for a specific class of applications? We plan to submit the modules that we have identified to BioPortal to enable the user community to use the modules in their applications, review them and comment on them. However, our initial evidence, which we present in this paper, indicates that our approach can indeed find interesting domain-specific modules.

References

1. Francopoulo, G., Monte George, Nicoletta Calzolari, Monica Monachini, Nuria Bel, Mand Pet, Claudia Soria: LMF for multilingual, specialized lexicons. In: LREC, Genova, Italy (2006)

Fig. 1. The ontology alignment process Ontology Alignment Framework.To perform the matching between concepts in different ontologies, we focus both on syntactical and text in entity descrip- tions and also their semantic structure in the ontology representations. This process, illustrated in the block diagram shown in Figure 1, is divided into two main sub-tasks: Alignment and SKOS translation. The inputs are two ontologies and result of the process is an SKOS-based ontology that contains automatically defined associations. The alignment task analyses lexical and structural attributes of ontologies to automatically produce associations between concepts. The re- lation is defined: R(A,B) =< A,B, Relation,S(A,B) > where A and B are ontology concepts, Relation describe semantic relations between these concepts which have five types: equal beIncluded, include, disjoint, related, and S(A, B) is similarity measure for two concepts based on their structure and lexical analysis.

Fig. 2. Snapshot of the specified properties in the integrated ontology

Table 1. Comparison of BLOOMS and PnP BLOOMS on French ontologies of the Benchmark track of OAEI 2009.

Fig. 1. Proposed network architecture and Results

Fig. 1. Domain Ontology built starting from LO; and LO2.

Related topics:

Automated reasoning

Connect with 287M+ leading minds in your field

Discover breakthrough research and expand your academic network

Explore
Papers
Topics

Features
Mentions
Analytics
PDF Packages
Advanced Search
Search Alerts

Journals
Academia.edu Journals
My submissions
Reviewer Hub
Why publish with us
Testimonials

Company
About
Careers
Press
Help Center
Terms
Privacy
Copyright
Content Policy

580 California St., Suite 400

San Francisco, CA, 94104

© 2025 Academia. All rights reserved