Ontology-based knowledge management systems enable the automatic discovery, sharing and reuse of structured data sources on the semantic web. With the emergence of multilingual ontologies, accessing knowledge across natural language barriers has become a pressing issue for the multilingual semantic web. In this paper, a semantic-oriented cross-lingual ontology mapping (SOCOM) framework is proposed to enhance interoperability of ontology-based systems that involve multilingual knowledge repositories. The contribution of cross-lingual ontology mapping is demonstrated in two use case scenarios. In addition, the notion of appropriate ontology label translation, as employed by the SOCOM framework, is examined in a cross-lingual ontology mapping experiment involving ontologies with a similar domain of interest but labelled in English and Chinese respectively. Preliminary evaluation results indicate the promise of the crosslingual mapping approach used in the SOCOM framework, and suggest that the integrated appropriate ontology label translation mechanism is effective in the facilitation of monolingual matching techniques in cross-lingual ontology mapping scenarios.
The promise of the semantic web is that of a new way to organise,
present and search information that is based on meaning and not
just text. Ontologies are explicit and formal specifications of
conceptualisations of domains of interests [
In this paper, a summary of current CLOM approaches is presented in section 2. A semantic-oriented cross-lingual ontology mapping (SOCOM) framework that aims to facilitate mapping tasks carried out in multilingual environments is proposed and discussed in section 3. To illustrate possible applications of the SOCOM framework on the multilingual semantic web, two use case scenarios including cross-language document retrieval and personalised querying of multilingual knowledge repositories are presented in section 4. An overview of the initial implementation of the proposed framework is given in section 5. Section 6 presents an experiment that engages the integrated framework in a mapping scenario that involves ontologies labelled in English and Chinese, and discusses the evaluation results and findings from this experiment. Finally, work in progress is outlined in section 7.
Current CLOM strategies can be grouped into five categories,
namely manual processing, corpus-based approach,
instancebased approach, linguistic enrichment of ontologies and the
twostep generic approach. A costly manual CLOM process is
documented in [
Trojahn et al. [
Trojahn et al’s framework and RiMOM’s approach both
employ a generic two-step method, where ontology labels are
translated into the target natural language first and monolingual
matching techniques are applied next. The translation process
occurs in isolation of the mapping activity, and takes place
independently of the semantics in the concerned ontologies. As a
result, inadequate and/or synonymic translations can introduce
“noise” into the subsequent matching step, where matches may be
neglected by matching techniques that (solely) rely on the
discovery of lexical similarities. This conception is further
examined in [
Notable work in the field of (semi-)automatic ontology label
translation conducted by Espinoza et al. [
Given ontologies O1 and O2 (see Figure 1) that are labelled in different natural languages, O1 is first transformed by the SOCOM framework into an equivalent of itself through the ontology rendering process as O1'. O1' contains all the original semantics of O1 but is labelled in the natural language that is used by O2. O1' is then matched to O2 using monolingual matchers to generate candidate matches, which are then reviewed by the matching assessment mechanism in order to establish the final mappings.
Ontology renditions are achieved by structuring the translated
ontology labels in the same way as the original ontology O1, and
assigning these translation labels to new namespaces to create
well-formed resource URIs in O1' (for more details, please see
[
The semantics defined in O1 can indicate the context that a tobe-translated label is used in. Given a certain position of the node with this label, the labels of its surrounding nodes (referred to as surrounding semantics in this paper) can be retrieved and studied. For example, for a class node, its surrounding semantics can be represented by the labels of its super/sub/sibling-classes. For a property node, its surrounding semantics can be represented by the labels of the resources which this property restricts. For an individual, the surrounding semantics can be characterised by the label of the class it belongs to. Depending on the granularity of the given ontologies in a mapping scenario, an ontological resource’s surrounding semantics should be modelled with flexibility. For example, if the ontologies are rich in structure, immediate surrounding resource labels (e.g. direct super/sub relations) alone can form the content of the surrounding semantics. If the ontologies are rich in instance, where the immediate surrounding label (e.g. the class an instance belongs to) alone is weak to provide the instance’s context of use, indirect (e.g. all super/sub classes declared in the ontology) resource labels should be included in the surrounding semantics. The goal of obtaining surrounding semantics of a given resource is to provide the translation selection process with additional indications of the context a resource is used in7.
As O1 is transformed so that it can be best mapped to O2, the
semantics defined in O2 therefore can act as broad translation
selection rules. When several translation candidates are all
linguistically correct for a label in O1, the most appropriate
translation is the one that is most semantically similar to what is
used in O2. An example of appropriate ontology label translation
is shown in Figure 2, where the source ontology is labelled in
Chinese and is mapped to an English target ontology. The class 摘
要 from the source ontology has translation candidates abstract
and summary. To determine the most appropriate translation, the
defined semantics of the target ontology can influence the
translation selection process. To understand how this is possible,
consider three scenarios. Figure 2a demonstrates a situation where
a class named Summary exists in the target ontology. In this case,
Summary would be considered as more appropriate than abstract
since it is the exact label used by the target ontology. Figure 2b
illustrates another scenario where the target ontology contains a
class named Sum. From a thesaurus or a dictionary, one can learn
that Sum is a synonym of summary, therefore, instead of using
either abstract or summary, Sum will be chosen as the appropriate
translation in this case. Figure 2c shows a third scenario where
both Abstract and Summary exist in the target ontology, the
appropriate translation is then concluded by studying the
surrounding semantics. The source class 摘要 has a super-class 出
版物 (with translation candidates publication and printing), two
sibling-classes 章 节 (with translation candidates chapter and
section) and 书 籍 (with translation candidates book and
literature). Its surrounding semantics therefore include:
{publication, printing, chapter, section, book, literature}.
Similarly, in the target ontology, the surrounding semantics of the
7 The generation of surrounding semantics presented in this paper
does not attempt to estimate the semantic relatedness between
concepts, it is a procedure performed within readily defined
ontologies in a cross-lingual ontology mapping scenario that
aims to gather the context of use for a particular resource in the
given ontologies. Though one might assume that the SOCOM
framework would work best when ontologies with similar
granularity are presented, this however, is not a requirement of
the framework. As already mentioned, the surrounding
semantics are modelled with flexibility, where indirectly related
concepts in the ontology would be collected as long as the
surrounding well illustrates the context of use for a particular
ontological resource.
class Summary contains: {BookChapter, Reference}, and the
surrounding semantics of the class Abstract would include:
{Mathematics, Applied}. Using string comparison techniques, one
can determine that the strings in the surroundings of the target
class Summary are more similar to those of the source class.
Summary therefore would be the appropriate translation in such a
case. Note that the SOCOM framework is concerned with
searching for appropriate translations (from a mapping point of
view) but not necessarily the most linguistically correct
translations (from a natural language processing point of view),
because our motivation for translating ontology labels is so that
the ontologies can be best mapped8. This should not be confused
with translating labels for the purpose of ontology localisation,
where labels of an ontology are translated so that it is “adapted to
a particular language and culture” [
Once O1' is generated, various monolingual matching techniques can be applied to create matches between O1' and O2. The selection of these monolingual matchers depends on the feedback generated from the mapping result assessment. Assessment feedback can be implicit (i.e. pseudo feedback) or explicit. Pseudo feedback is obtained automatically, where the system assumes matches that meet certain criteria are correct. For example, “correct” results may be assumed to be the ones that have confidence levels of at least 0.5. The precision of the matches generated can then be calculated for each matching algorithm used, which will allow the ranking of these algorithms. The ranking of the MT sources can also be determined upon establishment of the usage of each MT source (i.e. as percentages) among the “correct” matches. Based on these rankings, the top performing MT tools and matching algorithms can then be selected for the future executions of the SOCOM framework. Explicit feedback is generated from users and is more reliable than pseudo feedback, which can aid the mapping process in the same way as discussed above.
Matching assessment feedback allows insights into how the
correct mappings are generated, in particular, which translation
tool(s) and matching algorithm(s) are most suitable in the
specified CLOM scenario. Such feedback in turn could influence
the future selection of appropriate label translations and the
monolingual matching techniques to use. Finally, the feedback
should be influenced by the selection rationale employed during
the translation selection process and the monolingual matching
process. Such rationale can be captured as metadata as part of the
mapping process and include information such as the influence
sources used, translation tools used, monolingual matching
techniques used, similarity measures of semantic surroundings
and so on. The use of matching assessment feedback addresses
one of the scalability issues that arise. Consider a mapping
scenario where the concerned ontologies contain thousands of
entities, one way to rapidly generate mapping results and improve
mapping quality dynamically is to use the pseudo feedback. For
the first, e.g. 100 mapping tasks, assume the ones that satisfy
certain criteria are correct, detect how they are generated, and
keep using the same techniques for the remaining mapping tasks.
This assessment process can also be recursive where the system is
adjusted for every few mapping tasks. Finally, explicit feedback
involves users in the mapping process, which contributes towards
addressing one of the challenges, namely user involvement in
ontology matching as identified by Shvaiko & Euzenat in [
The notion of using conceptual frameworks such as thesauri and
ontologies in search systems [
User generated content such as forums often contain
discussions on how to solve particular technical problems, and a
large amount of content of this type is written in English.
Consider a scenario illustrated in Figure 3, where the user whose
preferred natural language is Portuguese is searching for help on a
forum site, but the query in Portuguese is returning no satisfactory
results. Let us assume that the user also speaks English as a
second language and would like to receive relevant documents
that are written in English instead. To achieve this, domain
ontologies in Portuguese and English can be extracted based on
text presented in the documents using such as Alani et al.’s
approach [
Personalisation can also be enhanced with the integration of
the SOCOM framework in scenarios such as the one shown in
Figure 4, where a user is bi/multi-lingual and would like to
receive documents in a restricted knowledge domain in various
natural languages as long as they are relevant. To achieve this,
ontology-based user models9 containing knowledge such as user
interests and language preferences can be generated pre-runtime
using approaches such as [
SOCOM framework. At run time, a user query is transformed to be associated with a concept or concepts in the user model. By looking up in the mapping triplestore, the matched concepts in various knowledge repositories (the German and the Spanish knowledge repositories in the case of Figure 4) can be obtained, which will then lead to the retrieval of relevant documents in different natural languages.
To examine the soundness of the appropriate ontology label translation selection process proposed in the SOCOM framework, an initial implementation of the proposal has been completed that uses just the semantics within the given ontologies in a CLOM scenario. This light-weight translation selection process (i.e. one that includes semantics in O1 and semantics in O2, but excludes the six other influence sources as shown in Figure 1) is the focus of the implementation and the evaluation presented in this paper.
This initial SOCOM implementation integrates the Jena 2.5.5 Framework10 to parse the formally defined input ontologies. To collect candidate translations for ontology labels in O1, the GoogleTranslate11 0.5 API and the WindowsLive12 translator are used 13 . Synonyms of ontology labels in O2 are generated by querying WordNet14 2.0 via the RiTa15 API. Ontology labels are often concatenated to create well-formed URIs (as white spaces are not allowed), e.g. a concept associate professor can be labelled as AssociateProfessor in the ontology. As the integrated MT tools cannot process such concatenated labels, they are split into sequences of their constituent words before being passed to the MT tools. This is achieved by recognising concatenation patterns. In the previous example, white spaces are inserted before each capital letter found other than the first one. The candidate 10 http://jena.sourceforge.net 11 http://code.google.com/p/google-api-translate-java 12 http://www.windowslivetranslator.com/Default.aspx 13 One could use a dictionary/thesaurus here, however, as the appropriate ontology label translation selection process in the SOCOM framework is not a word sense disambiguation mechanism (see section 3), off-the-self MT tools are efficient to collect candidate translations. 14 http://wordnet.princeton.edu 15 http://www.rednoise.org/rita translations are stored in a translation repository, whereas the synonyms are stored in a lexicon repository. Both repositories are stored in the eXist16 1.0rc database.
The appropriate translation selection process invokes the
repositories in the database via the XML:DB 17 1.0 API, to
compare each candidate translation of a given source label to what
is stored in the lexicon repository. An overview of this appropriate
translation selection process can be seen in Figure 5. If a
one-toone match (note that the match found in the lexicon repository can
be either a target label used in O2, or a synonym of a target label
that is used in O2) is found, the (matched target label or the
matched synonym’s corresponding) target label is selected as the
appropriate translation. If one-to-many matches (i.e. when several
target labels and/or synonyms in the lexicon repository are
matched) are found, the surrounding semantics (see section 3) of
the matched target labels are collected and compared to the
surrounding semantics of the source label in question. Using a
space/case-insensitive edit distance string comparison algorithm
based on Nerbonne et al.’s method [
Figure 5. Overview of the Appropriate Ontology Label
Translation Selection Process
Once appropriate translations are identified for each label in O1, given the original source ontology structure, O1' is generated using the Jena Framework. Finally, O1' is matched to O2 to generate candidate matches via the Alignment API20 version 3.6.
To evaluate the effectiveness of the integrated appropriate translation selection process, this initial implementation of the SOCOM framework is engaged in a CLOM experiment that 16 http://exist.sourceforge.net 17 http://xmldb-org.sourceforge.net/index.html 18 http://www.wikipedia.org 19 http://developer.yahoo.com/search/content/V1/
termExtraction.html
20 http://alignapi.gforge.inria.fr
involves ontologies labelled in Chinese and English describing
the research community domain, against a baseline system – the
generic approach, where labels are translated in isolation using
just the GoogleTranslate 0.5 API and matches are generated using
the Alignment API 21 version 3.6 (see [
Figure 6 gives an overview of the experiment. A Chinese ontology CSWRC 22 is created manually by a group of domain experts (excluding the authors of this paper) based on the English SWRC23 ontology. It contains 54 classes, 44 object properties and 30 data type properties. This Chinese ontology is matched to the English ISWC 24 ontology (containing 33 classes, 18 object properties, 17 data type properties and 50 instances) using the generic approach and the SOCOM approach, generating results M-G and M-S respectively. As the CSWRC ontology is formally and semantically equivalent (with the same structured concepts but labelled in Chinese) to the SWRC ontology, a reliable set of gold standard (referred to as Std. in Figure 6) can be generated as matches found between the SWRC ontology and the ISWC ontology using the Alignment API25. By comparing results M-G and M-S to Std., this experimental design aims to find out which approach can generate higher quality matching results, when the concerned ontologies hold distinct natural languages and varied structures.
Precision and recall26 scores of M-G and M-S are calculated, see Figure 7, where a match is considered correct as long as the identified pair of corresponding resources is included in the gold standard Std., regardless of its confidence level. 21 The Alignment API 3.6 contains eight matching algorithms, namely NameAndPropertyAlignment, StructSubsDistAlignment, ClassStructAlignment, NameEqAlignment, SMOANameAlignment, SubsDistNameAlignment, EditDistNameAlignment and StringDistAlignment. For each correspondence found, a matching relationship is given and is accompanied by a confidence measure that range between 0 (not confident) and 1 (confident). 22 http://www.scss.tcd.ie/~bofu/SOCOMExperimentJuly2009/
Ontologies/CSWRC.owl 23 http://ontoware.org/frs/download.php/298/swrc_v0.3.owl 24 http://annotation.semanticweb.org/iswc/iswc.owl 25 Based on the assumption that the CSWRC ontology is equivalent to the SWRC ontology, this experimental design aims to validate whether matches generated using the exact same matching algorithms would result the same or highly similar corresponding concepts. 26 Given a gold standard with R number of matching results, and an evaluation set containing X number of results, if N number of them are correct based on the gold standard, then for this evaluation set precision = N/X, recall = N/R and f-meaure = 2/(1/precision + 1/recall).
Precision 1.00 0.75 GGeenneerriicc AAvpgp.ro=a0c.h5914
SSOOCCOOMM AAvpgp.ro=a0c.h6100 1 2 3 4 5
6 7 8
Algorithm Matching Results (a) Precision (b) Recall
Figure 7a shows that except the NameEqAlignment and the StringDistAlignment algorithm, all other matching methods indicate equal or higher precision when using the SOCOM approach. The aforementioned two algorithms employ strict string comparison techniques, where no dissimilarity between two labels is overlooked. Though this is a desirable characteristic at times, in this particular experiment setting, some matches are neglected in Std.. E.g. when using the StringDistAlignment algorithm, the gold standard was unable to establish a match between the class AssociateProfessor (in SWRC) and the class Associate_ Professor (in ISWC) because these labels are not identical, although this would have been a sound match if a human was involved or if preprocessing was undertaken. When the SOCOM approach is used to match CSWRC to ISWC, the most appropriate translation for the class 副教授 (associate professor) in the source ontology was determined as Associate_Professor since this exact English label was used in the target ontology. Consequently, a match with 1.00 confidence level between the two was generated in M-S. However, as this correspondence was not included in Std., such a result is deemed as incorrect. Similar circumstances led to the lower precision scores of the SOCOM approaches in cases that involve the NameEqAlignment and the StringDistAlignment algorithms. Nevertheless, on average, with a precision score at 0.61, the SOCOM approach generated more correct matching results than the generic approach overall. Furthermore, at an average recall score of 0.5067 (see Figure 7b), the SOCOM approach demonstrates that its correct results are always more complete than those generated by the generic approach.
As precision and recall each measures one aspect of the match quality, f-measure scores are calculated to indicate the overall
So far, the confidence levels of matching results have not been taken into account. To include this aspect in the evaluation, confidence means of the correct matches and their standard deviations are calculated. The mean is the average confidence of the correct matches found in a set of matching results, where the higher it is, the better the results. The standard deviation is a measure of dispersion, where the greater it is, the greater the spread in the confidence levels. Higher quality matching results therefore are those with higher means and lower standard deviations. On average, when using the SOCOM framework, the confidence mean is 0.7105. Whereas, a lower mean of 0.6970 is found in the generic approach. The standard deviation when using the SOCOM framework is 0.2134, which is lower than 0.2161 as found in the generic approach. These findings denote that matches generated using the SOCOM approach are of higher quality, because they are not only more confident but also less dispersed.
Moreover, average precision, recall and f-measure scores are collected at various thresholds. These scores are calculated when the conditions a correct result must satisfy adjust, i.e. a matching result is only considered correct when it is included in the gold standard, and it has confidence level of at least 0.25, 0.50, 0.75 or 1.00. An overview of the trends is shown in Figure 8. As the requirement for a correct matching result become stricter, the precision (Figure 8a) and recall (Figure 8b) scores both decline as a result, leading to a similar decreasing trend in the f-measure (Figure 8c) scores. The differences in the recall scores of the two approaches are greater than the differences of their precision scores. This finding suggests that the matches generated using the two approaches may appear similar in their correctness, but the ones generated by the SOCOM approach are more complete. Overall, the SOCOM approach always has higher precision, recall 27 Note that neither precision nor recall alone is a measurement of the overall quality of a set of matching results, as the former is a measure for correctness and the latter is a measure for completeness. One can be sacrificed for the optimisation of the other, for example, when operating in the medical domain, recall may be sacrificed in order to achieve high precision; when merging ontologies, the opposite may be desired. and f-measure scores than the generic approach no matter what the threshold is28. This finding further confirms that the matches generated using the SOCOM approach are of higher quality. 0.25 0.5 0.75
1
Threshold (c) F-Measure Trend
Lastly, one can argue that the differences in the f-measure scores found between the generic and the SOCOM approach are rather small and therefore can be ignored. To validate the difference (if it exists) of the two approaches, paired t-tests are carried out on the f-measure scores collected across various thresholds, and a p-value of 0.001 is found. At a significance level of α=0.05, it can be concluded that the f-measure scores are statistically significant, meaning that the SOCOM approach generated higher quality matches than the generic approach. 28 Dotted lines of the generic and the SOCOM approach shown in Figure 8 are almost parallel to one another, this may be in part a result of the engineering approach deployed in the experiment (i.e. using the same tools in the implementation for both approaches). Further research, however, is needed to confirm the validity of this speculation.
A semantic-oriented framework to cross-lingual ontology mapping is presented and evaluated in this paper. Preliminary evaluation results of an early prototype implementation illustrate the effectiveness of the integrated appropriate ontology label translation mechanism, and denote a promising outlook for applying CLOM techniques in multilingual ontology-based applications. The findings also suggest that a fully implemented SOCOM framework – i.e. one that integrates all the influence factors (discussed in section 2) – would be even more effective in the generation of high quality matches in CLOM scenarios.
The implementation of such a comprehensive SOCOM framework is currently on-going. It is planned to be evaluated using the benchmark datasets from the OAEI 2009 campaign, engaging the proposed framework in the mapping of ontologies that are written in very similar natural languages, namely English and French. In addition, the SOCOM framework is to be embedded in a demonstrator cross-language document retrieval system as part of the Centre for Next Generation Localisation, which involves several Irish academic institutions and a consortium of multi-national industrial partners aiming to develop novel localisation techniques for commercial applications.
This research is partially supported by Science Foundation Ireland (Grant 07/CE/11142) as part of the Centre for Next Generation Localisation (http://www.cngl.ie) at Trinity College Dublin.