A Framework for the Automated Alignment of Ontologies

Transcription

1 A Framework for the Automated Alignment of Ontologies Computer Science Masters Project Final Report University of Colorado, Colorado Springs By Justin Gray Advisory Committee Dr. Jugal Kalita Dr. Edward Chow Dr. Tim Chamillard April 29, 2008

2 Table Of Contents Chapter 1 - Introduction... 5 Chapter 2 - Background Research... 6 Ontology... 6 Alignment / Related Work... 6 COMA FalconAO... 6 RiMOM... 7 Chapter 3 - Problem Statement... 8 Chapter 4 - Architecture Chapter 5 - Implementation Interfaces IEvidence IOntology IRelation ISemanticDiscovery Threading and Event Model Evidence Relation Expression Parsing Examples Aligner Data Types EvidenceResult RelationResult Argument Implemented Evidences Hyponymy Pattern Hyponymy Pattern

3 Hyponymy Pattern Relation in Phi Pattern Relation in Phi Pattern Meronymy Pattern Meronymy Pattern Disjoint Pattern Disjoint Pattern Implemented Semantic Discovery Mechanisms WordNet Implemented Relations Generic Relation Tools Used Programming Languages Development Environments Libraries Application Server Database Web Based Interface SOAP Web Service JSP Human Interaction Chapter 6 Results Examples Success Criteria Results Hyponymy Pattern Hyponymy Pattern Hyponymy Pattern Relation in Phi Pattern Relation in Phi Pattern Meronymy Pattern

4 Meronymy Pattern Disjoint Pattern Disjoint Pattern Chapter 7 - Conclusions, Future Research Problems Encountered Wikipedia OpenCyc Robust Ontologies Well Defined Ontologies Manual Alignment References Appendix A Schemas Appendix B Ontologies Used for Testing Ontology Ontology Ontology Ontology Ontology Appendix C Alignment Results Appendix D Tools Java NetBeans Eclipse Jena WordNet Tomcat MySQL

5 Table Of Figures Figure 1 - A Brief Example of Hyponymy... 8 Figure 2 - Architecture Diagram Figure 3 - Required Ontology Concepts Figure 4 - Required Semantic Discovery Concepts Figure 5 - Hyponymy Pattern 1 Diagram Figure 6 - Hyponymy Pattern 2 Diagram Figure 7 - Hyponymy Pattern 3 Diagram Figure 8 - Relation in Phi Pattern 1 Diagram Figure 9 - Relation in Phi Pattern 2 Diagram Figure 10 - Meronymy Pattern 1 Diagram Figure 11 - Meronymy Pattern 2 Diagram Figure 12 - Disjoint Pattern 1 Diagram Figure 13 - Disjoint Pattern 2 Diagram Figure 14 - Ontology Figure 15 - Ontology

6 Chapter 1 - Introduction In a perfect world everyone could agree on an organized description of the world. Unfortunately even domain experts are unable to agree on how we describe the world around us. The World Wide Web has brought us formalized machine readable languages (e.g. [1]OWL 1 ) to express meaning using ontologies. With the recent push toward Web 3.0 there has been an explosion in the number of ontologies and it s no surprise that they rarely describe the world in exactly the same way. Take for instance the word Mustang. Let us assume Mustang has been used as a class name in two different ontologies. With a cursory analysis we might be led to believe that these two words describe the same concept, but this might not always be the case. Upon closer inspection we notice that in the first ontology Mustang is a subclass of something called a Horse, and in the other ontology it is a subclass of something called an Automobile perhaps these two aren t so similar. In this project we provide an automated mechanism to align ontologies using analysis that is deeper than that of simple word association. This will be achieved through the use of a web based application while simultaneously providing a web service based machine to machine interface and an open, extensible programmatic API. 1 Web Ontology Language, an extension of RDF (Resource Description Framework) 5

7 Chapter 2 - Background Research Ontology The concept of ontology is deeply tied to its original definition in the study of philosophy; it has existed since the time of Aristotle [2] and has been used to better the understanding of the world around us for millennia. The computer science definition of ontology is quite similar to that used in philosophy and can be accurately described to define[s] a set of representational primitives with which to model a domain of knowledge or discourse. The representational primitives are typically classes (or sets), attributes (or properties), and relationships (or relations among class members). The definitions of the representational primitives include information about their meaning and constraints on their logically consistent application. [8] While this is not the only definition of ontology, it will fit our needs quite well. Alignment / Related Work The problem of aligning ontologies has been approached in many different ways. Some of the most successful alignment approaches have been COMA++ [3], FalconAO [4] and RiMOM [5]. While there have been several recent papers written on the topic of ontology alignment [6, 7], the most successful methods used were restrictive and not easily extensible, furthermore they could only discover equivalence relations across ontologies. Below is a description of three very recent papers on the topic. COMA++ An automatic match process in COMA consists of several steps. In the first step the imported schemas and ontologies are transformed into a generic graph representation. The graph nodes represent schema/ontology components such as classes or properties and have attributes like name and data type. All relationships, e.g. aggregations and specializations, are uniformly represented by edges between nodes. In the next step graph nodes are matched with each other using a match strategy and matchers. There is no differentiation made between node types, so that for example classes and properties can be matched. The similarity values obtained by the individual matchers are aggregated according to a combination strategy (average, etc.). The match candidates are selected from the aggregated correspondences, e.g. based on a threshold criterion. Finally, the result mapping (RDF alignment) is generated. [3] FalconAO There are two matchers integrated in Falcon-AO: one is a matcher based on linguistic matching for ontologies, called LMO; the other is a matcher based on graph matching for ontologies, called GMO. LMO combines two different approaches to gain linguistic similarities: one is based on lexical comparison; the other is based on statistic analysis. GMO uses directed bipartite graphs to represent ontologies and measures the structural similarity between graphs by a new measurement. [4] 6

8 RiMOM Using a Bayesian risk minimization model RiMOM calculates a minimum risk mapping across ontologies for alignment purposes. [5] 7

9 Chapter 3 - Problem Statement To align ontologies it is necessary to understand both the relationships between classes internal to the ontologies to be aligned and the relationships between the ontologies. Within an ontology the relationship between classes is explicitly defined by the ontology itself. Between ontologies the relationship is less clear; we will rely upon the class names within the ontologies, which represent the name of a thing or concept, to align the ontologies. Specifically it is the relationships between the ontologies that we intend to discover. We can begin to solve this problem by defining the concept of Evidence. Evidence is assigned as an arbitrary score that indicates the likelihood of a semantic relationship between two classes. Take for instance, evidence of hyponymy [6]; where a word is a specific subclass of a more general word. If in Ontology-A there is a class named Canine and in Ontology-B there is a class named Canine, we are very fortunate as these two words are perfect synonyms 2. In Ontology-A Beagle is a subclass of Canine and can be understood to be a hyponym of Canine in Ontology-A, from this we can infer that Beagle in Ontology-A is a subclass (hyponym) of Canine in Ontology-B. Figure 1 - A Brief Example of Hyponymy 2 It s important to note this is not always the case, i.e. Mustang the car and Mustang the horse. But for the purposes of this example, let s assume Canine is referring to an animal and not a type of tooth, or anything else. 8

10 The relationships on the left of Figure 1 represent concepts that we can test for between our two ontologies, the relationships on the right are implied by the evidence we find on the left. We call this arrangement of Evidence a Pattern[6], when the scores derived from patterns are placed in a weighted formula we have the full concept of a Relation, this is the final result of alignment as it is our best calculated guess as to the relationship between classes of disparate ontologies. We propose to provide a framework for ontology alignment that leverages this basic approach. The framework will provide constructs required to instantiate and process ontologies for alignment. More details regarding evidence patterns are described later in this document. It becomes immediately obvious that there can be any number of different evidence types and patterns derived from the known relationships between classes. Furthermore, with the number of classes in ontologies it becomes apparent that to find appropriate relationships we must be able to compare (worst case) every class in an ontology to every class in its comparable ontology at least once. To address the computational complexity of these problems the system built exploits parallelism by searching for multiple patterns across the ontologies simultaneously. 9

11 Chapter 4 - Architecture The ontology alignment API was designed to allow the user to define custom methods of alignment thus removing the restriction of one general approach to ontology alignment. This approach is simple, yet powerful and easily extensible. Figure 2 - Architecture Diagram From the bottom up a user must provide (or utilize the existing interfaces) an interface to a semantic discovery mechanism. This semantic discovery mechanism, such as WordNet is generic and can be used by concepts called evidence. Evidence is gathered by searching for patterns within and across ontologies that either support or oppose the formation of relationships between classes in two ontologies (see examples). Evidence is also weighted by the user- the weights can be used by Java classes called Relations. A relation is tasked with gathering evidence to support it, and it is also tasked with evaluating a weighted equation built with the weights gathered from evidence. Each of the concepts: Evidence, Relation, Semantic Discovery and Ontology are meant to be utilized as interfaces. The API defines only an interface to each of the mechanisms required for ontology 10

12 alignment; this provides the user an extensible interface for to define their own Evidence, Relations, Semantic Discovery and Ontology. The API also provides some implementations that can be used out of the box for ontology alignment. For instance Semantic Discovery; the API provides access to WordNet [See Appendix D] as the base input to Evidence Primitives. The API also provides an execution model, designed to instantiate and manage all of the above mentioned concepts in a generic fashion. It is this alignment engine that allows the user to rapidly develop, test and deploy new alignment approaches. To further facilitate rapid alignment we have built an easy to use, web-based front end to the API and a machine-to-machine SOAP-based web service to the API. Both will allow the user to adjust the weights of Evidence for the purpose of providing the best discovery of Relations between ontologies. Aligning ontologies becomes computationally complex very quickly, in the majority of situations we must at least compare every class in one ontology to every class in the other ontology leading to a O(n 2 ) complexity 3. Due to the complexity of aligning ontologies we utilize a multi-threaded approach to discovering relations across the ontologies where each pattern is searched in parallel across the ontologies using different worker threads. This provides a scalable, high performance alignment system. 3 We do acknowledge that there are situations where this could be worse or better and intend to provide analysis of this complexity 11

13 Chapter 5 - Implementation In this section we describe the alignment APIs implementation details. These details are essential to understanding the operation of the alignment mechanism and give good insight for any user desiring to utilize this API to perform their own ontology alignment. Interfaces The ontology alignment API achieves extensibility by defining a set of interfaces that allow the user to provide their own implementations for the basic constructs needed to represent and align ontologies. IEvidence The IEvidence interface requires that the user provide it with two implementations of IOntology and an implementation of ISemanticDiscovery. The interface specifies the requirement for methods to get and set Weight, which is a unitless double precision floating point number used to represent the weight of the results provided by the evidence implementation 4. IEvidence only specifies a single method hasrelationship() which returns a list of EvidenceResult An implementation of IEvidence may use whatever means the user desires to determine its EvidenceResult list. The general pattern for determining evidence is to implement an algorithm that reasons over the two input ontologies using methods inherent to the ontology structure (provided by IOntology) and methods provided by its implementation of ISemanticDiscovery. Once the algorithm is complete it should populate the EvidenceResult list with the appropriate representation of its alignment. Details of this population are explained below in EvidenceResult. IOntology The IOntology interface allows the user to define a representation of an ontology using whatever source or structure they desire. The only restriction placed on the representation of an ontology is that the user must provide the following concepts: 4 Note this can be negative; finding evidence contradicting a relationship is a valid and encouraged, finding. 12

14 Required Concept <Argument> Get All Class Names <> Get All Subclasses <Class Name> Get All Superclasses <Class Name> Get All Equivalent Classes <Class Name> Get All Disjoint Classes <Class Name> Description This is the simplest of all the required methods, it simply requires that the user return a complete list of all of the classes in her ontology. This method takes as input the name of a class within the user s ontology, it will then return all of the subclasses of the provided class. This method takes as input the name of a class within the user s ontology, it will then return all of the superclasses of the provided class. This method takes as input the name of a class within the user s ontology, it will then return all of the classes equivalent to the provided class. This method takes as input the name of a class within the user s ontology, it will then return all of the classes disjoint to the supplied class. Figure 3 - Required Ontology Concepts By providing this interface we allow the user to seamlessly interface to any representation of an ontology they can imagine (provided it can represent the required concepts). For instance, in this application we provide access to any generic OWL ontology, OpenCyc 5, DAML 6,Wikipedia 7, etc. all using the same interface. IRelation IRelation is extremely simple in its interface, yet can become quite complex in its implementation. The only required method for the relation is findrelation() which only requires two ontologies. 5 OpenCyc is the open source version of the Cyc ontology. This extremely large general knowledge base contains millions of assertions about the concepts it covers. 6 DARPA Agent Markup Language 7 There have been various attempts to glean semantic information from the articles and links contained within Wikipedia [9] due to its wide variety of information and semi structured format. 13

15 The implementation of IRelation expects the user to use whatever mechanisms desired to discover true 8 relations between classes in the supplied ontologies. Generally speaking the pattern of implementing a relation is for the user to utilize multiple Evidence implementations to search for evidence supporting relationships between ontologies, place the evidences into a weighted formula (operating off weights assigned to the evidence implementations) that will generate the returned relationships. ISemanticDiscovery The semantic discovery interface provides the user the ability to find semantic relationships between words within its implementations corpus. The required interfaces are in the following table: Required Concept <Argument> Is Synonym <ClassOne, ClassTwo> Is Hyponym <ClassOne, ClassTwo> Is Hypernym <ClassOne, ClassTwo> Is Meronym <ClassOne, ClassTwo> Is Holonym <ClassOne, ClassTwo> Is Entail <ClassOne, ClassTwo> Is Cause-To <ClassOne, ClassTwo> Is Attribute <ClassOne, ClassTwo> Is Pertainym <ClassOne, ClassTwo> Is Antonym <ClassOne, ClassTwo> Is Similarity <ClassOne, ClassTwo> Description Two words that can be interchanged in a context are said to be synonymous relative to that context. A word that is more specific than a given word. A word that is more generic than a given word. A word that names a part of a larger whole. A word that names the whole of which a given word is a part. Have as a logical consequence. Denotes a causal relationship. A noun for which adjectives express values. A relational adjective. A pair of words between which there is an associative bond resulting from their frequent co-occurrence. Denotes not quite synonym, two words are similar in their meaning. Figure 4 - Required Semantic Discovery Concepts Utilizing ISemanticDiscovery the user can leverage whatever corpus of relationships they have at their disposal, e.g. WordNet, dictionary.com, etc A user wishing to extend the concept of semantic 8 True means a real relationship between classes, this means the output of whatever algorithms utilized has determined the relationship to be true between the ontologies. 14

16 discovery may do so, but relations and evidence must also be extended to handle expanded understanding of semantic discovery. Threading and Event Model Depending on the implementations of IEvidence, ISemanticDiscovery and IRelation, execution of the required algorithms could potentially take a great deal of time to complete. As the tasks associated with many of these concepts are independent 9 the alignment API was a good candidate for a multithreaded architecture, as such we have implemented a threading and event model to manage and report on the execution of simultaneous threads of execution. Evidence This portion of the threading and execution model describes how evidence is handled by the alignment API. EvidenceExecutionManager The EvidenceExecutionManager exists as a singleton class that serves as a global point of reference for the addition, removal, execution and result storage of EvidenceThreads. When an EvidenceThread is sent to the EvidenceExecutionManager it is immediately placed into the execution pool. The EvidenceExecutionManager maintains a table containing the current status and UID 10 of each of the threads inside its execution pool. This data structure is exposed via synchronous static methods defined in the EvidenceExecutionManager. EvidenceThread EvidenceThread provides the user with an executable object to which an implementation of IEvidence can be attached. The EvidenceThread will handle the instantiation, execution and cleanup associated with the discovery of evidence. It also provides an event notification mechanism so that interested parties (other classes) may attach status listeners to the evidence thread. These status listeners fire whenever the status of an EvidenceThread changes. Relation This portion of the threading and execution model describes how relations are handled by the alignment API. RelationExecutionManager The RelationExecutionManager exists as a singleton class that serves as a global point of reference for the addition, removal, execution and result storage of RelationThreads. When a RelationThread is sent to the RelationExecutionManager it is immediately placed into the execution 9 Except for the highest level Relation, which requires all of its evidences be found before it can be expressed. 10 Unique Identifier 15

17 pool. The RelationExecutionManager maintains a table containing the current status and UID of each of the threads inside its execution pool, this data structure is exposed via synchronous static methods defined in the RelationExecutionManager. RelationThread RelationThread provides the user with a Runnable object to attach an implementation of IRelation to. The RelationThread handles the instantiation, execution and cleanup associated with the discovery of evidence. It also provides an event notification mechanism so that interested parties (other classes) may attach status listeners to the evidence thread, these status listeners fire whenever the status of an RelationThread changes. Expression Parsing To provide the ability for the user to define a weighted equation for the calculation of relations we defined a simple language for the representation of basic mathematical operations. The language provides constructs for addition, subtraction, multiplication and division of variables and constants, all of which are treated as the Java type double. The alignment API provides a parsing and evaluation class to handle these expressions. This class will be described in more detail in the Implementation section of this paper. The structure of an expression is as follows: (OP arg1 arg2 ) where OP is one of the four reserved words in the language ADD, SUB, MUL, DIV which represent addition, subtraction, multiplication and division respectively. The arguments arg1 and arg2 represent the inputs for the binary operation OP, and must have quotation marks surrounding them when they represent either a constant or a variable. However, an argument can be replaced with another expression without the need for a quotation mark. Examples To perform any operation, all of which are binary in this language, we simply build the expression in the form given above. The simplest case is passing two constants to an operator. Below we enumerate each operation and give its result. Common Representation Expression Result (ADD 4 2 ) (SUB 4 2 ) * 2 (MUL 4 2 ) / 2 (DIV 4 2 ) 2.0 Table 1 - Simple Operations Using this language we can also express nested operations, order of operations is determined by parenthesis, the innermost parenthesis of an expression are evaluated first, then the next most inner and so on. A few examples can be seen in the table below. 16

18 Common Representation Expression Result (4 + 2) * 2.5 (MUL(ADD 4 2 ) 2.5 ) 15.0 (7* 8) / 4 (DIV(MUL 7 8 ) 4 ) 14.0 (4 + 2) *(3 + 7) (MUL(ADD 4 2 )(ADD 3 7 )) 60.0 Table 2 - Nested Operations We can also pass variables to the expression parser. Programmatically we pass them as a type called Argument which has a name and a value, this will be covered in more depth below in the implementation section. For now, it is important only to understand that we have the ability to externally assign values to the variables written in an expression. A few examples are provided below 11. Common Representation Expression Result x = 2 y = 4 (MUL(ADD y x ) 2 ) 12.0 (y + x) * 2 myvariable = 8.5 (DIV (MUL 7 myvariable ) 4 ) (7* myvariable) / 4 (4 + 2) *(3 + 7) (MUL(ADD 4 2 )(ADD 3 7 )) 60.0 Table 3 - Variable Operations Aligner Perhaps the least complex class in the alignment API, the aligner takes in the two ontologies to be aligned and the evidences that provides indicators of the existence of relationships and generates an XML alignment file. This file provides the mapping between classes in the input ontologies to be used to generate a single aligned ontology or used as-is to map between ontologies. The file generated conforms to the schema provided in Appendix A. Data Types This section describes the data types used for passing information between components of the alignment API. As classes they do not implement any significant methods beyond that of providing getters and setters to private data fields. EvidenceResult EvidenceResult provides a basic representation for the resultant of evidence and relation exploration across ontologies. It contains a basic structure that holds four values: ClassOne, ClassTwo, 11 Because it s actually more difficult to express in the common representation, we did not include an example where the variable name had spaces in it, but it should be noted that this is allowed in the expression syntax. 17

19 Relationship, and Weight. These represent two class names, the relationship between them 12 and the unitless double floating point number representing the weight of the relationship. RelationResult RelationResult represents an attempt to provide a basic representation for the result of relations. It contains a list of EvidenceResults and an overall score representing the result of its expression represented as a double. Argument Argument allows the user to associate a value with a name for the purposes of expression evaluation. Generally the user should initialize these with the values resultant from evidence and the names of evidence as the name. Implemented Evidences In this section we describe in detail the types of evidence we implemented in the alignment API. These patterns of evidence represent only a few basic patterns used to demonstrate the functionality of the alignment API. While significantly more complex patterns are possible, these simple patterns serve to provide a template for implementation of evidence in this alignment API. All of these patterns were developed in [6] specifically to explore new methods of ontology alignment. 12 Stored as a String 18

20 Hyponymy Pattern 1 The implementation of Hyponymy Pattern One [6] begins by comparing every class in ontology 1 to every class in ontology 2 searching for a relationship of synonymy, when a relationship of synonymy is found the pair of classes sharing said relationship is noted. After every combination of classes has been explored the algorithm will iterate over the synonymous pairs, each of the classes from ontology 1 that were synonymous to a class in ontology 2 are checked for subclasses, if subclasses exist evidence is noted that the subclasses are hyponyms to the corresponding synonymous in ontology2. This pattern is shown in Figure 5. Figure 5 - Hyponymy Pattern 1 Diagram 19

21 Hyponymy Pattern 2 The implementation of Hyponymy Pattern Two [6] begins by comparing every class in ontology 1 to every class in ontology 2 searching for a relationship of hyponymy, when a relationship of hyponymy is found the pair of classes sharing said relationship is noted. After every combination of classes has been explored the algorithm will iterate over the hyponymy pairs, each of the classes from ontology 1 that were hyponyms to a class in ontology 2 are checked for subclasses, if subclasses exist evidence is noted that the subclasses are hyponyms to the corresponding hyponyms in ontology2. This pattern is shown in Figure 6. Figure 6 - Hyponymy Pattern 2 Diagram 20

22 Hyponymy Pattern 3 The implementation of Hyponymy Pattern Three [6] begins by comparing every class in ontology 1 to every class in ontology 2 searching for a relationship of hyponymy, when a relationship of hyponymy is found the pair of classes sharing said relationship is noted. After every combination of classes has been explored the algorithm will iterate over the hyponymy pairs, each of the classes from ontology 1 that were hyponymy to a class in ontology 2 are checked for subclasses, if subclasses exist evidence is noted that the subclasses are hyponyms to the corresponding hyponyms in ontology2. This pattern is shown in Figure 7. Figure 7 - Hyponymy Pattern 3 Diagram 21

23 Relation in Phi Pattern 1 The implementation of Relation in Phi Pattern One [6] begins by comparing every class in ontology 1 to every other class in ontology 1 searching for any disjoint, equivalent, subclass or superclass relationships. If any of these relationships exist, the pair of classes sharing these relationships is noted. After every combination of classes in ontology 1 has been explored, the algorithm will compare the first class in the pairs of classes exhibiting some relationship in Phi to every class in ontology 2, if the compared classes exhibit a relationship of synonymy the algorithm will note evidence of a disjoint, equivalent, subclass or superclass relationship between the related class in ontology 1 and the class in ontology 2. This pattern is shown in Figure 8. Ontology 1 Pattern Ontology 2 Implies Relationship Ontology 1 Ontology 2 Class A Class A Class A P Class A P Synonym Class B Class B Figure 8 - Relation in Phi Pattern 1 Diagram 22

24 Relation in Phi Pattern 2 The implementation of Relation in Phi Pattern Two [6] begins by comparing every class in ontology 1 to every other class in ontology 1 searching for any disjoint, equivalent, subclass or superclass relationships. If any of these relationships exist the pair of classes sharing these relationships is noted. After every combination of classes in ontology 1 has been explored, the algorithm will compare the first class in the pairs of classes exhibiting some relationship in Phi to every class in ontology 2, if the compared classes exhibit a relationship of hypernymy the algorithm will note evidence of a disjoint, equivalent, subclass or superclass relationship between the related class in ontology 1 and the class in ontology 2. This pattern is shown in Figure 9. Ontology 1 Pattern Ontology 2 Implies Relationship Ontology 1 Ontology 2 Class A Class A Class A P Class A P Hypernym Class B Class B Figure 9 - Relation in Phi Pattern 2 Diagram 23

25 Meronymy Pattern 1 The implementation of Meronymy Pattern One [6] begins by comparing every class in ontology 1 to every other class in ontology 1 relationships of meronymy. If any of these relationships exist the pair of classes sharing these relationships is noted. After every combination of classes in ontology 1 has been explored, the algorithm will compare the first class in the pairs of classes exhibiting a relationship of meronymy to every class in ontology 2, if the compared classes exhibit a relationship of synonymy the algorithm will note evidence of meronymy between the related class in ontology 1 and the class in ontology 2.This pattern is shown in Figure 10. Ontology 1 Pattern Ontology 2 Implies Relationship Ontology 1 Ontology 2 Class A Class A Class A Meronym Class A Meronym Synonym Class B Class B Figure 10 - Meronymy Pattern 1 Diagram 24

26 Meronymy Pattern 2 The implementation of Meronymy Pattern Two [6] begins by comparing every class in ontology 1 to every other class in ontology 1 relationships of meronymy. If any of these relationships exist the pair of classes sharing these relationships is noted. After every combination of classes in ontology 1 has been explored, the algorithm will compare the first class in the pairs of classes exhibiting a relationship of meronymy to every class in ontology 2, if the compared classes exhibit a relationship of hypernymy the algorithm will note evidence of meronymy between the related class in ontology 1 and the class in ontology 2. This pattern is shown in Figure 11. Ontology 1 Pattern Ontology 2 Implies Relationship Ontology 1 Ontology 2 Class A Class A Class A Meronym Class A Meronym Hypernym Class B Class B Figure 11 - Meronymy Pattern 2 Diagram 25

27 Disjoint Pattern 1 The implementation of Disjoint Pattern One [6] begins by iterating over every class in ontology 1 and searching for disjoint classes within ontology 1. All classes in ontology 1 that have disjoint relationships to other classes within ontology 1 and their disjoint counterparts are noted. After every classes in ontology 1 has been checked, the algorithm will compare every disjoint class to every class in ontology 2, if the compared classes exhibit a relationship of synonymy the algorithm will note evidence of a disjoint relationship between the class in ontology 1 and the class in ontology 2. This pattern is shown in Figure 12. Ontology 1 Pattern Ontology 2 Implies Relationship Ontology 1 Ontology 2 Class A Class A Class A Disjoint Class A Disjoint Synonym Class B Class B Figure 12 - Disjoint Pattern 1 Diagram 26

28 Disjoint Pattern 2 The implementation of Disjoint Pattern One [6] begins by iterating over every class in ontology 1 and searching for disjoint classes within ontology 1. All classes in ontology 1 that have disjoint relationships to other classes within ontology 1 and their disjoint counterparts are noted. After every classes in ontology 1 has been checked, the algorithm will compare every disjoint class to every class in ontology 2, if the compared classes exhibit a relationship of synonymy the algorithm will note evidence of a disjoint relationship between the class in ontology 1 and the class in ontology 2. This pattern is shown in Figure 13. Ontology 1 Pattern Ontology 2 Implies Relationship Ontology 1 Ontology 2 Class A Class A Class A Disjoint Class A Disjoint Hypernym Class B Class B Figure 13 - Disjoint Pattern 2 Diagram Implemented Semantic Discovery Mechanisms There were issues implementing OpenCyc as a semantic discovery mechanism, as such we were only able to implement WordNet as a semantic discovery mechanism. WordNet WordNet was utilized as a semantic discovery mechanism for this project. As this project will only utilize the English language, this package appeared to offer the most complete, robust semantic database of the chosen language and was chosen to be the core implementation for semantic discovery. To access WordNet we leveraged the JWNL (Java WordNet Library), a Java API written to traverse the WordNet database files. 27

29 Implemented Relations Initially we had intended to implement FalconAO and COMA++ as relations within this architecture to demonstrate the user s ability to implement any type of relation in this framework. Due to some constraints such as availability of code and scope of this project we were unable to implement any alternate alignment methods; instead we implemented Generic Relation (see below). Generic Relation Generic Relation is a relation class meant for general consumption by users and the web based portion of this project. Generic Relation a provides the user the ability to pass a list of evidences paired with semantic discovery mechanisms, two ontologies, and a weighted expression for evaluation; it will handle all of the discovery and calculations associated with discovery of a generic relation. Because of its generic design it doesn t allow the user to do anything overly complex, but it does provide the capability to be consumed generically by other classes. Tools Used In this section we outline the tools used in the implementation of this project. All of the tools used in this project were obtained free of charge from various universities and open source projects across the internet. A detailed list of specific URLs for each tool can be found in Appendix D of this document. Programming Languages We chose to use the Java programming language to build the ontology alignment API. We chose this language after performing a brief survey of available libraries for the consumption and processing of common ontology languages and finding that a significant portion of them were written as Java APIs. Java was also the language used to implement the machine to machine, web services portion of this tool they utilize the ontology alignment API heavily. We have chosen to use JSP (Java Server Pages) to implement the web based front end to this system for its convenience of access to the ontology alignment API. Development Environments NetBeans We chose to use the NetBeans Integrated Development Environment (IDE) for the alignment API portions of this project. We chose NetBeans as our development environment due to a combination of the authors familiarity with the IDE and its excellent integration of support for Java programming. Eclipse We chose to use the Eclipse IDE for the web programming portions of this project. We chose Eclipse due to a combination of the authors familiarity with the IDE and its support for JSP and Web Services programming. NetBeans was not chosen for this particular task due to the fact web programming support was not functional on the Windows Vista operating system which was used by the author, at the time of publication. 28

30 Libraries Jena After initial attempts to utilize the Jena API directly we decided to utilize the Protégé API for the parsing of ontologies. We found the Protégé interface to be superior to the Jena interface for ease of use in basic traversal of owl ontologies 13. Jena provides a programmatic interface for the parsing of a variety of ontology types. In this project we utilized it via Protégé to operate over our test ontologies. Furthermore Jena provides a mechanism by which programs can consume as well as create well formed RDF/OWL documents for publication\consumption across the World Wide Web. WordNet WordNet was utilized as a semantic discovery mechanism for this project. As this project will only utilize the English language, this package appeared to offer the most complete, robust semantic database of the chosen language and was chosen to be the core implementation for semantic discovery. To access WordNet we leveraged the JWNL (Java WordNet Library), a Java API written to traverse the WordNet database files. WordNet enables us to discover the semantic relationships between words in a corpus. For instance, it is possible to form a query to WordNet to discover whether two words are hyponyms of each other. OpenCyc OpenCyc is the open source version of the Cyc ontology. This extremely large general knowledge base contains millions of assertions about the concepts it covers. We will use only the semantic discovery mechanisms of OpenCyc for this project, however it could also be implemented as an IOntology for alignment purposes, however its size may prove prohibitive at achieving this goal. This particular library requires the user of the ontology alignment API to provide an OpenCyc server for the API to connect to, there is a free version of this server available from Cyc, the link can be found in Appendix D of this document. OpenCyc provides functionality similar to that of WordNet, enabling the discovery of semantic relationships between concepts. We propose utilizing multiple semantic discovery mechanism so that different implementations could compliment eachother. 13 It should be mentioned that the Protégé API actually uses Jena at its core to access ontologies. 29

31 Application Server We have chosen to use Tomcat as our application server. The application server acts as a host to the web services and web based front end for the ontology alignment API. The Tomcat application server was chosen due to cost and ability to deploy Java \JSP applications in a production environment. Database MySQL was chosen as the database implementation for this project. It was chosen due to its small size, ease of use, availability and authors experience. As added support for this choice, JWNL supports the possibility of loading the WordNet database files into a MySQL database. This offers the possibility of future speed and scalability enhancements for the WordNet semantic discovery mechanism. Web Based Interface To further assist users ability to utilize this framework, we chose to expose this framework via multiple web based methods. SOAP Web Service We implemented a basic SOAP web service that simply leverages the GenericRelation within the Alignment API. JSP Human Interaction We also provided a JSP based web page that allows the user to define their own input parameters to the GenericRelation and alignment API to generate their own ontology alignment file. 30

32 Chapter 6 Results Examples In this section we will review an example of alignment between two ontologies; we will go through the process used by the alignment API step by step detailing exactly what happens at each step. We will align Ontologies 4 and 5 from the appendix using a pattern named Evidence Of Hyponymy 1 A diagram representing each of the ontologies relevant structure has also been included in this section, see Figures 14 and 15. Conference Presentation KeynoteTalk Event SocailEvent Location Workshop Presenter Attendee KeynoteSpeaker Person Chair CommitteeMember Committee Group Organization Panel Figure 14 - Ontology 4 31

33 BSAlumnus Alumnus MSAlumnus Collaborator PhDAlumnus AdjunctFaculty AffiliatedFaculty AssistantProfessor Faculty Person AssociateProfessor GuestSpeaker PrincipalFaculty PrincipalInvestigator Professor Sponsor BSStudent Student MSStudent Visitor PhDStudent Figure 15 - Ontology 5 32

34 Evidence of hyponymy is defined using the semantics of OWL with external evidence from WordNet. It is discovered when we can find two classes, one in our first ontology and one on the second ontology whose class names are synonyms. We understand through the semantics of owl that all the subclasses of a class are hyponyms of that class, and since we have found a synonym in a different ontology, we can derive that the subclasses in the first ontology are also subclasses of the synonymous class in the second ontology. A diagram explaining evidence of hyponymy can be found in Figure 5. To search for evidence of hyponymy we begin by searching for a synonymous relationship between classes in ontology 4 and ontology 5, we compare all the classes in Ontology 4 to all the classes in ontology 5. When we find such a relationship we will note it for future use. After searching over the ontologies we find that there is only one synonymous relationship between classes, there is a class in ontology 4 named Person and a class named Person in ontology 5. We may now retrieve from our ontology 4 all of the subclasses of Person which include: Alumnus, BSAlumnus, MSAlumnus, Student, Faculty, Collaborator, Sponsor, PrincipalInvestigator. Each of these are relayed up to the relation as evidence. To calculate the weight of this discovery we assign a value of 1 for every instance of hyponymy found in this evidence, and a value of.5 for every class mapped. In our case we found one case of hyponymy and mapped eight classes giving a raw score of 5. This raw score is also returned to the higher level concept of a relation along with the evidences. This score is placed into a related equation at the relation level and weighted against other evidences run across the ontology. The relation, once it has all of the scores obtained from searching evidence has its own raw score as dictated by its expression. If this score meets a threshold determined by the user, the relation is said to exist. The user s threshold tells the alignment engine that there is an evidence of hyponymy between the classes: Alumnus, BSAlumnus, MSAlumnus, Student, Faculty, Collaborator, Sponsor, PrincipalInvestigator in ontology 4 and Person in ontology 5. As such, it will add this to the mapping generated at the end of ontology alignment. It is likely that this is one of many relations searched for across these two ontologies, the process described above would be repeated for each of the relations being explored across the input ontologies. Success Criteria To measure success we manually aligned several ontologies and compare those with the results of our alignment system. We will measure accuracy using precision and recall. Results The results presented in the following section represent the ability of the alignment API to discover evidence across the set of ontologies in Appendix B. The results were gathered by running an instance of relation that only searches for a single type of evidence over the specified pair of ontologies. An alignment file was then produced representing the discovered relationships from the evidence observed 33

35 in the ontology. There was no weighting associated with the evidence, all evidence was set as valid for this exercise to allow us to measure performance. After automated alignment, we manually checked for the specified evidence between the given ontologies, we noted precision and recall associated with the automated alignment against that of the author, which we treat as the truth data. Hyponymy Pattern 1 Hyponymy Pattern 1 seemed to perform reasonably well compared to some of the other evidences. Areas where it performed poorly occurred where the definition of the evidence prohibited it from finding a relationship, for instance when comparing ontologies 4,3 the classes named Organization in each class were unable to align due to their lack of subclasses. Pattern Ontology Pair Precision+ Recall+ Precision- Recall- Hyponymy Pattern 1 1, % % % % Hyponymy Pattern 1 2, % % % % Hyponymy Pattern 1 3, % % % % Hyponymy Pattern 1 4, % % % 96.00% Hyponymy Pattern 1 4, % % % % Hyponymy Pattern 1 4, % % % 99.26% Hyponymy Pattern 1 4, % % % 99.14% Hyponymy Pattern 1 5, % % % % Table 2 - Hyponymy Pattern 1 Results Hyponymy Pattern 2 Hyponymy Pattern 2 encountered difficulties where it was unable to discover the semantic relationship between words in the same manner as the human aligner. Using a semantic discovery mechanism other than WordNet should increase the accuracy of Hyponymy Pattern 2. Pattern Ontology Pair Precision+ Recall+ Precision- Recall- Hyponymy Pattern 2 1,4 0.00% 0.00% 93.44% 98.28% Hyponymy Pattern 2 2, % % % % Hyponymy Pattern 2 3, % 14.14% 86.22% 99.81% Hyponymy Pattern 2 4, % 20.00% 78.57% % Hyponymy Pattern 2 4, % 25.00% 89.66% % Hyponymy Pattern 2 4, % 2.56% 65.45% % Hyponymy Pattern 2 4, % 2.60% 73.68% % Hyponymy Pattern 2 5, % % % 0.00% Table 3 - Hyponymy Pattern 2 Results Hyponymy Pattern 3 Hyponymy Pattern 3 has results identical to that of Hyponymy Pattern 2. This is due to the fact that WordNet does not appear to appropriately handle the directional relationship of hyponymy, it treats the 34

36 phrase Faculty is a hyponym of Person the same as Person is a hyponym of Faculty. Improvements in WordNet or perhaps a different semantic discovery mechanism should alleviate this problem. Pattern Ontology Pair Precision+ Recall+ Precision- Recall- Hyponymy Pattern 3 1,4 0.00% 0.00% 93.44% 98.28% Hyponymy Pattern 3 2, % % % % Hyponymy Pattern 3 3, % 14.14% 86.22% 99.81% Hyponymy Pattern 3 4, % 20.00% 78.57% % Hyponymy Pattern 3 4, % 25.00% 89.66% % Hyponymy Pattern 3 4, % 2.56% 65.45% % Hyponymy Pattern 3 4, % 2.60% 73.68% % Hyponymy Pattern 3 5, % % % 0.00% Table 4 - Hyponymy Pattern 3 Results Relation in Phi Pattern 1 Relation in Phi Pattern one performed exceptionally well due to WordNets ability to correctly identify synonyms in most cases. Both of the relations in Phi in this section were restricted by the relations defined in Phi (within the ontologies). None of the chosen ontologies included relationships such as equivalence or disjoint, as such we were only able to find relations in Phi as related to superclass/subclass relationships. Pattern Ontology Pair Precision+ Recall+ Precision- Recall- Relation in Phi 1 1, % % % % Relation in Phi 1 2, % % % % Relation in Phi 1 3, % % % % Relation in Phi 1 4, % 90.91% 96.00% % Relation in Phi 1 4, % % % % Relation in Phi 1 4, % % % % Relation in Phi 1 4, % 62.50% 98.82% % Relation in Phi 1 5, % % % % Table 5 - Relation in Phi Pattern 1 Results 35

37 Relation in Phi Pattern 2 Relation in Phi Pattern two performed far worse than pattern one. We believe this to be related to lack of expressivity for relationships of hypernymy within WordNet. As in Hyponymy Pattern 3, we had issues with WordNet failing to handle the directional relationship associated with hypernymy. Pattern Ontology Pair Precision+ Recall+ Precision- Recall- Relation in Phi 2 1, % 40.74% 70.37% % Relation in Phi 2 2, % 45.45% 0.00% 0.00% Relation in Phi 2 3, % 33.33% 95.96% % Relation in Phi 2 4,1 3.85% % 0.00% 0.00% Relation in Phi 2 4,2 0.00% 0.00% 0.00% 0.00% Relation in Phi 2 4, % % % 86.76% Relation in Phi 2 4, % % % 0.00% Relation in Phi 2 5, % % % 0.00% Table 6 - Relation in Phi Pattern 1 Results Meronymy Pattern 1 Interestingly there was no meronymy in any of the ontologies to be aligned. The algorithm performed properly finding no instances of meronymy in any of the pairs. We will discuss this result further in the problems section of this document. Pattern Ontology Pair Precision+ Recall+ Precision- Recall- Meronymy Pattern 1 1, % % % % Meronymy Pattern 1 2, % % % % Meronymy Pattern 1 3, % % % % Meronymy Pattern 1 4, % % % % Meronymy Pattern 1 4, % % % % Meronymy Pattern 1 4, % % % % Meronymy Pattern 1 4, % % % % Meronymy Pattern 1 5, % % % % Table 7 - Meronymy Pattern 1 Results Meronymy Pattern 2 Pattern Ontology Pair Precision+ Recall+ Precision- Recall- Meronymy Pattern 2 1, % % % % Meronymy Pattern 2 2, % % % % Meronymy Pattern 2 3, % % % % Meronymy Pattern 2 4, % % % % Meronymy Pattern 2 4, % % % % Meronymy Pattern 2 4, % % % % Meronymy Pattern 2 4, % % % % Meronymy Pattern 2 5, % % % % 36