This paper proposes an ontology mapping based framerowk that allows searching for web resources using multiple ontologies. The proposed solution uses a mapping ontology that is a part of a recent Semantic Web initiative called the Simple Knowledge Organization System (SKOS). On top of that, we propose the search algorithm that takes arguments from one ontology and generates queries compliant with other ontologies. We evaluated the solution on a web application that allows using a local ontology, which describes content of a web site, to search for web resources in remote digital libraries or object repositories based on more general content ontologies.
In a past few years large collections of web resources
became available either through the digital libraries (such as
ACM Portal), community-based object repositories, or
more importantly as widely dispersed web resources in
many individual institutions. Several interoperability
initiatives are trying to address the issue of searching across
multiple object collections. However, the effectiveness of
searching is hampered by the fact that individual web
resources are typically not interconnected into the web and
therefore lacking the context which makes the Google’s
PageRank algorithm [
Copyright 2005
However, one can hardly find two different object
repositories relaying on the same classification.
Furthermore, the previous research showed that community
members have real difficulty of making annotations of their
objects using subject taxonomies [
In order to address this problem here we propose the use of
ontology mappings to define relations between concepts
from different ontologies [
Although the present semantic web research try to improve most of interoperability issues, some problems still exist.
Web resource metadata and domain ontologies (i.e.
taxonomies) are often defined at different ontological
levels. In order to underpin this statement let us consider an
example of combining Dublin Core (DC) metadata schema
[
Legend:
instance of
mri – mapping relation
that are defined as classes in an RDF Schema, we annotate
the metadata (i.e. schema instances) with ontology classes
(i.e. schema). Those keywords are listed in the subject
element of the DC metadata schema. Since ontology
languages do not have a strict separation between
ontological levels [
Currently, there are many different domain ontologies
developed for the use on the Web. Very often developers
are not able to reuse existing ontologies, as they were built
for different purposes. For instance, some sources (e.g.
object repositories, digital libraries) where we look for
some web resources are based on different classifications
(e.g. the ACM CCS in the ACM Digital Library [
Here we describe only one way for defining mappings,
although there are many practically used ontology mapping
techniques [
In order to address two problems listed in previous section
our solution uses the Simple Knowledge Organization
System (SKOS) [
concept schemes; · SKOS Extension – containing extensions to the SKOS
Core useful for specialized applications. <rdf:RDF> <skos:ConceptScheme rdf:ID="&acm-ccs;acm-ccs"> <skos:hasTopConcept rdf:resource="&acm-ccs;A" /> <!-- ... --> <skos:hasTopConcept rdf:resource="&acm-ccs;K" /> </skos:ConceptScheme> <!-- ... --> <skos:Concept rdf:ID="&acm-ccs;H.3"> <skos:prefLabel xml:lang="en">Information Storage and Retrieval</skos:prefLabel> <skos:inScheme rdf:resource="&acm-ccs;acm-ccs" /> <skos:broaderGeneric rdf:resource="&acm-ccs;H" /> <skos:narrowerGeneric rdf:resource="&acm-ccs;H.3.1" /> <!-- ... --> <skos:narrowerGeneric rdf:resource="&acm-ccs;H.3.m" /> </skos:Concept> <!-- ... --> <skos:Concept rdf:ID="&acm-ccs;H.3.3">
<skos:prefLabel xml:lang="en">Information Search and Retrieval</skos:prefLabel> <skos:inScheme rdf:resource="acm-ccs" /> <skos:broaderGeneric rdf:resource="&acm-ccs;H.3" /> <skos:narrowerGeneric rdf:resource="&acm-ccs;H.3.3.1" /> <!-- ... --> <skos:narrowerGeneric rdf:resource="&acm-ccs;H.3.3.6" /> </skos:Concept> <!-- ... --> <skos:Concept rdf:ID="&acm-ccs;H.3.3.1"> <skos:prefLabel xml:lang="en">Information
Filtering</skos:prefLabel> <skos:inScheme rdf:resource="&acm-ccs;acm-ccs" /> <skos:broaderGeneric rdf:resource="&acm-ccs;H.3.3" /> </skos:Concept <!-- ... --> </rdf:RDF> <!--IM1.1 - History and motivation for information systems
->H.5.m - Miscellaneous --> <skos:Concept rdf:about="&imc;IM1.1"> <map:minorMatch>
<skos:Concept rdf:about= "&acm-ccs;H.5.m"/> </map:minorMatch> </skos:Concept> <!-- IM1.2 - Information storage and retrieval (IS&R) ->
H.3 - Information storage and retrieval--> <skos:Concept rdf:about="&imc;IM1.2"> <map:exactMatch>
<skos:Concept rdf:about= "&acm-ccs;H.3"/> </map:exactMatch> </skos:Concept> <!--IM1.6 - Search, retrieval, linking, navigation ->
Union of H.3.3 - Information Search and Retrieval
E.2.3 - Linked representations --> <skos:Concept rdf:about="&imc;IM1.6"> <map:majorMatch>
<map:OR about="#OR1"/> </map:majorMatch> </skos:Concept> <map:OR ID="OR1"> <map:memberList rdf:parseType="Collection"> <skos:Concept rdf:about="&acm-ccs;H.3.3"/> <skos:Concept rdf:about="&acm-ccs;E.2.3"/> </map:memberList> </map:OR> a) b)
Figure 2. The use of SKOS: a) An excerpt of the ACM CCS in the XML/RDF format of the SKOS. The classification comprises the 11 top level concepts marked with letters from A to K. Most of the top level concepts are further subdivided into three more levels with numbers being added to their identifiers; b) an excerpt of the mappings between the ACM CCS and another ontology (an Information Management course curriculum ontology) defined in the SKOS Mappings SKOS Core provides a model for expressing the basic exactMatch, majorMatch, minorMatch). Such a rich set of structure and content of concept schemes. Basically, the semantic relations for expressing mapping is useful in SKOS Core defines a set of both RDFS properties and ranking search results to reflect the weight of the mapping. RDFS classes that can be used to express the content and Apart from the properties, the SKOS Mapping has the three structure of a concept scheme (such as Concept, broader, classes for defining: intersection of concepts (the AND narrower, related, subject, isSubjectOf). For example, the class), union of concepts (OR), and negation (NOT). broader property is used to specify that a concept is broader than another one. In order to define subclass/superclass relations we can use the SKOS Extension vocabulary and its properties narrowerGeneric and broaderGeneric that are sub-properties of the narrower and broader properties, respectively. The narrowerGeneric property is semantically equivalent to the rdfs:subClassOf property, and thus has a slight different meaning from the narrower property.
In Figure 2b we show how we have used the SKOS
Mapping to express the mapping between an e-learning
relevant course curriculum ontology and the ACM CCS
ontology. The curriculum ontology captures the
Information Management course [
OR1) of other concepts (e.g. H.3.3 and E.2.3). As mappings
relations are not symmetric [
We use ACM CCS to illustrate the use of SKOS to define
domain ontology. The ACM CCS is probably the most
comprehensive classification in the domain of computer
science [
The SKOS Mapping vocabulary contains a set of properties for specifying mapping relations among concepts from different domain ontologies (broadMatch, narrowMatch,
The substance of having mappings among different ontology-based vocabularies is to enable the use of the ontology A to search web resources annotated with concepts from another ontology B. Accordingly, we dedicate this section to the search algorithm we developed. exactMatch
The algorithm is based on the following presumptions: Input arguments of the search algorithm are concepts of the source ontology; Results of the search algorithm are concepts of the target ontology; Mapping relations among concepts from both source and target ontologies are defined using the SKOS Mappings; For each input argument the search algorithm looks for target ontology concepts that have defined mappings. We call those target ontology concepts – matched concepts. The search algorithm also looks for child concepts of matched concepts.
When ranking search results, different kinds of the SKOS Mappings relations should be taken into account.
The input argument of the initial algorithm is a concept from the source ontology. The algorithm searches for matched concepts in the target ontology based on all types of SKOS mappings relation types. Next, the algorithm looks for child concepts of the matched concepts, but only a predefined number of levels (dmax) below the matched concept in the target ontology (see Figure 3a).
The algorithm creates 5 different lists of matched concepts called clusters (one for each mapping relation type) as well as 5 clusters of child concepts (dmax levels below) of the matched concepts. Finally, the algorithm merges all clusters respecting the order of clusters listed in the cluster-names variable in Figure 4 (NB Figure 4 does not illustrate this algorithm version, but the next one). In fact, the merging is performed by connecting clusters using the union operator. Although the algorithm in a rather simple way searches for the matched concepts in the target ontology as well as ranks the resulting set of matched concepts, it still has some open issues: the resulting concept list is completely discrete structure due to the simple merging; the ranking procedure treats all children of the matched concepts within the same cluster in the same way, so concepts within a cluster are randomly ordered; and searching for child concepts a predefined number (dmax) levels below the matched node can take out of consideration some relevant child concepts.
First, the improved algorithm uses all the children of matched concepts in the target ontology regardless their depth level (see Figure 3b). Second, it uses the weight factor to determine ranks of both matched concepts and their children in the resulting list of concepts. The algorithm calculates the weight factor of a matched concept according to the type of the mapping relation connecting it with the source ontology concepts. The weight factor for each type of mapping relation is predefined (i.e. a constant number) and is subject to change depending on the tree structure of the target ontology (i.e. it can be fine tuned). Note also that referent weight factor is the exactMatch relation, while others (i.e. major, minor, and broad) are calculated relatively to it. That is the reason way that value is also an function search-concept (input-concept, WFEM) cluster-names := {“exactMatch”, “broadMatch”, “exactMatchChildren”, “broadMatchChildren” , “narrowMatch”, “narrowMatchChildren” “majorMatch”, “majorMatchChildren”, “minorMatch”, “minorMatchChildren”}; clusters := create-hash-map(); result := {}; for-each name in cluster-names matched-concepts := get-matched-concepts(name, input-concept); clusters[name] := matched-concepts; end-for-each for-each name in cluster-names for-each concept in clusters[name]
put-in-sorted-list(result, concept, calculate-WF(concept, name)); end-for-each end-for-each return result; end-function input argument of the search algorithm (WFEM). The weight factor for every matched concept child depends on (see Figure 3b): the maximal depth level of the matched (parent) concept; the distance of the child concept from its parent; the weight factor of its parent. Accordingly, the weight factor of the child concept is calculated using the following formula:
WFch = WFp – (WFp / (1 + dlmax)) * dch (1) where: · WFch – weight factor of the child concept; · WFp – weight factor of the matched (parent) concept; · dlmax – maximal depth level of the matched (parent)
concept; · dch – distance of the child concept from the matched
(parent) concept.
Relaying on the aforementioned facts we revise the algorithm. In Figure 4 we show a high level description of the search function (i.e. search-concept) in an informal pseudo-code. The first part of the algorithm is similar to the previous version. The difference is that the clusters are not merged like in the first algorithm, but they are stored to be members of a hash map – a memory structure keeping the track about all clusters. Once all clusters are created, the algorithm puts the concepts from each cluster in the resulting list (result) using the put-in-sorted-list procedure. Concepts in the resulting list are sorted according to their weight factors. Since the same concept
Source ontology
Query argument can be in more then one cluster (e.g. broadMatchChildren and majorMatchChildren), the procedure prevents the repetition of the same concept in the resulting list by using its best weight factor.
Although this variant of the algorithm solves the most the problems we have mentioned for the first one, the algorithm still has some limitations that are referred in detail in the next subsection.
The search algorithm presented in the previous section does not solve the case when mapping is not defined between the query argument and the target ontology (see Figure 5). Although the previous search algorithm variants look for children of matched concepts in the target ontology, it does not expand the query arguments that are parts of the source ontology. In fact, the solution works properly if mapping is defined between the query argument and one or more concepts from the target ontology. However, if there are no mappings defined for the query argument then the query will return an empty resulting list.
To overcome this issue, we additionally improved the search algorithm. The algorithm looks for both child and parent concepts in the source ontology that have defined mappings with concepts of the target ontology when the query argument has no defined mappings. In order to calculate weight factors of result concepts, the algorithm takes into account the fact that the distance between the
Target ontology query arguments and all its child and parent concepts with defined matching relations is not the same. Relaying on that fact we calculate the value of the weight factor (WFi) for exact match (see the previous subsection) for each parent and child concept of the query argument in the source ontology using the following formula:
WFi = WFEM – abs(dlsc – dli) * step (2) where: · WFEM – weight factor of the exact match relation predefined for the case when there is a mapping relation between the query argument and the target ontology; · dlsc – depth level of the query argument; · dli – depth level of a parent/child concept of the query argument that has a mapping relation with the target ontology; · step – predefined value that specifies the impact of the distance between the query argument and its child/parent concept i.
Once we calculate the weight factor for the exact match relation, the weight factors of other mapping relations can be calculated as we have already explained in the previous subsection. In Figure 6 we show the final version of the search algorithm capturing the explanation given in this subsection and employing the search algorithm shown in Figure 4.
We implemented the algorithm using OWLJessKB [
In order to evaluate the search algorithm we developed a
web-based application in the domain of e-learning for an
information management course. The course is based on the
ACM/IEEE computer science curriculum recommendation
[
The number of results is decreased when increasing the number of classifiers in a query. It was completely opposite to expectations as those query arguments are connected with the OR logical operator. The reason for such a behavior is that the ACM DL Advanced Search uses the Verity indexing engine (http://www.verity.com), I1M I.1M .I12M .I31M .I41M .I51M .I61M .I17M .I81M I2M .I12M .I22M .I32M .I42M .I52M I3M .13 .23 .33 .4 4M .14 .42 .34 IM IM IM I3M I IM IM IM which selects only those objects whose weight factors pass over a specific threshold. Since their weight factors depend on the number of classification parameters, the less number of found objects can pass over the threshold The last level of classification is omitted from the queries in the web application. Due to a high number of classification concepts used in queries, the ACM DL Advanced Search can return an empty list of found concepts. The effect is especially stressed when using top level concepts as query arguments. The ACM DL search engine selects only those objects whose weight factors pass over a specific threshold. Increasing the number of classification parameters also increases the threshold and therefore eliminating some of the objects. However, this does not affect the best matching results. concept from the course ontology did not have direct mapping relations with the target ontology, but they just inherited mapping relation from their parents.
Finally, say that we could not rank search results according
to our ranking algorithm in either experiment, since we used
two different digital libraries where we did not have any
control in ranking of the found resources. In order to
evaluate our ranking algorithm we are developing
screenscraping functions of both ACM DL and Merlot web pages
showing search results.
500,000
450,000
400,000
350,000
300,000
250,000
200,000
150,000
100,000
50,000
0
Text keyword
With ACM CCS classes
Full number
multiple ontologies, provided we defined mapping between
the source ontology and any number of target ontologies.
Comparing the search algorithm with other solutions we can
find similarities with the Intelligent Product Information
Search that employs ontology mapping to search for
products using web services of several sellers based on
different product ontologies [
In the future we plan to integrate the developed search
algorithm into the eduSource Communication Layer (ECL)
being developed in our research laboratory as a part of its
federated search engine [
This work was funded by Canada 's LORNET NSERC Research Network. The authors would especially like to thank Bernard Rous and Robert Okajima from the ACM Headquarter Office who provided details about the Advance Search engine of the ACM Digital Library.