Towards Mutual Understanding: Rule-Based and Learning ...huang/papers/Thesis-Huang-2007.pdf · Towards Mutual Understanding: Rule-Based and Learning-Based Matching Algorithms for

Towards Mutual Understanding: Rule-Based and Learning-Based

Matching Algorithms for Ontologies

by

Jingshan Huang

Master of EngineeringUniversity of South Carolina, 2004

Bachelor of EngineeringFuzhou University, 2000

————————————————————–

Submitted in Partial Fulfillment of the

Requirements for the Degree of Doctor of Philosophy in the

Department of Computer Science and Engineering

College of Engineering and Information Technology

University of South Carolina

2007

Major Professor Chairman, Examing Committee

Committee Member Committee Member

Committee Member Dean of The Graduate School

Acknowledgments

There are lots of people I would like to thank for a huge variety of reasons.

First, and foremost, I would like to give a very special thanks to my advisor, Profes-

sor Dr. Michael N. Huhns, for his excellent guidance and encouragement throughout

my graduate education at USC. I could not have imagined having a better advisor

and mentor. If not for Dr. Huhns’ high standards of scholarship, intellectual integrity,

continuous funding, and support, as well as his openness and flexibility, I would never

have finished my Ph.D. study. Dr. Huhns has not only supervised my academic ac-

tivities, but also helped in many other ways as well—in particular, the unforgettable

lunch soccer games. I was extremely fortunate to work under Dr. Huhns’ supervision

for five years.

I want to express my deep gratitude to Dr. Marco G. Valtorta, who has been

the PIs for most of my research projects. Thank you for providing me with an

extraordinarily comfortable environment to work in.

Thanks to my committee members, Dr. Larry M. Stephens, Dr. Jose M. Vi-

dal, and Dr. Antonello Monti (external), for managing to read the whole thesis so

thoroughly, and for your good suggestions to make my thesis better.

I am also grateful to all the rest of the academic and support staff of the Depart-

ment of Computer Science and Engineering at USC. Special thanks to Dr. Duncan A.

Buell for his excellent lectures in Analysis of Algorithms, and many valuable sugges-

tions in my graduate study. Also, much respect to my officemates, Jiangbo, Laura,

Benito, Hong, and Hrishi, etc., for putting up with me for five years.

ii

Last, but by no means the least, I am greatly indebted to my family for providing

a loving environment for me. In particular, thanks to my parents, Lei Huang and

Fangpei Lin. They bore me, raised me, supported me, taught me, and loved me.

iii

Abstract

Ontologies are formal, declarative knowledge representation models. They form a

semantic foundation for many domains, such as Web services, E-commerce, service-

oriented computing, and the Semantic Web. As the Semantic Web gains attention

as the next generation of the Web, the importance of ontologies increases accord-

ingly. However, because their designers have different conceptual views of the world,

the resultant ontologies are heterogeneous. The heterogeneity can lead to misunder-

standings, so there is a need for ontologies from different partners to be related and to

reuse, wherever possible, each other’s concepts. The availability of a global ontology

can mitigate the heterogeneity, but it is infeasible, as verified by both theory and

practice; an alternative manual matching process is time-consuming and error-prone,

and cannot scale. Therefore, tools for ontology matching are in great need. However,

performing ontology matching automatically is an extremely difficult task. Much

research has been done on this topic and the suggested approaches can be catego-

rized as either rule-based or learning-based. The former works on ontology schema

information, and the latter considers both schemas and instance data. The approach

described in this thesis makes six assumptions to bound the matching problem, and

explains the assumptions and the bounds they provide. Then, three systems are pre-

sented towards the mutual reconciliation of concepts from different ontologies: (1)

the Puzzle system belongs to the rule-based approach; (2) the SOCCER (Similar On-

tology Concept ClustERing) system is mostly a learning-based solution, integrated

with some rule-based techniques; and (3) the Compatibility Vector system, although

iv

not an ontology-matching algorithm by itself, instead is a means of measuring and

maintaining ontology compatibility, which helps in the mutual understanding of on-

tologies and determines the compatibility of services (or agents) associated with these

ontologies.

v

Contents

Acknowledgments ii

Abstract iv

List of Figures xi

1 Introduction 1

1.1 Definition of an Ontology . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Ontologies vs. Relational Models . . . . . . . . . . . . . . . . . . . . 3

1.3 Inherent Heterogeneity of Ontologies . . . . . . . . . . . . . . . . . . 5

1.4 Research Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 Centralized and Distributed Approaches to Deal with Ontology

Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.2 Running Examples . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.3 Problems with Manual Ontology Matching . . . . . . . . . . . 12

1.5 Challenges in Ontology Matching . . . . . . . . . . . . . . . . . . . . 18

1.6 Hypothesis to Be Evaluated and Thesis Structure . . . . . . . . . . . 20

2 Background 22

2.1 Previous Research in Ontologies . . . . . . . . . . . . . . . . . . . . . 22

2.2 Research in Ontology Schema Matching . . . . . . . . . . . . . . . . . 25

2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.2 Rule-Based Schema Matching . . . . . . . . . . . . . . . . . . 26

vi

2.2.3 Learning-Based Schema Matching . . . . . . . . . . . . . . . . 30

2.2.4 Other Ontology-Matching Algorithms . . . . . . . . . . . . . . 35

2.3 Miscellaneous Research in Ontology Area . . . . . . . . . . . . . . . . 37

3 Overview of the Improved Solution Herein 43

3.1 Assumptions Made . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Constraints in Semantic Matching . . . . . . . . . . . . . . . . . . . . 46

3.3 Three Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Puzzle System 48

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Comparison with Other Rule-Based Algorithms . . . . . . . . . . . . 48

4.3 Details of Puzzle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.1 Top-Level Procedure . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.2 Relocate Function . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.3 Linguistic Matching . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3.4 Contextual Matching . . . . . . . . . . . . . . . . . . . . . . . 56

4.3.5 Domain-Independent Reasoning . . . . . . . . . . . . . . . . . 58

4.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4.1 Four Measures in Ontology Matching . . . . . . . . . . . . . . 63

4.4.2 Experiment Set One . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.3 Experiment Set Two . . . . . . . . . . . . . . . . . . . . . . . 68

5 SOCCER System 71

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

vii

5.2.1 Problems with Rule-Based Algorithms . . . . . . . . . . . . . 72

5.2.2 Problems with Learning-Based Algorithms . . . . . . . . . . . 72

5.2.3 The Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 Related Work in Clustering Algorithms . . . . . . . . . . . . . . . . . 74

5.4 Details of SOCCER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4.1 Phase I: Learn Weights . . . . . . . . . . . . . . . . . . . . . . 76

5.4.2 Phase II: Cluster Concepts . . . . . . . . . . . . . . . . . . . . 82

5.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.5.1 Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . 87

5.5.2 Test Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.5.3 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . 89

6 Compatibility Vector System 93

6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.2 Related Work in Quality of Service . . . . . . . . . . . . . . . . . . . 93

6.3 Example Scenario and Its Solution . . . . . . . . . . . . . . . . . . . 94

6.3.1 A Running Example in E-Business Interaction . . . . . . . . . 94

6.3.2 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4 Details of Compatibility Vector System . . . . . . . . . . . . . . . . . 96

6.4.1 Center Ontology and Concept Distance . . . . . . . . . . . . . 96

6.4.2 Compatibility Vectors . . . . . . . . . . . . . . . . . . . . . . 98

6.4.3 Dynamically Adjusting Vectors . . . . . . . . . . . . . . . . . 100

6.4.4 Utilities of Compatibility Vectors . . . . . . . . . . . . . . . . 106

6.4.5 Features of Compatibility Vectors . . . . . . . . . . . . . . . . 107

6.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

viii

6.5.1 Test Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.5.2 Experiment Set One . . . . . . . . . . . . . . . . . . . . . . . 111

6.5.3 Experiment Set Two . . . . . . . . . . . . . . . . . . . . . . . 112

7 Future Work 114

7.1 Future Work for Three Systems in this Thesis . . . . . . . . . . . . . 114

7.1.1 Puzzle System . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.1.2 SOCCER System . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.1.3 Compatibility Vector System . . . . . . . . . . . . . . . . . . . 115

7.2 Future Work for Other Approaches . . . . . . . . . . . . . . . . . . . 115

8 Conclusion 119

Bibliography 121

ix

List of Figures

1.1 Ontology 1 for Example SOC Application . . . . . . . . . . . . . . . 10

1.2 Ontology 2 for Example SOC Application . . . . . . . . . . . . . . . 11

1.3 Semantic Web Example Scenario . . . . . . . . . . . . . . . . . . . . 12

1.4 Swoogle Search on “professor university” . . . . . . . . . . . . . . . . 13

1.5 akt ontology LITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.6 ita-ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.7 Mid-level-ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.8 Possible Similarities between Ontologies Developed Independently . . 21

4.1 Precision and Recall of Resultant Ontologies (Set One) . . . . . . . . 66

4.2 Merging Convergence Experiment . . . . . . . . . . . . . . . . . . . . 67

4.3 Four Measures of Resultant Ontologies (Set Two) . . . . . . . . . . . 70

5.1 Neural Network Structure . . . . . . . . . . . . . . . . . . . . . . . . 80

5.2 Evolution of Superconcept Number with the Changing of Similarity

Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.3 Weight Learning—setting 1 . . . . . . . . . . . . . . . . . . . . . . . 89

5.4 Weight Learning—setting 2 . . . . . . . . . . . . . . . . . . . . . . . 90

5.5 Clustering Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.1 Graphical Representations for Ontology1 and center1 . . . . . . . . . 97

6.2 Compatibility Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.3 Dynamic Adjustment of Compatibility Vectors . . . . . . . . . . . . . 99

x

6.4 Example of New Vector Generation . . . . . . . . . . . . . . . . . . . 103

6.5 Utility of Compatibility Vectors—Experiment Set One . . . . . . . . 112

6.6 Utility of Compatibility Vectors—Experiment Set Two . . . . . . . . 113

xi

Chapter 1

Introduction

As a formal and declarative knowledge representation model, ontologies are becoming

increasingly important as a foundation for many kinds of Web applications, such as

Web services, E-commerce, and service-oriented computing (SOC). With the Seman-

tic Web gaining attention as the next generation of the Web, the issue of reconciling

different views of independently developed and exposed data sources becomes increas-

ingly critical. An ontology serves as a basis for solving this problem. Also, ontologies

are fundamental to SOC, which is viewed as the computing paradigm of the near fu-

ture, allowing for the dynamic interaction of services provided by distributed business

partners.

1.1 Definition of an Ontology

There are many different definitions for an ontology. In this thesis, the following one

[52] is adopted: “An ontology is a computational model of some portion or domain of

the world. The model describes the semantics of the terms used in the domain. It is

often captured in some form of a semantic network—a graph whose nodes are concepts

or individual objects and whose arcs represent relationships or associations among

the concepts. The network is augmented by properties and attributes, constraints,

functions, and rules, which govern the behavior of the concepts.” The following

1

qualitative formula shows the components of an ontology.

Ontology = Concepts + Relationships + Constraints (1.1)

Concepts are sometimes referred to as classes or, in graphical depictions of on-

tologies, as nodes; these three terms are used interchangeably in this thesis. For

relationships, there are basically two different categories. The first category is the

relationship between a concept and a member from a fixed, common, and shared

set of concepts. This fixed set usually contains special concepts such as “Integer,”

“Double,” and “String.” Because this kind of relationship maps a concept to a data

type, it is often referred to as a “property” or “attribute.” The second category is

the relationship between regular concepts, in contrast with the special concepts men-

tioned above. In the rest of this thesis, “relationship” means this second category,

unless specifically indicated otherwise. This is similar to the distinction made in data

modeling between entity-relationship (ER) models and entity-relationship-attribute

(ERA) models. Constraints provide refinements on and among relationships and the

values of properties. For example, the concept of Automobile might have the rela-

tionship hasParts with the concept Wheel, with the constraint that an Automobile

has exactly four parts that are instances of the Wheel concept.

The meaning of a concept, i.e., the semantics of a concept, is therefore determined

by four aspects: (1) the name of the concept, (2) the properties of the concept, (3) the

relationships of the concept, and (4) some constraints. These four features together

specify a conceptual model for each concept from the viewpoint of an ontology de-

signer. Note that the remainder of this thesis does not consider constraints, because

constraints can be represented as general statements in mathematics or programming

2

languages and thus are difficult to reason about automatically in order to resolve their

heterogeneity, where it occurs.

1.2 Ontologies vs. Relational Models

As a knowledge representation model, ontologies have several advantages over re-

lational models for describing the semantics of a domain. These advantages are

summarized as follows:

• Reasoning independence

In ontologies, a description logic (DL) is adopted as a calculus of meaning

with well-documented logical operators, including not, and, or, all, and some.

For example, (all vehicles have tires) and (all cars are vehicles) implies (all

cars have tires). The conclusion is drawn based on the logical constants alone,

no matter what the contextual non-logical words are (“vehicles,” “tires,” and

“cars” in this case). Therefore, the reasoning process is independent of the

specific knowledge base.

• Indexing separation from knowledge representation

In a relational model, information lookup always depends on a specific index,

and the latter depends in turn on how knowledge representation is built. We

usually either cannot obtain the knowledge from every direction (due to inade-

quate coverage), or pay for the knowledge acquisition by much redundancy. For

example, consider the following two simplified tuples in a database table.

tankCar - superClass : railwayCar

railwayCar - superClass : vehicle

3

A search for “railwayCar” will reveal that “vehicle” is its superclass, but there

is no way to find the classes whose superclass is “railwayCar.” In order to get

that information, we need to add a slot to the table, such as “superClassOf.”

An ontology would represent the information in this example as

(superClass railwayCar tankCar)

(superClass vehicle railwayCar)

By indexing on each argument of these two assertions, it is easy to find whose

superclass is “railwayCar.” Notice that this kind of indexing is separate from

knowledge representation.

• Implicit knowledge preservation

A relational model is equivalent to a frame-and-slot representation. There is no

way to specify the relationships among different slots in the relational model

itself. The only method to make inferences about one slot from others is to

create a piece of code that encodes the relationship wanted. For example, to

add a restriction “if the number of tires of a vehicle is greater than 6, then the

number of cylinders is greater than 4” requires specific instructions in the code.

For ontologies, DL can be used to state the preferred relationships declaratively.

In this sense, the implicit knowledge stays in the knowledge base itself, i.e.,

the ontology, and has nothing to do with specific applications. In the above

example, the following rule is independent of any code, and is able to preserve

the implicit knowledge.

(implies (greaterThan numberOfTires 6) (greaterThan numberOfCylinders 4))

• More reusable knowledge

This feature results from the previous three. No further explanation is necessary.

4

Therefore, ontologies can capture both the structure and semantics of information

environments, especially in environments with heterogeneous semantics. An ontology-

based search engine can handle both simple keyword-based queries as well as complex

queries on structured data [52].

1.3 Inherent Heterogeneity of Ontologies

As discussed above, an ontology tries to describe a conceptualization of some domain.

Considering the fact that anyone can design ontologies according to his/her own con-

ceptual view of the world, ontological heterogeneity among different parties becomes

an inherent characteristic of software applications software applications. The hetero-

geneous semantics occurs in two ways. (1) Different ontologies could use different

terminologies to describe the same conceptual model. That is, different terms could

be used for the same concept, or an identical term could be adopted for different

concepts. (2) Even if two ontologies use the same name for a concept C, the associ-

ated properties and the relationships with other concepts for C are most likely to be

different.

1.4 Research Motivation

1.4.1 Centralized and Distributed Approaches to Deal with

Ontology Heterogeneity

To handle the issue of inherent heterogeneity in ontologies, many approaches have

been proposed. Generally speaking, there are two kinds of solutions.

5

The first solution is a centralized one, that is, to build a central ontology that

is agreed-upon, global, and unique and includes every concept that can satisfy the

needs of different parties. Cyc [16] is an example of a centralized solution. However,

known central ontologies are not large enough to include all concepts of interest to

every individual ontology and application designer. Each need for a new ontology

will have to provide its own particular extensions, which will be different and likely

incompatible with the extensions added by others. For ontologies whose extensions

are in different domains, the reason for the incompatibility is obvious. For ontologies

whose extensions are in the same domain, such a situation still exists. One expla-

nation is that within the same domain different applications might require different

viewpoints. For example, the parts of an engine could be described in many different

ways, e.g., physically, functionally, or spatially. One application might be interested

in such questions as “where does fuel go when it leaves the fuel pump?” and “how

does a change in the pressure produced by the fuel pump affect the flow from the

fuel injector?” while another application might concentrate on questions like “what

is next to the fuel injector?” and “what is connected to the fuel pump?” Obviously,

ontologies for these two applications will look quite different from each other. The

insight behind this phenomenon is that ontologies are merely models of some do-

mains, and these models are constructed by different users with different purposes.

Therefore, the designed models are bound to be different.

Cyc has been under development for more than 22 years, and its inability to

completely solve the problem of heterogeneity in ontologies indicates the difficulty of

the centralized solution. In linguistics, the attempt to produce a universal language,

i.e., Esperanto, failed simply because it could not capture all semantics and cultural

6

differences among different languages. Analogically, a central ontology is not likely

to represent all conceptual models needed by different parties. Briefly, “if there were

a central authority with a global ontology to which all Web components adhered,

and if the components of the Web were static, and if the identity of the components

were fixed, and if there were a small fixed number of component types, then the

challenges of interoperation and understanding would disappear, but the Web would

no longer be the vibrant useful place upon which the global economy and modern

society increasingly rely.” [52]

Because of the current unavailability of the centralized solution, it is natural to

turn to the other solution: a distributed one. Basically, a distributed solution focuses

on the ability for individual ontologies to be matched and reconciled with each other,

and possibly incorporate concepts from each other.

1.4.2 Running Examples

Example 1—Heterogeneous Ontologies in Web Pages

Most Web pages do not have underlying ontologies. In order to enable applications

to operate across different Web sites automatically, the sites must have corresponding

ontologies describing their semantics. The ontologies might still have a wide variety

of forms and semantics, due to the diverse application purposes for the sites. For

example, consider the following first ten sites returned by a Google search on “popu-

lation usa.”

Page 1. http://www.cia.gov/cia/publications/factbook/rankorder/2119rank.html

Page 2. http://www.census.gov/population/www/popclockus.html

Page 3. http://www.census.gov

7

Page 4. http://www.cia.gov/cia/publications/factbook/geos/us.html

Page 5. http://www.prb.org

Page 6. http://www.mapsofworld.com/usa

Page 7. http://usinfo.state.gov/usa/infousa/facts/stats.htm

Page 8. http://www.theodora.com/wfbcurrent/united states/united states people.html

Page 9. http://www.islam101.com/history/population2 usa.html

Page 10. http://www.geohive.com

Because of the different possible purposes for someone initiating the above Google

search, different ontology schema designs can exist.

• Some might be interested in the population of just the US. It is straightforward

to build a concept of “Country,” with “population” as one of its properties or

relationships.

• Some might want to know which country has the largest population, besides the

US population data. Then it is more efficient to have an ontology schema having

the concept of “Population,” with “country” as a property or relationship of

this concept.

• Some might look for the date on which the US population passes 300 million. In

this case, a binary relationship is not sufficient to express the needed semantics.

Instead, a ternary relationship is built to link three concepts, i.e., “Country,”

“Population,” and “Date.”

In addition, even for the same purpose, it is obvious that many variations could

happen in terms of the ontology schema. For example, Web site 3 makes use of “Pop-

ulationClocks” as the concept name, while Web site 5 adopts “PopulationEstimates.”

8

Another example is, although both Web sites 4 and 10 use the same term “Popula-

tion,” the former has many more properties than the latter, including “ageStructure,”

“medianAge,” and “growthRate,” etc.

Example 2—Heterogeneous Ontologies in SOC Applications

Consider an example SOC application: construct an ontology schema for the following

made-up report from an intelligence agency. “CIA Report Date 1 April, 2004 (from

MI5): The British Special Branch arrested suspect XYZ at his residence at 11 St.

Mary’s Place, London. Found in XYZ’s bedroom was a small container holding 8

ounces of pentaerythritol (PETN) and triacetone triperoxide (TATP). This is the

same explosive that a terrorist tried to use on American Airlines flight #63 from

Paris to Miami on 22 December 2001.”

Sixteen graduate students in our department built their own ontologies for this

scenario independently. These ontologies are small and contain only a few concepts,

but many diversities have been found. Two schemas (Figures 1.1 and 1.2) are shown

as the examples. It is not trivial to reconcile those heterogeneous ontologies, although

they are much simpler than typical real-world ones.

Example 3—Heterogeneous Ontologies in the Semantic Web

For the proposed Semantic Web, Web sites will be marked up with meaningful tags

that provide semantics to the contents of the sites. Essentially, the Semantic Web

provides us with machine-understandable data, and therefore makes it possible for

the data on the Web to be processed and shared by automated tools, as well as by

people [6]. Let us look at an example scenario in the Semantic Web (Figure 1.3).

9

Figure 1.1: Ontology 1 for Example SOC Application

Imagine that a prospective student would like to gather some information about

the professors in some universities of interest. He relies on some computer-based

client (agent) in searching such data on different Semantic Web sites. By typing

“professor university” in the Swoogle service [57], 129 different results are returned

(Figure 1.4), all of which are related to the domain of “University” and “Professor,”

and all are created and maintained by ontology professionals. Three pages, along with

their associated ontologies, are taken as an example to show the need for ontology

matching in order to obtain mutual understanding among the different sites.

1. akt ontology LITE (Figure 1.5)

URL: http://www.csd.abdn.ac.uk/ cmckenzi/playpen/rdf/akt ontology LITE.owl

10

Figure 1.2: Ontology 2 for Example SOC Application

2. ita-ontology (Figure 1.6)

URL: http://www.mondeca.com/owl/moses/ita.owl

3. Mid-level-ontology (Figure 1.7)

URL: http://reliant.teknowledge.com/DAML/Mid-level-ontology.owl

From the above three ontologies, we can see that even for a concept of “Profes-

sor,” which is quite standard a term in the domain of “University,” there still exist

many possible variations among different ontologies. For example, different from

the other two ontologies, akt ontology LITE uses “Professor-In-Academia” instead of

“Professor” as the concept name. Another example is, although both ita-ontology

11

Figure 1.3: Semantic Web Example Scenario

and mid-level-ontology adopt “Professor,” the former contains a rich set of subclasses

(eight in total) for this concept, as well as four properties; whereas the latter has

neither subclass nor property available. In order for the student’s agent to make use

of the information on these Web sites, it must be able to reconcile its own ontology

with the ontologies for these sites.

1.4.3 Problems with Manual Ontology Matching

The first attempts at ontology matching were carried out by humans. There are some

critical drawbacks for this manual effort.

First, it is time-consuming. Compared with machines, a human might have more

12

Figure 1.4: Swoogle Search on “professor university”

intelligence to some extent and in some aspects. However, manually matching on-

tologies is tedious work. Without help from computers, it will take a human quite a

long time to match even two ontologies of moderate size, say, 50 concepts and 200

relationships each.

Second, it is error-prone. Although humans have some advantages over computers

in common-sense knowledge and some reasoning mechanisms whose details are not

yet understood, computers do have their own strong points that humans lack. For

example, it is hard or even impractical for a human to remember all concepts already

considered, as well as their properties and relationships, along the ontology-matching

process, especially when dealing with ontologies that are large. Therefore, a manual

13

Figure 1.5: akt ontology LITE

14

Figure 1.6: ita-ontology

15

Figure 1.7: Mid-level-ontology

16

matching result could contain some “careless” errors if there is no auxiliary method

of recording the necessary information for the human.

Third, it has no ability to scale. This disadvantage becomes increasingly obvious

in the current “E-age.” Many millions of pages are now available in the Web, and

the amount of disparate source data has never stopped increasing since the invention

of the Internet. During such an “information explosion” era, the lack of the ability

to scale matching capacity with the ever-growing of information is unimaginable.

Therefore, to develop tools that are either automatic or semiautomatic and can

help people in matching ontologies is of great need and value. This thesis is based on

such motivation, and concentrates on ontology-matching tools, aiming to achieve the

ultimate goal of reconciling heterogeneous ontologies from different sources.

It is worth mentioning that according to a more general classification, ontology

matching consists of two different sub-domains: schema matching and data matching.

The former deals with the schema issue, and tries to match ontology schemas no

matter via ontology schemas (concept names plus properties and relationships) alone,

or the associated data in ontologies, or both. On the contrary, the latter focuses on

problems such as: how to detect duplicate data fragments in different ontologies

(that is, two data items referring to the same real-world object); how to reconcile

inconsistent data values for the same slot; and so on. This thesis concentrates on

schema matching, not data matching; and from this point on, “ontology matching”

refers to “ontology schema matching,” unless specifically indicated otherwise.

17

1.5 Challenges in Ontology Matching

Although ontology matching is very critical to many applications, especially those

using the Web, it is not trivial at all. In fact, this is an extremely challenging prob-

lem for researchers in a lot of domains, such as knowledge representation, artificial

intelligence, information retrieval, and database design, etc.

First, ontology matching is essentially quite subjective.

As mentioned before, ontology heterogeneity results from different and likely incon-

sistent viewpoints about some part of the world. Therefore, for different users, no

matter from the same or different domains, they are bound to have subjective opin-

ions about how to match ontologies, and those opinions are usually different from

each other and have different preferences. Therefore, there is no such gold standard

by which the evaluation of the matching result could be carried out without any bias.

Sometimes we need a group of human beings to work together and decide what the

correct matching should be. In cases where there are conflicting opinions, some sort

of voting is necessary.

Second, there are limited sources to infer the semantics.

When an ontology is available:

• In many cases, only schema information is available. A software application at

most can make use of concept names, concept properties, and concept relation-

ships. Because different ontologies can freely adopt different terminologies, the

clues given by schemas are subject to how these terminologies are similar to

each other.

18

• In some cases, the data associated with ontologies are also available. Suppose

we are provided with enough data, which itself is not always guaranteed, but the

potentially inconsistent data values among different ontologies give rise to the

problem of how to make good use of these data. More frustratingly, sometimes

it is the question of whether or not we can even make use of them. For exam-

ple, a recent Google search for “USA population in 2005” returned more than

10 million hits, with the following example values: 296,226,106; 296,188,835;

297,077,717; 95,734,134; and 17,000 (which is the 2005 population in Mesquite,

Nevada, USA). Even if all these numbers are in the same format, which happens

to be the case here, there is still no obvious way to reconcile these values.

• In rare cases, the design documentation about the ontology of interest might

be obtained. However, these documentations are often of dubious quality and

value. Wrong or outdated documentations will likely mislead the matching

process. Moreover, it is not straightforward to train machines to understand

documentations, even when they are correct and up-to-date.

Third, concepts cannot be considered separately.

Within any ontology, concepts are constrained by relationships with other concepts.

This kind of interdependency in determining the concept semantics makes the match-

ing process rather difficult. Consider the following example where we are trying to

match concept A from ontology1 with concept B from ontology2 to see whether or

not they are equivalent to each other. To make the decision, we might need to ac-

quire knowledge about whether or not the concepts having relationships with A in

ontology1 and the concepts having relationships with B in ontology2 are equivalent

19

to each other. A possible loop is obvious here, e.g., to match A and B, we need to

match A1 and B1, the latter in turn requires to match A2 and B2, and so on. Finally,

to match A and B might end up in requiring the result of matching A and B.

1.6 Hypothesis to Be Evaluated and Thesis Struc-

ture

The hypothesis to be evaluated in this thesis is that ontologies developed indepen-

dently, but for related domains, can be reconciled by using a combination of rule-based

and learning-based matching algorithms. These algorithms can exploit the similarities

that might occur in heterogeneous ontologies, due to the use of common languages or

common structures. For example, as illustrated in Figure 1.8, the ontologies devel-

oped independently by A and B might share similarities because these ontologies are

modeling the same portion of the real world, especially if the developers have used

similar languages or tools. Success in satisfying this hypothesis will yield a better

mutual understanding of heterogeneous semantics among different, and usually dis-

tributed, parties. Moreover, interoperability among autonomous applications would

be increased afterwards.

The rest of this thesis is organized as follows. Chapter 2 introduces the background

research work in ontologies, with the emphasis on ontology-matching algorithms.

Chapter 3 presents an overview of the solution in this thesis to handle the ontological

heterogeneity issue, including the assumptions made. Chapters 4, 5, and 6 describe

Puzzle, SOCCER, and Compatibility Vector system in detail, respectively. Chapter

7 talks about the future work, and finally, Chapter 8 concludes.

20

Figure 1.8: Possible Similarities between Ontologies Developed Independently

21

Chapter 2

Background

First, some papers are introduced regarding the background knowledge of ontologies.

Then the focus is put on the research work in ontology schema matching, and finally

some other research related to ontologies is described briefly.

2.1 Previous Research in Ontologies

D. L. McGuinness et al. [37] present an ontology environment, Chimaera, aiming at

automatically supporting two tasks. First, to merge multiple ontologies; and second,

to diagnose and evolve ontologies. The motivation is based on the following insights.

Ontologies have become central components in many applications including search,

e-commerce, configuration and, arguably, every large Web site. As ontologies be-

come larger, more distributed, and longer lived, the need for ontology creation and

maintenance environments grows.

In [10], D. Calvanese et al. propose a new Description Logic (DL), DL-Lite,

specifically tailored to capture basic ontology languages, while keeping low complex-

ity of reasoning, which means not only computing subsumption between concepts,

and checking satisfiability of the whole knowledge base, but also answering complex

queries over the set of instances maintained in secondary storage. The authors show

that in DL-Lite the usual DL reasoning tasks are polynomial in the size of the TBox,

22

and query answering is polynomial in the size of the ABox. A notable feature of

DL-Lite is to allow for a separation between TBox and ABox reasoning during query

evaluation, and thus takes advantage of the query optimization strategies provided

by current DBMSs.

Based on the interoperation of ontologies, P. Mitra et al. [43] propose a scalable

and easily maintainable approach on the use of ontologies. This approach is to use

rules that cross the semantic gap by creating an articulation or linkage between the

systems involved. Those rules are generated using a semiautomatic articulation tool

with the help of a domain expert, and an easy-to-use graphical interface is provided

to assist the expert in making sure that the system is reliable.

In [51], A. Segev and A. Gal aim at formalizing the inter-relationships between

a manually generated ontology and automatically generated contexts. The authors

provide a formal mathematical framework that delineates the relationship between

contexts and ontologies, and then use the model to define the uncertainty associated

with automatic context extraction from existing documents and provide a ranking

method, which ranks ontology concepts according to their suitability with a given

context.

H. Gagliardi et al. [26] present a method to enrich semantically the tables from

the Web. First, heterogeneous XML documents are extracted from the Web. Then a

thematic data warehouse is built automatically composed of these XML documents.

Finally, through means of tags and values coming from the ontology of the application,

data tables are enriched.

A. Firat et al. [25] describe the coupling of contexts and ontologies for semantic

integration in the ECOIN semantic interoperability framework. Because ontological

23

terms in ECOIN correspond to multiple related meanings in different contexts, each

ontology includes a context model that describes how a generic ontological term can

be modified according to contextual choices to acquire specialized meanings. The

authors claim that this paper is the first to show how ECOIN addresses the case of

“single-ontology with multiple contexts” with an example.

D. Ramachandran et al. [49] present a translation of a large part of the Cyc

ontology into first-order logic. Cyc is the largest existing common-sense knowledge

base whose ontology makes heavy use of higher-order logic constructs such as a context

system, first class predicates, etc. Many of these higher-order constructs are believed

to be keys to Cyc’s ability to represent common-sense knowledge and reason with

it efficiently. The authors discuss the tradeoffs between expressivity and efficiency

in representation and reasoning, they also present some experiment results using

VAMPIRE, SPASS, and the E Theorem Prover on the Cyc KB, after its conversion

to first-order logic. The authors claim that although the use of higher-order logic

is not essential to the representability of common-sense knowledge, it will greatly

improve the efficiency of reasoning.

Based on their insights that in the elicitation and application of ontologies, the

meaning of the ontological knowledge is dependent on the context, P. Leenheer and A.

Moor [32] consider the role of context in ontology elicitation by introducing context

in a concept definition server for ontology representation. A real-world case study is

carried out.

24

2.2 Research in Ontology Schema Matching

2.2.1 Overview

According to the classification in [21], most schema-matching techniques can be di-

vided into two categories: rule-based solution and learning-based solution. The so-

lutions under the first category, rule-based solutions, consider schema information

only. Different algorithms have different methods of specifying a set of rules (usually

domain-independent, although could be designed to include domain features); then

these rules are applied to the available schema information, such as concept names,

properties, data types, relationships, and other constraints, etc, to match schemas

of interest. Different algorithms distinguish from each other by using different spe-

cific rules. However, they usually have the same advantage of relatively fast running

speed. Also, they share the same disadvantage of ignoring the additional information

possibly brought by instance data associated with schemas, when these instance data

are available.

The solutions under the second category, learning-based solutions, consider both

schema information and the associated instance data. Various kinds of machine learn-

ing techniques have been adopted in ontology-matching area. The most common

ones include text content classification, k-nearest neighbor, Naive Bayes, and deci-

sion tree techniques. While taking advantages of extra clues contained in instance

data, learning-based solutions are prone to run a longer time than rule-based solu-

tions do (mostly because of the data training phase). Also, the difficulty in getting

enough and/or good-quality data is a potential problem.

25

2.2.2 Rule-Based Schema Matching

In [44], N. F. Noy and M. A. Musen develop and implement PROMPT, an algorithm

that provides a semiautomatic approach to ontology merging and alignment. By

performing some tasks automatically and guiding the user in performing other tasks

for which his intervention is required, PROMPT helps in understanding ontologies

covering overlapping domains and eventually reusing these heterogeneous ontologies.

PROMPT also determines possible inconsistencies in the state of the ontology, which

result from the user’s actions, and suggests ways to remedy these inconsistencies.

The authors claim that PROMPT is based on a general OKBC-complaint knowledge

model and therefore can be applied across various platforms. The Protege knowledge-

modeling environment is extended with a tool based on the PROMPT algorithm and

an empirical evaluation of that tool is performed with promising results. The same

authors extend PROMPT to Anchor-PROMPT [45], in which the input are ontologies

in a graph structure with classes as nodes and slots as links. Along with ontologies,

a set of pairs of related terms defined by the user or automatically identified by lexi-

cal matching, which they call anchors, is also input into the system. The algorithm

then analyzes the paths in the subgraph limited by the anchors and determines which

classes frequently appear in similar positions on similar paths - those classes will be

regarded as more likely to represent semantically similar concepts. Again, experi-

ments are carried out and the authors claim that they have achieved the results that

could not have been obtained using the term names alone.

S. Castano et al. present H-MATCH in [11] and [13]. This is an algorithm

for dynamically matching distributed ontologies. H-MATCH has been developed in

the HELIOS framework, conceived for supporting knowledge sharing and ontology-

26

addressable content retrieval in peer-based systems. By exploiting ontology knowledge

descriptions, H-MATCH can be used to dynamically perform ontology matching at

different levels of depth, with different degrees of flexibility and accuracy. The authors

divide the semantics of a concept into its linguistic and contextual parts. The former

captures the meaning of terms used as concept names, while the latter evaluates the

semantic affinity between two concepts by taking into account the affinity between

their contexts, which are concept properties and relationships. The time complexity

of H-MATCH is claimed by the authors to be O(n2), with n the number of elements

in the contexts of the concept to be matched.

In [23] and [24], D. Dou et al. view ontology translation as ontology merging and

automated reasoning, which are in turn implemented through a set of axioms. The

authors regard the merge of two related ontologies as obtained by taking the union

of the terms and the axioms defining them, then adding bridging axioms that relate

the terms in one ontology to the terms in the other through the terms in the merge.

They claim that if all ontologies and datasets can be expressed in terms of some uni-

form internal representation, semantic translation can be implemented by automatic

reasoning, and the language they use, Web-PDDL, has the right degree of flexibil-

ity to achieve this automation. A special-purpose inference system, OntoEngine, for

performing automated reasoning in merged ontologies for the purpose of ontology

translation has been designed. Also, an ontology translation server, OntoMerge, has

been set up to apply and validate the proposed method.

O. Udrea et al. [59] study the problem of integrating two RDF ontologies under

a given set of Horn clauses that specify semantic relationships between terms in

the ontology, as well as under a given set of negative constraints. They formally

27

define the notion of a witness to the integrability of two ontologies, and provide

the polynomial Computing RDF Ontology Witness (CROW) algorithm to find a

witness. The performance of CROW has been reported on DAML, SchemaWeb, and

OntoBroker ontologies as well as on synthetically generated data.

A translation system (TranScm) based on schema-matching is introduced by T.

Milo and S. Zohar [41]. The TranScm system aims at simplifying the intricate task of

data conversion. The authors define common schema and data models, where schemas

and data from many common models can be represented. Through a set of predefined

rules, the source schema is compared with the target one, and each component in the

source is matched with a corresponding component in the target. According to the

matching results obtained, data instances of the source schema can then be translated

to instances of the target schema. The authors claim that the TranScm system allows

a convenient specification and customization of data conversions, and can be easily

combined with the traditional data-based translation languages.

S. Melnik et al. [38] present a structural matching algorithm based on a fixpoint

computation that is usable across different scenarios and is able to match diverse

data structures. Their algorithm takes two graphs as input, and produces as output

a mapping between corresponding nodes of the graphs. The authors define several

filtering strategies for pruning the immediate result of the fixpoint computation. In

addition, they suggest a quality metric (i.e., the labor savings brought to users by

the algorithms) for evaluating the performance of matching algorithms. They also

show that how their system is deployed as one of several high-level operators in an

implemented testbed for managing information models and mappings.

In [35], J. Madhavan et al. present an algorithm, Cupid, for generic schema match-

28

ing outside of any particular data model or application. Cupid discovers mappings

between schema elements based on their names, data types, constraints, and schema

structure. This algorithm makes use of a set of techniques (e.g., the integrated use

of linguistic and structural matching, context-dependent matching of shared types),

and has a bias toward leaf structure where much of the schema content resides. The

authors claim that their experimental results show a better performance of Cupid

compared with two other schema-matching systems (DIKE and MOMIS).

F. Giunchiglia et al. [27] view match as an operator that takes two graph-like

structures and produces a mapping between the nodes of these graphs that correspond

semantically to each other. They discover mappings by computing semantic relations,

and they determine the latter by analyzing the meaning which is codified in the

elements and the structures of schemas. The authors present basic and optimized

algorithms for semantic schema matching, and they discuss the implementation within

the S-Match system. In addition, they validate their approach and evaluate S-Match

against three other matching systems, Cupid, COMA, and Similarity Flooding, and

the results look promising in particular for what concerns quality and performance.

Based on their insight that organizational knowledge typically comes from numer-

ous independent sources, each with its own semantics, L. Stephens et al. [56] describe

a methodology by which information from large numbers of such sources can be as-

sociated, organized, and merged. The hypothesis is that a multiplicity of ontology

fragments, representing the semantics of the independent sources, can be related to

each other automatically without the use of a global ontology. The authors propose

that any pair of ontologies can be related indirectly through a semantic bridge con-

sisting of many other previously unrelated ontologies, even when there is no way to

29

determine a direct relationship between the original pair in question. The relation-

ships among the ontology fragments indicate the relationships among the sources,

enabling the source information to be categorized and organized. In addition, com-

mon parts of the ontologies reinforce each other, resulting in a consensus ontology.

An evaluation of the proposed methodology has been conducted by relating numerous

small, independently developed ontologies for several domains.

2.2.3 Learning-Based Schema Matching

In [22], A. Doan et al. describe a system GLUE that employs machine learning tech-

niques to find semantic mappings between ontologies. Given two ontologies, for each

concept in one ontology GLUE finds the most similar concept in the other ontology.

They give well-founded probabilistic definitions to several practical similarity mea-

sures and show that GLUE can work with all of them. A key feature of GLUE is

that it uses two learning strategies, i.e., a Content Learner and a Name Learner, each

of which exploits a different type of information, that is, in the data instances (by

the Content Learner) and the taxonomic structure of the ontologies (by the Name

Learner). After obtaining the results from these two learners, a Metalearner is used

to combine the predictions from both learners and then build a similarity matrix

based on the combined result. Lastly, common knowledge and domain constraints

are incorporated through a Relaxation Labeler, and the mappings are finally calcu-

lated. A set of experiments on several real-world domains are described and show

that GLUE proposes highly accurate semantic mappings. In addition, they extend

GLUE to find complex mappings (many-to-one mappings) between ontologies and

describe experiments that show the promise of the approach.

30

A. B. Williams and C. Tsatsoulis [65] present their theory for learning ontologies

among agents with diverse conceptualizations to improve group semantic concept

search performance. The authors introduce two algorithms, i.e., recursive semantic

context rule learning and unsupervised concept cluster integration, to address the

issue of how agents teach each other to interpret and integrate knowledge using diverse

ontologies. The main idea of the former is that when an interpretation value falls

between the positive and negative interpretation thresholds for some concept (that is,

the interpretation uncertainty situation arises, and the agent may know this concept),

the agent will try semantic context rule (which is a rule learned using the semantic

descriptors of the concept in question as target concepts to learn from) recursively to

increase the interpretation value above that concept’s positive threshold. The concept

cluster integration deals with the situation where the agent may know several concepts

(when the interpretation values for each of these concepts are between the positive

and negative thresholds). In this case, the agent will cluster all these concepts into

a reformulated concept, and then apply new interpretation rules for this clustered

concept.

In [64] and [61] (the latter is an extension of the former), A. B. Williams introduces

a methodology and algorithm for multiagent knowledge sharing and learning in a peer-

to-peer setting. By this means, the author addresses the agent knowledge sharing

problem of how agents deal with diverse ontologies. He shows how his approach

will enable multiagent systems to assist groups of people in locating, translating,

and sharing knowledge using his Distributed Ontology Gathering Group Integration

Environment (DOGGIE). An agent first tries to locate similar semantic concepts from

its acquaintance agents by sending them a concept name and a set of instance data

31

for that concept. During this learning period, different kinds of machine learning

techniques are adopted (including decision tree, k-nearest neighbor, and Naive Bayes

supervised algorithms). After locating similar concepts among each other, agents can

continue to translate concepts and then are able to share meanings. By conducting

a rich set of experiments, the author claims that DOGGIE agents are able to teach

each other what their concepts mean using their own conceptualization of the world.

L.-K. Soh describes a framework for distributed ontology learning embedded in

a multiagent environment [54]. The objective is to improve communication and un-

derstanding among the agents while agent autonomy is still preserved. Each agent

maintains a dictionary for its own experience and a translation table. The former

allows the agent to compare and discover relationships between a pair of concepts,

whereas the latter is used to enable the agent to learn and record the vocabulary of its

neighbors that is useful for the collaboration among agents. The concept learning and

interpretation are based on a description vector (a list of word-frequency pairs) for

each concept. Equipped with this distributed ontology learning capabilities, agents

are able to evolve independently their own ontological knowledge, and at the same

time maintain translation tables through learning to help sustain the collaborative

effort. In [55], the same author focuses on how neighborhood profiling, the transla-

tion tables, and query experience influence the collaborative activities among agents.

He aims to investigate the learning of useful neighbors for sharing queries, the effi-

ciency of query handling in different real-time scenarios and with different resource

constraints, and the effects of different concepts and query demands on collaborative

understanding. The author claims that in general, the number of negotiation threads

available to each agent in the system has a key role in determining the quality of

32

success of a query task, the average success rate of a negotiation, and the degree of

collaboration among agents.

[18], [19], and [46] are a series of work in ontology matching based on a Bayesian

approach. Their methodology for automatic ontology mapping is built on BayesOWL,

a probabilistic framework developed for modeling uncertainty in Semantic Web. The

algorithm first learns probabilities using Naive Bayes text classification technique

by explicitly associating a concept with a group of sample documents retrieved and

selected automatically from the Web. The probabilities learned include priors about

concepts, conditionals between subconcepts and superconcepts, and raw semantic

similarities between concepts in two different ontologies. Then these probabilities

together with the original ontologies are automatically translated into the Bayesian

network structures, whose conditional probability tables are constructed from learned

priors or conditionals with reasoning services within a single ontology supported by

Bayesian inference. Finally, the algorithm takes as input a set of learned initial raw

similarities and finds new mappings between concepts from two different ontologies

as an application of the authors’ formalized Bayesian network mapping theory, which

is based on evidential reasoning across two Bayesian networks.

[60] shows another ontology-matching approach based on probability theory. The

authors present a domain independent method for handling interoperability problems

by learning a mapping between ontologies. The learning method is based on exchang-

ing instances of concepts that are defined in the ontologies. They first identify pairs

of instances of concepts that denote the same entity in the world using information

retrieval techniques. Then based on these pairs of instances, they propose and eval-

uate mappings between ontologies. During each step of the matching process, the

33

likelihood that a decision is correct is taken into account. F. Wiesman and N. Roos

claim that no domain knowledge is required in their method, and that the struc-

tures of ontologies being matched play no role. To guarantee the correctness of this

method, the authors have derived estimations for the odds that a mapping is correct.

In addition, the effectiveness of this method has been verified through a large number

of experiments.

In [2], M. Afsharchi et al. present a general method for agents using ontologies as

part of their knowledge representation to teach each other concepts to improve their

communication and thus cooperation abilities. They aim at getting both positive and

negative examples for a concept only vaguely understood by a particular agent from

others. This agent then make use of one of its known concept learning methods to

learn the concept in question, involving other agents again by taking votes in case

of conflicts in the received knowledge. By this means, agents that are not sharing

common ontologies are allowed to establish common grounds on concepts known only

to some of them, if these common grounds are needed during cooperation. The

authors claim that although concepts learned by an agent are only compromises

among the views of the other agents, their proposed method enhances the autonomy

of agents using them substantially.

J. Madhavan et al. show how a corpus of schemas and mappings can be used to

augment the evidence about the schemas being matched [34]. Such a corpus typically

contains multiple schemas that model similar concepts and their properties. The

authors exploit a corpus in two ways. They first increase the evidence about each

element being matched by including evidence from similar elements in the corpus.

Then they learn statistics about elements and their relationships and use them to infer

34

constraints that will be used to prune candidate mappings. They also describe how

to use known mappings to learn the importance of domain and generic constraints.

The authors claim that corpus-based matching outperforms direct matching (i.e., the

one without the benefit from a corpus) in multiple domains.

A. B. Williams et al. [63] investigate a method for autonomous agents to develop

local consensus ontologies to aid in the communication within a multiagent system

of business-to-business (B2B) agents. The authors compare variations of syntactic

(based on string edit distance) and semantic (through the help from WordNet) sim-

ilarity matching to form local consensus ontologies. They show how autonomous

ontology merging has potential for improving how agents conduct B2B Web service

discovery and composition. The authors claim that the use of a lexical database in-

creases the number of relationships found but increases the amount of time required

to form the consensus ontologies. They also claim that the rate of the number of

concepts merged appears to decrease as the number of merge operations increases.

2.2.4 Other Ontology-Matching Algorithms

M. Schorlemmer and Y. Kalfoglou [50] elaborate on the mathematical foundations

of the meaning coordination problem that agents face in open environments. They

investigate to which extent the Barwise-Seligman theory of information flow (IF)

provides a faithful theoretical description of the partial semantic integration that two

agents achieve as they progressively align their underlying ontologies through the

sharing of tokens (such as instances). Also, the insights and practical implications

of the Barwise-Seligman theory with respect to the general meaning coordination

problem are discussed. The key idea in this paper is that channel theory indicates

35

that IF crucially involves both types and tokens because information is carried by

particular tokens. Based on the insight that the logical relationship between concepts

arise when tokens are being connected by means of an IF channel, to know what these

connections at the token-level is therefore fundamental for determining the semantic

integration of ontologies at the type-level.

In [20], H. Do and E. Rahm develop the COMA schema-matching system as

a platform to combine multiple matchers in a flexible way. They provide a large

spectrum of individual matchers (including an approach aiming at reusing results

from previous match operations), and several mechanisms to combine the results of

matcher executions. COMA is used as a framework to comprehensively evaluate the

effectiveness of different matchers and their combinations for real-world schemas. The

authors claim that their experiments indicate a promising result.

In [30], B. He and K. C. Chang present a quite different approach for matching

schemas than most of other approaches. Based on two distinguishing characteris-

tics observed on the “deep Web” (there are ample sources that provide structured

information in the same domain as the Web scales; the sources’ aggregate schema

vocabulary tends to converge at a relatively small size), the authors propose a new

paradigm, statistical schema matching. They take a holistic approach to match all in-

put schemas by finding an underlying generative schema model. A general statistical

framework MGS is proposed to discover such a hidden model. There are three com-

ponents for MGS, hypothesis modeling, generation, and selection. In addition, the

authors specialize their general framework to develop Algorithm MGSsd, targeting

at synonym discovery by designing and discovering a model that specifically captures

synonym attributes. The authors claim that over hundreds of real Web sources in

36

four domains have been tested in MGSsd and the results show good accuracy.

M. Gruninger et al. [29] describe how model-theoretic invariants of an ontology

can be used to specify semantic mappings translation definitions between application

ontologies and an interlingua. In particular, examples have been presented using the

Process Specification Language (PSL) ontology as the neutral medium in integration.

The sets of models for the core theories of PSL are partitioned into equivalence classes

defined with respect to the invariants of the models. Each equivalence class in the

classification of PSL models is axiomatized using a definitional extension of PSL. The

authors claim that their approach can be generalized to other ontologies by specifying

the invariants for the models of the axiomatizations.

An approach by utilizing a state-of-the-art record-linkage system in conjunction

with a data-integration system is presented by M. Michalowski in [39]. This approach

aims at matching entities from various data sources both accurately and automati-

cally. The data-integration system is able to automatically determine which secondary

sources need to be queried when linking records from various data sources. In turn,

the record-linkage system is then able to utilize this additional information to improve

the accuracy of the linkage between datasets.

2.3 Miscellaneous Research in Ontology Area

In this section, some other research work in ontology area, all related to ontology-

matching issue, is briefly introduced.

D. Calvanese and G. D. Giacomo discuss in [9] information integration under a

logical perspective in which the global view is seen as an ontology expressed in class-

based formalisms. Data sources have been considered simply as systems that provide

37

data but make no further contribution to the query-answering process. The authors

resort to an expressive description logic, ALCQI, that fully captures class-based rep-

resentation formalisms, and they show that query answering in data integration, as

well as all other relevant reasoning tasks, is decidable. However, when large amounts

of data are dealt with, the high computational complexity leads to a consideration of

DL-Lite, a specifically tailored restriction of ALCQI that ensures tractability of query

answering in data integration while keeping enough expressive power to capture the

most relevant features of class-based formalisms.

In [8], M. H. Burstein and D. V. McDermott review some of the processing as-

sumptions that were made in the development of the Semantic Web service modeling

ontology OWL-S and argue that, as a practical matter, the translation function can-

not always be isolated in mediator agents. Ontology mappings need to be published

on the Semantic Web just as ontologies themselves are. The translation for service

discovery, service process model interpretation, task negotiation, service invocation,

and response interpretation may then be distributed to various places in the archi-

tecture so that translation can be done in the specific goal-oriented informational

contexts of the agents performing these processes. Finally, the authors present ar-

guments for assigning translation responsibility to particular agents in the cases of

service invocation, response translation, and matchmaking.

P. F. Green et al. [28] propose the use of the BWW ontologically-based models,

in particular, the representation model, as a candidate starting point for the evalua-

tion of enterprise systems interoperability standards. The authors explain that these

models have been used to analyze and evaluate many different modeling grammars

to date. They map the constructs of the BWW representation model to the con-

38

structs of ebXML BPSS v1.01 in an effort to show the potential usefulness of BWW

representation model analysis of a business process specification for enterprise inter-

operability. Specifically, they propose that users will lack important implementation

information because of representational deficiencies with regard to things, external

events, and system-level structure and decomposition. Due to ontological redun-

dancy, the authors propose that the complexity of the specification is unnecessarily

increased. Finally, they propose that users of the specification will have to bring in

extra-model knowledge to understand constructs in the specification due to instances

of ontological excess. The authors claim that such propositions need to be empirically

tested in order to be verified.

In [3], H. Alani presents a new approach for automatic construction of ontologies.

His idea is based on reusing the increasing number of online ontologies to build new

ontologies, rather than the current costly habit of starting from scratch. The proposed

system intends to make use of a number of technologies to complete its task, such as

ontology searching, ranking, segmentation, mapping, merging, and evaluation. The

author claims that because his purpose is to avoid reinventing the wheel by providing

users with a tool to help them gather and learn from existing domain representations,

thus bootstrapping their ontology construction task, users of the proposed system will

be expected to modify, delete from, and add to the automatically built ontology as

they see fit.

D. L. McGuinness [36] identifies some of the issues with respect to existing ontology-

enhanced e-commerce applications, reports and discusses findings from experiences in

building and using ontologies for Web deployments in general and e-commerce specif-

ically. She also identifies some “low-hanging fruit” applications, and discusses some

39

research directions.

S. Castano et al. [12] describe a comprehensive framework, named H3, for ontology-

addressable contents in P2P systems, which is composed by a knowledge infrastruc-

ture layer (HELIOS) and a communication infrastructure layer (HERMES). The H3

framework proposes to build an overlay network among peers in which each peer

maintains a peer ontology describing its knowledge of the network. For query rout-

ing, the topology of the overlay network mirrors the semantic neighborhood of the

peers given by the semantic relationships among the ontologies they own.

In [17], J. Diggelen et al. propose a layered communication protocol, ANEMONE,

to deal with the hampered communications in open heterogeneous multiagent systems

due to the lack of shared ontologies. By incorporating techniques for ontology ex-

change, this protocol enables the agents to gradually build towards a semantically

integrated system through establishing minimal and effective shared ontologies. The

authors test their approach on a number of heterogeneous news agents, and they show

that how these agents successfully exchange information on news articles, despite ini-

tial difficulties raised by heterogeneous ontologies.

Y. A. Tijerino et al. [58] introduce an approach, Table Analysis for Generating

Ontologies (TANGO), to generate ontologies based on table analysis. Based on con-

ceptual modeling extraction techniques, TANGO attempts to (1) understand a table’s

structure and conceptual content; (2) discover the constraints that hold between con-

cepts extracted from the table; (3) match the recognized concepts with ones from

a more general specification of related concepts; and (4) merge the resulting struc-

ture with other similar knowledge representations. The authors claim TANGO as a

formalized method of processing the format and content of tables that can serve to

40

incrementally build a relevant reusable conceptual ontology.

In [62], A. B. Williams et al. address the problem of agents collaboratively creating

a common ontology through consensus methods using human user-created diverse

ontologies as their starting point. The authors evaluate various voting algorithms

used by the agents in Intelligent Distributed Ontology Consensus System (IDOCS)

for the iterative agreement phase of the consensus process. They also demonstrate

their approach with proof of concept experiments in the genetics research phenotyping

domain.

H. Alani and C. Brewster [4] present AKTiveRank system to provide tools in

facilitating the reuse of existing knowledge structures (such as ontologies) via ranking

these structures. AKTiveRank uses as input the search terms provided by a knowledge

engineer and ranks the ontologies using the output of an ontology search engine. A

number of metrics is applied to investigate the appropriateness of this ranking process

and to compare its results with a questionnaire-based human study. The authors claim

that AKTiveRank will have great utility although there is potential for improvement.

In [53], L. Soh and C. Chen present the work balancing ontological and operational

factors in building collaborations within multiagent neighborhoods. Their innovation

takes into account the desired level of performance, service priorities, and relaying of

tasks to determine whether an agent should entertain ontological learning, which are

more expensive but more rewarding in the long run, or carry out operational learning,

which are less expensive and more rewarding in the short term. Also, when collabo-

rating with each other, agents need to determine which agents to approach and how

to approach them. The authors claim that with balanced profile-based reinforcement

learning (operational) and inference-based ontological learning, agents reach desired

41

level of performance while improving the neighborhood health and communication

cost.

P. Pantel et al. [47] build two systems for automatic data alignment and inte-

gration: Guspin for automatically identifying equivalence classes or aliases, and Sift

for automatically aligning data across databases. The main idea is to identify the

most informative observations and then to match entities that share them. The au-

thors argue that for matching entities within or across heterogeneous data sources,

a general-purpose solution cannot depend on the presence or reliability of auxiliary

data, such as structural information or metadata. Instead, it must leverage the avail-

able data (or observations) that describe the entities. By applying these two systems

into real-world applications, including aligning US Environmental Protection Agency

(EPA) data between the Santa Barbara Country Air Pollution Control Distric (SB-

CAPCD) and Ventura Country Air Pollution Control Distric (VCAPCD) emissions

inventory databases and the CARB statewide inventory database, as well as to iden-

tify equivalence classes in the EPA’s Facilities Registry System (FRS), the authors

claim that their work can significantly reduce the amount of human effort involved

in creating single-point access to multiple heterogeneous databases. Although the

power of these two systems depends on gathering the right observations that entities

might share, this model can potentially solve several serious and urgent problems that

governments face, such as terrorist detection and identity theft.

42

Chapter 3

Overview of the Improved Solution

Herein

Recall that the problem faced is to match a set of independently designed ontologies.

First, some assumptions to this challenge are given, followed by the constraints in

semantic matching, and finally, three systems are presented to solve the ontology-

matching problem.

3.1 Assumptions Made

There are six assumptions in this thesis.

1. All source ontologies are from the same or similar general domain, and they

have “Thing” as a built-in common root.

2. Each source ontology is correct or reasonable in itself.

3. The domain-independent relationships in all source ontologies are specified by

a common set of predicates (superClassOf, subClassOf, partOf, contains, etc),

and each predicate has the same semantics across all source ontologies.

4. There are no conflicting facts about relationships among all source ontologies.

43

5. All source ontologies handle “Individual” and “Collection” in the same way, i.e.,

via either “MetaClass” or “MetaSlot.”

6. There are only one-to-one mappings between concepts. No one-to-many and

many-to-many mappings exist.

These assumptions are further explained next, and the limitations they introduce

are also discussed in detail.

1. This assumption is based on the insight that in real-world applications, it is not

common to have a need for two ontologies from totally different domains to be

matched with each other. As a knowledge representation model, ontologies will

lose significance if they are “stand-alone.” In other words, ontologies always

serve for some applications, Web services for example. Therefore, it is assumed

that the chance for two applications from completely different domains to in-

teract with each other is relatively small. For the assumption of a common root

“Thing,” it is straightforward and trivial to achieve. Upon the completion of

ontology matching, this common root can either be removed or remain in source

ontologies.

2. It is assumed that source ontologies are designed by domain knowledge experts,

and are therefore not likely to contain incorrect and/or unreasonable informa-

tion. For example, stating that “numberOfValves” is a property of “Person” is

neither correct nor reasonable. If we collect ontologies from Web sites with good

reputation, Swoogle service and DAML Ontology Library [33] for example, this

assumption should be satisfied. Otherwise, the quality of the matching result

is bound to decrease with the decreasing of the quality of input ontologies.

44

3. The assumption of having the same semantics for the same predicate (with

respect to domain-independent relationships only) is a reasonable one if it is

assumed that the designers use the same language, e.g., OWL, to build source

ontologies. In addition, with the help of ontology management tools, Protege

[48] for example, the ontology designers even do not have to learn any language

in constructing ontologies. Instead, they can make use of easy-to-understand

GUIs to build their ontologies and the output will guarantee a uniform predicate

set. Notice that besides domain-independent relationships, different ontologies

can have their own specific relationships, i.e., domain-dependent relationships,

that are not included in this thesis.

4. “No conflicting facts” here means that for any pair of concepts, (A, B), and any

domain-independent relationship, R, that has an inverse relationship, R’, if R

(A, B) is true then R’(A, B) is false. This assumption will make the problem

easier to be solved. In cases where it does not hold, the solution in this thesis

should be extended. For example, a suitable voting mechanism might be needed

when presented with conflicting information.

5. The key difference between “Individual” and “Collection” classes is that the

instance of the former is an object corresponding to some real-world entity,

while the instance of the latter is still a class. The necessity of introducing

“Collection” class is due to the existence of some special properties that are not

suitable to be assigned to common classes, i.e., “Individual” classes. For exam-

ple, consider the class “Person.” It will be meaningless to assign “averageAge”

property to this class, because the instance of “Person,” some real person in

the world, will never have a value for this “averageAge” property. There are

45

two options to solve this problem. One option is to create an additional special

class, i.e., a “Collection” class, whose instance is a “Person” class. Then this

special class can have the “averageAge” property. The other option is to add

an additional special property to the “Person” class. This special property will

record and maintain the value for “averageAge,” and instances of “Person” will

never instantiate this special property. These two different solutions are referred

to as MetaClass solution and MetaSlot solution, respectively. In real-world

ontologies, there are not many properties that need special treatment as dis-

cussed above. If there do exist any such properties in source ontologies, it is

assumed that they are handled in the same way.

6. There is no doubt that one-to-many and many-to-many mappings are more

complex than one-to-one mappings. In addition, these complex mappings are

sometimes quite useful and desirable. However, it is also clear that the latter is

a starting point upon which the former can be handled. Therefore, one-to-many

and many-to-many mappings are considered as interesting directions for future

work, and are not included in this thesis.

3.2 Constraints in Semantic Matching

As discussed in Section 1.1, the semantics of a concept is determined by three aspects:

(1) concept name, (2) concept properties, and (3) concept relationships. These three

features together specify a conceptual model for each concept from the viewpoint

of ontology designers, and form the constraints on which the semantic matching is

based. Notice that name and properties usually contain a lot of linguistic information,

46

while relationships only contain limited such information. For example, subClassOf

relationship means two concepts have a relationship corresponding to the linguistic

meaning of “subClassOf.” However, due to assumption 3 above, i.e., same semantics

for same predicate, there is no constraint in relationships with respect to the linguistic

feature.

3.3 Three Systems

In this thesis, three systems are presented for ontology-matching problem, i.e., the

Puzzle system, the SOCCER (Similar Ontology Concept ClustERing) system, and

the Compatibility Vector system. According to the classification in [21], Puzzle be-

longs to rule-based solution, while SOCCER is mostly a learning-based solution,

integrated with some rule-based techniques. The Compatibility Vector system is not

an ontology-matching algorithm by itself. Rather, it is a means of measuring and

maintaining ontology compatibility, which not only helps the mutual understand-

ing among ontologies, but also determines the compatibility of services (or agents)

associated with these ontologies.

47

Chapter 4

Puzzle System

4.1 Overview

Puzzle is a system extended from the work by L. Stephens et al. [56], aiming at

merging a number of source ontologies by matching them with each other. In [56],

the main technique for semantic matching between two ontology concepts relies on

simple string and substring matching. Their work has been extended in this thesis to

incorporate: further linguistic analysis; extended use of WordNet [40] to include the

search of not only synonyms but also antonyms, plurals, hypernyms, and hyponyms;

use of the Java WordNet Library API [1] for performing run time access to the Word-

Net dictionary, instead of having to initialize the synsets a priori; and reasoning rules

based on each concept’s linguistic feature (concept name) and contextual feature (con-

cept properties and the domain-independent relationships subClassOf, superClassOf,

equivalentClassWith, and siblings) to infer new relationships among concepts from

different ontologies.

4.2 Comparison with Other Rule-Based Algorithms

As mentioned in Section 3.3, Puzzle is a rule-based solution. In this section, Puzzle

is briefly compared with some state-of-the-art and well known rule-based ontology-

48

matching algorithms.

• Puzzle is fully automated. This feature is necessary, especially in terms of the

successful invocation and seamless integration of Web applications. Some semi-

automated systems, PROMPT for example, require user interventions, which

are not always available in the dynamic Web environment. Some other prob-

lems with PROMPT are shown here. (1) If the anchors are chosen incorrectly

(this situation is quite likely because PROMPT only takes into account string

matching when selecting anchors), then the final result will be much unsatisfac-

tory with the errors spreading out from anchors to other concepts. (2) During

the matching process, PROMPT regards a concept and those concepts having

sub/superClassOf relationships with it as a single concept. The consequence is

obvious: those concepts that have sub/superClassOf relationships indeed will

be output as equivalent ones instead. (3) When comparing paths between two

pairs of anchors (one pair from each source ontology), only path length is con-

sidered, without taking into account the semantics of links along those paths.

• Puzzle can treat graph-structured ontologies, which are not only more complex

than tree-structured ontologies (as in Cupid and S-Match), but also a more

realistic schema for most Web applications, because multiple inheritance can-

not be represented by a tree. Also, Cupid does not consider sub/superClassOf

relationships, which are the most common ones in real-world ontologies.

• Puzzle exploits both the linguistic and the contextual features of a concept, and

combines these two features together to determine what does a concept mean

in an ontology. It is more advanced than Similarity Flooding, which considers

49

concept names alone and can only represent partial semantics of ontological

concepts.

• Puzzle incorporates WordNet into the linguistic analysis phase, under the as-

sumption that natural language provides common semantics. Both H-MATCH

and S-Match make use of WordNet as well. However, in H-MATCH, the the-

saurus has to be initialized for each domain for which it is used. If additional

knowledge or a different domain is needed then the user has to input the re-

spective terminology interactively. On the contrary, Puzzle dynamically gets

access to WordNet dictionary at run time. For S-Match, it misuses holonym

and meronym for sub/superClassOf relationships. Instead, they are in fact

supporting partOf relationship.

• Puzzle applies a set of reasoning rules to infer new relationships among concepts

from different ontologies. These rules are based on the domain-independent

relationships (subClassOf, superClassOf, equivalentClassWith, and siblings), to-

gether with each concept’s property list.

4.3 Details of Puzzle

The goal is to develop a methodology for constructing a merged ontology from two

original ones. This methodology can then be applied iteratively to all source ontolo-

gies, and finally a resultant ontology will be obtained from merging a set of original

ones. Although there does not exist such a global and agreed-upon ontology, it is

assumed that there is a common metamodel, i.e., OWL DL, for the ontologies to be

merged, and it is also assumed that natural language provides common semantics

50

during the ontology-merging process.

4.3.1 Top-Level Procedure

The ontology merging is carried out at the schema level, that is, the concentration is

on the structure (schema) information of ontologies. Internally an ontology is repre-

sented using a directed acyclic graph G (V, E), where V is a set of ontology concepts

(nodes), and E is a set of edges between two concepts, i.e., E = {(u, v)|u and v belong

to V , and u has a superClassOf relationship with v}. Recall that it is assumed all

ontologies share “Thing” as a common built-in root. In order to merge ontologies,

G1 and G2, each concept from one ontology is relocated into the other ontology. A

breadth-first order is adopted to traverse G1 and a concept C is picked up as the

target to be relocated into G2. Consequently, at least one member of C’s parent set,

Parent(C), in the original graph G1 has already been put into the suitable place in

the destination graph G2, before the relocation of C itself. The pseudocode below

describes this top-level procedure, whose time complexity is obviously O(n2), with n

the number of concepts in the merged ontology.

Input: Two ontologies G1 and G2

Output: Merged ontology G2

begin

new location of G1’s root = G2’s root

for each node C (except for the root) in G1

Parent(C) = C’s parent set in G1

51

for each member pi in Parent(C)

pj = new location of pi in G2

relocate(C, pj)

end for

end for

end

Top-Level Procedure—merge(G1, G2)

An implementation detail is worth mentioning here. Because of the characteristics

of traversing a directed acyclic graph, there is a possibility that one or more parents

of a certain concept may not have been relocated before that concept itself is visited.

However, at least one of the parents will have been relocated. In this case, the target

concept is revisited after all its parents have been visited. Notice that the progress is

guaranteed, because the graphs in question are acyclic.

4.3.2 Relocate Function

The relocate function in the top-level procedure is used to relocate C into a sub-

graph rooted by pj. The main idea is: try to find the relationship between C and

pj’s direct child(ren) in the following descending priorities: equivalentClassWith, su-

perClassOf, and subClassOf. Because equivalentClassWith has most significant and

accurate information, it is straightforward that equivalentClassWith has been assigned

52

the highest priority. For superClassOf and subClassOf, since a top-down procedure

is adopted to relocate concepts, the former has been given a higher priority than

the latter. If none of these three relationships can be found, the only option is to let

C be another direct child of pj. The following pseudocode describes relocate function.

Input: Two nodes N1 and N2

Output: The modified structure of N2 according to information from N1

begin

if there exists any equivalentClassWith relationship with N1 in the child(ren)

of N2

merge N1 with it

else if there exists any superClassOf relationship with N1 in the child(ren)

of N2

Children(N1) = set of such subclass(es)

for each member ci in Children(N1)

add links from N2 to N1 and from N1 to ci

remove the link from N2 to ci

end for

else if there exists any subClassOf relationship with N1 in the child(ren)

of N2

53

Parent(N1) = set of such superclass(es)

for each member pi in Parent (N1)

recursively call relocate(N1, pi)

end for

else

add a link from N2 to N1

end if

end

Relocate Function—relocate(N1, N2)

Notice that: (1) relocate function embodies a set of reasoning rules, which will be

described later on; and (2) there is a recursive call within relocate function. This re-

cursion is guaranteed to terminate, because the number of the nodes within a graph is

finite, and the worst case is to call relocate repetitively, until the algorithm encounters

a node without any child.

To determine the relationship between C and pj’s direct child(ren), three semantic

constraints need to be considered, i.e., concept name, concept properties, and concept

relationships, as discussed in Section 1.1. These three semantic features can be fur-

ther grouped into: (1) the linguistic feature—concept name, and (2) the contextual

feature—property list and the relationships with other concept(s).

54

4.3.3 Linguistic Matching

The name of a concept reflects the meaning that the ontology designer intended to

encode. Puzzle uses string matching techniques to match linguistic features. Further-

more, WordNet is integrated by using the JWNL API [1] in Puzzle. In this way, the

synonyms, antonyms, hyponyms, and hypernyms of an English word can be obtained.

In addition, WordNet performs some stemming, e.g., the transformation of a noun

from plural to singular form.

It is claimed that for any pair of ontology concepts, C and C’, their names, NC and

NC′ , have the following mutually exclusive relationships, in terms of their linguistic

features (the vlinguistic mentioned below refers to the similarity between two concept

names).

• anti-match: NC is a antonym of NC′ , with vlinguistic = 0;

• exact-match: either NC and NC′ have an exact string matching, or they are the

synonyms of each other, with vlinguistic = 1;

• sub-match: NC is either a postfix or a hypernym of NC′ , with vlinguistic = 1;

• super-match: NC′ is either a postfix or a hypernym of NC , with vlinguistic = 1;

• leading-match: the leading substrings from NC and NC′ match with each other,

with vlinguistic equaling the length of the common leading substring divided

by the length of the longer string. For example, “active” and “actor” have a

common leading substring “act,” resulting in a leading-match value of 36;

• other: vlinguistic = 0.

55

When relocating C, the linguistic matching is performed between C and all the

candidate concepts in the destination graph G2, and a list is built for each of three

types of relationship of C, i.e., equivalentClassWith, superClassOf, and subClassOf.

For each candidate concept C’, if an exact-match or a leading-match (with vlinguistic

≥ threshold) is found, C’ is put into C’s candidate equivalentclass list; if a sub-match

is found, C’ is put into C’s candidate subclass list; and if a super-match is found,

C’ is put into C’s candidate superclass list. Then Puzzle continues the contextual

matching between C and each concept in the three candidate lists to obtain further

information.

4.3.4 Contextual Matching

In essence, the context of an ontology concept C consists of two parts: its relationships

with other concept(s), and its property list. The former include equivalentClassWith,

subClassOf, superClassOf, and sibling, and is implicitly embodied in the graph traverse

process mentioned before. The latter is discussed next.

Considering the property lists, P(C) and P(C’), of a pair of concepts, C and C’, be-

ing matched, the goal is to calculate their similarity value: vcontextual = wrequired·vrequired

+ wnon−required·vnon−required, where vrequired and vnon−required are the similarity values

calculated for the required property list and non-required property list, respectively.

wrequired and wnon−required are the weights assigned to each list. Notice that vrequired

and vnon−required are calculated by the same procedure.

Suppose the numbers of properties in two property lists (either required or non-

required ones), P1 and P2, are n1 and n2, respectively. Without loss of generality,

it is assumed that n1 ≤ n2. There are three different matching models between two

56

properties.

1. total-match

• The linguistic matching of the property names results in either an exact-

match, or a leading-match with vlinguistic ≥ threshold; and

• The data types match exactly.

Let vt = number of properties with a total-match, and ft=vt

n1. Here ft is a cor-

recting factor for name-match, embodying the integration of heuristic reasoning.

It is claimed that between two property lists, the more pairs of properties being

regarded as total-match, the more likely that the remaining pairs of properties

will also hit a match, as long as the linguistic match between their names is

above a certain threshold value. For example, assume that both P1 and P2 have

ten properties. If there are already nine pairs with a total-match, and further-

more, if it is found out that the names in the remaining pair of properties are

similar with each other, then it is much more likely that this pair will also have

a match, as opposed to the case where only one or two out of ten pairs have a

total-match.

2. name-match

• The linguistic matching of the property names results in either an exact-

match, or a leading-match with vlinguistic ≥ threshold; but

• The data types do not match.

57

Let vn = number of properties with a name-match, and fn=vt+vn

n1. Similar to

ft, fn also serves as a correcting factor for datatype-match.

3. datatype-match

Only the data types match. Let vd = number of properties with a datatype-

match.

After all the possible matching models are found in the above order, the similarity

between the two property lists can be calculated as 1n1

(vt·w1 + vn(w2 + ft·w′2) + vd(w3

+ fn·w′3)), where:

• wi (i from 1 to 3) is the weight assigned to each matching model; and

• w′i (i from 2 to 3) is the correcting weight assigned to the matching models of

name-match and datatype-match.

4.3.5 Domain-Independent Reasoning

Remember that to merge two ontologies, it is in essence to relocate each concept

from one ontology into the other one. After the linguistic and contextual similarities

are obtained, a set of domain-independent reasoning rules are applied to infer the

relationship between the target concept to be relocated and the candidate concept in

the destination ontology.

58

Relationships among Property Lists

Suppose there are two ontologies, A and B, each of which is designed according to

the OWL DL specification. Furthermore, let n(A) and n(B) be the sets of concepts

in A and B, respectively, with ni(A) and nj(B) be the individual concept for each set

(1 ≤ i ≤ |n(A)| and 1 ≤ j ≤ |n(B)|), and P(ni(A)) and P(nj(B)) be the property list

for each individual concept.

Consider the property lists, P(ni(A)) and P(nj(B)). Let si and sj be the set size

of these two lists. There are four mutually exclusive possibilities for the relationship

between P(ni(A)) and P(nj(B)):

• P(ni(A)) and P(nj(B)) are consistent with each other if and only if

i. Either si = sj orabs(si−sj)

si+sj≤ threshold, and

ii. vcontextual ≥ threshold

The corresponding concepts, ni(A) and nj(B), are denoted by ni(A)p↔ nj(B);

• P(ni(A)) is a subset of P(nj(B)) if and only if

i. si ≤ sj, and

ii. vcontextual ≥ threshold

The corresponding concepts, ni(A) and nj(B), are denoted by ni(A)p→ nj(B);

• P(ni(A)) is a superset of P(nj(B)) if and only if

i. si ≥ sj, and

ii. vcontextual ≥ threshold

The corresponding concepts, ni(A) and nj(B), are denoted by ni(A)p← nj(B);

• Other.

59

Relationships among Concepts

Given any two ontology concepts from different ontologies, there are five mutually

exclusive relationships between them:

• subClassOf, denoted by ⊆

• superClassOf, denoted by ⊇

• equivalentClassWith, denoted by ≡

• sibling, denoted by ≈

• other, denoted by 6=

Reasoning Rules

Based on the linguistic and contextual features, Puzzle uses three domain-independent

rules to incorporate the reasoning mechanism. These rules are applied to concepts

from different ontologies. Therefore, they are referred to as inter-ontology reasoning.

• Rule 1 and 2 consider two ontologies, A and B.

[Rule 1] This rule is straightforward, claiming that the sub/superClassOf re-

lationships of a class are transferable to its equivalent classes.

- Preconditions:

ni(A) ≡ nk(B) and (ni(A) ⊆ nj(A) or ni(A) ⊇ nj(A))

- Conclusion:

nk(B) ⊆ nj(A) or nk(B) ⊇ nj(A)

60

[Rule 2] If two classes share a same parent, then their relationship is one of:

equivalentClassWith, superClassOf, subClassOf, and sibling.

- Preconditions:

ni1(A) ⊇ ni2(A) and

nj1(B) ⊇ nj2(B) and

ni1(A) ≡ nj1(B) and

1. (the names of ni2(A) and nj2(B) have either an exact-match, or a leading-

match with vlinguistic ≥ threshold) and ni2(A)p↔ nj2(B)

2. (the name of nj2(B) is a sub-match of the name of ni2(A)) and ni2(A)p→

nj2(B)

3. (the name of nj2(B) is a super-match of the name of ni2(A)) and ni2(A)

p← nj2(B)

4. None of above three holds

- Conclusion:

1. ni2(A) ≡ nj2(B)

2. ni2(A) ⊇ nj2(B)

3. ni2(A) ⊆ nj2(B)

4. ni2(A) ≈ nj2(B)

61

The intuition behind rule 2 is as follows. After the linguistic matching phase,

three candidate lists are obtained for target concept C. For each concept in

these lists, C’, the contextual similarity between C and C’ is then calculated to

make the final decision.

• Rule 3 considers three ontologies, A, B, and C.

[Rule 3] If two ontologies have no direct relationship between them, a third

ontology will be referred to, in order to find out the semantic bridge between the

original two ontologies of interest. In theory, the more ontologies the semantic

bridge comprises, the more likely it will be succeeded in discovering the hidden

relationships that are not obvious originally. The metaphor is that an ontology

is like a piece of jigsaw puzzle. It is difficult to relate two random pieces of a

jigsaw puzzle until they are constrained by other puzzle pieces. This is also the

reason that this matching algorithm is named as “Puzzle.”

- Preconditions:

ni1(A) ≡ nk1(C) and

nk2(C) ≡ nj2(B) and

ni1(A) ⊇ ni2(A) and

nk1(C) ⊇ nk2(C) and

1. (the names of ni2(A) and nj2(B) have either an exact-match, or a leading-

match with vlinguistic ≥ threshold) and ni1(A)p↔ nk1(B)

2. (the name of nj2(B) is a sub-match of the name of ni2(A)) and ni2(A)p→

nj2(B)

62

3. (the name of nj2(B) is a super-match of the name of ni2(A)) and ni2(A)

p← nj2(B)

4. None of above three holds

- Conclusion:

1. ni2(A) ≡ nj2(B)

2. ni2(A) ⊇ nj2(B)

3. ni2(A) ⊆ nj2(B)

4. ni2(A) ≈ nj2(B)

Notice that in Puzzle, rule 3 is reflected in the iterative application of the

merging algorithm to original ontologies.

4.4 Evaluation

4.4.1 Four Measures in Ontology Matching

In the research area of ontology matching, there are four commonly adopted measures,

with regard to the performance of (semi)automatic matching algorithms.

• Precision p: The percentage of correct predictions over all predictions, repre-

senting the correctness aspect of the matching performance.

• Recall r: The percentage of correct predictions over correct matching, estimat-

ing the completeness aspect of the matching performance.

63

• F-Measure f (= 2rpr+p

): Also known as Harmonic Mean, aiming to consider both

Precision and Recall. It avoids the bias from adopting Precision or Recall

alone.

• Overall o (= r(2-1p)): A measure on the post-match effort, i.e., how much

human effort is needed to remove false matches and add missed ones.

Notice that: (1) “all predictions” are predictions from the matching algorithm of

interest; (2) “correct predictions” are predictions consistent with a manual matching

process; and (3) “correct matching” is the matching result from a manual match-

ing. According to the above four measures, it is obvious that there is no objective

standard in evaluating the performance of a matching algorithm. Instead, the eval-

uation is quite subjective, which results directly from the fact that ontologies are

a conceptual model representing their designers’ viewpoints. Even for a same ontol-

ogy, without the documentation from its original designer, different users might have

different interpretations regarding its semantics.

4.4.2 Experiment Set One

The first set of experiments are based on a collection of sixteen ontologies for the

domain of “Building,” constructed by graduate students in computer science and

engineering department at our university. These ontologies are used to evaluate the

performance of the Puzzle system, and analyze the merging convergence as well.

Test Ontologies

The characteristics of these test ontologies are listed in Table 4.1, and summarized as:

having between ten and eighteen concepts, with eleven to thirty-five properties and

64

Table 4.1: Characteristics of Test Ontologies—Experiment Set One

Max Depth Concepts Properties RelationshipsOntology1 8 16 25 20Ontology2 6 15 23 21Ontology3 6 18 15 19Ontology4 6 11 35 17Ontology5 7 14 24 22Ontology6 7 10 19 18Ontology7 8 17 21 27Ontology8 5 16 15 24Ontology9 8 16 18 19Ontology10 5 15 22 25Ontology11 7 13 17 16Ontology12 9 16 20 23Ontology13 7 14 12 21Ontology14 7 16 26 24Ontology15 9 17 15 20Ontology16 6 16 11 21

sixteen to twenty-seven relationships. Notice that these ontologies are “toy” ones,

compared to those real-world ontologies, which will be introduced in the next section.

Analysis of Resultant Ontology

The top-level procedure in Section 4.3.1 is iteratively applied to merge two ontologies,

using a random order, until all sixteen original ontologies are merged into a single

ontology. For example, a possible order is: Ontology1 + Ontology2 → Ontology12,

Ontology12 + Ontology3 → Ontology123, and so on. During this iterative loop, two

ontology experts are asked to carry out a manual matching up to the point at the end

of each round of merging; then the results from Puzzle and the manual matching are

compared. The Precision and Recall measures are then plotted, at the end of each

loop. The result is shown in Figure 4.1. Notice that this result is not statistically

65

Figure 4.1: Precision and Recall of Resultant Ontologies (Set One)

valid but indicative. Both measures reflect a promising result, except when the fourth

and the tenth ontologies are merged. The original ontologies were checked. A reason

for the unsatisfactory result is due to unreasonably designed ontologies. For example,

in one ontology, “HumanBeing” and “InsectSpecie” are the only properties of the

concept “LivingThing.”

Analysis of Merging Convergence

One hypothesis is that as each additional ontology is merged, there should be less new

information, i.e., concept, property, or relationship, added to the resultant ontology.

To test this hypothesis, the following experiment has been conducted. The amount

of newly discovered information is gathered, when the second, third, sixth, eleventh,

thirteenth, fourteenth, and sixteenth ontologies were merged. Figure 4.2 shows the

66

Figure 4.2: Merging Convergence Experiment

result of this experiment, which verifies the hypothesis.

Out of the sixteen original ontologies, all possible merging orders were considered.

The purpose is to remove any bias that might be introduced by the presence of unusual

ontology samples. This is a huge number; for example, there are 1,680 combinations

when the third ontology is to be merged, and 25,000 for the fourth one. It is impossible

to try all these orders. The solution is that if the population size is less than or equal

to 30 then all possible orders will be tried; otherwise a sample space of size 30 will

be randomly chosen.

A monotonically decreasing pattern is shown in Figure 4.2. As the number of

ontologies merged increases, the numbers of concepts, properties, and relationships

67

learned from additional ontologies decrease.

4.4.3 Experiment Set Two

The second set of experiments are based on real-world ontologies, built and main-

tained by professionals, in “Business” domain.

Test Ontologies

The following ten ontologies are returned from Swoogle service, by a search on key-

word “Business.”

1. ter: http://www.mindswap.org/2003/owl/swint/terrorism

2. tra: http://opales.ina.fr/public/eon2003/Travel-OilEdExportRDFS.rdfs

3. tou: http://homepages.cwi.nl/∼troncy/DOE/eon2003/Tourism-OilEdExportRDFS.rdfs

4. spa: http://212.119.9.180/Ontologies/0.3/space.owl

5. pri: http://www.daml.org/services/owl-s/security/privacy.owl

6. ops: http://moguntia.ucd.ie/owl/Operations.owl

7. obj: http://www.flacp.fujitsulabs.com/tce/ontologies/2004/03/object.owl

8. swa: http://svn.mindswap.org/pychinko/pychinko/allogtests/mindswapRealized.rdf

9. mgm: http://ontologies.isx.com/onts/2005/02/isxbusinessmgmtont.owl

10. gfo: http://www.onto-med.de/ontologies/gfo.owl

The characteristics of these test ontologies are summarized in Table 4.2. Notice

the high percentage of sub/superClassOf relationships.

68

Table 4.2: Characteristics of Test Ontologies

Features ter tra tou spa pri ops obj swa mgm gfoMax Depth 5 7 6 8 5 8 8 7 9 11Concept # 27 51 53 90 26 91 38 61 72 127Property # 47 42 58 173 23 113 88 71 116 158

Relationship # 41 47 48 158 38 139 70 87 109 162sub/superClassOf # 32 35 38 135 31 120 57 74 85 137sub/superClassOf % 78% 74% 79% 85% 82% 86% 81% 85% 78% 85%

Analysis of Resultant Ontology

Similar with the methodology in Section 4.4.2, a random order is picked up to merge

all test ontologies, and the results from Puzzle are compared with those from a man-

ual matching by two ontology experts. Precision, Recall, F-Measure, and Overall

measures are evaluated and plotted in Figure 4.3.

69

Figure 4.3: Four Measures of Resultant Ontologies (Set Two)

70

Chapter 5

SOCCER System

5.1 Overview

SOCCER stands for Similar Ontology Concept ClustERing. It is a learning-based

algorithm, combined with rule-based techniques, to match ontologies from distributed

sources. The uniqueness and contribution of this approach are that it learns ontology

schemas based on schema information alone, which is a more challenging problem

than the one tackled by many other learning-based algorithms that make use of

instance data as well. A neural network approach is applied to learn weights for

different semantic aspects, and then an agglomerative algorithm is adopted to cluster

similar concepts. To the best of my knowledge, SOCCER is the first learning-based

ontology-matching algorithm exploiting schema information alone, aiming to take

advantage of both rule-based and learning-based ontology-matching approaches.

5.2 Challenges

As discussed in Section 1.1, the semantics of an ontology concept is determined by

three aspects: (1) concept name, (2) concept properties, and (3) concept relationships.

These three features together specify a conceptual model for each concept from the

viewpoint of an ontology designer. Any ontology-matching algorithm, either rule-

71

based one or learning-based one, needs to handle some or all of these three semantic

aspects, by different rules or machine learning techniques.

5.2.1 Problems with Rule-Based Algorithms

The rule-based algorithms usually have the advantage of relatively fast running speed,

but share the disadvantage of ignoring the additional information from instance data.

In addition, there is a more serious concern for this type of algorithms. In order

to obtain a helpful matching result from any algorithms, more than one of three

semantic aspects (name, properties, and relationships) should be considered. If only

one aspect is taken into account then a meaningful matching result is unlikely to be

acquired. Once two or more aspects are considered, it is unavoidable to determine the

corresponding weights for different aspects, reflecting their different importance (or

contributions) in ontology matching. Many existing rule-based algorithms, including

Puzzle in this thesis, make use of human heuristics and/or domain knowledge to

predefine these weights.

5.2.2 Problems with Learning-Based Algorithms

While taking advantage of extra clues contained in instance data, the learning-based

algorithms are likely to be slower. Moreover, the difficulty in getting enough good-

quality data is also a potential problem. On the other hand, it is very challenging for

machines to learn to match ontologies by only providing with schema information.

The most critical challenge is that, because ontologies reflect their designers’ con-

ceptual views of part of the world, they exhibit a great deal of diversities. Identical

terms can be used to describe different concepts, or vice versa, different terms can be

72

assigned to the same concept. A more complicated situation is, even if the same set

of terms are adopted, which is almost impossible in the real life, different designers

can still create different relationships for the same concept, corresponding to their

different conceptual views for this concept. Compared with schemas, instance data

usually have a lot less varieties. Therefore, existing learning-based algorithms make

use of instance data, more or less.

5.2.3 The Solution

Based on the insight of the pros and cons of current matching techniques, a new

ontology-matching algorithm has been designed. SOCCER (Similar Ontology Con-

cept ClustERing) is a learning-based algorithm, combined with rule-based techniques.

The main idea is that machine learning techniques are essential in ontology matching.

However, at the same time, it is preferable to avoid the problem of lacking instance

data, either in quality or in quantity, which is common for real-world ontologies. The

learning process is therefore carried out at the schema level, instead of the instance

level.

Ontology matching consists of many mapping tasks. SOCCER concentrates on

finding equivalent concept pairs as the first step. In addition, after the successful

discovery of pairs of equivalent concepts, it is not difficult to design an algorithm to

merge/align corresponding ontologies.

There are many different kinds of relationships in ontologies, including domain-

dependent ones and domain-independent ones (e.g., superClassOf, subClassOf, partOf,

and contains). In this chapter, sub/superClassOf relationships, which are the most

common ones in most real-world ontologies, are considered.

73

5.3 Related Work in Clustering Algorithms

Beeferman et al. [5] introduce a technique for mining user transactions with a search

engine. They view the dataset as a bipartite graph, with the vertices corresponding

to queries and URLs. They then apply an agglomerative algorithm to these vertices

to identify related queries and URLs. Their method assists users in Web search, and

measures the effectiveness of the discovered clusters.

A Flocking based approach for document clustering is presented in [15]. With-

out requiring initial partitional seeds, this algorithm generates clusters through the

embedding of the high-dimensional data on a two-dimensional grid. Each document

object is represented with a flock boid, whose simple local rules result in complex

global behaviors, which eventually lead to a document clustering.

[14] presents a comparison of conceptual, divisive, and agglomerative approaches,

with regard to the task of automatically learning taxonomies from textual data. De-

spite of the different but comparable performances, each approach has its own ben-

efits. The authors also propose a systematic way of evaluating ontology learning

algorithms.

5.4 Details of SOCCER

First, superconcept is defined as a set of original concepts. Within each superconcept,

all components, i.e., original concepts, are from different ontologies; at the same time,

they are equivalent to each other. The goal of SOCCER is to find all superconcepts

across a set of ontologies.

• The problem faced is a typical unsupervised learning problem, in the sense that

74

it deals with finding a structure in a collection of unlabeled data.

• A cluster is a collection of objects that are similar to each other, and dissimilar

to objects belonging to other clusters. Therefore, each superconcept is viewed

as a cluster.

• The number of superconcepts is not known prior to the matching process.

Therefore, partitioning (also known as exclusive) clustering algorithms, such

as K-means and its variants, are not suitable.

• As a representative of hierarchical clustering algorithms, an agglomerative

clustering algorithm fits the needs here.

In order for a satisfactory result from any agglomerative clustering algorithm, two

issues need to be handled properly.

1. First, a distance measure needs to be defined between data points. As discussed

before, concept semantics consists of three aspects: name, properties, and rela-

tionships. A three-dimensional vector is designed for each concept, where each

dimension corresponds to one semantic aspect. The overall similarity is then

calculated between a pair of concepts (from different ontologies), which is the

weighted sum of similarities from all corresponding dimensions. This overall

similarity among concepts is adopted as the distance measure, and the key is

to assign proper weights for different semantic aspects.

2. After all pairwise similarities are obtained, an agglomerative clustering algo-

rithm is applied to generate a set of clusters (superconcepts). During this clus-

tering process, a threshold is required to determine when the algorithm should

be terminated.

75

Therefore, SOCCER consists of two phases. Phase I learns weights and Phase II

deals with clustering.

5.4.1 Phase I: Learn Weights

The main idea is, given a pair of ontologies to be matched, it is reasonable to assume

that the contributions of different semantic aspects to ontology understanding should

be independent of specific concepts, although it is recognized that many design di-

versities might exist. In fact, different contributions, which are the foundation for

different weights, are characteristics of ontologies viewed as a whole. That is, during

ontology matching, weights are features with regard to ontologies, rather than indi-

vidual concepts. Therefore, it is possible to learn these weights for all concepts by

training examples from a subset of concepts.

Concept Similarity

Similarity in Concept Names The similarity s1 between a pair of concept names

is a real value in the range of [0, 1]. Some pre-processing on these two strings is

performed before the calculation of s1. For example, the removal of hyphens and

underscores. Another example is the transformation of a noun from its plural form

to a single form, which is accomplished automatically through WordNet JWNL API.

If two names have an exact string matching or are synonyms of each other in

WordNet, then s1 has a value of 1. Otherwise, s1 is calculated according to

s1 = 1− d

l, (5.1)

76

where d stands for the edit distance between two strings, and l for the length of the

longer string.

Similarity in Concept Properties Given two lists of concept properties (includ-

ing those inherited from ancestors), p1 and p2, their similarity s2 is a real value in the

range of [0, 1], and s2 is calculated according to

s2 =n

m, (5.2)

where n is the number of pairs of properties matched, and m is the smaller cardinality

of lists p1 and p2.

In order for a pair of properties, one from p1 and the other from p2, to be matched,

their data types should be the same or compatible with each other (float and double

for example), and their property names should be similar with each other. In addition,

the idea of “stable marriage” is adopted in determining the matched property pairs.

That is, once two properties are considered matched, it means that they both find the

best matched one from the other property list. During a loop handling the similarity

matrix built between p1 and p2, in each iteration a pair with the maximum value in

the current matrix is picked up, say cell [i, j], and then the matrix is updated by

discarding both row i and column j.

Similarity in Concept Relationships As mentioned before, the relationships

considered are sub/superClassOf. In order to obtain a better matching result, in-

formation is made use of as much as possible. For example, suppose there are two

pairs of equivalent concepts, and the numbers of concepts in-between are different

77

from each other, i.e., the ontology with more detailed design tends to have more in-

termediate concepts. If the direct parent alone is considered, the information from

this multilayered parent-child hierarchy will be ignored. Therefore, not only the di-

rect parent of a concept is considered, but also all of its ancestors are considered as

well, i.e., concepts along the path from this concept up to the common built-in root

“Thing.” Descendants (direct and indirect children of a concept) are not taken into

account, because it would lead to an infinite loop if both ancestors and escendants

are considered.

Given two lists of concept ancestors, a1 and a2, their similarity s3 is a real value

in the range of [0, 1], and is obtained by first calculating the similarity values for

pairwise concepts (one from a1, the other from a2, considering all combinations),

then assigning the maximum value to s3. Notice that this is a recursive procedure

but is guaranteed to terminate, because (1) the number of concepts is finite; and (2)

it is assumed that “Thing” is a common root for two ontologies being matched.

Concept Similarity Matrix After s1, s2, and s3 between two concepts, C1 and

C2, are calculated, the overall similarity value s between C1 and C2 is obtained as the

weighted sum of s1, s2, and s3:

s =3∑

i=1

(wisi), (5.3)

where3∑

i=1

wi = 1, and s ∈ [0, 1]. Notice that wi’s are randomly initialized, and will

be adjusted through a learning process that is discussed in the next section.

For two ontologies being matched, O1 and O2, the similarity values are calculated

78

for pairwise concepts (one from O1, the other from O2, considering all combinations).

Then a n1 × n2 matrix M is built to record all values calculated, where ni is the

number of concepts in Oi. The cell [i, j] in M stores the similarity value between

the ith concept in O1 and the jth concept in O2.

Weight Learning by Artificial Neural Network

The purpose of SOCCER Phase I is to try to learn different weights for different

semantic aspects. The learning problem is designed as follows.

• Task T : match two ontologies (in particular, find equivalent concept pairs)

• Performance measure P : Precision, Recall, F-Measure, and Overall with regard

to manual matching

• Training experience E: a set of equivalent concept pairs by manual matching

• Target function V : a pair of concepts → <

• Target function representation: V (b) =3∑

i=1

(wisi)

Artificial neural network is chosen as the learning technique, based on the following

considerations.

• Instances are represented by attribute-value pairs

• The target function output is a real-valued one

• Fast evaluation of the learned target function is preferable

79

Figure 5.1: Neural Network Structure

Network Design A two-layer 3 × 1 network is adopted in SOCCER, as shown in

Figure 5.1. The input into this network is a vector ~s, which consists of s1, s2, and

s3, representing the similarity in name, properties, and ancestors, respectively, for

a given pair of concepts. The output from this network is s, the overall similarity

value between these two concepts, calculated according to Formula (5.3). Notice

that a linear function might not be powerful enough to reflect the true relationships

among wi’s. However, “the delta rule converges toward a best-fit approximation to

the target concept even when the training examples are not linearly separable.” [42]

If more relationships among ontology concepts are to be considered, then one or more

layers of hidden units might need to be added to express a rich variety of nonlinear

decision surfaces.

80

Initially, a concept similarity matrixM is obtained for O1 and O2, with wi’s being

initialized randomly. Then a set of concepts are randomly picked up from O1, and

the corresponding equivalent concepts are found in O2 by a manual matching. Each

of such manually matched pairs will be processed by SOCCER, and the similarity

values in name, properties, and ancestors for these two concepts are calculated and

used as a training example to the network in Figure 5.1.

Hypothesis Space and the Searching Strategy In this learning problem, it is

assumed that the hypothesis space is a three-dimensional space consisting of w1, w2,

and w3. For every weight vector ~w in the hypothesis space, the learning objective

is to find the vector that best fits the training examples. Gradient descent (delta

rule) is adopted as the training rule, and the searching strategy within the hypothesis

space is to find the hypothesis, i.e., weight vector, that minimizes the training error

with regard to all training examples. According to [42], a standard definition of the

training error E of a hypothesis is given by

E(~w) ≡ 1

2

∑d∈D

(td − od)2, (5.4)

where D is the set of training examples, td is the target output for training example

d, and od is the output of the network for d.

The above formal definition is customized according to the characteristics of the

learning problem here. For any training example d, instead of a given target value td,

some other values are needed. The intuition is that, a given pair of manually matched

concepts corresponds to a cell [i, j] inM, therefore, the value of cell [i, j] should be

the maximum one in both row i and column j. Suppose the maximum value for row

81

i and column j are tr and tc, respectively, then the customized description of E is

E(~w) ≡ 1

2

∑d∈D

[(tr − od) + (tc − od)]2. (5.5)

Accordingly, the weight update rule for gradient descent in SOCCER is

∆wi = η∑d∈D

[(tr − od) + (tc − od)]sid, (5.6)

where η is the learning rate, and sid is the si value for a specific training example d.

5.4.2 Phase II: Cluster Concepts

An Agglomerative Clustering Algorithm

Upon obtaining the learned weights for three semantic aspects (name, properties,

and relationships), the similarity matrix is recalculated between every two ontologies.

An agglomerative clustering algorithm is then adopted to form a set of supercon-

cepts. In the following procedure, similarity between clusters (a) and (b) is denoted

by s[(a), (b)], which is calculated as the average similarity between all pairs of con-

cepts from (a) and (b), i.e., s[(a), (b)] = 1uv

u∑i=1

v∑j=1

s[(ai), (bj)], where (ai) and (bj) are

component concepts in (a) and (b), respectively; and u and v are the numbers of

concepts in (a) and (b), respectively.

Input:

• Ontologies O1, O2,..., and Ok

• Mij’s (i, j ∈ [1, k] and Mij is the recalculated similarity matrix between Oi

and Oj)

82

Output:

• A set of superconcepts

begin

1. Each original concept forms a singleton cluster

2. Find a pair of clusters, (a) and (b), such that their similarity s[(a), (b)] = max

(s[(m), (n)])

3. If s[(a), (b)] > similarity threshold, go to step 4, otherwise go to step 7

4. Merge (a) and (b) into a new cluster (a, b)

5. For all ontologies containing (a) and (b), update their matrices by deleting

the row and column corresponding to (a) and (b); for other ontologies whose

matrices contain (a) or (b), recalculate the row/column corresponding to (a) or

(b), using the similarity between new cluster (a, b) and any existing cluster (c):

s[(a, b), (c)] = 12

(s[(a), (c)] + s[(b), (c)])

6. Repeat steps 2 and 3

7. Output current clusters as the set of superconcepts

end

Pseudocode for Agglomerative Clustering

83

From the above procedure, it can be discovered that the key to correctly obtain a

set of superconcepts depends on whether or not a suitable similarity threshold can

be determined. This is not trivial at all, and the following strategy is taken to tackle

this challenge.

First of all, let the number of concepts in Oi be ni (i ∈ [1, k]). Without loss of

generality, suppose n1 ≥ nj (j ∈ [2, k]). The number of total clusters (superconcepts)

should then be within the range of [n1,k∑

i=1

ni].

Possible values of threshold are real numbers in [0, 1]. With the decrease of thresh-

old value, the number of superconcepts will decrease as well. Let us pay attention

to two extreme situations. (1) If threshold is set to 1, then no pair of concepts will

be regarded as equivalent ones, and no new clusters are to be generated. Therefore,

there will bek∑

i=1

ni resultant superconcepts. (2) On the other hand, if threshold is set

to 0, then every concept in Oj (j ∈ [2, k]) finds its equivalent one in O1, and there

will be n1 superconcepts.

The number of superconcepts changes with the changing of threshold value. This

results in a certain shape of curve. If after an initial drop, there emerges a plateau,

followed by a second drop, then it is reasonable to conclude that threshold can possibly

be assigned the value corresponding to the beginning of this plateau (Figure 5.2).

The intuition is: the semantic similarity between non-equivalent concepts and that

between equivalent concepts are different, and this difference could be remarkable

enough to form a plateau. In addition, the starting point of the plateau indicates the

point from which the superconcept number starts to converge.

As shown in the pseudocode for agglomerative clustering, Average Linkage ap-

proach is used to calculate the distance between two clusters, by the average over

84

Figure 5.2: Evolution of Superconcept Number with the Changing of SimilarityThreshold

distances of all pairs of components. This approach is more computationally expen-

sive than either Single Linkage approach, which defines the distance between two

clusters as the minimum distance between them; or Complete Linkage approach,

which defines the distance between two clusters as the maximum distance between

them. The reasons to choose average linkage approach are:

• Single linkage approach tends to force clusters together due to a single compo-

nent, and therefore causes “chaining phenomenon.”

• Complete linkage approach is quite sensitive to noises in the data set, and

produces very compact clusters.

85

• Average linkage approach is the most appropriate one for our problem, because

it is preferable for distributed partners to gather ontological information from as

many other partners as possible. Only in this way can a most possibly favorable

mutual understanding be achieved.

Characteristics of the Clustering Algorithm

Some pleasing features in this agglomerative clustering algorithm are summarized

below.

• It is insensitive to order of input data. By taking into account all ontologies

at the same time, the algorithm will not be affected by input order. In addition,

a global instead of local optima is going to be achieved, due to the fact that

the algorithm always look for a concept pair with maximum similarity across

all ontologies.

• It is quite robust to noises. By adopting average linkage approach in calcu-

lating cluster distances, the algorithm is not likely to be misled by noise data.

• It can deal with different types of attributes. All three semantic aspects

for ontology concepts are considered, which reflect different attributes with re-

gard to an ontology designer’s conceptual model.

• It has minimal requirements for domain knowledge to determine in-

put parameters. Given the learned weights, users are not required to hold

any domain knowledge at all. Domain expertise is only needed when users want

to verify the matching results from the algorithm.

86

• Its output is easy to be interpreted. By determining similarity threshold

and therefore the termination condition, the algorithm renders a set of supercon-

cepts, containing equivalent concepts from distributed ontologies. This output

is quite self-explanatory to users.

5.5 Evaluation

5.5.1 Experiment Design

The hypothesis is that a set of superconcepts exist across distributed ontologies. This

hypothesis can be further divided into two sub-hypotheses.

1. Three weights for semantic aspects learned from a subset of concepts are rep-

resentative of all concepts in the same ontology. In order to verify this, it is

necessary to show that the weight-learning process itself is a correct one, i.e.,

three weights converge to certain values.

2. The resultant superconcepts are meaningful, and alleviate human efforts in

matching ontologies from distributed sources. This will be verified by applying

the learned weights to the clustering process, and then comparing the output

equivalent concepts with manual matching results.

5.5.2 Test Ontologies

Eight real-world ontologies, built and maintained by professionals, are used as the

test ontologies.

1. akt: http://www.csd.abdn.ac.uk/∼cmckenzi/playpen/rdf/akt ontology LITE.owl

87

Table 5.1: Characteristics of Source Ontologies

Features akt aktive iswc ita ka semiport univ MidMax Depth 8 6 5 8 6 7 7 10Concept # 81 62 30 67 33 41 59 117Property # 105 97 68 99 70 61 90 126

Relationship # 116 85 49 101 53 67 81 203sub/superClassOf # 83 57 32 73 43 46 63 146sub/superClassOf % 71% 67% 65% 73% 81% 69% 78% 72%

Instance Data % 24% 0% 29% 0% 0% 0% 0% 14%

2. aktive: http://www.mindswap.org/2004/SSSW04/aktive-portal-ontology-latest.owl

3. iswc: http://annotation.semanticweb.org/iswc/iswc.owl

4. ita: http://www.mondeca.com/owl/moses/ita.owl

5. ka: http://protege.stanford.edu/plugins/owl/owl-library/ka.owl

6. semiport: http://ontoware.org/frs/download.php/18/semiport.owl

7. univ: http://www.mondeca.com/owl/moses/univ.owl

8. Mid: http://reliant.teknowledge.com/DAML/Mid-level-ontology.owl

Their characteristics are summarized in Table 5.1. In these randomly chosen

ontologies, the most common relationships are sub/superClassOf (from 65% to 81%).

In addition, only three ontologies have instance data associated with schemas, with

fairly low percentages (24%, 29%, and 14%) over the whole file.

88

0

0.1

0.2

0.3

0.4

0.5

0.6

0 10 15 20 30 50 70 100 200 500 1000 2000 3000 5000

valu

es fo

r wei

ghts

and

trai

ning

err

or

number of iterations

w1w2w3

training error

Figure 5.3: Weight Learning—setting 1

5.5.3 Results and Analysis

Weight Convergence

Weight learning is carried out for every two ontologies. The experiment results for

akt and iswc ontologies are shown as examples.

Initial weights are randomly set, i.e., w1 = 0.22, w2 = 0.28, w3 = 0.5; learning

rate η is set to 0.05; and three pairs of equivalent concepts are provided by human.

Figure 5.3 shows the values of the training error and wi’s after different iterations of

the gradient descent algorithm. After setting η to 0.2 and keeping other parameters

the same, the result is shown in Figure 5.4.

89

0

0.1

0.2

0.3

0.4

0.5

0.6

0 10 15 20 30 50 70 100 200 500 1000 2000 3000 5000

valu

es fo

r wei

ghts

and

trai

ning

err

or

number of iterations

w1w2w3

training error

Figure 5.4: Weight Learning—setting 2

Clustering Result

The learned weights (for example, w1 = 0.56, w2 = 0.16, w3 = 0.27 for akt and iswc)

are used to recalculate similarity matrices, then the clustering algorithm is carried out

for all eight test ontologies. The resultant evolution pattern of superconcept number

with the changing of similarity threshold is plotted in Figure 5.5. Based on the curve

shape, SOCCER determines “0.55” as the value for similarity threshold, and outputs

the corresponding superconcepts. Out of 309 pairs of equivalent concepts suggested

by SOCCER, 257 are agreed by two ontology experts; and there are another 86 pairs

not in SOCCER output but suggested by experts.

90

Figure 5.5: Clustering Result

Analysis

From the evolution of weights in Figures 5.3 and 5.4, it is clear that all three weights

for semantic aspects converge. At the same time, the training error also con-

verges, along with the changing of these weights. Moreover, after the learning rate

increases from 0.05 to 0.2, the convergence speeds up. The number of iterations

needed drops dramatically from 500 in the former to 70 in the latter.

By comparing the matching result from SOCCER with that from experts, the

following four measures are calculated:

• Precision p = 257309

= 0.83

• Recall r = 257257+86

= 0.75

91

• F-Measure = 2rpr+p

= 0.79

• Overall = r(2-1p) = 0.6

The detailed description of the above four measures can be found in Section 4.4.1.

92

Chapter 6

Compatibility Vector System

6.1 Overview

There is an important but mostly neglected research topic in Web application domain—

how to select suitable partners, e.g., Web service providers and business partners,

with which to interact. More compatible ontologies are likely to yield a better un-

derstanding among partners. In this sense, ontology compatibility is used as a basis

for partners to select candidate partners. Based on this insight, a compatibility vec-

tor system, built upon an ontology-merging algorithm, is designed to measure and

maintain ontology compatibility.

6.2 Related Work in Quality of Service

Quality of service (QoS) is becoming a significant factor with the widespread deploy-

ment of Web services. By QoS, it refers to the non-functional properties of services,

such as reliability, availability, and security. Ontology quality consists of many as-

pects, of which the compatibility is one of the most important ones, because better

compatibility leads directly to better understanding, which is critical during business

interactions. Notice that the quality of services themselves is a separate research topic

that will not be covered in this chapter.

93

[7] proposes a Service Query and Manipulation Language (SWSQL) to maintain

QoS-attribute ontologies and to publish, rate, and select services by their functionality

as well as QoS properties. Based on SWSQL, they extend the UDDI registry to a

service repository by combing a relational database and an attribute ontology.

Zhou et al. [66] provide a DAML-QoS ontology as a complement to a DAML-S

ontology in which multiple QoS profiles can be attached to one service profile. In

addition, they present a matchmaking algorithm for QoS properties.

One widely used QoS attribute is user rating, but it is subjective to the perception

of an end user and is limited by the lack of an objective representation of performance

history. Kalepu et al. [31] introduce reputation, a composition of user rating, compli-

ance, and verity as a more viable QoS attribute. Ontologies are applied to QoS-aware

service selection, execution, and composition. A selected ontology itself can adopt

some QoS measures to facilitate mutual ontology understanding as discussed in this

paper.

6.3 Example Scenario and Its Solution

6.3.1 A Running Example in E-Business Interaction

An example scenario of the business interaction within an e-business environment can

be envisioned as follows. E-business partners are represented by service agents, then:

1. A number of agents form an e-business community (EBC), within which services

provided by different agents might be integrated, and have the ability to render

a more complete and functional service. This integration requires the mutual

understanding of the individual ontology underlying each agent.

94

2. The agents outside this EBC can request help from the community, and make

use of its services, either the original ones or the integrated one. This request

requires not only an understanding of the related ontologies, but also the ability

to choose suitable agent(s), especially under the situations where resources are

limited.

Consider the travel business as an example. Many websites provide services for

this business area, e.g., Expedia.com, Orbitz.com, and Hotels.com. When a customer

makes his/her travel plan, it is very possible that, for some specific dates, one web-

site would provide a flight ticket with the lowest price, while another website would

have the best offer in car rentals, and a third website would offer the cheapest hotel

reservations. Therefore, it is preferable for the services from all these websites to be

integrated to render the best vacation package for each customer. On the other hand,

some customers might be interested in one service alone, only to buy a flight ticket

for example. In this case, these customers would find it beneficial if there is an agent

gathering and comparing information from all related websites. In either case, the

mutual understanding among agents representing different websites is necessary.

Two major problems need to be solved. First, during the formation of an EBC,

how can it be ensured that all agents within the community have no problem in

understanding each other’s ontology? Second, an agent seeking coordination from

outside this community would like to choose those agents that understand its ontology

best. How can it ensure this selection is a correct one?

95

6.3.2 Solution Overview

An ontology compatibility vector system is designed to tackle the above challenges.

This vector system is built upon an ontology-merging algorithm, Puzzle for exam-

ple. The main idea is: along with the formation of an EBC, a center ontology is

created by merging all original ones; then the distances (dissimilarities) from original

ontologies to this center are suitably encoded in the compatibility vectors stored in

the center. Based on the information contained in the vectors, partners are supposed

to understand the ontology from each other without trouble, and the partner from

outside this community will have no difficulty in choosing candidate partners that

have ontologies with good compatibilities. In addition, these vectors can be adjusted

efficiently and dynamically, both during the period in which the EBC is formed and

after an EBC is created as well.

6.4 Details of Compatibility Vector System

6.4.1 Center Ontology and Concept Distance

Formation of a Center

As mentioned before, the center is generated by merging all original ontologies, step

by step, as each new partner joins an EBC. At the beginning, when there is only one

partner, its ontology is regarded as the center. With new partners join the community,

the new ontologies are merged with the current center. The resultant merged ontology

is the newly obtained center.

96

Figure 6.1: Graphical Representations for Ontology1 and center1

Concept Distance Calculation

Being the result of merging original ontologies, the center contains information from

all sources. With respect to whether or not a specific original ontology, Ontologyi,

understands each concept in the center, there are two situations. The first one is that

for one specific concept in the center, Ontologyi can understand it, but possibly with

less accurate and/or complete information. The second situation is that Ontologyi

is not able to recognize that concept at all. In either case, the concept distance is

represented by the amount of information missing, i.e., the number of relationships

not known in Ontologyi. Equation (6.1) formalizes the concept distance d.

d =2∑

i=1

(wini), (6.1)

where n1 is the number of sub/superClassOf relationships not known in Ontologyi,

n2 is the number of other relationships not known; wi’s are corresponding weights,

and w1 + w2 = 1.

Consider the ontologies in Figure 6.1. For Ontology1 on the left, concept “Intangi-

ble” has one subClassOf (“AbstractThing”); four superClassOf (“TemporalThing,”

97

“SpatialThing,” “Mathematical,” and “IntangibleIndividual”); and one disjointWith

(“PartiallyTangible”). For merged center1 on the right (note that center is built incre-

mentally, therefore, there are different centeri’s), the concept “Intangible” has more

information from other ontologies: one more subClassOf (“PartiallyIntangible”);

one more disjointWith (“Tangible”); and one more superClassOf (“OtherIntangi-

bleStuff”). Thus, the concept distance from “Intangible” in Ontology1 to “Intangible”

in center1 is w1×2+w2×1. Notice that one “isa” link in Figure 6.1 corresponds to a

pair of relationships. That is, if C1 “isa” C2, then C1 has a subClassOf relationship

with C2, and C2 has a superClassOf relationship with C1. Also notice that Equation

(6.1) is suitable for both situations, i.e., independent of whether or not the original

ontology recognizes that concept. For example, if in Ontology1 there is no concept

“Intangible,” then the distance becomes w1 × 7 + w2 × 2.

6.4.2 Compatibility Vectors

Inside the center, there is a set of compatibility vectors, one for each original ontology.

A compatibility vector consists of a set of dimensions, each corresponding to one

concept in the center. Therefore, all compatibility vectors have identical number of

dimensions, i.e., equaling to the number of the concepts in the center. Each dimension

has three sub-dimensions. The first sub-dimension tells us whether or not the original

ontology understands this concept; the second sub-dimension records the concept

name in the original ontology if the latter does recognize that concept; and the third

sub-dimension encodes the distance from the concept in the original ontology to the

concept in the center. An example of compatibility vectors is shown in Figure 6.2.

For the first concept in the center, “Spatial,” Partner1 knows it as “Spatial”

98

Figure 6.2: Compatibility Vectors

Figure 6.3: Dynamic Adjustment of Compatibility Vectors

99

and has a concept distance of 2.7; Partner3 also understands this concept, but with

a different name, “Space,” and a bigger concept distance of 4.5; neither Partner2

nor Partnerm recognizes concept “Spatial,” therefore, they have the same concept

distance, 5.0.

6.4.3 Dynamically Adjusting Vectors

During the Formation of an EBC

As mentioned before, when there is only one partner, its compatibility is perfect. In

the compatibility vectors stored in the center, each concept distance has a value of

zero. However, with the adding of new partners into this EBC, the compatibilities

for existing partners might be changed, because newly joined partners could contain

ontologies with more accurate and/or complete information.

An example is shown in Figure 6.3, demonstrating the process of dynamic distance

adjustment. After ontology1 and ontology2 are merged to generate center1, the dis-

tance between these two original ontologies and the merged one, center1, is calculated

and stored in the compatibility vectors of center1. Upon the joining of ontology3 and

the generation of center2, the compatibility vector for center1 in center2 is calculated

and integrated with the compatibility vectors for ontology1 and ontology2 in center1;

then the compatibility vectors for ontology1 and ontology2 are generated in center2.

This is explained in detail next.

For example, we have compatibility vectors in both center1 and center2. Now

we want to update the compatibility vectors in center2. Originally there are two

compatibility vectors in center2: one for ontology3, and the other for center1. The

former will remain the same as is; while the latter will be replaced by several new

100

vectors, the number of which is determined by the number of the vectors in center1

(two in this example).

Remember that center1 has one vector for each partner when center1 is gener-

ated. Each vector in center1 will be integrated with the vector for center1 in center2,

therefore creating a new vector correspondingly in center2. The following procedure

describes the generation of such a new vector.

Input:

• compatibility vector v for center1 in center2

• compatibility vector u for partneri in center1

Output:

• compatibility vector w for partneri in center2

begin

for each dimension d in v

yn = d’s first sub-dimension’s value

nm = d’s second sub-dimension’s value

dis = d’s third sub-dimension’s value

create a new dimension nd in w

101

if yn = “Yes”

find in u the dimension od for concept nm

yn old = od’s first sub-dimension’s value

nm old = od’s second sub-dimension’s value

dis old = od’s third sub-dimension’s value

nd’s first sub-dimension = yn old

nd’s second sub-dimension = nm old

nd’s third sub-dimension = dis + dis old

else (yn = “No”)

nd’s first sub-dimension = yn

nd’s second sub-dimension = nm

nd’s third sub-dimension = dis

end if

end for

end

102

Figure 6.4: Example of New Vector Generation

Pseudocode for New Vector Generation

It is not difficult to figure out that the time complexity for the above procedure

is O(nlogn), because there are n dimensions in each vector, requiring n steps for the

loop. Within each loop, all steps take constant time, except for the one finding some

dimension in u. Suppose in u the dimensions are indexed by the concept names, then

a binary search is able to locate a specific dimension within O(logn).

Figure 6.4 exemplifies how the above pseudocode works. There are two source

vectors, u and v. The second one, v, is traversed, one dimension each time.

1. The values for the first dimension are “Yes,” “Intangible,” and “2.3.” The

dimension for “Intangible” in u is then found, and its values are obtained,

i.e., “Yes,” “Intang,” and “1.6.” Finally the values for the new dimension are

103

calculated in the resultant vector w, which are “Yes,” “Intang,” and “3.9” (the

result of 1.6 + 2.3).

2. The values for the second dimension are “Yes,” “Tangible,” and “1.7.” After

the values for dimension “Tangible” in u are obtained, i.e., “No,” “N/A,” and

“6.7,” the values for the new dimension in w are figured out as “No,” “N/A,”

and “8.4” (the result of 6.7 + 1.7).

3. The values for the third dimension are “No,” “N/A,” and “5.9.” These three

values are simply copied into the new dimension in w.

4. This continues until the traverse of all dimensions in v is finished.

After an EBC is Created

In cases where existing original ontologies change their schema information after an

EBC is created, the compatibility vectors need to be modified accordingly. There are

several situations.

1. One or more new concepts are added.

2. One or more concepts are removed.

3. No concept is added or removed, but new relationships are added.

4. No concept is added or removed, but existing relationships are removed.

5. No concept is added or removed, but existing relationships are modified.

The solution is outlined as follows.

104

1. For case 1, a subgraph of the modified ontology needs to be merged with the

center. The subgraph consists of the new concept and all its ancestors and de-

scendants, together with all concepts having relationships with the new concept.

After this merging process, the new concept is relocated in the center. If this

concept has already existed in the center and no new information (relationship)

is added, then only the compatibility vector for the modified ontology needs to

be updated; otherwise all vectors need to be updated.

2. For case 2, if the removed concepts come from both the modified ontology and

other original ontologies, and the modified ontology does not provide additional

information with regard to the removed concepts, then only the compatibility

vector for this modified ontology needs to be updated; otherwise all vectors

need to be updated.

3. For case 3, if the new relationships have already existed in the center, then

only the compatibility vector for that modified ontology needs to be updated;

otherwise all vectors need to be updated.

4. For case 4, if the removed relationships come from both the modified ontology

and other original ontologies, then only the compatibility vector for this modi-

fied ontology needs to be updated; otherwise all vectors need to be updated.

5. Case 5 is a combination of cases 3 and 4.

105

6.4.4 Utilities of Compatibility Vectors

Ontology Understanding within the EBC

The center maintains the compatibility vectors for all original ontologies; in addition,

the vectors themselves contain such information as whether or not an original ontology

understands a specific concept, what is the concept name in the original ontology, and

so on. Therefore, if two partners would like to try to understand each other’s ontology,

they can simply refer to the center and obtain the corresponding compatibility vectors.

By this means, compatibility vectors help partners in their mutual understanding of

ontological concepts.

Partner Selection from outside the EBC

When a partner from outside this EBC requests for partner(s) to coordinate with,

it would like to choose those that understand its ontology best. The requesting

partner first compares its own ontology with the center, and then searches in the

compatibility vectors to find all partners understanding the concept of its interest. If

there is more than one candidate, the coordination request will be sent to those with

good compatibilities, that is, with low concept distances. Because the compatibility

vectors are stored and maintained by the center, the partners have no way to modify

or manipulate the vectors. In this sense, the selection of partner(s) is objective and

without bias.

106

6.4.5 Features of Compatibility Vectors

Correctness of Compatibility Vectors—A Precise Approach

To record and maintain the proper compatibility of each partner inside an EBC, the

key is to obtain a correct center by which to evaluate the distance from the center to

each original ontology, and thereby acquire the corresponding compatibility vector.

When a new partner joins the EBC, instead of communicating with each existing

partner, it only talks with the center. Therefore, if it can be proved that the newly

merged ontology is a correct new center, the correctness of compatibility vectors is

guaranteed.

First, according to the merging algorithm in the Puzzle system (Chapter 4), each

time when two ontologies are merged, the resultant one will contain all information

from both original ones. Next, Lemma 1 and Theorem 1 are introduced.

Lemma 1. When two ontologies, A and B, are merged using the algorithm in Puzzle,

the result is the same, regardless of whether A is merged into B or B is merged into A.

Proof by induction:

1. Base Case: Both A and B contain two concepts, i.e., besides one common built-

in root, “Thing,” A contains C1 and B contains C2.

If A is merged into B according to the top-level merging procedure in Puzzle,

“Thing” in A is considered equivalent with “Thing” in B; then C1 is compared

with all the direct children of the root in B, in this case C2, to determine where to

put C1 in B. This is based on the relocate function inside the top-level merging

107

procedure. On the contrary, if B is merged into A, “Thing” in B is considered

equivalent with “Thing” in A; then C2 is compared with C1 to determine where

to put C2 in A. Obviously, the same merged ontology is obtained in both cases.

2. Induction: Assume that Lemma 1 holds for all cases where the numbers of con-

cepts contained in A and B are less than (i+1) and (j+1), respectively. Now

consider the case where A and B contain (i+1) and (j+1) concepts, respectively.

Suppose the superClass set of the (i+1)th concept in A, Ci+1, is PA(Ci+1), and

suppose the location of PA(Ci+1) in merged ontology M is PM(Ci+1). The po-

sition of Ci+1 in M is determined by the relationships between Ci+1 and all the

direct children of PM(Ci+1). From the inductive hypothesis it is known that

PM(Ci+1) is identical no matter whether A is merged into B or B is merged into

A. Therefore, the position of Ci+1 in M will also be the same in both situations.

That is, Ci+1 , the (i+1)th concept in A, will be put into the same position in M

in both merging orders. Similarly, the (j+1)th concept in B will also be put into

the same position in M in both merging orders. Therefore, in the case where

A and B contain (i+1) and (j+1) concepts, respectively, the same resultant

ontology is obtained regardless of the merging order taken.

Theorem 1. The final result of merging a number of ontologies is identical, no mat-

ter by which order the original ontologies are merged using the algorithm in Puzzle.

Proof by induction:

1. Base Case: There are two ontologies to be merged.

According to Lemma 1, when two ontologies, A and B, are merged, the result

108

is the same no matter whether A is merged into B, or B is merged into A.

2. Induction: Assume that Theorem 1 holds for all cases where the number of

ontologies to be merged is less than (n+1). Now consider the case where (n+1)

ontologies are merged.

Let the indexes of these ontologies be: 1, 2, ..., (n+1). Consider two arbitrary

orders by which these (n+1) ontologies are merged: order1 and order2. Suppose

the last indexes in order1 and order2 are i and j, respectively.

• If i equals j, then the first (n) indexes in order1 and order2 are the same,

just in different orders. The first (n) ontologies are merged to get Mergedn.

According to the inductive hypothesis, Mergedn in order1 is identical with

Mergedn in order2. Then Mergedn is merged with the last ontology in

both order1 and order2, and the same result will be obtained.

• If i does not equal j, the first (n) indexes in order1 are mutated such that

the nth index be j; then the first (n) indexes in order2 are mutated such that

the nth index be i. Now the first (n-1) indexes in order1 and order2 are in

common (possibly in different orders), and the last two are (j, i) and (i, j),

respectively. Notice that this kind of mutation will not affect the merging

result of the first (n) ontologies according to our inductive hypothesis. The

first (n-1) ontologies are then merged to get Mergedn−1. According to the

hypothesis, Mergedn−1 in order1 is identical with Mergedn−1 in order2.

Finally Mergedn−1 is merged with the last two ontologies in both order1

and order2, and the same result will be obtained.

109

Complexity of Compatibility Vectors—An Efficient Approach

• The time complexity of establishing an EBC, along with the achievement of

a mutual understanding of ontological concepts, is on the order of O(mn2),

with n the number of the concepts in the center, and m the number of original

ontologies. The process of creating an EBC is the one to generate a merged

center. For the ontology merging, O(mn2) is needed, because m ontologies need

to be merged, and each merging procedure takes time O(n2), as described in

Section 4.3.1.

• In order to dynamically update the compatibility vectors during the formation

of an EBC, extra time will be spent. According to the previous analysis in

Section 6.4.3, O(nlogn) is needed for updating one partner, so the extra time for

all partners is O(mnlogn). Therefore, the total time complexity of establishing

an EBC becomes O(mn2 + mnlogn), which is still on the order of O(mn2).

• For the update after an EBC is formed, the time complexity is O(n2), because

only one merging process is carried out.

• For partner selection, the time complexity is O(n2), because only the comparison

between the ontology from the requesting partner and the center is needed.

6.5 Evaluation

6.5.1 Test Ontologies

The test ontologies for evaluating the Compatibility Vector system are the same as

those in Section 4.4, i.e., a collection of sixteen ontologies for the domain of “Building”

110

from computer science students, and ten real-world ontologies in “Business” domain.

6.5.2 Experiment Set One

Experiment Design

1. One original ontology (randomly chosen) is fixed as the one from the coordination-

requesting partner.

2. An EBC is simulated out of the remaining five, ten, and fifteen ontologies as

three experiment settings.

3. For each setting the following is carried out in two groups. In the first group

the requesting partner always interacts with those with the best compatibil-

ity, according to concept distances calculated; while in the second group the

interaction happens with a randomly chosen partner.

4. The resultant merged ontologies from two groups are then compared.

Experiment Result

The results are plotted in Figure 6.5. It is clear that, after adopting the compati-

bility vectors, both Precision and Recall have been improved. Therefore, in cases

where sufficient resources are not available and only a certain number of partners can

be chosen for coordination, compatibility vectors increase the efficiency by choosing

suitable partners.

111

Figure 6.5: Utility of Compatibility Vectors—Experiment Set One

6.5.3 Experiment Set Two

Experiment Design

1. One original ontology (randomly chosen) is fixed as the one from the coordination-

requesting partner.

2. An EBC is simulated out of the remaining nine ontologies in two settings.

3. In the first setting, the requesting partner interacts with a randomly chosen

partner; while in the second setting, this interaction always happens with the

partner with the best compatibility, according to concept distances calculated.

4. The fixed ontology is switched from the first one to the tenth one, then the

average values of Precision and Recall are calculated for all settings.

112

Figure 6.6: Utility of Compatibility Vectors—Experiment Set Two

Experiment Result

The results are plotted in Figure 6.6. It is clear that, after adopting the compati-

bility vectors, both Precision and Recall have been improved. Therefore, in cases

where sufficient resources are not available and only a certain number of partners can

be chosen for coordination, compatibility vectors increase the efficiency by choosing

suitable partners.

113

Chapter 7

Future Work

7.1 Future Work for Three Systems in this Thesis

7.1.1 Puzzle System

1. To take into consideration other relationships during the matching process, such

as partOf , hasPart, causeOf , and hasCause, etc.

2. To integrate the OWL Validator into the Puzzle system, such that the post-

match manual efforts could be further reduced.

7.1.2 SOCCER System

1. The focus has been on locating equivalent concepts, leaving other mapping

tasks, e.g., discovering parent-child pairs, as future work.

2. Another possible future work is to include other relationships besides sub/superClassOf

into the matching process. This might result in requiring multilayer artificial

neural networks.

114

7.1.3 Compatibility Vector System

1. How to handle the vulnerability issue inherent in the centralized solution that

the current approach uses?

2. What kind of mechanism is suitable if qualities of both ontologies and services

are considered simultaneously?

7.2 Future Work for Other Approaches

Instead of applying a single technique, it is possible to investigate a heuristic-

combination approach, including Puzzle, SOCCER, and the following three ad-

ditional ones.

1. CSP-Based Ontology Matching. To determine the semantics of an ontology

concept, it is necessary to consider its name, its properties, and its relationships.

Therefore, whether or not two concepts are equivalent to each other really de-

pends on whether or not there is agreement (to some extent) on these three

aspects. Based on this insight, the ontology-matching problem can be viewed

as the satisfaction of a set of domain-independent constraints.

Several challenges are envisioned here:

• A constraint is needed for each pair of concepts. Suppose that each

constraint only considers concept names, concept properties, and subClas-

sOf relationships. Even for this minimum set, the satisfaction of each con-

straint cannot be decided until the satisfaction of the constraints among

corresponding superclasses has been determined. This in fact results in a

115

top-down breadth-first traverse of graphs. If other relationships are consid-

ered, the situation is worse. For example, if the superClassOf relationship

is added, then a loop will be generated.

• Failed satisfaction of part of the constraint does not necessarily

deny a pair of equivalent concepts. For classic CSP, if after an exhaus-

tive search (e.g., backtracking search) no value assignment can be found to

satisfy the constraints, it is safe to say that there is no solution. However,

for the ontology-matching problem, it is likely that two equivalent concepts

from different ontologies will not agree on every aspect. For example, they

might agree on concept names and properties while disagreeing on concept

relationships, which means the constraint is not satisfied.

• It is difficult to determine the thresholds. The possible constraint

adopted is “a certain degree of similarity in name and a certain degree of

similarity in properties and a certain degree of similarity in relationships.”

It is not trivial to predefine these thresholds, and there is no obvious way

to adjust them if they do not work well.

Despite the above challenges, CSP-Based Ontology Matching is worthy of re-

search. The first difficulty is not just for CSP. One possible solution is to ignore

some less important information. The second difficulty actually originates from

the third. If there exists a solution to handle the threshold issue (possibly by

applying machine learning techniques), then the second challenge will be solved

as well, by a straightforward revision of any classic CSP algorithm.

2. Graph Isomorphism-Oriented Ontology Matching. Graph isomorphism

116

is an area that has attracted a significant amount of research. There are two

kinds of isomorphism, graph-graph and graph-subgraph, of which the latter is

more suitable for being applied to the ontology-matching problem. Out of the

three semantic aspects of an ontology concept, its name and properties can

be regarded as the linguistic part, while its relationships can be viewed as the

structural part. This provides the foundation to solve the ontology-matching

problem through graph isomorphism.

The main idea is that we do not know which one of the linguistic and struc-

tural parts plays a more important role in determining the concept semantics.

If the semantics depends more on the structure, then it is possible to apply

isomorphism algorithms to select a set of candidate concept pairs. Those con-

cepts within each candidate pair have a common feature, that is, the structures

of the subgraphs rooted by those concepts in this pair are identical to (classic

morphing) or similar with (revised morphing) each other. After obtaining all

candidate concept pairs, those unlikely pairs are then filtered out by checking

the corresponding linguistic constraints, and a final matching result is therefore

obtained.

The potential drawback of this approach is its typically high time and/or space

complexity to perform the graph isomorphism. It is well known to be NP-

complete and therefore has no linear time complexity solution. Nevertheless,

this approach is still feasible in theory.

3. Google-Aided Ontology Matching. By typing a pair of concepts in ques-

tion, and analyzing the returning hits from Google, indications might be ob-

117

tained regarding how similar these two concepts are, through the frequency in

which they appear together. Google provides copious, although shallow on-

tological knowledge. A potential challenge is that if only schema information

is utilized and if the concept names are uncommon, then help from a Google

search might not be significant enough.

118

Chapter 8

Conclusion

Ontologies are formal, declarative knowledge representation models, they form a se-

mantic foundation for many domains. The importance of ontologies increases as the

Semantic Web gains attention as the next generation of the Web. However, because

ontological heterogeneity is problematic, there is a need for ontologies from different

sources to be related and possibly reuse each other’s concepts. In addition, because

the approach of a global ontology is not feasible, and because a manual matching

process has many drawbacks, tools for ontology matching are in great need. De-

spite the importance of ontology matching and the number of researchers that have

investigated it, it is far from being solved.

In this thesis, six assumptions are made to bound the ontology-matching problem;

then the constraints exploited are explained when analyzing concept semantics; after

that, three systems are presented towards the mutual understanding and reconcilia-

tion of concepts from different ontologies.

The Puzzle system is a completely automated rule-based ontology-matching ap-

proach. It exploits the semantics of concept name, concept properties, and concept

relationships; then it applies a set of reasoning rules to infer the newly obtained

knowledge. A set of experiments show the promising performance.

The SOCCER (Similar Ontology Concept ClustERing) system is mostly a learning-

based approach, integrated with some rule-based techniques, to match heterogeneous

119

ontologies. A neural network is applied to learn weights for different semantic aspects;

then an agglomerative algorithm is adopted to cluster similar concepts. SOCCER is

the first approach to learn ontology schemas based on schema information alone,

aiming to take advantage of both rule-based and learning-based matching techniques.

The Compatibility Vector system is not an ontology-matching algorithm by itself,

but instead is a means of measuring and maintaining ontology compatibility, which

helps in the mutual understanding of ontologies and determines the compatibility of

services (or agents) associated with these ontologies. This approach is precise and

efficient, verified by both theoretic proofs and experimental results.

The above three systems are explained and analyzed in detail, along with the

corresponding evaluations. Finally, some future work in ontology-matching area has

been envisioned.

The hypothesis addressed in this thesis has been evaluated successfully. It has

been shown that ontologies developed independently, but for related domains, can be

reconciled by using a combination of rule-based and learning-based matching algo-

rithms. These algorithms can exploit the similarities that might occur in heteroge-

neous ontologies, due to the use of common languages or common structures. That

is, via the help from the rule-based and learning-based matching algorithms, a better

mutual understanding of heterogeneous semantics has been achieved among different,

distributed parties. In addition, interoperability among autonomous applications has

increased as well.

120

Bibliography

[1] JWNL (Java WordNet Library) 1.3. http://sourceforge.net/projects/jwordnet,

June 2006.

[2] M. Afsharchi, B.H. Far, and J. Denzinger. Ontology-guided learning to improve

communication between groups of agents. In Proceedings of the Fifth Interna-

tional Joint Conference on Autonomous Agents and Multiagent Systems (AA-

MAS 06), Hakodate, Japan, May 2006.

[3] H. Alani. Position paper: Ontology construction from online ontologies. In

Proceedings of the Fifteenth International World Wide Web Conference (WWW

06), Edinburgh, UK, May 2006.

[4] H. Alani and C. Brewster. Ontology ranking based on the analysis of concept

structures. In Proceedings of the Third International Conference on Knowledge

Capture (K-CAP 05), Banff, Alberta, Canada, October 2005.

[5] D. Beeferman and A. Berger. Agglomerative clustering of a search engine query

log. In Proc. KDD 00, Boston, MA, August 2000.

[6] T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. Scientific Amer-

ican, 284(5):34–43, 2001.

[7] A.S. Bilgin and M.P. Singh. A daml-based repository for qos-aware semantic

web service selection. In Proceedings of IEEE International Conference on Web

Services (ICWS 04), San Diego, CA, July 2004.

121

[8] M.H. Burstein and D.V. McDermott. Ontology translation for interoperability

among semantic web services. AI Magazine, 26(1):71–82, Spring, 2005.

[9] D. Calvanese and G.D. Giacomo. Data integration: A logic-based perspective.

AI Magazine, 26(1):59–70, Spring, 2005.

[10] D. Calvanese, G.D. Giacomo, D. Lembo, M. Lenzerini, and R. Rosati. Dl-lite:

Tractable description logics for ontologies. In Proceedings of the Twentieth Na-

tional Conference on Artificial Intelligence (AAAI 05), Pittsburgh, PA, July

2005.

[11] S. Castano, A. Ferrara, and S. Montanelli. H-match: an algorithm for dynami-

cally matching ontologies in peer-based systems. In Proceedings of the first VLDB

International Workshop on Semantic Web and Databases (SWDB 03), Berlin,

Germany, September 2003.

[12] S. Castano, A. Ferrara, S. Montanelli, E. Pagani, and G.P. Rossi. Ontology-

addressable contents in p2p networks. In Proceedings of the First WWW Inter-

national Workshop on Semantics in Peer-to-Peer and Grid Computing (SemP-

GRID 03), Budapest, Hungary, May 2003.

[13] S. Castano, A. Ferrara, S. Montanelli, and G. Racca. Matching techniques for

resource discovery in distributed systems using heterogeneous ontology descrip-

tions. In Proceedings of the International Conference on Information Technology:

Coding and Computing (ITCC 04), Las Vegas, NV, April 2004.

122

[14] P. Cimiano, A. Hotho, and S. Staab. Comparing conceptual, divisive and ag-

glomerative clustering for learning taxonomies from text. In Proc. ECAI 04,

Valencia, Spain, August 2004.

[15] X. Cui, J. Gao, and T. Potok. A flocking based algorithm for document clustering

analysis. Journal of Systems Architecture, 52(8):505–515, 2006.

[16] Cyc. http://www.cyc.com, June 2006.

[17] J. Diggelen, R.J. Beun, F. Dignum, R.M. Eijk, and J. Meyer. Anemone: An

effective minimal ontology negotiation environment. In Proceedings of the Fifth

International Joint Conference on Autonomous Agents and Multiagent Systems

(AAMAS 06), Hakodate, Japan, May 2006.

[18] Z. Ding, Y. Peng, and R. Pan. A bayesian approach to uncertainty modeling

in owl ontology. In Proceedings of the International Conference on Advances in

Intelligent Systems - Theory and Applications, Luxembourg, November 2004.

[19] Z. Ding, Y. Peng, R. Pan, and Y. Yu. A bayesian methodology towards auto-

matic ontology mapping. In Technical Report WS-05-01 of AAAI Workshop on

Contexts and Ontologies: Theory, Practice, and Applications, Pittsburgh, PA,

July 2005.

[20] H. Do and E. Rahm. Coma–a system for flexible combination of schema matching

approaches. In Proceedings of the Twenty-eighth VLDB Conference, Hong Kong,

China, 2002.

[21] A. Doan and A.Y. Halevy. Semantic integration research in the database com-

munity: A brief survey. AI Magazine, 26(1):83–94, Spring 2005.

123

[22] A. Doan, J. Madhavan, R. Dhamankar, P. Domingos, and A. Halevy. Learning

to match ontologies on the semantic web. The VLDB Journal, 12(4):303–319,

Springer-Verlag, New York, NY, USA, 2003.

[23] D. Dou, D. McDermott, and P. Qi. Ontology translation by ontology merging and

automated reasoning. In Technical Report of the European Knowledge Acquisition

Workshop on Ontologies for Multiagent Systems, Bologna, Italy, July 2002.

[24] D. Dou, D. McDermott, and P. Qi. Ontology translation on the semantic web.

In Proceedings of the International Conference on Ontologies, Databases, and

Applications of Semantics, Lecture Notes in Computer Science, Berlin: Springer-

Verlag, 2003.

[25] A. Firat, S. Madnick, and F. Manola. Multi-dimensional ontology views via

contexts in the ecoin semantic interoperability framework. In Technical Report

WS-05-01 of AAAI Workshop on Contexts and Ontologies: Theory, Practice,

and Applications, Pittsburgh, PA, July 2005.

[26] H. Gagliardi, O. Haemmerle, N. Pernelle, and F. Sais. An automatic ontology-

based approach to enrich tables semantically. In Technical Report WS-05-01 of

AAAI Workshop on Contexts and Ontologies: Theory, Practice, and Applica-

tions, Pittsburgh, PA, July 2005.

[27] F. Giunchiglia, P. Shvaiko, and M. Yatskevich. Semantic schema matching. In

Proceedings of the Thirteenth International Conference on Cooperative Informa-

tion Systems (CoopIS 05), Agia Napa, Cyprus, November 2005.

124

[28] P.F. Green, M. Rosemann, , and M. Indulska. Ontological evaluation of enterprise

systems interoperability using ebxml. IEEE Transactions on Knowledge and

Data Engineering, 17(5):713–725, 2005.

[29] M. Gruninger and J.B. Kopena. Semantic integration through invariants. AI

Magazine, 26(1):11–20, Spring, 2005.

[30] B. He and K.C. Chang. Statistical schema matching across web query interfaces.

In Proceedings of SIGMOD 03, San Diego, CA, June 2003.

[31] S. Kalepu, S. Krishnaswamy, and S.W. Loke. Reputation = f(user ranking,

compliance, verity). In Proceedings of IEEE International Conference on Web

Services (ICWS 04), San Diego, CA, July 2004.

[32] P. Leenheer and A. Moor. Context-driven disambiguation in ontology elicitation.

In Technical Report WS-05-01 of AAAI Workshop on Contexts and Ontologies:

Theory, Practice, and Applications, Pittsburgh, PA, July 2005.

[33] DAML Ontology Library. http://www.daml.org/ontologies, June 2006.

[34] J. Madhavan, P.A. Bernstein, A. Doan, and A. Halevy. Corpus-based schema

matching. In Proceedings of the Twenty-first International Conference on Data

Engineering (ICDE 05), Tokyo, Japan, April 2005.

[35] J. Madhavan, P.A. Bernstein, and E. Rahm. Generic schema matching with

cupid. In Proceedings of the Twenty-seventh VLDB Conference, Roma, Italy,

2001.

125

[36] D.L. McGuinness. Ontologies for electronic commerce. In Proceedings of the

AAAI 99 Artificial Intelligence for Electronic Commerce Workshop, Orlando,

Florida, July 1999.

[37] D.L. McGuinness, R. Fikes, J. Rice, and S. Wilder. The chimaera ontology

environment. In Proceedings of the Seventeenth National Conference on Artificial

Intelligence (AAAI 00), Austin, TX, July 2000.

[38] S. Melnik, H. Garcia-Molina, and E. Rahm. Similarity flooding: A versatile graph

matching algorithm and its application to schema matching. In Proceedings of

the Eighteenth International Conference on Data Engineering (ICDE 02), San

Jose, CA, 2002.

[39] M. Michalowski, S. Thakkar, and C.A. Knoblock. Automatically utilizing sec-

ondary sources to align information across sources. AI Magazine, 26(1):33–44,

Spring, 2005.

[40] A.G. Miller. Wordnet: A lexical database for english. Communications of the

ACM, 38(11):39–41, ACM Press, 1995.

[41] T. Milo and S. Zohar. Using schema matching to simplify heterogeneous data

translation. In Proceedings of the Twenty-fourth VLDB Conference, New York,

NY, 1998.

[42] T. Mitchell. Machine Learning. McGraw-Hill, 1997.

[43] P. Mitra, G. Wiederhold, and M. Kersten. A graph-oriented model for articula-

tion of ontology interdependencies. In Proceedings of the Seventh International

Conference on Extending Database Technology, Konstanz, Germany, March 2000.

126

[44] N.F. Noy and M.A. Musen. Prompt: Algorithm and tool for automated ontol-

ogy merging and alignment. In Proceedings of the 17th National Conference on

Artificial Intelligence (AAAI 00), AAAI Press, Menlo Park, CA, USA, 2000.

[45] N.F. Noy and M.A. Musen. Anchor-prompt: Using non-local context for seman-

tic matching. In Proceedings of the Workshop on Ontologies and Information

Sharing at the Seventeenth International Joint Conference on Artificial Intelli-

gence (IJCAI 01), Seattle, WA, August 2001.

[46] R. Pan, Z. Ding, Y. Yu, and Y. Peng. A bayesian network approach to ontology

mapping. In Proceedings of the International Semantic Web Conference, Galway,

Ireland, November 2005.

[47] P. Pantel, A. Philpot, and E. Hovy. Data alignment and integration. IEEE

Computer Magazine, 38(12):43–50, 2005.

[48] Protege. http://protege.stanford.edu, June 2006.

[49] D. Ramachandran, P. Reagan, and K. Goolsbey. First-orderized researchcyc:

Expressivity and efficiency in a common-sense ontology. In Technical Report

WS-05-01 of AAAI Workshop on Contexts and Ontologies: Theory, Practice,

and Applications, Pittsburgh, PA, July 2005.

[50] M. Schorlemmer and Y. Kalfoglou. Progressive ontology alignment for meaning

coordination: An information-theoretic foundation. In Proceedings of the Fourth

International Joint Conference on Autonomous Agents and Multiagent Systems

(AAMAS 05), Utrecht, Netherlands, July 2005.

127

[51] A. Segev and A. Gal. Putting things in context: A topological approach to map-

ping contexts and ontologies. In Technical Report WS-05-01 of AAAI Workshop

on Contexts and Ontologies: Theory, Practice, and Applications, Pittsburgh,

PA, July 2005.

[52] M.P. Singh and M.N. Huhns, editors. Service-Oriented Computing - Semantics,

Processes, Agents, 1st edn. Wiley, Chichester, England Press, 2005.

[53] L. Soh and C. Chen. Balancing ontological and operational factors in refining

multiagent neighborhoods. In Proceedings of the fourth international joint con-

ference on Autonomous agents and multiagent systems, The Netherlands, 2005.

[54] L.-K. Soh. Multiagent distributed ontology learning. In Working Notes of the

second AAMAS OAS Workshop, Bologna, Italy, July 2002.

[55] L.-K. Soh. Collaborative understanding of distributed ontologies in a multiagent

framework: Design and experiments. In Proceedings of the Third International

Workshop on Ontologies in Agent Systems (OAS 03), Melbourne, Australia,

2003.

[56] L. Stephens, A. Gangam, and M.N. Huhns. Constructing consensus ontologies for

the semantic web: A conceptual approach. World Wide Web Journal, 7(4):421–

442, Kluwer Academic Publishers, 2004.

[57] Swoogle. http://swoogle.umbc.edu, June 2006.

[58] Y.A. Tijerino, D.W. Embley, D.W. Lonsdale, Y. Ding, and G. Nagy. Towards on-

tology generation from tables. World Wide Web: Internet and Web Information

Systems, 8(3):261–285, 2005.

128

[59] O. Udrea, Y. Deng, E. Ruckhaus, and V.S. Subrahmanian. A graph theoret-

ical foundation for integrating rdf ontologies. In Proceedings of the Twentieth

National Conference on Artificial Intelligence (AAAI 05), Pittsburgh, PA, July

2005.

[60] F. Wiesman and N. Roos. Domain independent learning of ontology mappings. In

Proceedings of the Third International Joint Conference on Autonomous Agents

and Multiagent Systems (AAMAS 04), New York, NY, July 2004.

[61] A.B. Williams. Learning to share meaning in a multi-agent system. Autonomous

Agents and Multi-Agent Systems, 8(2):165–193, Kluwer Academic Publishers,

The Netherlands, 2004.

[62] A.B. Williams, T.A. Krygowski, and G. Thomas. Using agents to reach an

ontology consensus. In Proceedings of the First International Joint Conference

on Autonomous Agents and Multiagent Systems (AAMAS 02), Bologna, Italy,

July 2002.

[63] A.B. Williams, A. Padmanabhan, and M.B. Blake. Local consensus ontologies

for b2b-oriented service composition. In Proceedings of the Second International

Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS 03),

Melbourne, Australia, July 2003.

[64] A.B. Williams and Z. Ren. Agents teaching agents to share meaning. In Pro-

ceedings of Fifth International Conference on Autonomous Agents (AGENTS

01), Montreal, Canada, May 2001.

129

[65] A.B. Williams and C. Tsatsoulis. Diverse web ontologies: What intelligent agents

must teach to each other. In AAAI Spring Symposium on Intelligent Agents in

Cyberspace, Stanford University, March 1999.

[66] C. Zhou, L. Chia, and B.S. Lee. Daml-qos ontology for web services. In Proceed-

ings of IEEE International Conference on Web Services (ICWS 04), San Diego,

CA, July 2004.

130