Camila Bezerra da Silva - repositorio.ufpe.br · First of all, I thank God for your presence in my life, the support that gave me to ﬁnish this work despite the difﬁculties that

“ModOnto: A Suite of Tools for Modularizing Ontologies”

By

Camila Bezerra da SilvaM.Sc. Dissertation

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, August/2009

www.cin.ufpe.br/~posgraduacao

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Camila Bezerra da Silva

“ModOnto: A Suite of Tools for ModularizingOntologies”

Trabalho apresentado ao Programa de Pós-graduação emCiência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial paraobtenção do grau de Mestre em Ciência da Computação.

A M.Sc. Dissertation presented to the Federal University ofPernambuco in partial fulfillment of the requirements for thedegree of M.Sc. in Computer Science.

Advisor: Prof. Dr. Frederico FreitasCo-Advisor: Prof. Dr. Jérôme Euzenat

RECIFE, August/2009

To my dear mother.

Acknowledgements

First of all, I thank God for your presence in my life, the support that gave me to finishthis work despite the difficulties that I lived in the last months.

I want to thank to my family, in special, my dear mother, Jacira, who always supportsme, advises me and lead me for the ways of life, that if were not for her constant struggleto provide me a better life, I would not be where I am today.

I want to express my thanks to my advisors, Fred Freitas and Jérôme Euzenat for theorientation, patience, dedication and incentive. The work presented in this dissertationwould not be possible without their support and advice.

I really want to thank for the opportunity that Jérôme gave me to spend 3 months atINRIA under his advising, which contributed to increase my knowledge and to finalizethe implementation of the ModOnto.

I would like to thank boyfriend, José Dihego, who has been present at my side givingsupport in the difficult moments.

And, I also want to thank all the people who helped me directly or indirectly in therealizing of this work.

vi

"The greater the obstacle, the more glory in overcoming it."—JEAN-BAPTISTE POQUELIN (Moliere)

Resumo

Devido aos problemas relacinados com o gerenciamento e o raciocínio em grandes on-tologias, um forte interesse e uma conseqüente investigação ativa em modularizaçãode ontologias vem emergindo na comunidade científica relacionada à Web Semântica.Uma vez que muitas ontologias são preferivelmente grandes artefatos, para uma adoçãoem grande escala das mesmas, por exemplo, na Web Semântica, é necessário permitirque desenvolvedores de ontologias possam incluir apenas as entidades e axiomas quesão relevantes para a aplicação que estão a desenvolver. Além da reutilização, o uso demodularização de ontologias é útil para muitas outras tarefas, incluindo suporte a queries,raciocínio distribuído, desenvolvimento em grande escala e manutenção de ontologias.Alguns abordagens para modularização têm sido propostas, no entanto nemhuma delasdispõe de uma ferramenta flexível que permita não só definição de módulos, mas tambémoutros tipos de tarefas, como análise sintática e semântica, biblioteca de módulos euma poderosa ferramenta para seleção de entidades. Esta dissertação propõe um con-junto de ferramentas, chamado ModOnto, para cumprir esses requisitos. Incorpora umaabordagem para modularização de ontologias que herda alguns dos princípios de Engen-haria de Software Orientada para Objeto, que são o encapsulamento e o ocultamento deinformação.

Palavras-chave: Modularização de ontologias, Reuso, Extração de módulos

viii

Abstract

Ought to problems with management and reasoning large ontologies, strong interestand a consequent active research on ontology modularization has been emerging in theSemantic Web research community. Once many ontologies are rather large artifacts, for alarge scale adoption of them, e.g. in the Semantic Web, it is necessary to enable ontologydevelopers to include only those entities and axioms that are relevant for the applica-tion which they are developing. In addition to reuse, ontology modularization is usefulfor many other tasks, including query answering, distributed reasoning, scalable evolu-tion and maintenance. Some ontology modularization approaches have been proposed;nevertheless neither of them disposes of a flexible tool that permits not only ontologymodule definitions but also other support tasks, like syntactical and semantic checkingof the modules, module library and powerful entity selection facilities. This dissertationproposes a suite of tools, called ModOnto, to meet these requirements. It incorporatesan approach to ontology modularization that inherits some of the main principles fromobject-oriented Software Engineering, which are encapsulation and information hiding.

Keywords: Ontology modularization, Reuse, Module extraction

ix

Contents

List of Codes 1

Glossary 2

1 Introduction 41.1 Context and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Text Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Ontology 92.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Ontology Components . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Ontology Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Description Logics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 Description Logic Reasoning . . . . . . . . . . . . . . . . . . . 142.5 Ontology Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.1 The first languages . . . . . . . . . . . . . . . . . . . . . . . . 162.5.2 The Semantic Web and its Languages . . . . . . . . . . . . . . 172.5.3 OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Ontology Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.1 Ontology development tools . . . . . . . . . . . . . . . . . . . 21

OILEd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22OntoEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22OntoLingua Server . . . . . . . . . . . . . . . . . . . . . . . . 23Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.6.2 Ontology matching and integration tools . . . . . . . . . . . . . 24Chimaera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25ODEMerge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Alignment API . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.6.3 Neon ToolKit . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

x

3 Ontology Modularization 313.1 Reusability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Syntactical and Semantic Modularity . . . . . . . . . . . . . . 34short title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Semantic Modularization . . . . . . . . . . . . . . . . . . . . . 34

3.2.2 Coupling and Cohesion . . . . . . . . . . . . . . . . . . . . . . 353.3 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4 Partitioning Approaches . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4.1 Structured-Based Partitioning . . . . . . . . . . . . . . . . . . 373.4.2 Ontology Partitioning using ε-connections . . . . . . . . . . . 38

3.5 Formal Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.1 DDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.2 IDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.6 Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6.1 COWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6.2 ε-connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.6.3 PDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.7 Selection Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.7.1 ModTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.7.2 NeOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.8.1 Alignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.8.2 OO principled ontology modules . . . . . . . . . . . . . . . . . 523.8.3 Tool Support for Ontology Modularization . . . . . . . . . . . 52

4 ModOnto 544.1 The OntoCompo Approach . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.1 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Language Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . 56Language Semantics . . . . . . . . . . . . . . . . . . . . . . . 60

4.2 Features and Functionalities . . . . . . . . . . . . . . . . . . . . . . . 604.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.3.1 Module API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.3.2 Module Extractor . . . . . . . . . . . . . . . . . . . . . . . . . 644.3.3 Module Linker . . . . . . . . . . . . . . . . . . . . . . . . . . 65

xi

4.3.4 Module Checker . . . . . . . . . . . . . . . . . . . . . . . . . 664.3.5 Module Reasoner . . . . . . . . . . . . . . . . . . . . . . . . . 664.3.6 Module Library . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.4 Used Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4.1 OWL API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4.2 Alignment API . . . . . . . . . . . . . . . . . . . . . . . . . . 714.4.3 IDDL Reasoner . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Classical Reasoning . . . . . . . . . . . . . . . . . . . . . . . 71Distributed Reasoning . . . . . . . . . . . . . . . . . . . . . . 71

4.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.5.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Human Readable Syntax . . . . . . . . . . . . . . . . . . . . . 734.5.2 Creating the module in the ModOnto . . . . . . . . . . . . . . 754.5.3 RDF Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.5.4 Alignment process . . . . . . . . . . . . . . . . . . . . . . . . 784.5.5 Syntactic and Semantic Checker . . . . . . . . . . . . . . . . 80

5 Conclusions and Future Work 825.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.3 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Bibliography 86

Appendices 91

Diagrams of Classes 92

Code of the Usage Example 95

xii

List of Figures

2.1 Classes and instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 ontology markup languages . . . . . . . . . . . . . . . . . . . . . . . . 172.5 RDF Triple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 OntoEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.8 The steps of the ODEMerge Methodology . . . . . . . . . . . . . . . . 262.9 An alignment generated by the alignment API . . . . . . . . . . . . . . 282.10 Neon ToolKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Distributed system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 C-OWL mapping from the family ontology to the familia ontology . . . 423.3 Link Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4 Swoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.5 P-DL example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6 ModTool’s algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.7 ModTool’s methodology . . . . . . . . . . . . . . . . . . . . . . . . . 473.8 Modularization plugins for the NeOn Toolkit . . . . . . . . . . . . . . 493.9 Metamodel for ontology modules . . . . . . . . . . . . . . . . . . . . . 503.10 Metamodel for ontology modules . . . . . . . . . . . . . . . . . . . . . 503.11 Metamodel for ontology modules . . . . . . . . . . . . . . . . . . . . . 513.12 Comparative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.1 Module Language tags and descriptions. . . . . . . . . . . . . . . . . . 574.2 ModOnto Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 624.3 Module API Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 634.4 Module Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.5 Module Linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.6 Module B uses module A . . . . . . . . . . . . . . . . . . . . . . . . . 664.7 Module Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.8 Module Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.9 Implementation aspects of thw OWL API . . . . . . . . . . . . . . . . 704.10 Dependecies between the ontologies and the Menu module . . . . . . . 73

xiii

4.11 Importing entities from Pizza Ontology . . . . . . . . . . . . . . . . . 764.12 Creating the NorthEasternBrazilianPizza class . . . . . . . . . . . . . . 774.13 Module Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

1 Renderer Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922 Parser Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933 Syntatical Checker Diagram . . . . . . . . . . . . . . . . . . . . . . . 934 Library Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945 Reasoner Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

xiv

List of Tables

2.1 OWL Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

xv

List of Codes

3.6.1 Module in XMLSchema format . . . . . . . . . . . . . . . . . . . . . . 434.1.1 Module in XMLSchema format . . . . . . . . . . . . . . . . . . . . . . 584.1.2 Module in XMLSchema format . . . . . . . . . . . . . . . . . . . . . . 594.5.1 Menu Module in RDF Syntax . . . . . . . . . . . . . . . . . . . . . . 794.5.2 NorthEasternBrazilianPizza class . . . . . . . . . . . . . . . . . . . . 804.5.3 Alignment in RDF format between the Pizza ontology and the Menu

Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.0.1 Menu Module in RDF Syntax . . . . . . . . . . . . . . . . . . . . . . 95.0.2 The contains and the exports of the Menu module in RDF Syntax . . . 96.0.3 NorthEasternBrazilianPizza class . . . . . . . . . . . . . . . . . . . . 97

1

Glossary

A

AI Artificial Intelligence, p. 16.

API Application Programming Interface, p. 68.

D

DDL Distributed Description Logics, p. 39.

DL Description logics, p. 13.

I

IDDL Integrated Distributed Description Logics, p. 41.

K

KB Knowledge Base, p. 13.

KIF Knowledge Interchange Format, p. 16.

KM Knowledge Management.

KR Knowledge Representation, p. 13.

O

OBO Open Biomedical Ontologies, p. 69.

OKBC Open Knowledge Based Connectivity, p. 23.

OO Object Oriented.

OWL Web Ontology Language, p. 18.

P

P-DL Package-based Description Logics, p. 44.

2

GLOSSARY

R

RDF Resource Description Framework, p. 17.

T

Turtle Terse RDF Triple Language, p. 69.

X

XML Extensible Markup Language, p. 17.

3

1Introduction

1.1 Context and Motivation

With the advent of the Internet, it appeared the Semantic Web that provides automatedinformation access based on machine-processable semantics of data and heuristics thatuse these metadata(Berners-Lee et al. (2001)). The idea is that the machines mightunderstand the data disposed in the Web. The explicit representation of the semanticsof data using the ontologies, will enable a Web to provide a quality level of service.However, the success of the Semantic Web depends of a number of efforts; one of themis ontology reuse.

Moreover, Ontology construction is deemed to be a time-consuming and labour-intensive task. Therefore, it heavily relies on the possibility of reusing existing ontologies.

The ontology subfield that provides methodologies to guide to developers is knownas Ontology Engineering. Most of its methodologies share similar iterative phases, likespecification, implementation and evaluation with Software Engineering techniques.

However, a culture of building blocks for ontologies, such as the component culturethat took over the realm of object oriented Software Engineering, has not shown up in theOntology Engineering yet.

Ontology modularization comes up as a way to solve the problem of defining a partof an existing ontology to be reused, in order to enable ontology developers to includeonly those concepts and relations that are relevant for the application they are modelingan ontology for.

Ontology editors such as Protégé1, allow the reuse of another ontology by includingit in the model that is being designed (in Protégé this happens through the inclusion of

1http://protege.stanford.edu/

4

1.1. CONTEXT AND MOTIVATION

other projects). The web ontology language OWL2 offers the possibility to import anOWL ontology by means of the <owl:imports> statement. The semantics of this importstatement is that all definitions contained in the imported ontology file are included inthe importing ontology, as if they were defined in the importing ontology file. Moreover,owl:import is directed; i.e, only the importing ontology is affected, and is transitive, e.g,if A imports B and B imports C, then A imports all definitions contained in C.

The problem with these reuse techniques is that when they import a given ontology,the whole content of it is included in the new one; thus, it is not possible to import onlyrelevant parts of the ontology, every definitions are included. This consists in a seriouslimitation that leads to several problems:

• Reasoning scalability: the reasoners are known to perform well on small-scale on-tologies, with performances degrading rapidly as the size of the ontology increases.

• Complexity management: the larger the ontology, the more difficult it is to controlthe accuracy of the design.

• Understandability: it is easier to understand an ontology contents if the ontology issmall.

To deal with the lack of ontology modularity, some approaches have been proposed -some of them are presented in chapter 3. At least one large ontology editor has alreadyimplemented modularization, the NeOn toolkit3. Indeed, the NeOn project received abudget of almost 15 million euros and gathers 17 European research institutions in orderto produce an ontology toolkit that is much more flexible and powerful than the currentones and one of the relevant branches of it refers to ontology modularization.

Nevertheless, although these ontology modularization approaches that have beenalready proposed, neither of them disposes yet of a flexible tool that permits not onlyontology module definitions but also other support tasks, like syntactical and semanticchecking of the modules, module library and powerful entity selection facilities. Mostmodularization approaches to the problem focus on linking ontologies (or modules) ratherthan building modules that can encapsulate foreign parts of ontologies (or other modules)that can be managed more easily.

2http://www.w3.org/TR/owl-features/3http://www.neon-toolkit.org/

5

1.2. GOAL

1.2 Goal

With this dissertation our objective was to propose a suite of tools for modularizationof ontologies which tackles the problems cited above. Thus, it aims at providing anenvironment for building modules by reusing ontologies or other modules. Moreover, itprovides others support tasks like consistency checking of modules both syntacticallyand semantically.

This work is part of a project of cooperation between CIN-UFPE and INRIA4 (InstitutNational de Recherche en Informatique et en Automatique), entitled “Composition andModules for Ontology Engineering” (OntoCompo), funded by CNPq5 (National Counselof Technological and Scientific Development) and INRIA. Its goal is to build an approachfor modularization that inherits two of the main principles from object-oriented SoftwareEngineering, which are encapsulation and information hiding. The approach encompassesa language definition with syntaxes and semantic notions, to represent the module.

1.3 Contributions

The main contribution of this dissertation is the availability of the suite of tools thatprovides support to build ontology modules, based on the OntoCompo approach. Thesuite offers interesting support tools like a library of modules that will help developers tochoose suitable modules to be reused in a new one.

Nevertheless, at least three novel, distinctive features are also present, which at thebest of our knowledge is not implemented in any other ontology module tool:

1. Semantic checking of the module being created. This checking is accomplished in avery flexible manner; users can choose from two semantics, the usual DL semanticswhich is proper to usual DL ontologies, or the Integrated DL semantics based onIDDL(Zimmermann (2007)), which is adequate for distributed DL ontologies. Toachieve this step, we had to integrate an IDDL reasoner with the suite.

2. Syntactical checking, that assures that the module does not contain any syntacticalerrors.

3. Support to the use of alignments among the imported modules ( or ontologies ) andthe new one.

4http://www.inria.fr/5http://www.cnpq.br/

6

1.4. APPLICATIONS

4. Compliance with an on-the-making standard module format, the NeOn moduleformat.

According to the literature review carried out for this work, we have drawn to theconclusion that the different proposals ( PDL, ε-connections, C-OWL, etc ) are not wellsupported by tools.We were not able to find a module development environment thatsupports not only the creation of modules, but also other support tasks, like syntacticaland semantic checking of the modules, and other necessary tasks for the good and safedevelopment of a module. Therefore, this work can be viewed as an attempt to make forthe lack of this type of tool. An additional research interest was to deploy such a tooldeparting from the ontology module language defined in the project.

The suite has been developed in Java language and use three APIs: OWL API6 fromManchester, Alignment API( Euzenat (2004) ) and the IDDL (Zimmermann and Duc(2008a)) Reasoner from INRIA.

1.4 Applications

The present work may have potential impacts in several application scenarios, includingthe following:

Collaboration Development: the building process of an ontology usually involve co-operation among several domain experts. The ModOnto provides support forefficient collaborative building of large, modular ontologies.

Ontology Reuse: the lack of modularity in current ontology languages forces an onto-logy to be totally reused. An ontology has to be completely reused even if onlya small fragment of it is actually needed. The ModOnto provides mechanisms tobuild ontology modules by reusing small fragments of several imported ontologies(or modules).

Support Tasks for Module Development: besides the module development, ModOntooffers others support tasks like modules library.

1.5 Text Organization

The presented work was described in five chapters. The present chapter aims to give tothe reader a view of the work and the context and motivation to realize it.

6http://owlapi.sourceforge.net

7

1.5. TEXT ORGANIZATION

In Chapter 2 describes the concept of ontology; methodologies, tools, languagesto development of ontologies. The goal is to show the available mechanisms for thedevelopment of ontologies and what of them give us support to reuse them.

In Chapter 3 describes Ontology Modularization which comes up as a way to developontologies by reusing parts from others ontologies and the existent approaches.

In Chapter 4 presents the main contribution of this dissertation which is the suiteof tools for ontology modularization and the OntoCompo approach. And it is given anexample of using the ModOnto, the module development as well as the other supporttasks like syntactical checker.

In Chapter 5 the conclusions and contributions are given of this work. Moreover, itis proposed the future works.

8

2Ontology

2.1 Introduction

The word ontology stems from the field of Philosophy, where it means explanation ofbeing. The goal was to try to define all things of the word. In this context, the philosopherstry to answer questions like “What is a being?”.

As for the Computer Science mainstream, ontologies were introduced in the 80’s,in the area of Artificial Intelligence for representing knowledge to be employed inautomatic inferences of knowledge-based systems. Ontologies have been used as a formof organizing knowledge information, mainly with regard to formal representation ofknowledge. The main purpose is to provide sharing and reusing knowledge.

There are several definitions in the literature, which provide different and complemen-tary points of view.

One of the first definitions was given by Neches et al. (1991), who defined an ontologyas follows: “An ontology defines the basic terms and relations comprising the vocabularyof a topic area as well as the rules for combining terms and relations to define extensionsto the vocabulary.” This definition provides some vague guidelines: define terms, relationsand rules to combine terms.

Few years later, Gruber (1993) defined an ontology as “an explicit specification of aconceptualization”. After this, many definitions of what an ontology is were proposed.Afterwards, Borst (1997) modified Gruber’s definition as: “Ontologies are defined as aformal specification of a shared conceptualization”. By conceptualization, it refers toan abstract model of some phenomenon in the world by having identified the relevantconcepts of the represented domain. By explicit, it means that the type of concepts used,and the constraints on their use are declarative. By formal, it refers to the fact that theontology should be machine readable and processable. And shared reflects the notion that

9

2.2. ONTOLOGY COMPONENTS

an ontology captures consensual knowledge, that is, it is not private of some individual,but accepted by a group. This definition became the most quoted in literature and by theontology community.

Ontology provides a shared vocabulary, which can be used to model a domain, that is,concepts and its types that exist, and their properties and relations. And, they are widelyused in different areas: Knowledge Engineering, Databases and Software Engineering.

2.2 Ontology Components

According to Perés and Corcho (2002) the ontology is composed of five components:

1. Classes - represent a set of individuals with common characteristics in a domain.They are organized in taxonomies and can be abstract or concrete concepts, simpleor complex, real or unreal. The figure 2.1 illustrates two classes: the Countryclass, which represents the set of Countries of the world and a Person class whichrepresents a set of people.

Figure 2.1 Classes and instances

Figure 2.2 Instances

10

2.3. ONTOLOGY ENGINEERING

2. Instances - represent objects in the domain. Individuals of the classes Country andPearson can be seen in figure 2.2. The Japan is an individual from the CountryClass, for instance.

3. Relations - represent connections between two classes. Naturally, relations canalso be instantiated. For instance, in figure 2.3 the individuals from the Personclass is related with the individuals from the Country class through the “wasBorn”property. Thus the individual Chan from the class Person related by the relation“wasBorn” to the individual Vietnam from the class Country.

Figure 2.3 Relations

4. Axioms - are predicating about the elements that are always true. Example: If ananimal is carnivore, it eats meat, where Animal and Meat are classes and “eats” isthe relation between them.

5. Functions - complex structures formed from certain relations that can be used inplace of an individual term in a statement. Example: Mother is a function thatrelates an animal to exactly one female animal.

After having defined the ontology elements, in the following we will discuss on waysof how to build ontologies, a subarea known as Ontology Engineering.

2.3 Ontology Engineering

According to Gómez-Pérez and colleagues, Ontology Engineering (OE) refers to the setof activities regarding to process, life cycle, methods, methodologies, tools and languagesthat support the ontology development (Gomez-Perez et al. (2004)).

11

2.3. ONTOLOGY ENGINEERING

When we intend to represent something in an ontology, it is necessary to makedesign decisions. Gruber(Gruber (1995)) proposed a set of design criteria for ontologydevelopment:

Clarity: an ontology should effectively communicate the intended meaning of definedterms. The definitions should be objective and, as much as possible, independentof social or computational context.

Coherence: the ontology should be used to make inferences that are consistent with thedefinitions. At least, the defining axioms included it should be logically consistent.

Extendibility: an ontology should be designed to be possible to use it at shared do-main. It should be able to define new terms for special uses based on the existingvocabulary, in a way that does not require the revision of the existing definitions.

Minimal encoding bias: the conceptualization should be specified at the knowledgelevel without depending on a particular symbol-level encoding. Encoding biasshould be minimized, because knowledge-sharing agents may be implemented indifferent representation systems and representation styles.

Minimal ontological commitment: an ontology should require the minimal ontologi-cal commitment sufficient to support the intended knowledge sharing activities.Thus, an ontology should make as few claims as possible about the domain beingmodeled, allowing the part committed to the ontology to specialize and instantiatethe ontology as needed.

In the last years, Ontology Engineering attracted plenty of attention of the researches.Hence, many methodologies, tools and languages have appeared to assist the task ofbuilding ontologies. When a new ontology is about to be built, several questions arisein the its development related to the methodology, tools and language that must be used,such as the ones listed below:

• Which methods and methodologies can I use for building ontologies?

• How can I reuse other ontologies?

• How can the applications use the existing ontologies?

• Which language(s) should I use to implement my ontology?

12

2.4. DESCRIPTION LOGICS

• Is the language chosen appropriate for exchanging information between differentapplications?

• Is the language chosen supported by any development tool?

• What are the inference mechanisms attached to the ontology language?

In order to solve these questions it is needed to know about the methodologies,tools, languages, domain of the ontology, and so on. The next sections present themain characteristics of methodologies, tools and languages, which can help to solve theprevious questions.

First, we explain the Description Logic which is a formalism that supports severallanguages like OWL.

2.4 Description Logics

Description logics (DL) means a family of knowledge representation (KR) formalismswith the purpose of representing knowledge of an application domain by defining therelevant concepts of the domain, and using these concepts to specify properties andindividuals occurring in the domain.

Differently from their predecessors, the name Description Logics indicates the lan-guages which are equipped with a formal and logic-based semantics(Baader et al. (2003)).

In DL classes(concepts) can be defined in terms of descriptions that specify the pro-perties that objects must satisfy to belong to the concept. These descriptions are expressedusing a language that allows the building of complex descriptions, including restrictionson the binary relationships(called roles) connecting objects. Moreover, provides to theuser infer implicitly knowledge from the knowledge that is explicitly contained in aknowledge base.

Decidability and complexity of the inference depend on the expressive power of thechosen DL. However, it comes up inference problems of high complexity when is useda very expressive DLs or still the results may even be undecidable. On the other hand,very weak DLs may not be sufficiently expressive to represent the important concepts ofa given application.

A DL knowledge base (KB) comprises two components:

• TBox(Terminological Box): is a set of inclusion axioms and equivalent axioms.The TBox introduces the terminology, i.e., the vocabulary of an application. The

13


vocabulary consists of concepts, which denote sets of individuals, and roles, whichdenote binary relationships between individuals. Example: {Father v Person,GrandFather ≡ Person u ∃ hasChild.Parent}

• ABox: contains assertions about named individuals in terms of this vocabulary.Example: {Peter:Father, Peter hasChild John}

Assume that we want to define the concept of “A happy woman is married to a goodman, has at least one child and has a good job”. This concept can be described with thefollowing concept description:

HappyWoman≡Humanu¬Manu (∀married.GoodMan)u≥ 1hasChild u ∀has.GoodJob

2.4.1 Description Logic Reasoning

Several systems based on ontologies make reasoning using them. The reasoning taskbecomes even easier when the formalism in which the ontologies are defined, alreadyprovides reasoning services, like DL ( Description Logic ). For instance, DL languagesenable the automatic organization of the classes defined in an ontology, into a specialisa-tion/generalisation hierarchy ( ontology classification), a reasoning task that provides thedetection of potential modeling errors such as inconsistent class descriptions and missingsub-class relationships.

There are reasoners that provide these services like Pellet and fact++ for the DLlanguage ( OWL, Ontology Web Language, the standard ontology language for theSemantic Web ). They are able to infer logical consequences from a set of asserted factsor axioms, among other reasoning tasks.

One of the main services offered by a DL reasoner is to test whether or not oneclass is a subclass of another class ( subsumption service ). Another service is to checkthe ontology consistency. Based on the description of a class, the reasoner can checkwhether or not it is possible for the class to have any instances. A class is deemed to beinconsistent if it cannot possibly have any instances.

The standard inference services that are offered by reasoners are:

• Consistency checking: ensures that an ontology does not contain any contradictorysentences.

• Concept satisfiability: determines if is possible for a class to have any instances. Ifa class is unsatisfiable, then defining an instance of that class will cause the wholeontology to be inconsistent.

14


• Classification: computes the subclass relations between every named class to createthe complete class hierarchy. The class hierarchy can be used to answer queriessuch as getting all or only the direct subclasses of a class.

• Realization: finds the most specific classes that an individual belongs to; i.e.,realization computes the direct types for each of the individuals.

For example, consider the following sentences below:

1. Drivers drive vehicles

2. ‘Bus drivers’ drive buses

3. A bus is a vehicle

These sentences in DL is equivalent to:Drivers ≡ ∃drive.vehicleBusDrivers ≡ ∃drive.busBus v Vehicle

A subsumption reasoning allows the inference that “bus drivers are drivers”(BusDrivers= Drivers) since “vehicle” is more general than “bus”.

An example of inconsistency is given below:Human ≡ ∀eat.(Meat t Vegetable) u ∃eat.Meat u ∃eat.VegetableMeat u Vegetable ≡ ⊥Vegetarian ≡ ∀eat.VegetableVegetarian(Mary)Human(Mary)

These axioms mean that Humans have to eat both Meat or Vegetable which aredisjoint classes. Vegetarians eat only Vegetables and Mary is human and is Vegetarian.

So, according to the axioms above, Mary is a human and is vegetarian. This sentenceis inconsistent since humans have to eat meat.

Next, we discuss some languages on which ontologies can be built.

15

2.5. ONTOLOGY LANGUAGES

2.5 Ontology Languages

2.5.1 The first languages

At the beginning of the 1990s, it appeared a set of ontology languages based on AI.Basically, such ontology languages were based on first order logic (i.e. KIF), on framescombined with first order logic (i.e. Ontolingua, OCML1 and FLogic) or on DescriptionLogic (i.e. Loom).

KIF (Hayes and Menzel (2001)) was created in 1992 in order to be an interchangeformat for diverse KR systems. KIF is based on First Order Logic (FOL). After, it wasdeveloped by the Stanford University, the Ontolingua (Farquhar et al. (1996)), which wasbuild on KIF and combines the KR paradigms of frames. It allows the representationof concepts, taxonomies of concepts, n-ary relations, functions, axioms, instances andprocedures. However, the KIF based Ontolingua has a problem with its expressive power,so that no general reasoner support for KIF exists.

Loom (MacGregor (1991)) was developed simultaneously with Ontolingua at theInformation Science Institute (ISI) from the University of South California. Loom isa language based on Description Logics and production rules. The following ontologycomponents can be represented with this language: concepts, concept taxonomies, n-aryrelations, functions, axioms and production rules.

FLogic (Kifer et al. (1990)) was developed in 1995 and combines frames and firstorder logic. Basically it provides classes, attributes with domain and range definitions,is-a hierarchies with set inclusion of subclasses and multiple attribute inheritance, andlogical axioms that can be used to further the relationships between elements of anontology and its instances.

SHOE (Heflin et al. (1999)) was built in 1996 as an extension of HTML, in theUniversity of Maryland. SHOE combines frames and rules and uses tags different fromthose of the HTML specification. SHOE just allows representing concepts, relations,instances and deduction rules, which are used by its inference engine to obtain newknowledge. However, it was based on a database perspective and not in a KR formalism.

OIL(Fensel et al. (2000)) had as main goal the easy adoption by the Semantic Webdevelopers. This language adds frame-based KR primitives and its formal semantics isbased on DLs, it was organized in layers to facilitate the use, and had a reasoner, theFact2 classifier to perform automatic classifications of concepts.

1http://kmi.open.ac.uk/projects/ocml/2http://www.cs.man.ac.uk/ horrocks/FaCT/

16


DAML(DARPA Agent Markup Language) is an extension of OIL without inferencemechanism.

2.5.2 The Semantic Web and its Languages

There are billions of documents on the World Wide Web (WWW), which are used bybillions of users globally; for that reason, it is increasingly difficult to find, organize, andmaintain the information required by the users. The notion of a Semantic Web (Berners-Lee et al. (2001)), that provides enhanced information access based on the exploitationof machine-processable meta-data, has been proposed to address these problems.

The Semantic Web is accepted as an extension of the current Web where, documentsare annotated with meta-information. This meta-information defines how the informationcontained in documents will be available in a processable way by machines. The explicitrepresentation of meta-information, accompanied by ontologies, will enable a Web thatprovides a qualitatively new level of service.

Ontologies are a key to enable technology for the Semantic Web. Because they providea semantic model to the data, enabling common vocabulary to exchange information.

Figure 2.4 ontology markup languages

The development of the Semantic Web proceeds in steps, each step building a layeron top of another. The Figure 2.4 shows the main layers of the Semantic Web.

At the bottom there is XML language that permit to write structured Web documentswith a vocabulary defined by the developer. Unfortunately XML imposes no semanticconstraint on the meaning of these documents. XML is responsible for an important rolein the exchange of a wide variety of data on the Web.

17


RDF is a basic data model for writing simple statements about Web objects(resources).The data models can be represented in a XML syntax. Its structure is composed by threeobjects: resource, properties and triples. Resource is what is described by a RDFexpression and is identified by URI (Uniform Resource Identifier). A property is anycharacteristic used to describe a resource. A triple has the follows form: < resource,property, value >, that means “the resource that has the property with certain value”. Forexample, the figure 2.5 represents the statement “Camila Bezerra is the owner of the Webpage http://www.cin.ufpe.br/ cbs”.

Figure 2.5 RDF Triple

RDF Schema provides a model of primitives for organizing Web objects into hier-archies. The main primitives are classes and properties, subclasses and subpropertiesrelationships, and domain and range restrictions.

OWL is a language for describing properties and classes of RDF resources, withsemantics for generalization hierarchies of such properties and classes.

The logic layer allows to write specific applications with declarative knowledge.The proof layer involves deductive process and representation of proofs in Web

languages(the languages described previously) and validation.Finally, the trust layer will comes up from the use of digital signatures and other types

of knowledge.Due to the great importance of the OWL to this work, OWL will be discussed in more

details in the next section.

2.5.3 OWL

In 2001, the W3C formed a working group called Web-Ontology (WebOnt) WorkingGroup. The aim of this group was to make a new ontology markup language for theSemantic Web, called OWL (Web Ontology Language). It has taken DAML+OILfeatures as the main input for developing OWL and have proposed the first specificationof this language (McGuinness and van Harmelen (2004)). OWL has three increasingly-expressive sublanguages: OWL Full, OWL DL, and OWL Lite.

• OWL Full: represented the OWL language more expressive. It permits the combi-nation of primitives of the OWL with RDF/RDF Schema. For example, in OWL

18


Full a class can be treated simultaneously as a collection of individuals and as anindividual in its own right; this is not permitted in OWL DL. However, the languagehas become so powerful as to be undecidable, resulting in a incomplete reasoningsupport.

• OWL DL: in order to obtain computational efficiency, OWL DL restricts how theconstructs from OWL and RDF may be used. Essentially application of OWL’sconstructor’s to each other is disallowed, thus ensuring that the language corre-sponds to Description Logic. The advantage of this is that it permits efficientreasoning support.

• OWL Lite: it is the more restrictive and include the expressivity of frames anddescription logic with restrictions. For example, classes can only be defined interms of named superclasses, and only certain kinds of class restrictions can beused.

OWL is built on RDF and RDF Schema and uses RDF’s XML-based syntax.OWL adds more vocabulary for describing properties and classes. For instance,

relations between classes(e.g. inheritance), cardinality(e.g. “at least four”), characteristicsof properties (e.g. functional), and others.

The table 2.5.3 shows some constructs from the OWL language. The “intersetionOf”,“unionOf” and “complementOf” are constructs deriving from the set theory.

“allValuesFrom” and “someValuesFrom” are property restrictions, for example, aparticular class may have a “someValuesFrom” restriction on a property that at least onevalue for that property is of a certain type. As described in the last line of the table:“Exists at least one woman that has a child”.

“masCardinality” and “minCardinality” are cardinality restricions. That is, the restric-tions constrain the cardinality of that property on instances of that class. For example, “Awoman that has 3 childrens at most”.

Moreover, all the conditions that we have used in class descriptions have been “neces-sary” conditions.

Necessary conditions can be read as, “If something is a member of this class then it isnecessary to fulfil these conditions”. With necessary conditions alone, we cannot say that,“If something fulfils these conditions then it must be a member of this class”. A class thatonly has necessary conditions is known as a Primitive (partial) Class. A class that hasat least one set of necessary and sufficient conditions is known as a Defined (complete)

19

2.6. ONTOLOGY TOOLS

Constructor DL Syntax ExampleintersectionOf C1u·· ·uCn Person u Employed

unionOf C1 t ·· · tCn Man tWomancomplementOf ¬C ¬ManallValuesFrom ∀P.C ∀hasChild.Mother

someValuesFrom ∃P.C ∃hasChild.WomanmaxCardinality ≤nP ≤3hasChild.WomanminCardinality ≥ nP ≥ 1hasChild.Woman

Table 2.1 OWL Constructs

Class. In our Pizza ontology, Cheesypizza is a defined class ( i.e. with a necessary andsufficient condition)’.

2.6 Ontology Tools

In the last years, a high number of environments dealing with ontology have appeared.The ontology tools can be classified as follows(Gomez-Perez et al. (2002)):

Ontology development tools: this class includes tools that can be used for building anew ontology from model or reusing existing ontologies. Beyond the usual editionand browsing functionality, these tools usually include ontology documentation,ontology export and import functions from different formats, graphical views ofthe ontologies, ontology libraries, inference engines, etc.]

Ontology evaluation tools: they appear as support tools that ensure that ontologies andtheir related technologies have a given level of quality. For example, the Onto-Analyser and OntoGenerator, both supported by Ontoprise3 and Institute AIFB4,were realized as plugins for OntoEdit(Sure et al. (2002)) which is a graphicallyoriented ontology engineering environment. OntoAnalyser focuses on evaluationof ontology properties, in particular language conformity and consistency. Onto-Generator focuses on evaluation of ontology based tools, in particular performanceand scalability.

Ontology-based annotation tools: these tools have been designed to allow users inser-ting and maintaining (semi)automatically ontology-based markups in Web pages.

3http://www.ontoprise.de4http://www.aifb.uni-karlsruhe.de

20

2.6. ONTOLOGY TOOLS

For example, the COHSE5 developed by the Manchester Information ManagementGroup and the Southampton’s Intelligence, Agents and Multimedia Group(IAM).The aim of this set of tools is the use of metadata to support the construction andnavigation of links in the Semantic Web.

Ontology storage and querying tools: these tools have been created to allow usingand querying ontologies easily. Example: the Sesame6, is being developed byAidministrator Nederland. It is a system consisting of a repository, a query engineand an administration module for adding and deleting RDF data and Schemainformation.

Ontology learning tools: they are used to (semi)automatically derive ontologies fromnatural language texts. The ontology learning is a complex multi-disciplinaryfield that uses the natural language processing, text and Web data extraction,machine learning and Ontology Engineering. For example, the Text2Onto7 is aframework, developed at the University of Karlsruhe, for ontology learning fromtextual resources. The idea is to get better extraction results and to reduce theneed for an experienced ontology engineer by using several different extractionapproaches and then combining the results. This architecture is based on Dataimport, Natural language process, algorithm library(Statistical, Data Mining, etc.),result presentation and ontology engineering environment.

Ontology merge and integration tools: the tools aim to solve the problem of mergingor integrating different ontologies on the same domain.

In addition, there are the ontology development tools and ontology merge and integra-tion tools, which receive more attention in this work because they are closely relating toOntology Modularization.

In the next sections, we will try to provide a broad overview of some of the availabletools and environments that can be used for the building ontologies and merge ontologies.

2.6.1 Ontology development tools

Many ontology development tools exist for building ontologies, but there is the necessityof interoperate between different tools. The lack of interoperability between all these

5http://cohse.semanticweb.org/6www.openrdf.org7http://ontoware.org/projects/text2onto/

21

2.6. ONTOLOGY TOOLS

tools generate problems, for example, when integrating an ontology into the ontologylibrary of a different tool.

Other problem is the fact that they do not cover all the activities of the ontology lifecycle.

In the next sections, we will show some ontology development tools.

OILEd

OILEd(Horrocks et al. (2000)) is a graphical ontology editor, implemented in Java,developed by the University of Manchester.

The knowledge model of OILEd is based on DAML+OIL. Thus, OILEd offers afamiliar frame-like paradigm for modeling while still supporting the rich expressivenessof DAML+OIL where required. Classes are defined in terms of their superclasses andproperty restrictions, with additional axioms capturing further relationships such asdisjointness. The expressive knowledge model allows the use of complex compositedescriptions as role fillers. This is in contrast to other existing frame-based editors, wheresuch anonymous frames must be named before they can be used as models.

Moreover, OilEd provides the FaCT8 reasoner to check the consistency of ontologies,add implicit subClassOf relations, and export ontologies to different formats, includingthe Ontology Interchange Language Resource Description Framework (OIL-RDF) andDARPA Agent Mark Up Language Resource Description Framework (DAML-RDF).

OntoEdit

OntoEdit(Sure et al. (2002)) is an Ontology Engineering Environment which has a gra-phical interface and supports the development and maintenance of ontologies. OntoEdit9

is built on top of a powerful internal ontology model, which can be serialized using XML,and supports the internal file handling. This tool supports representation-language tomodel concepts, relations and axioms. Furthermore, provides graphical views to supportmodeling of different phases of the Ontology Engineering cycle.

The tool allows the user to edit a hierarchy of concepts or classes (figure 2.6). Theconcepts may be abstract or concrete, which indicates whether or not it is allowed to createinstances of the concept. The tool allows similar to the well-known “copy-and-paste”functionality the reorganizing of concepts within the hierarchy.

8http://www.cs.man.ac.uk/ horrocks/FaCT/9http://www.ontoknowledge.org/tools/ontoedit.shtml

22

2.6. ONTOLOGY TOOLS

Figure 2.6 OntoEdit

OntoLingua Server

The Ontolingua Server(Farquhar et al. (1996)) has been developed by the KnowledgeSystems Laboratory (KSL) at Stanford University. Consist in a set of tools and servicesthat support the building of shared ontologies between distributed groups. The architectureprovides access to a library of ontologies, translators to languages like Prolog, and aneditor to create and browse ontologies. Furthermore, it permits that remote editors canbrowse and edit ontologies. Remote or local applications can access any of the ontologiesin the ontology library using the OKBC (Open Knowledge Based Connectivity) protocol.

23

2.6. ONTOLOGY TOOLS

Protégé

Protégé10 is a free, open-source platform that provides a suite of tools to build domainmodels and knowledge-based applications with ontologies.

Protégé implements a set of knowledge-modeling structures and actions that supportthe creation, visualization, and manipulation of ontologies in various representationformats. The user can customize the Protégé for creating knowledge models. Moreover,Protégé can be extended by way of a plug-in architecture for building knowledge-basedtools and applications.

The protégé provides the tab plugins which provide capabilities as visualization,ontology merging and version management, inferencing, and so on. The OntoViz andJambalaya tabs, for example, present different graphical views of a knowledge base, withthe Jambalaya tab allowing interactive navigation, zooming in on particular elements inthe structure, and different layouts of nodes in a graph to highlight connections betweenclusters of data.

The Protégé-OWL editor(see figure 2.7) is an extension of Protégé that supports theOWL, which is the most recent development in standard ontology languages, supportedby the World Wide Web Consortium (W3C).

The Protégé-OWL editor enables users to: load and save OWL and RDF ontologies,edit and visualize entities(classes, properties,instances and SWRL11 rules), define logicalclass characteristics as OWL expressions, execute reasoners such as Description Logicclassifiers and edit OWL individuals for Semantic Web markup.

2.6.2 Ontology matching and integration tools

The area of ontology matching has been received high interest from the communitybecause it helps to solve problems related to ontology heterogeneity. The diversityof information dispose on the Web must coexist with the interaction between systems.An option to make different ontologies compatible is to establish mappings betweenontologies, and to merge them at run-time.

Ontology merging is the process of generating a single, coherent ontology from twoor more existing and different ontologies related to the same subject. A merged singlecoherent ontology includes information from all source ontologies but is more or lessunchanged. The original ontologies have similar or overlapping domains but they are

10http://protege.stanford.edu/11http://www.w3.org/Submission/WRL/

24

2.6. ONTOLOGY TOOLS

Figure 2.7 Protégé

unique and not revisions of the same ontology.Ontology merge is very important in design time, since the merger companies or

organizations in general can lead to a merge of their ontologies. Because there may bethe necessity of merging several ontologies to have another with better quality.

Ontology alignment aiming to find relationships between concepts belonging todifferent ontologies. The ontology alignment problem can be described in one sentence:given two ontologies each describing a set of discrete entities (which can be classes,properties, rules, predicates, etc.), find the relationships (e.g., equivalence or subsumption)holding between these entities.

Below we present some of the ontology matching and integration tools.

Chimaera

Chimaera(McGuinness et al. (2000)) is a merging and diagnostic web-based browserontology environment. It supports merging multiple ontologies together and diagnosingindividual or multiple ontologies. The development was based on development of theothers user interfaces for knowledge applications such as the Ontolingua, the StanfordCML editor and the Stanford JAVA Ontology Tool(JOT).

Chimaera contains an editing environment and allows the user to use others edi-tor/browser environment like OntoLingua. It facilitates merging by allowing users to

25

2.6. ONTOLOGY TOOLS

upload existing ontologies into a new workspace or into an existing ontology.Chimaera allows users to run a diagnostic suite of tests selectively to analyze the

ontologies. The tests include incompleteness tests, syntactic checks, taxonomic analysis,and semantic checks.

ODEMerge

ODEMerge (Ramos (2004)) is a tool to merge ontologies that is integrated in WebODE,the software platform to build ontologies that has been developed by the Ontology Groupat Technical University of Madrid. Therefore, it is a client-server tool that works in theWeb.

ODEMerge provides a partial software support for the methodology for merging on-tologies elaborated by Diego (R (2001)). This methodology proposes the following steps(see Figure 2.8): transformation of formats of the ontologies to be merged, evaluation ofthe ontologies, merging of the ontologies, evaluation of the result and transformation ofthe format of the resulting ontology to be adapted to the application where it will be used.

Figure 2.8 The steps of the ODEMerge Methodology

An important characteristic of ODEMerge is that it can be used to merge ontologies inso many ontology implementation languages as the ones that WebODE processes, sinceWebODE is the host platform of ODEMerge.

Alignment API

This API for manipulating alignments, was developed at the INRIA-Grenoble12. Theauthors have designed a format for expressing alignments in a uniform way(Euzenat

12http://www.inrialpes.fr/

26

2.6. ONTOLOGY TOOLS

(2004)). The goal of this format is to make available alignments to be shared on the Web.This format is expressed in RDF.

The API itself is a Java description of tools for accessing the common format. Itdefines four main interfaces (Alignment, Cell, Relation and Evaluator) and proposes thefollowing services ( see http://alignapi.gforge.inria.fr/):

• Storing, finding and sharing alignments;

• Piping alignment algorithms (improving an existing alignment);

• Manipulating (thresholding and hardening);

• Generating processing output (transformations, axioms, rules);

• Comparing alignments;

• And publishing ontology alignments on the Web.

The alignment description is composed of the following components:

• a pair of ontologies between which the correspondences are established;

• a level used for characterizing the type of correspondence;

• a set of correspondences which express the relation holding between entities of thefirst ontology and entities of the second ontology;

• an arity (default 1:1) which the usual notations are 1:1, 1:m, n:1 or n:m.

The alignment described in the figure 2.9 displays the alignments between entitiesfrom two bibliographic ontologies. It contains two correspondences; the first one relatesthe class reviewed article from onto1 to the class article from onto2, with a confidencefactor of 0,63.

2.6.3 Neon ToolKit

The NeOn toolkit13 is a free, open source extensible Ontology Engineering Environment.It has been developed by the NeOn project which is a 14.7 million Euros project involving14 European partners.

13http://www.neon-toolkit.org/

27

2.6. ONTOLOGY TOOLS

Figure 2.9 An alignment generated by the alignment API

The NeOn toolkit contains plugins for ontology management and visualization. Thecore features include: basic editing of XML, visualization/browsing, import/export toF-Logic, (subsets of) RDF(S) and OWL. It is part of the reference implementation of theNeOn architecture.

The toolkit combines several features of the approaches discussed above, like deve-lopment, alignment and evaluation of ontologies.

The NeOn Toolkit (see figure 2.10) is designed as an open and modular architec-ture, which includes infrastructure services, such as a registry and a repository, andsupports distributed components for ontology management, reasoning and collaborationin networked environments.

It has a strong emphasis on networked ontology management, i.e. support for en-gineering ontologies that are embedded in a network of ontologies via rich semanticrelationships, including models for modular ontologies and mappings across ontolo-gies(Haase et al. (2008)). Based on Eclipse, the Toolkit defines an open framework forplugin developers.

2.6.4 Conclusion

There are several tools, methodologies and techniques to develop and maintain ontologies,but neither of them provides a good support to reusing of ontologies.

28

2.6. ONTOLOGY TOOLS

Figure 2.10 Neon ToolKit

Therefore it would be very interesting if the ontology developer could build anontology by reusing parts of other ontologies.

Many ontology development methodologies and methods, such as the Ontology 101method and Methontology(described in the previous sections), include a reuse step inthe ontology development that allow ontology developers to integrate into the ontologythat they are currently designing and implementing an ontology that has already beendeveloped.

Concerning languages, only OWL give some support a reuse of ontologies. OWLprovides the <owl:imports> construct for linking multiple OWL ontologies to form alarger OWL ontology, i.e, the whole ontology is imported. However, such syntacticimporting solution of OWL lacks support for partial reuse of ontologies.

With respect to tools, Protégé allows the reuse of another ontology by including itin the model that is being designed, this happens through the inclusion of other projects.Besides, there is a plugin for Protégé, called Prompt which permits to extract a part ofan ontology. The user enter with a class, the system recursively follows the propertiesaround the selected class of the ontology, until a given distance is reached.

The NeOn ToolKit has a modularization plugin that provide to create modules reusingparts of an ontology and other modules. However, it does not permit important tasksrelated to reuse, for example, assigning restrictions to new entities(classes, properties

29

2.6. ONTOLOGY TOOLS

and instances) using the imported entities like disjointness of classes and existentialrestrictions.

The present work proposes a concrete tool which tries to supply the lack of mecha-nisms for modularization of ontologies.

In the next chapter, will discuss about the modularization of ontologies.

30

3Ontology Modularization

The notion of modularization came from Software Engineering where it refers to soft-ware development in a structured way that supports the combination of self-containedcomponents that are easier to build, reuse and maintain.

“From an Ontology Engineering perspective, modularization should be considered asa way to structure ontologies, meaning that the construction of a large ontology shouldbe based on the combination of self-contained, independent and reusable knowledgecomponents”(d’Aquin et al. (2007)).

By separating knowledge entities, modularization allows that the developers focusonly on the elements that are relevant for a given application at a given time. Therefore,the modularization improves performance, by reducing the amount of knowledge thathave to be manipulated by ontology-based tools, including reasoners and editors.

3.1 Reusability

Ontologies have been used to solve problems of distributed knowledge, integration ofinformation across applications and to permit an efficient communication between agentsin the e-commerce, for instance. But to obtain a successful result in these applications isneeded the ability to share and reuse existing ontologies.

Reusability is one of the most significant aspects in Software Engineering in general.For example, software engineers have developed libraries of software that are reusingin other applications. In Ontology Engineering, enabling knowledge reusability is animportant goal for building ontologies. Moreover, increasing the reusability of knowledgeimplies in the maximization of its usage among several activities. The main benefits ofontologies reuse are( Jarrar (2005)):

31

3.2. MOTIVATION

• Savings in cost, time and efforts: this means that instead of creating an entireontology with elements already built elsewhere, one may reuse an existent ontologyor some parts of it that satisfy your needs.

• Increasing reliability: a reusable ontology gives indication that is approved andgenerally accepted.

Nevertheless, there are challenges that hamper ontology reusability. The main pro-blem resides on the dependency up the purpose that an ontology is made for. Ontologiesare intended to capture knowledge at the domain level. Thus, when reuse knowledge for adifferent purpose, the usability perspectives for both purposes may differ. Therefore, on-tology reusability will be restricted depending on how different the usability perspectivesare.

Another important issue is the difficulty on identifying and isolating the reusable parts,i.e, allowing the general-purpose parts of an ontology to be reused instead of reusing thewhole ontology.

One possible way to achieve reusability is through the process of modularization thatconsists on identifying and extracting significant parts of an existent ontology. In thiscontext, the set of extracted entities is called module.

3.2 Motivation

The benefits of modularization are well known from many areas of Computer Science.For example, in Software Engineering there is the notion of components where you builda software reusing other components what provides quick development, organization,reusability and easy understanding.

Stuckenschmidt2003 (2003) mentions three benefits for Ontology Modularization:

Distributed Systems: ontologies in different places are built independent of each otherand can be assumed to be heterogeneous. Unrestricted referencing to concepts in aremote ontology can therefore lead to serious semantic problems as the domain ofinterpretation may differ even if concepts appear to be the same on a conceptuallevel. The introduction of modules with local semantics and clearly specifiedinterfaces can help to overcome this problem.

Large Ontologies: those ontologies that sometimes contain more than a hundred thou-sand concepts are hard to maintain as changes are not contained locally but can

32

3.2. MOTIVATION

affect large parts of the model. Another argument for modularization in the presen-ce of large ontologies is reuse as in most cases, we are not interested in the completeontology when building a new system, but only in a specific part. Experiences fromSoftware Engineering shows that modules provide a good level of abstraction tosupport maintenance and reuse.

Efficient Reasoning: a specific problem that occurs in distributed ontologies and verylarge models is the problem of efficient reasoning. The introduction of moduleswith local semantics and clear interfaces will help to resolve this problem andprovides a basis for the development of methods for localizing inference.

Moreover, modularization could help the ontologies developers to identify and selectonly those concepts and relations relevant for the application they are modeling anontology for(Bezerra et al. (2008)).

Considering aspects of Software Engineering, the modularization also brings benefits“as a mechanism for improving the flexibility and comprehensibility of a system whileallowing the shortening of its development time” (Parnas (2002)). Some authors fromOntology Engineering believes that modularity in ontologies may bring similar benefitsfor the development and management of large ontologies. The expected Engineeringbenefits of ontology modularity include the following ( Bao (2007) ):

Collaboration: a module can be more easily constructed collaboratively with separategroups working on different modules of the ontology.

Flexibility: a module can be easy built by composition or decomposition of parts ofother modules and ontologies; an ill-designed or obsolete module can be replacedwith a new module with controlled impact on other modules.

Understandability: due to the structure of a module, it is easier to understand thecontents of the module.

Debugging: well-defined semantic modularity can help developers to quickly find andsolve problems.

Scalability: many ontology tools, e.g., reasoners, editors and query engines, are knownto perform well on small-scale ontologies, but drastically degrade in performancewhen the size of the ontology increases.

33

3.2. MOTIVATION

3.2.1 Syntactical and Semantic Modularity

Bao (2007) suggests that the need for modularity can be viewed along some points dividedin basically two dimensions, the syntactical modularity and semantic modularity. Syntac-tical modularity addresses the need to organize large ontologies in multiple, manageable,compact modules, so that interactions between ontology modules are well-controlled formore efficient ontology construction, revision and reuse. Semantic modularity tacklesthe need to allow localized and contextual points of view of autonomous contributors ofdifferent ontology modules and distributed reasoning.

Syntactical Modularization

We can consider the following aspects of syntactical modularity:

Loose Coupling: consists on minimizing the interactions between the modules. It canbe measured by the connectedness of modules, i.e, the number of shared symbolsbetween axioms in different modules. In order to get an efficient reasoner, modulesmust be loosely connected.

Organizational Structure: consists on making modules by organization of symbols andrelations of moderate-sized units that are easy to design, use and reuse.

Syntactical Partial Reuse: it is the ability of reusing only relevant parts of an ontology.Modular structure would enable flexible and efficient partial reuse of the ontology.

Semantic Modularization

Typically the ontologies in the Semantic Web captures contextual knowledge. Suchknowledge may depend on implicit assumptions that the ontology users are not alwaysaware of. Some contextual aspects include the following:

Implicit Domain of Discourse: reuse of knowledge without regard to applicable contextcan lead to unintended consequences.

Differences in the universe of discourse: suppose we will query two ontologies aboutprofessors in two different departments. In the first ontology, the individuals areexplicitly enumerated by their names e.g., Professor = {John,Michel}. In thesame way, the second ontology, have Professor = {Peter,Mary}, but the namesare different and are disjoint from the ones in the first ontology. Hence, the

34

3.3. DEFINITION

two ontologies disagree on the members of Professor such that it has differentinterpretations in the two contexts.

Subjectivity: different contexts can occur when there are different political, cultural andsocial points of view of ontologies developers. For example, in Western countries,the notion of Weekend typically refers to Saturday and Sunday, while in Muslimcountries it is Friday and Saturday. This can cause inconsistences if both ontologiesare reused in a module.

Spatio-Temporal Contexts: the same sentences can regard different meanings in differ-ent places and time. For example, the sentence “Today is Monday” can be true orfalse depending on the place and time you are in the world.

Moreover, it is important a low coupling and strong cohesion that are explained below.

3.2.2 Coupling and Cohesion

Coupling focuses on aspects of relationships between modules, whereas cohesion empha-sizes the internal consistency of a module.

Coupling is the level of inter-dependency among the modules. The coupling is directlyrelated to cohesion, since the higher the coupling the lower the level of cohesion. This isbecause that when a module has a very strong dependency on another module or class, itis not “strong” enough to do tasks individually.

Modules with high coupling are more difficult to understand and maintain.Cohesion shows consistency or conceptual unity in the relationship with the other

modules. Cohesion depends on information hiding( isolating the internal implementationdetails of the module). A cohesive module should ideally have a unique responsibilitythat can be accomplished through a public service interface with the environment.

Therefore, is desirable low coupling and strong cohesion among the modules.

3.3 Definition

Generally speaking, a module is some subset of a whole that makes sense and cansomehow exist separated from the whole, although not necessarily supporting the samefunctionality as the whole.

From an application perspective, the module must be able to provide a reasonableanswer to at least some of the queries which it is intended to support.

35

3.3. DEFINITION

And, from the system perspective, the module organization must be capable ofimproving the performance of at least some of the ontology management services.

While the notion of module is quite well understood and accepted in the area ofSoftware Engineering, in the Ontology Engineering, it is not clear at all what the charac-teristics of an ontology module are. One possible definition for an ontology module is thefollowing:

An ontology module is a reusable component of a larger or more complex ontology,

which is self-contained but bears a definite relationship to other ontology modules.

In the literature we find similar definitions. Cuenca et al. (2006) state “a moduleshould contain information about a selfcontained subtopic”. This concurs with Stucken-schmidt2003 (2003) who state that “in order to facilitate the reuse of individual moduleswe have to make sure that modules are self-contained.” Thus, an ontology module isan ontology that is a self-contained subset of a parent ontology. An ontology moduleis self-contained if all the concepts defined in the module are defined in terms of otherconcepts in the module, and do not reference any concept outside the module. In additionBernardo Cuenca Grau (2005) state “the module for an entity is the minimal subset ofaxioms in the ontology that capture its meaning precisely enough and hence the minimalset of axioms that are required to understand, process, evolve and reuse the entity”.

Most ontologies are developed under the open world assumption, but a module mustbe self-contained, i.e, no references to concepts outside the ontology module. Thus,a reference outside of the ontology becomes false or unknown. This requires that theopen world assumption be relaxed in order to verify whether ontology modules areself-contained. Moreover, this definition implies that modules are not isolated entitiesbut are related to each other. The notion of intermodule relationships is analogous to thenotion of coupling in the Software Engineering paradigm.

There are two generic approaches about developing modules. One is the compositionapproach which modules are put together to form a collection providing some newservices. On the other hand, the decomposition approach, splitting may be done manually,but is more likely to be done automatically by the ontology management system, basedon a decomposition criterion explicitly defined by the ontology administrators. theapproaches are describe as following:

Composing (M⇐M′1⊗ ...M′n) is the favorite approach in Software Engineering wherea software is built by assembling modules.

Partitioning (O⇒ O′1⊗ ...O′n) is the back-up strategy when one starts with some mono-lithic software (or ontology) and attempts at transforming it into a modular software.

36

3.4. PARTITIONING APPROACHES

Depending on the reasons to do this (allowing separate inference or generatingmodules for reuse), the results may be different.

In the next sections we present a review and critical discussion of the main approachesto Ontology Modularization.

3.4 Ontology Partitioning and its Approaches

The partition process consist in splitting up the set of axioms into a set of modulesM1,· · · ,Mn such that each Mi is an ontology and the union of all modules is semanticallyequivalent to the original ontology O.

Below, we present two approaches based on Ontology Partitioning.

3.4.1 Structured-Based Partitioning

Stuckenschmidt and Klein (2004) proposed a method for structured-based ontologypartitioning which focus on the task of splitting up an existent ontology into a set ofmodules according to some criteria that define a good modularization. For this, theconcepts within a module must be semantically connected to each other and must nothave strong dependencies with information outside the module. The notion of dependencybetween concepts is defined as a weighted graph G = 〈C,D,w〉 where nodes (C) representconcepts and links (D) between concepts represent different kinds of dependencies thatcan be weighted(w) according to the strength of the dependency.

Their approach suggests two assumptions:

1. Dependencies between concepts can be derived from the structure of the ontology.

2. The quality of a modularization can be determined on the basis of the structure ofthe individual modules and the connections between them.

Moreover, they proposed a partitioning algorithm which has the following steps:

1. Create the Dependency Graph: in the first step, a graph structure is created thatrepresents the dependencies between elements in the ontologies.

2. Determine the Strength of Dependencies: next, the strength of the dependenciesbetween the concepts have to be determined. The strength of the dependency of aconnection between a node ci and c j is determined to be the proportional strengthsof the connection which describes the importance of a link from one node to theother based on the number of connections a node has.

37

3.4. PARTITIONING APPROACHES

3. Determine Modules: in this step, the set of concepts are chosen to be in one module.For this, the “line island”(Stuckenschmidt and Klein (2004)) method is used, thatconsists in choosing a set of nodes in which the strength of the connection betweenthe nodes inside the set is higher than the strength of any connection to nodesoutside the set is used to determine sets of concepts that should be in one module.

4. Assign Isolated Concepts: after partitioning, if some nodes which are not assignedto any module already exist, they are assigned to the module to which they havethe strongest connection.

5. Merging: in this step, if exists some neighbored modules strongly connected, theycan be merged.

6. Axiom Duplication: sometimes it is beneficial to duplicate axioms and includethem in more than one module. This occurs if the duplication phase decreases theconnectedness of the distributed ontology.

This approach is automatic and require minimal user involvement. One drawback isthat they don’t consider the semantics of the relations( the “mean” of the relations) intheir method, just provide a simple method based on the structure of the ontology.

3.4.2 Ontology Partitioning using ε-connections

Cuenca Grau et al. (2005) tackle the problem of transforming an OWL ontology O intoa ε-connection β in such way that each of the relevant sub-domains modeled in O isrepresent in a different component of β .

According to authors “the ε-partitioning problem is the problem of finding the ε-

module corresponding to each entity in O”.They proposed a partitioning algorithm that given an ontology O and a concept A,

retrieves a module M. The goal of the algorithm is to generate from the input ontology Oa directed labeled graph G(O), called the partitioning graph, and then use the graph tofind the module for each entity in O.

The algorithm consists of three main steps: first, a “safety” check, which is key forensuring that the obtained fragments preserve certain crucial entailments; second, thegeneration of the partitioning graph G(O) and, finally, the extraction of the module foreach entity from G(O).

However, ε-connections have limited expressiveness of the connections made betweenpartitions. Moreover, the semantics idea is that each ontology in the combination is

38

3.5. FORMAL INTERPRETATION

interpreted in a different logical domain, disjoint from the rest. This results in certainrestrictions to the partitioning process. For example, a concept in a certain ε-connectedontology can not be a subclass of a concept in a different ontology in the combination.

In the SWOOP(Cuenca Grau et al. (2005)) editor has the partitioning functionalitybased in this approach. Its mechanism consist in to break an given ontology into a setof modules connected by “ε-connections”, which preserving the completeness of localreasoning within all created modules.

3.5 Formal Interpretation of Ontology Modules

With the advent of the distributed ontologies, special reasoners to carry on queries basedon Description Logic taking into account their distributed nature. Indeed, the semantic ofdistributed DL ontologies must be defined formally. Below, we present two languagesthat have been proposed to make for such type of reasoning.

3.5.1 DDL - Distributed Description Logics

The Distributed Description Logics( Borgida and Serafini (2002) ) adopts a linkingmechanism relating the elements of "local ontologies" with elements of an "externalontology". The "local ontologies" are called "context".

Each context Ci is associated to its own local interpretation. Semantic relations areused to make correspondences between elements of local interpretation domains. Theserelations are expressed using bridges rules.

Bridge rules between concepts have important role in modular ontologies: They areintended to assert relationships, like concept inclusions, between elements of two differentlocal ontologies. However, the bridge rules are not assumed to be read as classical DLaxioms, mainly because of the local interpretation.

DDL is limited in connecting modules with roles. For instance, roles defined in otherontology modules (foreign roles) cannot be used to build new concepts, or to constructnew roles from foreign roles.

3.5.2 IDDL - Integrated Distributed Description Logics

One way of reasoning on a network of multiple ontologies adopted by DDL, P-DL andε-connection, for instance, consists in defining new formalisms which allow reasoningon multiple domains in a distributed way. However, these formalisms use ontology

39

3.5. FORMAL INTERPRETATION

Figure 3.1 Distributed system

correspondences like bridge rules, links or imports from one ontology’s point of view,while often, such correspondences are expressed from a point of view that includes bothaligned ontologies, which can lead to inconsistences. Below we show an inconsistenceexample extracted of Zimmermann and Duc (2008b).

For example, we consider a network of 3 independently developed ontologies O1,O2 and O3 connected via alignments A12, A13 and A23 probably computed by third partyontology matching tools. The first ontology is about geopolitical information, includingrulers, countries, etc. The second is an ontology of the biological kingdom Animalia. Thethird one is about geographical regions on Earth (see Figure 3.1).

The correspondence between O1 and O2 simply asserts that a Woman in O1 is a kindof Female in O2. The correspondence between O2 and O3 asserts the disjunctness ofconcepts Female and Country. Finally, the alignment between O1 and O3 denotes that aRegion in O1 defines the same thing as a Region in O3; that Guyana is a part of Franceand Guyana is a region in South America.

Other approaches would simply consider correspondences as axioms adding supple-mentary information about the merged ontologies. While it is a very natural possibility, itleads to an unexpected inconsistency. Since Guyana is a part of France, and partOf istransitive, Guyana, is also a part of Europe. Moreover, Guyana is a region, and therefore

40

3.6. APPROACHES

it ought to be an European region. Besides, a correspondence tells that it is also a SouthAmerican region. This is contradictory with the axiom of O3 stating that European regionsare disjoint with South American region.

IDDL (Zimmermann (2007)) is a formalism for distributed reasoning upon distributedsystem which is composed of a set of ontologies, interconnected by ontology alignments.

Similarly to DDL, an IDDL interpretation allocates a different interpretation to eachontology but instead of relating domains directly, they are correlated in another domaincalled global domain of interpretation, which could detected inconsistencies like the citedabove.

IDDL has the following interesting characteristics(Zimmermann (2007)):

• The distributed process uses existing DL reasoners like Pellet1 and Racer2;

• Local ontologies are encapsulated in the local reasoning system, so it is not neces-sary to access the content of the ontologies in order to determine the consistency ofthe overall system;

• The expressiveness of local ontologies is not limited as long as it is a decidableDescription Logic.

After having present these two semantics for distributed ontologies’ formal interpreta-tion, we will discuss modularization approaches that take advantage of them.

3.6 Modularization Approaches

In this section we will show some modularization approaches, each one with its ownmodularization techniques.

3.6.1 C-OWL - Context OWL

C-OWL(Bouquet et al. (2003)) is a language which extending the OWL syntaxes andsemantics and aim at the representation of contextual ontologies. Contexts are localmodels that represent a part of the domain view. An ontology is contextualized, orit is called contextual ontology, if its contents is kept local, are not shared with otherontologies and is put in relation with the contents of other ontologies via mappings.

1http://clarkparsia.com/pellet2http://www.sts.tu-harburg.de/ r.f.moeller/racer/

41

3.6. APPROACHES

A contextual ontology is represented by an OWL ontology and set of C-OWL map-pings. Each mapping is a set of bridge rules with the same target ontology. A C-OWLmapping has the following form:

• An identifier (URI)

• A source context containing an OWL ontology

• A target context containing an OWL ontology

• A set of bridge rules between the source ontology and the target ontology. Eachmapping is represented by:

1. a source and target element which is either a concept, a role or an individual.Therefore, the target element must be of the same type as the source element.

2. the type of mapping which is one of v−→, w−→, ⊥−→, ∗−→

In the figure 3.2 is displayed a representation of a C-OWL mapping from the familyontology to the familia ontology. In this example, the Person class is equivalent to Pessoaclass and the Sister class is disjoint to Irmao class. See the COWL code in the figure3.6.1.

Figure 3.2 C-OWL mapping from the family ontology to the familia ontology

C-OWL derives from DDL by considering the OWL as ontology language and byenriching the bridge rules. C-OWL does not support linking two entities in differentmodules with roles.

42

3.6. APPROACHES

<cowl:mapping><rdfs:comment>Example of a C-OWL mapping</rdfs:comment><cowl:sourceOntology

rdf:resource="http://www.example.org/Family.owl"/><cowl:targetOntology

rdf:resource="http://www.example.org/Familia.owl"/><cowl:bridgRule cowl:br-type="equiv">

<cowl:sourceConceptrdf:resource="http://www.example.org/Family.owl#Person"/>

<cowl:targedConceptrdf:resource="http://www.example.org/Familia.owl#Pessoa"/>

</cowl:bridgRule><cowl:bridgRule cowl:br-type="incompat">

<cowl:sourceConceptrdf:resource="http://www.example.org/Family.owl#Sister"/>

<cowl:targedConceptrdf:resource="http://www.example.org/Familia.owl#Irmao"/>

</cowl:bridgRule>...

</cowl:mapping>

Código 3.6.1: Module in XMLSchema format

3.6.2 Reusing of ontologies using “ε-connections”

Cuenca et al. (2006) proposed an approach based on “ε-connections”. An “ε-connection”is a set of connected ontologies which contains information about classes, propertiesand their instances, but the differentially of the OWL has a new type of property calledlink property. In OWL, object properties are used to relate individuals within a givenontology, while datatype relate individuals to data values. In the present approach thelink properties are used to relate individuals belonging to different ontologies.

Link properties allow to create classes in an ontology using information from adifferent ontology, provided that the domains of ontologies are disjoint.

A link property is a relation between instances of classes from different connectedontologies. The source of a link property is the ontology in which it has been declared;the target of the link is the ontology specified in the owl:foreignOntology tag. In thisfigure 3.3, the “wineIsFrom” linkProperty means that specific wines of a country, whichrelated the country ontology to Wine ontology.

The main idea is to break an ontology into a specific combination of smaller ontologies,called an ε-connection. Each ontology into the resulting combination modules is adifferent sub-domain of the input ontology, while the “connections” specify how eachontology in the combination is using information from the others.

The approach provides support for ε-connection in OWL Ontology editor and anOWL reasoner. The goal has been to build an ε-connection aware infrastructure, byextending the ontology editor SWOOP( see figure 3.4) and the reasoner Pellet, both of

43

3.6. APPROACHES

Figure 3.3 Link Property

the same authors.

Figure 3.4 Swoop

ε-connection restricts the terms of modules, as well as their local domains, to bedisjoint. This can be a serious limitation in some situations, because enforce domaindisjointness, for instance, subclass relations cannot be declared between concepts of twodifferent modules.

3.6.3 PDL - Package-based Description Logics

Similarly to C-OWL, P-DL(Bao et al. (2006)) extends from the Description Logic to sup-port selective knowledge sharing through a semantic mechanism and the establishment ofa minimal set of restrictions on the use of imported concepts and roles to support localizedsemantics, transitive propagation of imported knowledge, and different interpretationsfrom the point of view of different ontology modules.

44

3.7. SELECTION APPROACH

In P-DL, an ontology is composed of a set of modules, called packages. P-DL syntaxadopts a semantic importing approach that allows a subset of concepts defined in onepackage to be used in other packages, and imported concepts can be used to constructnew concepts.

Considering the figure 3.5 below:

Figure 3.5 P-DL example

The Package 2 cites the definition of “1:Dog” from package 1. The interpretation of“1:Dog” is the same on the shared portions of the local domains of packages 1 and 2. Thetwo packages need not agree on the interpretation of other unrelated concepts (e.g., Cats).

Moreover, P-DL semantics have the following properties:

• P-DL supports selective knowledge reuse

• Importing establishes one-to-one domain relations.

• Domain relations are compositionally consistent.

• There is no global negation, but only contextualized negation for each package.These two features (composition and limited-scope nagation assure avoiding pro-blems like the one cited in the IDDL subsection above.

• It is assured that inference results using distributed reasoning are equivalent toobtained in a classical reasoning applied on the integration of selected parts froman ontology.

3.7 Selection based Module Construction Approaches

This approach consist in extracting relevant parts from an ontology, called module, thatcovers a particular sub-vocabulary. This task has been called segmentation in Seidenbergand Rector (2006) and traversal view extraction in Noy and Musen (2004).

Considering a given ontology O, a module is formed by a sub-vocabulary of O, that isthe relevant part for the application.

Besides, the partitioning methods to build modules, there are other alternatives tobuild modules. One option is the selection of entities from different ontologies.

45


Moreover, even using partitioning, sometimes we need to relate entities from differentmodules. To realize this task is needed a module editor.

In this section we present two tools that uses an extraction approach to ontologymodularization. The approach consists in extracting relevant parts from one or moreontologies to build a module.

3.7.1 ModTool

ModTool ( Doran (2006) ) is a standalone tool and provides that an graphical userinterface(GUI) for generating ontology modules, with which is designed to allow the userto select which concepts she wants to produce an ontology module. ModTool recursivelyapplies a set of rules to generate an ontology module. It makes use of JENA3 to allow theontology being modularized and the ontology module produced to be persistently stored.

Figure 3.6 presents the description of the algorithm used by ModTool to generateontology modules. Basically, a set of rules are applied. There is a rule for each typeof relation that exists in an OWL ontology. The application of rules adds concepts andrelations to the module. When there are no more concepts that the rules can be applied tothe module is saved as an OWL file.

The author has also proposed a methodology for modularization ontology ( see figure3.7). The steps of the methodology are explains as follows ( Doran et al. (2007) ):

Define competency of module: in this step, on the ontology engineer defines the com-petency questions for the module; these questions should state what the ontologyengineer wants the ontology module to express.

Ontology Selection: in this step the ontology engineer selects the relevant ontologiesfrom which she extracts a module.

Ontology Evaluation: the goal is to evaluate the ontologies selected in the next step tosee how suitable they are for reuse. One criterion to evaluate could be the ontologypopularity. An other could be to check the ontology against the competencyquestions the ontology engineer defined for the ontology module.

Ontology Translation: consists in changing the representational language used to im-plement the ontology. This may be necessary to make the ontology compatiblewith the module extraction process being used.

Extract Module: in this step, the module is extracted from the select ontology.3http://jena.sourceforge.net/

46


Figure 3.6 ModTool’s algorithm

Figure 3.7 ModTool’s methodology

47


Check Competency: here, the extracted module is checked against the competencyquestions, in order to see if they are met.

Refine: when the extracted module doesn’t satisfy the competency questions, the onto-logy engineer should refine the module in a way that attempts to ensure that thecompetency questions are met.

Integrate: finally, when the module satisfies the competency questions, it can be inte-grated into the ontology being constructed.

A problem with tool is that if concepts in the ontology module inherit object propertiesfrom concepts that are not in the module then these object properties are not included.

3.7.2 NeOn Toolkit Support for Ontology Modularization

The NeOn ToolKit provides a set of plugins and software components for OntologyModularization(see figure 3.8). The central component is the NeOn Module API whichprovides the basic structure for creating and manipulating the modules.

The others plugins related to modularization are based on the module API. Theseinclude the plugin for specifying ontology modules, which allows the user to describe amodule in terms of imports and interfaces, composing ontology modules, which allows theuser to put together ontology modules to create new ontologies, the plugin for partitioningontologies, which allows the user to decompose an ontology into modules, and the pluginfor extracting modules from ontologies, which allows the user to extract from an ontologya part that satisfies certain given criteria(d’Aquin et al. (2008)).

The main functionalities are4:

• Create and manipulate the Export Interface elements for a module M and the ImportInterface elements for the modules imported by M;

• Compute the union between two modules by considering or ignoring namespace;

• Calculate the intersection between two modules by considering or ignoring names-pace;

• Compute the difference between two modules by considering or ignoring names-pace;

• Provide alignment between two modules.

4http://www.neon-toolkit.org/wiki/index.php/Modules

48


Figure 3.8 Modularization plugins for the NeOn Toolkit

The NeOn toolkit proposed a generic metamodel(see figure 3.9) for modular ontolo-gies that is consistent extension of the metamodels for OWL DL ontologies and mappings.The main class is the OntologyModule that represent the module. The module is modeledas a specialization of the class Ontology. The reuse of elements from one module byanother module is represented via the ImportInterface. The ExportInterface, modeled viaexports association, exposes the set of OntologyElements that are intended to be reusedby others modules.

Moreover, this tool proposed a syntax that implements the elements the abstractsyntax and of the metamodel at a technological level. They implemented this concretesyntax as an extension of OMV5 (Ontology Metadata Vocabulary) which is metadata thatreflecting the most relevant properties of ontologies for supporting their reuse.

Essentially, every class of the metamodel is represented as a Java class in the API.The module interface of the implementation is described in figure 3.10.

Figure 3.12 displays the screen which the user defines module interface. The user

5http://ontoware.org/projects/omv/

49


Figure 3.9 Metamodel for ontology modules


chooses the elements for the module that are imported from other modules, and can definean export interface with the elements that will be reused by other modules.

Although the notion to create a module reusing parts of another one, it is not possible tocreate, for example, a class that has a imported property, or to add cardinality restrictionsusing an imported entities. Hence, the modularization functionalities provided by the

50



NeOn ToolKit is limited, one of the drawback that we are attempting to make for.

51

3.8. DISCUSSION

3.8 Discussion

In this section, we will discuss the modularization approaches presented in the previoussections and argue against the lack of support to the use of alignments, the neglecting OOprinciples for Ontology Modularization and their limited tool support.

3.8.1 Alignments

DDL and ε-connections express semantic relationships between ontologies according tolocal ontology’s point of view. Thus, alignments cannot be defined in these languages,because relations among the ontologies are associated to one “context” and are nottransitive.

P-DL uses a import mechanism which modules ( called packages ) can be reusedby others modules. Each package typically consists of a set of highly related terms andrelationships between them. There is no notion of alignments between packages. P-DLallows an ontology module to make direct reference to terms defined in other ontologymodules, i.e., importing of foreign terms.

3.8.2 OO principled ontology modules

Neither of the approaches takes advantage of the OO paradigm as a set of guidingprinciples for ontology module construction and reuse. Indeed, concepts borrowed fromthis paradigm could help to delimit accurately the perimeter of ontology modules, thusregulating which parts could be imported/exported.

3.8.3 Tool Support for Ontology Modularization

Moreover the modular languages, there are tools for ontology modularization. Some ofthem have used these languages, like SWOOP that use ε-connection in its partitioningfunctionality.

We presented two tools: the ModTool and the modularization plugin to of the NeOntoolkit. Below, we present a comparative table between the ModTool and NeOn toolkitconsidering five criterios:

1. User involvement

2. Flexibility to select the terms

3. Build new concepts

52

3.8. DISCUSSION

Figure 3.12 Comparative Evaluation

4. Syntactical and Semantic checking

5. Define alignments

With relation to user involvement, the ModTool provides a partial involvement: theuser selects a concept she wants to produce a module.

In contrast to ModTool, the modularization plugin of the NeOn toolkit provides totalinvolvement of the user in the process of building modules. The user chooses the entitieswhich will be reused in the new module.

Nevertheless, none of them offer support to create new entities or adding new axioms,reusing the imported entities. Moreover, they do not provide other support tasks likesemantic checking, only providing the modules producing.

These flaws described here, motivated us to embark on the definition of ontologymodularization approach based on the OO paradigm and also to develop a suite of toolsbased on this modularization approach, and provides to the users different ways to developmodules and more other support tasks, all in one place, the ModOnto.

53

4The OntoCompo Approach and the

ModOnto Suite

In this chapter, it is explained in detail the main contribution of this dissertation which isa suite for modularization of ontologies, called ModOnto.

The suite offers a set of tools that helps the developers to extract significant ontologyparts and encapsulating them in a module. The generated module, in turn, can be reusedby other modules. Moreover, the suite provides support tasks, such as modules library,module syntactically and semantically consistency checking, etc.

The development of the suite was based on the OntoCompo approach, an extract ap-proach that inherits two of the main principles from object-oriented Software Engineering,encapsulation and information hiding.

The OntoCompo approach is explained in the next section.

4.1 The OntoCompo Approach

The OntoCompo project was settled between Cin/UFPE and INRIA-Rhône Alpes inorder to define and implement an ontology modularization approach based on the Ob-ject Oriented approach that provides the definition and composition of modules (orontologies).

Modules created in this way facilitate ontology reuse or partial reuse, by makingseparate development easier with encapsulation and interfaces.

In Software Engineering, encapsulation is the hiding of the internal mechanisms of asoftware component behind a defined interface, in such a way that users of the componentonly need to know what the component does, and cannot make themselves dependent onthe details of how it does it.

The approach adopted the principles of object-oriented components, thus, ontologiesor modules should be seen as units of knowledge (or modules), designed for compositionwith other modules.

The approach has two core requirements. First, the approach should offer facilitiesthat permit and support modules to be specified in such a way that avoids dependencefrom a particular ontology or module. The second requirement consists in buildingmodules in a modular way, but differently from modularization proposals which arebasically ontology linking approaches.

The properties typically expected from a module system are (Euzenat et al. (2007)):

54

4.1. THE ONTOCOMPO APPROACH

Encapsulation: enforces module independence by hiding implementation details toimporting modules. Module specifications are described as an interface whichwhat can be called by importing modules. So module implementation can evolvewithout affecting the importing module specification and modules are replaceableby others offering the same interface. In terms of ontologies, the implementationcorresponds to the set of axioms used to define it.

Separate development: since what imported modules provide is well-defined, softwaredevelopers can rely on this interface and develop their own part. This would beuseful as well for ontology development in which one can concentrate on the devel-opment of part of the model while the part it is relying on is still underspecified.

Separate compilation: decreases development time by avoiding recompiling huge ap-plications at every change. This has been tackled by Stuckenschmidt2003 (2003).

Reusability: because module specifications are descriptions of a coherent and explicitset of primitives that a module is meant to provide, a module can be reused inanother similar context.

Separate execution: allows to be more efficient by executing local code first. In Ontolo-gy Engineering, this is especially useful for inference system Grau et al. (2006).

Low coupling: is desirable that a module is so independent as possible from othermodules. Low coupling minimizes the "ripple effect" where changes in one modulecause errors in other modules. evolution.

High cohesion: modules whose elements are strongly and genuinely related to eachother are desired.

In order to have good module development, the approach has a formal language withsyntaxes and semantics formally defined to meet the requirements above. The modulelanguage must be able to encapsulate ontology fragments, to refer to other modules andto define the interface between these modules.

In the next sections it will be presented the language with its syntaxes and semantics.

4.1.1 Language

The module language enables its users to build modules by reusing pieces of othermodules, ontologies and/or including new definitions. This language has the featureslisted below:

55


• The designed module language wraps ontology fragments using RDF. Althoughthe language not bound to OWL ontology language, currently ontology fragmentsare expressed in the OWL language.

• New knowledge (classes, properties and individuals) can be defined from scratch,or reuse some of the imported definitions.

• Relations among modules make use of URIs (Uniform Resource Identifers).

• Relations among entities from foreign modules are expressed through alignmentsamong the OWL entities provided by these modules.

Language Syntaxes

The module language disposes of two syntaxes:

• a more concise human readable syntax for displaying in documents and

• a RDF1 (Resource Description Framework) syntax, compatible with OWL (McGuin-ness and van Harmelen (2004)), for exchanging between programs.

A module in this language is expressed by a set of tags. Each tag represents a blockof information.

• The Uses tag is the list of external modules or ontologies being used to build thenew one;

• Imports are the list of entities (classes, properties and instances) from other ontolo-gies or modules that are needed to create the new module.

• Contains represents the new entities created using or not imported entities. Newaxioms could be added as well.

• The alignments tag is needed when working with different modules in whichmappings are needed to relate exported entities.

• The exports tag lists are entities from the contains or from list of imported entitiesthat will be available when one reuses the module being defined, i.e. , the classes,properties, axioms and individuals ready for reuse. This tag incorporates theinterface of the module.

1http://www.w3.org/RDF/

56


Figure 4.1 Module Language tags and descriptions.

The Module has an internal ontology (corresponding to the Contains tag of the humanreadable syntax) with new constructs like classes and restrictions. This ontology isgenerated in a different file in the same directory of the module, because the moduleshould be expressed in independent language. Although currently modules are specifiedin OWL, the approach enables any other ontology languages.

Moreover, the language is compatible with the module specification from NeOnwhich is an ontology development environment that provides support to Ontology Modu-larization (see section 3.7.2).

RDF Syntax

The RDF syntax permits that machines can read and process the module and providesthe exchange between programs. The RDF syntax has the constructs discussed previously.Every block of information of the module corresponds to a “tag”. The format of RDFsyntax is presented in figure 4.1.

57


A formal description of the language, displayed as XMLSchema2 is showed in codes4.1.1 and 4.1.2.

<?xml version="1.0" encoding="UTF-8" ?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:element name="contains"><xs:complexType><xs:sequence><xs:element ref="owl2xml:Ontology" />

</xs:sequence></xs:complexType>

</xs:element>

<xs:element name="description"><xs:complexType><xs:attribute name="rdf:about" type="xs:string" use="required" />

</xs:complexType></xs:element>

<xs:element name="ExportedInterface"><xs:complexType><xs:sequence><xs:element ref="hasElement" maxOccurs="unbounded" />


</xs:element>

<xs:element name="exports"><xs:complexType><xs:sequence><xs:element ref="ExportedInterface" />


</xs:element>

<xs:element name="hasElement"><xs:complexType><xs:choice><xs:element ref="owl2xml:Individual" /><xs:element ref="owl2xml:OWLClass" /><xs:element ref="owl2xml:ObjectProperty" />

</xs:choice></xs:complexType>

</xs:element>

<xs:element name="ImportInterface"><xs:complexType><xs:sequence><xs:element ref="hasElement" maxOccurs="unbounded" />


</xs:element>

<xs:element name="imports"><xs:complexType><xs:sequence><xs:element ref="ImportInterface" />


</xs:element>


2http://www.w3.org/XML/Schema

58


<xs:element name="location"><xs:complexType><xs:attribute name="href" type="xs:string" use="required" />


<xs:element name="Module"><xs:complexType><xs:sequence><xs:element ref="description" /><xs:element ref="uses" /><xs:element ref="imports" /><xs:element ref="contains" /><xs:element ref="exports" />


</xs:element>

<xs:element name="owl2xml:Individual"><xs:complexType><xs:attribute name="rdf:about" type="xs:string" use="required" />


<xs:element name="owl2xml:ObjectProperty"><xs:complexType><xs:attribute name="rdf:about" type="xs:string" use="required" />


<xs:element name="owl2xml:Ontology"><xs:complexType><xs:sequence><xs:element ref="location" minOccurs="0" />

</xs:sequence><xs:attribute name="rdf:about" type="xs:string" use="required" />


<xs:element name="owl2xml:OWLClass"><xs:complexType><xs:attribute name="rdf:about" type="xs:string" use="required" />


<xs:element name="rdf:RDF"><xs:complexType><xs:sequence><xs:element ref="Module" />


</xs:element>

<xs:element name="uses"><xs:complexType><xs:sequence><xs:element ref="owl2xml:Ontology" maxOccurs="unbounded" />


</xs:element>

</xs:schema>


59

4.2. FEATURES AND FUNCTIONALITIES

Language Semantics

The semantics should describe formally how to interpret modules and what are thesemantic consequences of a module.

However, our approach is not tied to a specific representation formalism. Therefore,in its wide generality, the semantics of modules should be parameterized by the localrepresentation language. Additionally, modular ontology formalism can vary in the waythey treat the relations between modules.

The semantics of modules is depending on two definitions: the local semantics ofthe language describing a module’s internal knowledge; the semantics of imports andalignments.

The local semantics is provided by the ontology language which is used to describethe axiomatic content of a module. All kinds of logical formalisms could be, in principle,modularized and therefore used as a local semantics. However, we want to concentrateon Web ontologies that are written in OWL, so we focus on description logics.

Similarly to the local semantics, imports and alignments can be given several possiblesemantics. In the most general case, the interpretation of a module is recursively definedin function of the interpretations of its imported modules. This recursive definitionassumes that there is no cycle in the import chain, so each chain eventually leads to abase module with no import. Euzenat et al. (2007) provides the logical grounding of thesemantic notions, but it can be rephrased here as follows.

In order for an interpretation to satisfy a module, there are three conditions:

• The local interpretation must be a model of the content of the module, i.e., all localaxioms must be satisfied;

• The imported modules must be satisfied by their respective interpretations;

• The models of the imported modules and the importing modules must be compatibleaccording to the alignment and import semantics.

In the next sections, we describe the ModOnto suite, starting by its features andfunctionalities.

4.2 Features and Functionalities

ModOnto suite offers an intuitive graphical interface to build modules with severaloptions, not only to facilitate the choice of ontology/module elements but also to expressthe basic A L C DL ( Attribute Language with Complements ) constructs, for example:

60

4.3. ARCHITECTURE

• To build a new class, there is a functionality that help users to select set of classes,and like in Protege, the user can declare disjunctions among several classes. Theseoperations are carried out by a single mouse click.

• To create expressive property restrictions in necessary and necessary and sufficientconditions:

Quantifier Restrictions, which may be

– An existential restriction(∃), which specifies the existence of a (i.e. leastone) relationship along a given property to an individual that is memberof a specified class,

– Or an value restriction(∀) which states that if a relationship exists for theproperty then it must be to add individuals that are members of a specificclass.

Cardinality restrictions: describe the classes of individuals that have at least(MinimumCardinality), at most(Maximum Cardinality) or exactly a specified number ofrelationships with other individuals or datatype values.

HasValue Restrictions: denoted by the symbol ε , describes the set of individu-als that have at least one relations along a specified property to a specificindividual.

• To import entities from one or more ontologies ( or modules ).

• To build alignments between imported ontology or modules.

• To check the module syntactically and semantically. Semantic checks are carriedout using the IDDL reasoner( Zimmermann and Duc (2008a)).

• The user can build his own modules library.

In the next section will be explained the architecture of the ModOnto.

4.3 Architecture

This section shows the suite organization from a functional point of view and its mainelements. The interface among these elements is also specified. Figure 4.2 illustrates thearchitecture of the system.

61

4.3. ARCHITECTURE

The system is composed of six modules. The main module is the API which providesthe basic data structures.

Every module of the system has a Facade class that is a gate of communication withother parts of the system, it provides the main functions for other modules. The ModuleAPI provides the primitives to load an OWL ontology, and to extract its entities as well asto create the internal ontology ( represented by the contains tag ) part of the module.

Figure 4.2 ModOnto Architecture

4.3.1 Module API

Based on the implementation of the module specifications as described in the syntax, itprovides the basic data structure and renderers as well as a parsers on top of the structure.

62

4.3. ARCHITECTURE

The figure 4.3 illustrates the architecture of the Module API.

Figure 4.3 Module API Architecture

Model: contains the classes which represent the basic entities like the module andimports.

Factory: it is responsible for building the objects of the model, like the module and itsbasic entities(exports, contains,etc).

Renderer: is responsible for generating the module in RDF format, transform the modulein the object Java format to RDF format. For this, it was used the Visitor pattern.

Parser: the parser reads the module in RDF format and generates the correspondent toobject Java for posterior manipulation into the system. To build the parser it hasbeen used the Sax API3.

The Facade is the class that provides the services of the module, and the wholeimplementation of these services are hidden. It is based on Facade pattern.

We used the OWL API ( see section 4.4.1 ) to load, extract and manipulate theontologies and its entities like objet properties.

3http://www.saxproject.org/

63

4.3. ARCHITECTURE

4.3.2 Module Extractor

This module provides a graphical interface to extract elements from the imported ontol-ogy. Users are able to make a “select” over an ontology in a number of ways, such asselecting/ruling out entities (classes, roles, individuals). It is also possible to import itemsfrom more than one ontology. The extractor only manipulates ontologies; to manipulatemodules the Linker module, which is explained in the next section, must be used. TheExtractor interface can be viewed in figure 4.4.

Figure 4.4 Module Extractor

It is only possible to load ontologies in the OWL format. The user is able to

• load one or more ontologies;

• view the classes, properties and individuals of the ontology;

• click on any class and view its superclasses, subclasses and comments of theselected class;

• select/rule out the entities;

64

4.3. ARCHITECTURE

• select all superproperties of a selected property.

A case study of the usage of the Extractor ( see section 4.5.2 ) will highlight theusefulness and friendliness of the suite.

4.3.3 Module Linker

Figure 4.5 Module Linker

Permits to build modules using other modules, i.e, extracts entities from other modulesand to incorporate in a new one. The user is able to select only the elements from the“exported interface” from the imported module due to the encapsulation and informationhiding principles from the OO paradigm. Only the entities defined in the exportedinterface can be seen by other modules, the rest of its content is “hidden”. Such interfaceis represented by the elements that can be reused by other modules. It interacts with themodule library to pick up imported modules to be included, and support the specificationof necessary alignments among modules. For this, it is used the Alignment API ( Euzenat(2004) ). The module linker is shown in figure 4.5.

65

4.3. ARCHITECTURE

Figure 4.6 Module B uses module A

For instance, the figure 4.6 illustrates the module B using module A, the only part ofmodule A visible to module B is the exports of the module A, therefore module B canonly imports the entities described in the exports.

The user can also specify alignment between the imported module and the new one.The module provides an interface in which the user can choose the alignment method anda threshold for the alignment.

4.3.4 Module Checker

In an environment where lots of modules are available and evolving, module definitionsare prone to errors. So a syntactical checker should verify if all of the definitions neededby one module are present on its imported modules or in their own imported modules,and recursively.

In figure 4.7, it is displayed the module tab. Note that there are three buttons available,to check syntactically and semantically the module being defined.

The syntactical checking consists of verifying whether an imported entity frommodule B by module A exists in module B and so on, recursively with its importedmodules.

The semantic checking will be showen in the next section.

4.3.5 Module Reasoner

Modules have an internal ontology( referred by the contains tag ). Therefore it is importantto provide semantic checking for the module. We have integrated the IDDL reasonerwhich was developed by Zimmermann and Duc (2008a) (see section 4.4.3 ).

ModOnto provides to the user the options to check the module by using the classical

66

4.3. ARCHITECTURE

Figure 4.7 Module Tab

DL reasoning or a distributed DL reasoning(IDDL) according to IDDL semantics asdescribed in section 4.4.3.

Reasoning on ontologies can be seen in section 2.4.1.The main tab of the suite where it is displayed the characteristics of the module,

contains two buttons for the semantic checking (see figure 4.7).

4.3.6 Module Library

Built up on the Module API, the Module library( see figure 4.8 ) is a repository for“off-the-shelf” modules that will help developers to choose its proper modules as buildingblocks of their new modules. A module description in this library should include itsimported entities, content and exported entities.

The user can build her library and can reuse one of the modules stored in the library.The user has two options: load the selected module in the tab Module to be edited or loadit in the Linker to be reused in the current module.

67

4.4. USED TECHNOLOGIES

Figure 4.8 Module Library

4.4 Used Technologies

The tool was developed in Java4 and use APIs like OWL API from Manchester5 andAlignment API(Euzenat (2004)) described in the next sections.

4.4.1 OWL API

The OWL API6 is a Java interface and implementation for the Web Ontology LanguageOWL developed in University of Manchester.

The main goal is to provide data structures representing OWL ontologies and classesto create, manipulate, parse, render and reason about the structures.

The OWL API views an OWL ontology as a set of axioms. In the API, an OWLOn-tology interface provides access to the axioms in an ontology. Not only does this includelogical axioms, which encompass traditional OWL DL axioms and also rule axioms,

4http://java.sun.com/index.jsp5http://owlapi.sourceforge.net/6http://owlapi.sourceforge.net/

68


but it also includes annotations which are themselves represented as axioms. The APIprovides methods for the filtering and grouping of axioms in an ontology in an attempt tosupport as many different types of applications as possible.

The OWL API has a set of components including the follows:

• An API for OWL 2 and an efficient in-memory reference implementation

• RDF/XML parser and writer

• OWL/XML parser and writer

• OWL Functional Syntax parser and writer

• Turtle7 parser and writer

• KRSS8 parser

• OBO9 Flat file format parser

• Support for integration with reasoners such as Pellet10 and FaCT++11

• Support for black-box debugging

The OWL API is an implementation of OWL Language. For this, the API presentsthe following modules (see figure 4.9):

• Modelling: provides data structures that represent OWL ontologies/documents.

• Parsing: takes some syntactical presentation, e.g. OWL-RDF, and converting it tosome internal data structure.

• Serializing: produces a syntactical presentation, e.g. OWL-XML from a local datastructure.

• Manipulation/Change: it is able to manipulate the underlying objects.

• Inference: provides a representation that implements/understands the formal se-mantics of the language.

7http://www.w3.org/TeamSubmission/turtle/8http://krss.sourceforge.net/9http://www.obofoundry.org/

10http://clarkparsia.com/pellet/11http://owl.man.ac.uk/factplusplus/

69


Figure 4.9 Implementation aspects of thw OWL API

The main Java interfaces are:

• OWLOntology: represents an ontology. It consists of a collection of OWLAxioms.

• OWLEntity: it is the fundamental building block of the ontology, the classes,properties, individuals and datatypes.

• OWLClass: represents an OWL Class. Axioms relating to the class are held by anOWLOntology object. Axioms do not relate only to a class, but to a class withinthe context of an ontology.

• OWLProperty: represents the OWL Object properties and OWL Data Properties.Properties can have associated domains and ranges and there is also a propertyhierarchy.

• OWLDescription: represents an OWL class expression, atomic classes, booleanexpressions ( intersection, Union and Complement) and restrictions ( explicitquantification and cardinality restrictions ).

• OWLAxioms: An ontology contains a collection of OWLAxioms, each axiomrepresents some fact that is explicitly asserted in the ontology. Example: AnnotationAxioms, Declaration Axioms, Import Axioms and Logical Axioms.

The ModOnto takes advantage of the OWL API to manipulate the imported ontologyand the internal ontology( the contains ) of the module.

70


4.4.2 Alignment API

The alignment API(Euzenat (2004)), previously discussed in the Ontology chapter ( seesection 2.6.2 ), provides a way to manage alignments between ontologies.

In the ModOnto, given the two ontologies, an alignment method and a threshold thatis imputed by the user, the alignment is generated in the RDF format.

It is possible to define an alignment between modules, in this case, the alignment isdefined between the internal ontology( the contains ) of the modules.

4.4.3 IDDL Reasoner

Developed by the EXMO12 team in INRIA-Rhône Alpes13, the Java API for the IDDLreasoner implements the algorithm presented in the ( Zimmermann and Duc (2008a) ) fordistributed reasoning which requires some specific primitives to deal with alignments,global and local consistencies, alignment entailments, etc. The IDDL reasoner takesadvantage of the Alignment API and is compatible with the very common OWL-basedreasoners like Pellet and FaCT++.

IDDL is a formalism which inherits from the field of Description Logics and fromthe analysis of the distinct forms of distributed semantics in Zimmermann and Euzenat(2006).

The current version of the IDDL reasoner offers two main services: check consistencyand entailment.

Differently from classical reasoners like Pellet or FaCT++, the IDDLReasoner has tomanage a set of ontologies and alignments between these ontologies altogether.

The reasoner is able to perform two types of reasoning:

Classical Reasoning

With respect to classical reasoning, the IDDL reasoner puts everything (local ontologies,alignments between them) in a unique OWL ontology and reason on it.

The IDDL API provides the method isConsistent() which returns “true” if the uniqueOWL ontology is consistent.

Distributed Reasoning

For distributed reasoning, the IDDL reasoner consists of one global reasoner that uses alsoPellet. The IDDL reasoner needs to know about the consistency of each extended local

12http://exmo.inrialpes.fr/13http://www.inrialpes.fr/

71

4.5. USAGE EXAMPLE

ontology with help of a local reasoner associated. A local reasoner can be any (Pellet,FaCT++, Drago, IDDL itself, etc.) based on OWL and located on different sites. Thecommunication between the global reasoner and local ones i.e. access to local primitivesfrom global level can use the same interface for reasoners.

The IDDL API provides the method isConsistent() which returns “true” if the systemis IDDL consistent.

The next section will present a concrete example of building modules in the ModOntosuite.

4.5 Usage Example

With the goal to show the functionalities and benefits provided by the ModOnto, we willpresent an usage example explained in the next section.

4.5.1 Context

Imagine an application where we want to create a menu for a restaurant. The menuexposes the typical dishes from different places, and for each place there is a hint of awine.

Moreover, the restaurant intends to add a new kind of Pizza, the NorthEaternBrazili-anPizza, and a new kind of wine, the BrazilianWine, both typical from Brazil.

For these purposes, it will take advantage from other ontologies. The well-knownontology of pizzas will provide the several types of Pizza for the Menu module.

Therefore, the module Menu is some sort of aggregation module (or ontology) thatgenerates new services by aggregating previously available information from other on-tologies (or modules).

Indeed, the module Menu will only import specific information from other ontologies.For instance, it imports the class Pizza “QuattroFormaggi” from Pizza Ontology but notthe class “AmericanHot” Pizza because we do not want this kind of Pizza.

For this example, we will use the ontologies: Pizza14, Country15 and Food16. TheFood ontology imports the wine ontology, importation realized by “project inclusion”,reuse technic provides by the Protégé17, which uses the owl:import statement from theOWL language previously discussed in the introduction. As seen, this is a techniquewhich the whole ontology is imported, arising reasoning problems, for instance.

14http://www.co-ode.org/ontologies/pizza/2007/02/12/15http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries16http://www.w3.org/TR/2003/CR-owl-guide-20030818/food17http://protege.stanford.edu/

72

4.5. USAGE EXAMPLE

In resuming, we want a module that provides kinds of pizza, food and wine. For this,some entities will be imported from other ontologies. Every food is associated to a kindof wine. In special, a new kind of Pizza, the NorthEasternBrazilianPizza, will be created.The NorthEasternBrazilianPizza will be offered with the new wine: the BrazilianWine.

The figure 4.10 showed the relations between the imported ontologies and the Menumodule.

Figure 4.10 Dependecies between the ontologies and the Menu module

Below it describes the menu module according to the syntaxes presented previously.

Human Readable Syntax

The human readable syntax offers the possibility to express the modules in a way un-derstood by humans. Below, it is presented the Menu module in a human-readableformat.

__________________________________________________________________ModuleMenuThe First definitions that our new module should contain are the module identification

(in this syntax, the tag Module).__________________________________________________________________UsesPizza, Country and Food.Next it is needed to specify from which ontologies or modules the newly created

module is importing definitions from. That is represented by the Uses tag, in our case weare importing from the Pizza, Food and Country ontologies.

__________________________________________________________________

73

4.5. USAGE EXAMPLE

ImportsPizza Ontology

Classes: MeatTopping,MeatyPizza, VegetarianPizza, Marguerita,QuattroFormaggi,FruttiDiMare, Siciliana and hasCountryOfOrigin

Properties: hasTopping and hasCountryOfOrigin

Pizza Food

Classes:Meal, SeaFood, SpicyRedMeat, PastaWithLightCreamSauce,SweetDessert, PastaWithSpicyRedSauce and Wine.

Properties:hasDrink, hasColor and hasFlavor

Pizza Country

Classes: Country.Individuals: Brazil, France, Italy, Spain and Mexico.The tag Imports: only enlists the selected pieces of knowledge from the imported

ontologies/modules that will compose our new module.__________________________________________________________________Contains

Food ≡ ∀hasCountryOfOrigin.CountryPizzaNorthEasternBrazilianPizza v FoodNorthEasternBrazilianPizza vMeatyPizza u ¬ VegetarianPizzaNorthEasternBrazilianPizza ≡MeatyPizza u ∀hasTopping.SaltedMeatTopping u has-

CountryOfOrigin(Brazil)SaltedMeatTopping vMeatToppingNorthEasternBrazilianPizza v ∀hasDrink.(BrazilianWine)BrazilianWine vWine u hasColor(Red) u hasFlavour(Strong))

Then, comes the Contains tag, responsible for expressing the core of the module. Inthis example, we stated the necessary conditions for the new definitions.

First, that every individual Food class has an origin country. The new pizza, Piz-zaNorthEasternBrazilianPizza is a type of Food and is not a vegetarianPizza. Thenecessary and sufficient conditions for it is that it must be a MeatyPizza, with onlySaltedMeatTopping as its topping and coming from Brazil.

Moreover, the NorthEasternBrazilianPizza has a drink that is the BrazilianWine whichis a wine and has a red color and a strong flavour.

__________________________________________________________________

74

4.5. USAGE EXAMPLE

ExportsNorthEasternBrazilianPizza, BrazilianWine, MeatyPizza, VegetarianPizza,

Marguerita,QuattroFormaggi, FruttiDiMare, Siciliana, Meal, SeaFood,SpicyRedMeat, PastaWithLightCreamSauce, SweetDessert,PastaWithSpicyRedSauce and Wine.Finally, the Exports tag enlists the entities from the content or from the list of the

imported entities that will be available when one reuses the new module, i.e., the classes,properties, axioms and individuals ready for reuse.

4.5.2 Creating the module in the ModOnto

The first steps is to load the ontologies(Pizza, Food and Country) and to select the desiredentities of them.

The Extract module provides options to:

• select/deselect an entity;

• view for instance, the superclasses of a selected class and select one of the super-classes or all superclasses;

• select entities from one or more ontologies.

The interface contains panels to import classes, object properties, data properties andindividuals. The importing of Pizza Ontology can be view in the figure 4.11.

The steps of extraction are:

• Loading the imported Ontologies ( in this case, the Pizza, Country and Wineontology );

• Selecting the desired entities from the imported ontologies

After selecting the entities, the user can build new definitions like classes, propertiesand axioms.

First, we will create the new kind of wine, the BrazilianWine that is a subclass of theclass Wine and with red color and string flavor. To this end, we added two restrictionsthat represents the characteristics red and strong.

Next, we must create the special topping for the NorthEasternBrazilianPizza, theSaltedMeatTopping that is subclass of the MeatTopping.

Finally, we create a new kind of Pizza, the NorthEasternBrazilianPizza, which usesentities and relations from the Pizza ontology.

75

4.5. USAGE EXAMPLE

Figure 4.11 Importing entities from Pizza Ontology

The NorthEasternBrazilianPizza is subclass of the MeatyPizza ( Pizza ontology ) andis disjoint of the VegetarianPizza ( Pizza ontology ), and also has a SaltedMeatToppingthat is a new class created in this module.

Moreover, three restrictions will be created:

• a hasValue restriction to say that the NorthEaternBrazilianPizza is from Brazil.

• a universal restriction to say that all NorthEaternBrazilianPizza has topping Salted-MeatTopping.

• a universal restriction to express that the NorthEasternBrazilianPizza has drinkcalled BrazilianWine.

The figure 4.12 illustrates the creation of the NorthEasternBrazilianPizza class. Thenew definitions are saved in the contains (the internal ontology).

After creating the new definitions, we can define the entities that will be reused byother modules, the Exports tag. In this case, we will export the NorthEasternBrazili-anPizza, BrazilianWine, MeatyPizza, VegetarianPizza, Marguerita, QuattroFormaggi,

76

4.5. USAGE EXAMPLE

Figure 4.12 Creating the NorthEasternBrazilianPizza class

FruttiDiMare, Siciliana, Meal, SeaFood, SpicyRedMeat, PastaWithLightCreamSauce,Wine, SweetDessert and PastaWithSpicyRedSauce.

Finally, the module must be save in RDF format and the module description isdisplayed in the main tab (see figure 4.13).

4.5.3 RDF Format

In order to assure compatibility with the Semantic Web standards, this work provides anRDF/XML syntax that represents the human-readable syntax presented previously. Inthe figure 4.5.1 is displayed a part of the description module which the initial definitionof the Menu module with its uses tag which are the Pizza, Country and Food ontologyand part of the imports from these ontologies. Note that RDF was enough expressive to

77

4.5. USAGE EXAMPLE

Figure 4.13 Module Menu

describe what we aim; i.e, wrapping the external ontology/module parts.The whole description can be viewed in the appendix 5.3.After, the figure 4.5.2 exhibits the NorthEasternBrazilianPizza class described in OWL.

These definitions like the others definitions are in the internal ontology ( referenced bythe contains tag) saved in the same directory of the module.

Besides, ModOnto provides alignment between imported ontologies/modules, modu-les library and syntactically and semantically checker the module.

4.5.4 Alignment process

The user is able to define an alignment between the imported ontology or module and thenew one. For this, he chooses the alignment method ( is displayed for the user a methods

78

4.5. USAGE EXAMPLE

<rdf:RDF xmlns="http://www.inrialpes.fr/exmo/modules#"xml:base="http://www.inrialpes.fr/exmo/modules/menu.rdf"xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns:owl2xml="http://www.w3.org/2006/12/owl2-xml#"xmlns:mod="http://www.inrialpes.fr/exmo/modules#"xmlns:owl="http://www.w3.org/2002/07/owl#"xmlns:xsd="http://www.w3.org/2001/XMLSchema#"xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:owl2="http://www.w3.org/2006/12/owl2#"><Module>

<description rdf:about=""/><uses>

<owl2xml:Ontology rdf:about="http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries"><location href="file:/C:/Users/camila/Desktop/TestOnto/Countries.owl"/>

</owl2xml:Ontology><owl2xml:Ontology rdf:about=

"http://www.w3.org/TR/2003/CR-owl-guide-20030818/food"><location href="file:/C:/Users/camila/Desktop/TestOnto/food.owl"/>

</owl2xml:Ontology><owl2xml:Ontology rdf:about=

"http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl"><location href="file:/C:/Users/camila/Desktop/TestOnto/pizza.owl"/>

</owl2xml:Ontology></uses><imports>

<ImportInterface><hasElement>

<owl2xml:OWLClassrdf:about="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza#VegetarianPizza"/>

</hasElement><hasElement>

<owl2xml:OWLClass rdf:about="http://www.w3.org/TR/2003/CR-owl-guide-20030818/food#Seafood"/>


<owl2xml:Individualrdf:about="http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries#Mexico"/>

</hasElement>...

</ImportInterface></imports>

Código 4.5.1: Menu Module in RDF Syntax

list) and the threshold available in the view.We will define an alignment between the Menu module and the Pizza ontology, that

permits to know the grade of relation between the entities from Pizza Ontology and theMenu module if exists one. We will use the “SubsDistNameAlignment” method and athreshold of 0.2.

The figure 4.5.3 illustrates the alignment in RDF format which exhibits the relationbetween the Siciliana class from Pizza Ontology and the NorthEasternBrazilianPizzaclass equivalent to 0.2857 which means a weak similarity between the two classes. This

79

4.5. USAGE EXAMPLE

<owl:Class rdf:about="#SaltedMeatTopping"><rdfs:subClassOf rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#MeatTopping"/><rdfs:subClassOf rdf:resource="&owl;Thing"/>

</owl:Class>

<owl:ObjectPropertyrdf:about="http://www.w3.org/TR/2003/CR-owl-guide-20030818/food#hasDrink">

<rdfs:domain rdf:resource="#NorthEasternBrazilianPizza"/></owl:ObjectProperty>

<owl:Class rdf:about="#NorthEasternBrazilianPizza"><rdfs:subClassOfrdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#MeatyPizza"/><rdfs:subClassOf rdf:resource="&owl;Thing"/><rdfs:subClassOf>

<owl:Restriction><owl:onProperty rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#hasTopping"/><owl:allValuesFrom rdf:resource="#SaltedMeatTopping"/>

</owl:Restriction></rdfs:subClassOf><rdfs:subClassOf>

<owl:Restriction><owl:onProperty rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#hasCountryOfOrigin"/><owl:hasValue rdf:resource="http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries#Brazil"/>


<owl:Restriction><owl:onProperty rdf:resource="http://www.w3.org/TR/2003/CR-owl-guide-20030818/food#hasDrink"/>

<owl:allValuesFrom rdf:resource="#BrazilianWine"/></owl:Restriction>

</rdfs:subClassOf><owl:disjointWith rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#VegetarianPizza"/>

</owl:Class>

Código 4.5.2: NorthEasternBrazilianPizza class

value belongs to a range between 0 and 1.

4.5.5 Syntactic and Semantic Checker

The functionality of syntactic and semantic checker is available in the main panel whichcontains the information of the current module.

The syntactic checker consist in verifing if the linkages between the modules importedand the new one are valid. For example, if the module A imports the BrazilianWine classfrom the module Menu, and after we change the name of the BrazilianWine, this linkagebecomes invalid, whereas the BrazilianWine do not exists any more.

Moreover, the suite offers the option of checker the semantic using the DL formalism

80

4.5. USAGE EXAMPLE

<rdf:RDFxmlns=’http://knowledgeweb.semanticweb.org/heterogeneity/alignment#’

xmlns:rdf=’http://www.w3.org/1999/02/22-rdf-syntax-ns#’xmlns:xsd=’http://www.w3.org/2001/XMLSchema#’xmlns:align=’http://knowledgeweb.semanticweb.org/heterogeneity/alignment#’>

<Alignment><xml>yes</xml><level>0</level><type>**</type><method>fr.inrialpes.exmo.align.impl.method.SubsDistNameAlignment</method><onto1>

<Ontology rdf:about="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl"><location>http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl</location><formalism>

<Formalism align:name="OWL1.1" align:uri="http://www.w3.org/2006/12/owl11-xml#"/></formalism>

</Ontology></onto1><onto2>

<Ontology rdf:about="http://www.co-ode.org/ontologies/contentmenu.owl"><location>file:/C:/Users/camila/Desktop/TestOnto/contentmenu.owl</location><formalism>

<Formalism align:name="OWL1.1" align:uri="http://www.w3.org/2006/12/owl11-xml#"/></formalism>

</Ontology></onto2><map>

<Cell><entity1 rdf:resource=’http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#Siciliana’/><entity2 rdf:resource=’http://www.co-ode.org/ontologies/contentmenu2.owl#NorthEasternBrazilianPizza’/><relation>=</relation><measure rdf:datatype=’http://www.w3.org/2001/XMLSchema#float’>0.2857142857142857</measure>

</Cell></map>

</Alignment>

Código 4.5.3: Alignment in RDF format between the Pizza ontology and the MenuModule

or the IDDL formalism described in section 3.5.2.

81

5Conclusions and Future Work

With the growth of the Web the necessity of knowledge organization and efficient rea-soning of the information available on it has emerged. What lead to the creation of theSemantic Web. However, the success of the Semantic Web depends on a number ofprinciples, one of which is the reuse of ontologies.

Indeed, the lack of modularity of ontologies raise problems related with scalability,management, understandability and reasoning of ontologies.

The topic of ontology modularization comes up with the proposal to develop on-tologies as modules that are reused by others modules, which stems from a similar ideaexistent in the components culture of Software Engineering.

Due to these facts, in the last years the area of Ontology Modularization received alot of interest. Several approaches have been proposed to solve the problem to divideontologies in reusable parts. However, neither of them provides to the user a flexibletool that permits not only ontology module definitions but also other support tasks, likesyntactical and semantic checking of the modules

This dissertation presented a suite of tools for modularization of ontologies whichprovides several tasks to support ontology development process by means of reuse.Moreover, the suite provides a reasoner, syntactical checker, modules library and modulesalignment.

5.1 Contributions

Generally speaking, the main contribution of the dissertation is the suite for modulariza-tion of ontologies with features which are not present in other available tools, to the bestof our knowledge.

Chapter 4 has shown all the functionalities and benefits that are provided by theModOnto, which certainly puts it in the forefront of ontology modularization tools interms of usability.

We have also shown that the software modules that compose the ModOnto suiteimplement the specified requirements, as can be seen by the contributions below:

1. Semantic checking of the module being created. This checking is accomplishedin a very flexible manner; users can choose from two semantics, the usual DLsemantics or the Integrated DL semantics based on IDDL(Zimmermann (2007)).

82

5.1. CONTRIBUTIONS

As could be seen in section 4.3.5, the tool was integrated to the IDDL reasoned

produced at INRIA-Rhône Alpes, and tested with the two different semantics present

on the reasoner. This feature can satisfy the user that intends to use her modules

against each of these semantics.

2. Syntactical checking, that assures that the module does not contain any syntacticalerrors.

As seen in the section 4.3.4, that tool assures that the “linkages” among the modules

are verified to order to know whether the connections are valid. The user can know

if there are changes in the imported modules. Therefore, she knows if the module

reflects her purposes.

3. Support to the use of alignments among the imported modules ( or ontologies ) andthe new one.

As could be seen in section 4.3.3, the tool was integrated to the Alignment API

produced at INRIA-Rhône Alpes. This feature provides to the user the possibility to

define alignments between among the imported modules ( or ontologies ) and the

new one, in order to verify the grade of similarity among the entities.

4. Compliance with an on-the-making standard module format, the NeOn moduleformat.

The language has been built in a compatible way with the language adopted by the

NeOn, providing interoperability among other modularization tools( in this case

the NeOn).

The NeOn project has produced and implemented in its toolkit a module standardwhich is compatible and possible to integrate with the OntoCompo approach. Indeed, inthe context of this dissertation we had to chage OntoCompo original module format inorder to be compatible with the NeOn format, not only because it tends to a standard butalso due to the fact that INRIA, Monbonnot is an official member of NeOn and has takenpart of the NeOn module standard.

Moreover, we are considering the suite quite complete in the sense that its componentsperform a set of functions which are beyond the basic tasks, offered by other tools, enlistedin section 4.4. As seen, the ModOnto is composed of the following modules:

83

5.2. FUTURE WORK

Module API: is the basic layer of the suite. Provide the basic data structure and accessorsas well as a parser and renderer.

Module extractor: provides a graphical interface to extract elements from the importedontology. A user of this tool should be able to make a ’select’ over an ontology in anumber ways, such as selecting/ruling out entities (classes, roles, individuals). oneof the advantages of this tool, is the capability of importing items from more thanone ontology.

Module checker: is answerable to checker if all of the definitions needed by one moduleare present on its imported modules or in their own imported modules.

Module library: is a repository for "off-the-shelf" modules that will help developers tochoose its proper modules.

Module linker: provides support to import entities from other other modules.

Reasoner interface for modules: provides a semantic checker using the the DL formal-ism or IDDL formalism.

These modules provides several tasks to provide good support for the ontologydeveloper to build modules.

5.2 Future Work

In order to foster the approach and language popularity,we have planned a set of tasks toimproving the current version, which is listed above:

• Improving usability of the tool by means of a better graphical interface.

• Currently, it is not possible to create axioms involving just the imported entities,say, the imported entity A is subclass of the imported entity B. We want to becomethis possible.

• Providing a graphical representation of the modules that deploy the relations amongmodules.

• Providing query support to the modules, like existing in the Protege by means ofSPARQL 1.

1http://www.w3.org/TR/rdf-sparql-query/

84

5.3. PUBLICATIONS

Moreover, the suite must be integrated with popular ontology frameworks like Pro-tégé2, KAON23 and the ones from NeOn ToolKit4 too.

5.3 Publications

• Camila Bezerra, Frederico Luiz Gonçalves de Freitas, Antoine Zimmermann andJérôme Euzenat. ModOnto: A Tool for Modularizing Ontologies. In 3rd Workshopon Ontologies and their Applications (WONTO), 2008.

• Camila Bezerra, Frederico Luiz Gonçalves de Freitas, Jérôme Euzenat and AntoineZimmermann. An approach for Ontology Modularization. In COLIBRI: Colóquioem Informática: Brasil / INRIA, Cooperações, Avanços e Desafios, 2009.

2http://protege.stanford.edu/3http://kaon2.semanticweb.org/4http://www.neon-toolkit.org/

85

Bibliography

Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D., and Patel-Schneider, P. F.,editors (2003). The Description Logic Handbook: Theory, Implementation, and

Applications. Cambridge University Press.

Bao, J. (2007). Representing and Reasoning with Modular Ontologies. Ph.d. dissertation,Department of Computer Science, Iowa State University.

Bao, J., Caragea, D., and Honavar, V. (2006). Towards collaborative environments forontology construction and sharing. In CTS ’06: Proceedings of the International

Symposium on Collaborative Technologies and Systems, pages 99–108, Washington,DC, USA. IEEE Computer Society.

Bernardo Cuenca Grau, Bijan Parsia, E. S. A. K. (2005). Modularizing owl ontologies.In Proceedings of the 4th International Semantic Web Conference (Poster Track).

Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The Semantic Web. Scientific

American, 284, 34–43.

Bezerra, C., de Freitas, F. L. G., Zimmermann, A., and Euzenat, J. (2008). Modonto: Atool for modularizing ontologies. In 3rd Workshop on Ontologies and their Applications

(WONTO).

Borgida, A. and Serafini, L. (2002). Distributed description logics: Directed domaincorrespondences in federated information sources. In On the Move to Meaningful

Internet Systems, 2002 - DOA/CoopIS/ODBASE 2002 Confederated International

Conferences DOA, CoopIS and ODBASE 2002, pages 36–53, London, UK. Springer-Verlag.

Borst, W. N. (1997). Construction of Engineering Ontologies for Knowledge Sharing

and Reuse. Ph.D. thesis, University of Tweenty.

Bouquet, P., Giunchiglia, F., van Harmelen, F., Serafini, L., and Stuckenschmidt, H.(2003). C-owl: Contextualizing ontologies. In International Semantic Web Conference,pages 164–179.

Cuenca, Parsia, B., and Sirin, E. (2006). Combining owl ontologies using e-connections.Web Semantics: Science, Services and Agents on the World Wide Web, 4, 40–59.

Cuenca Grau, B., Parsia, B., Sirin, E., and Kalyanpur, A. (2005). Automatic partition-ing of OWL ontologies using E -connections. In DL 2005, Proceedings of the 18th

International Workshop on Description Logics, Edinburgh, UK, 2005.

86

BIBLIOGRAPHY

d’Aquin, M., Schlicht, A., Stuckenschmidt, H., and Sabou, M. (2007). Ontology mod-ularization for knowledge selection: Experiments and evaluations. In DEXA, pages874–883.

d’Aquin, M., Haase, P., Duc, C. L., and Zimmermann, A. (2008). Deliberable 1.1.4 :Neon formalism for modularization: Implementation and evaluation. Technical report,Neon Project.

Doran, P. (2006). Ontology reuse via ontology modularisation. In KnowledgeWeb PhD

Symposium (KWEPSY2006).

Doran, P., Tamma, V., and Iannone, L. (2007). Ontology module extraction for ontologyreuse: an ontology engineering perspective. In CIKM ’07: Proceedings of the sixteenth

ACM conference on Conference on information and knowledge management, pages61–70, New York, NY, USA. ACM.

Euzenat, J. (2004). An api for ontology alignment. In Proc. 3rd conference on interna-

tional semantic web conference (ISWC), Hiroshima (JP), pages 698–712.

Euzenat, J., Zimmermann, A., and de Freitas, F. L. G. (2007). Alignment-based modulesfor encapsulating ontologies. In 2nd International Workshop on Modular Ontologies

(WoMO), Whistler, British Columbia, Canada.

Farquhar, A., Fikes, R., and Rice, J. (1996). The ontolingua server: a tool for collaborativeontology construction. In International Journal of Human-Computer Studies.

Fensel, D., Horrocks, I., Harmelen, F. v., Decker, S., Erdmann, M., and Klein, M. C. A.(2000). Oil in a nutshell. In EKAW ’00: Proceedings of the 12th European Workshop

on Knowledge Acquisition, Modeling and Management, pages 1–16, London, UK.Springer-Verlag.

Gomez-Perez, A., Angele, J., Fernandez-Lopez, M., Christophides, V., Stutt, A., and Sure,Y. (2002). Deliverable 1.3: A survey on ontology tools. Technical report, UniversidadPolitecnia de Madrid.

Gomez-Perez, A., Corcho, O., and Fernandez-Lopez, M. (2004). Ontological Engineer-

ing : with examples from the areas of Knowledge Management, e-Commerce and

the Semantic Web. First Edition (Advanced Information and Knowledge Processing).Springer.

87

BIBLIOGRAPHY

Grau, C. B., Parsia, B., Sirin, E., and Kalyanpur, A. (2006). Modularity and webontologies. In Proceedings of the 10th International Conference on Principles of

Knowledge Representation and Reasoning (KR2006).

Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications.Knowledge Acquisition, 5, 199–221.

Gruber, T. R. (1995). Toward principles for the design of ontologies used for knowledgesharing. Int. J. Hum.-Comput. Stud., 43(5-6), 907–928.

Haase, P., Lewen, H., Studer, R., Tran, D. T., Erdmann, M., d’Aquin, M., and Motta, E.(2008). The neon ontology engineering toolkit. In WWW 2008 Developers Track.

Hayes, P. and Menzel, C. (2001). A semantics for the knowledge interchange format. InIn IJCAI 2001 Workshop on the IEEE Standard Upper Ontology.

Heflin, J., Hendler, J., and Luke, S. (1999). SHOE: A knowledge representation languagefor internet applications. Technical Report CS-TR-4078.

Horrocks, I., Fensel, D., Broekstra, J., Decker, S., Erdmann, M., Goble, C., van Harlemen,F., Klein, M., Staab, S., Studer, R., Motta, E., and Horrocks, I. (2000). The ontologyinference layer oil.

Jarrar, M. (2005). Towards Methodological Principles for Ontology Engineering. Ph.D.thesis, Vrije Universiteit Brussel, Brussels, Belgium.

Kifer, M., Lausen, G., and Wu, J. (1990). Logical foundations of object-oriented andframe-based languages. Technical report.

MacGregor, R. M. (1991). Inside the loom description classifier. SIGART Bull., 2(3),88–92.

McGuinness, D. L. and van Harmelen, F. (2004). Owl. http://www.w3.org/TR/owl-guide/m.

McGuinness, D. L., Fikes, R., Rice, J., and Wilder, S. (2000). The chimaera ontologyenvironment. In Proceedings of the Seventeenth National Conference on Artificial In-

telligence and Twelfth Conference on Innovative Applications of Artificial Intelligence,pages 1123–1124. AAAI Press / The MIT Press.

88

BIBLIOGRAPHY

Neches, R., Fikes, R., Finin, T., Gruber, T., Patil, R., Senator, T., and Swartout, W. R.(1991). Enabling technology for knowledge sharing. AI Mag., 12(3), 36–56.

Noy, N. F. and Musen, M. A. (2004). Specifying ontology views by traversal. InInternational Semantic Web Conference, pages 713–725.

Parnas, D. L. (2002). On the criteria to be used in decomposing systems into modules.pages 411–427.

Perés and Corcho (2002). Ontology Languages for the Semantic Web. IEEE Intelligents

Systems, 13, 54–60.

R, D. (2001). Método de mezcla de catálogos electrónicos. Technical report, Facultad deInformática de la Universidad Politécnica de Madrid.

Ramos, J. (2004). Mezcla automática de ontologías y catálogos electrónicos. Technicalreport, Facultad de Informática de la Universidad Politécnica de Madrid.

Seidenberg, J. and Rector, A. (2006). Web ontology segmentation: analysis, classificationand use. In WWW ’06: Proceedings of the 15th international conference on World

Wide Web, pages 13–22, New York, NY, USA. ACM.

Stuckenschmidt, H. and Klein, M. (2004). Structure-based partitioning of large concepthierarchies. In In: International Semantic Web Conference, pages 289–303.

Stuckenschmidt2003 (2003). Integrity and change in modular ontologies. In The Interna-

tional Joint Conference on Artificial Intelligence(IJCAI), pages 900–908.

Sure, Y., Erdmann, M., Angele, J., Staab, S., Studer, R., and Wenke, D. (2002). OntoEdit:Collaborative ontology development for the semantic web. In Proceedings of the first

International Semantic Web Conference 2002 (ISWC 2002), June 9-12 2002, Sardinia,

Italia. Springer, LNCS 2342.

Zimmermann, A. (2007). Integrated distributed description logics. In Description Logics.

Zimmermann, A. and Duc, C. L. (2008a). Reasoning on a Network of Aligned Ontologies.In D. Calvanese and G. Lausen, editors, Web Reasoning and Rule Systems, Second

International Conference, RR 2008, Karlsruhe, Germany, volume 5341 of Lecture

Notes in Computer Science, pages 43–57. Springer.

89

BIBLIOGRAPHY

Zimmermann, A. and Duc, C. L. (2008b). Reasoning with a network of aligned ontologies.Technical report, INRIA.

Zimmermann, A. and Euzenat, J. (2006). Three Semantics for Distributed Systems andtheir Relations with Alignment Composition. In I. F. Cruz, S. Decker, D. Allemang,C. Preist, D. Schwabe, P. Mika, M. Uschold, and L. Aroyo, editors, 5th International

Semantic Web Conference( ISWC), Athens, GA, USA, volume 4273 of Lecture Notes in

Computer Science, pages 16–29. Springer.

90

Appendices

91

Diagrams of Classes

Below the main classes’ diagrams of the ModOnto are displayed.To build the renderer, we have used the Visitor pattern which provide a way of

separating an algorithm from an object structure upon which it operates.

Figure 1 Renderer Diagram

92

Figure 2 Parser Diagram

Figure 3 Syntatical Checker Diagram

93

Figure 4 Library Diagram

Figure 5 Reasoner Diagram

94

Code of the Usage Example

In this appendix is displayed the generated codes in the example of the section 4.5.

<rdf:RDF xmlns="http://www.inrialpes.fr/exmo/modules#"xml:base="http://www.inrialpes.fr/exmo/modules/menu.rdf"xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns:owl2xml="http://www.w3.org/2006/12/owl2-xml#"xmlns:mod="http://www.inrialpes.fr/exmo/modules#"xmlns:owl="http://www.w3.org/2002/07/owl#"xmlns:xsd="http://www.w3.org/2001/XMLSchema#"xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:owl2="http://www.w3.org/2006/12/owl2#"><Module>

<description rdf:about=""/><uses>

<owl2xml:Ontology rdf:about="http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries">

<location href="file:/C:/Users/camila/Desktop/TestOnto/Countries.owl"/></owl2xml:Ontology><owl2xml:Ontology rdf:about="http://www.w3.org/TR/2003/CR-owl-guide-20030818/food">

<location href="file:/C:/Users/camila/Desktop/TestOnto/food.owl"/></owl2xml:Ontology><owl2xml:Ontology rdf:about="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl">

<location href="file:/C:/Users/camila/Desktop/TestOnto/pizza.owl"/></owl2xml:Ontology>

</uses><imports>

<ImportInterface><hasElement>

<owl2xml:OWLClassrdf:about="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza#VegetarianPizza"/>


<owl2xml:OWLClass rdf:about="http://www.w3.org/TR/2003/CR-owl-guide-20030818/food#Seafood"/>


<owl2xml:Individualrdf:about="http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries#Mexico"/>

</hasElement>...

</ImportInterface></imports>

Código .0.1: Menu Module in RDF Syntax

95

<contains><owl2xml:Ontology rdf:about="http://www.co-ode.org/ontologies/contentmenu.owl"/>

</contains><exports>

<ExportedInterface><hasElement>

<owl2xml:OWLClass rdf:about="menu#NorthEasternBrazilianPizza"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#BrazilianWine"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#VegetarianPizza"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#Margherita"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#QuattroFormaggi"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#FruttiDiMare"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#Siciliana"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#SpicyRedMeat"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#PastaWithSpicyRedSauce"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#PastaWithLightCreamSauce"/></hasElement><hasElement>

<owl2xml:OWLClass rdf:about="menu#SweetDessert"/></hasElement>

</ExportedInterface></exports>

</Module></rdf:RDF>

Código .0.2: The contains and the exports of the Menu module in RDF Syntax

96

<owl:Class rdf:about="#SaltedMeatTopping"><rdfs:subClassOf rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#MeatTopping"/><rdfs:subClassOf rdf:resource="&owl;Thing"/>

</owl:Class>

<owl:ObjectPropertyrdf:about="http://www.w3.org/TR/2003/CR-owl-guide-20030818/food#hasDrink">

<rdfs:domain rdf:resource="#NorthEasternBrazilianPizza"/></owl:ObjectProperty>

<owl:Class rdf:about="#NorthEasternBrazilianPizza"><rdfs:subClassOfrdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#MeatyPizza"/><rdfs:subClassOf rdf:resource="&owl;Thing"/><rdfs:subClassOf>

<owl:Restriction><owl:onProperty rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#hasTopping"/><owl:allValuesFrom rdf:resource="#SaltedMeatTopping"/>


<owl:Restriction><owl:onProperty rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#hasCountryOfOrigin"/><owl:hasValue rdf:resource="http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries#Brazil"/>


<owl:Restriction><owl:onProperty rdf:resource="http://www.w3.org/TR/2003/CR-owl-guide-20030818/food#hasDrink"/>

<owl:allValuesFrom rdf:resource="#BrazilianWine"/></owl:Restriction>

</rdfs:subClassOf><owl:disjointWith rdf:resource="http://www.co-ode.org/ontologies/pizza/2005/10/18/pizza.owl#VegetarianPizza"/>

</owl:Class>

Código .0.3: NorthEasternBrazilianPizza class

97

Documents

Camila Bezerra da Silva - repositorio.ufpe.br · First of all, I thank God for your presence in my life, the support that gave me to ﬁnish this work despite the difﬁculties that