a knowledge encapsulation approach to ontology...

Knowl Inf Syst (2011) 26:249–283DOI 10.1007/s10115-009-0279-y

REGULAR PAPER

A knowledge encapsulation approach to ontologymodularization

Faezeh Ensan · Weichang Du

Received: 29 January 2009 / Revised: 22 October 2009 / Accepted: 8 November 2009 /Published online: 16 January 2010© Springer-Verlag London Limited 2009

Abstract The development of monolithic ontologies for complex domains may facevarious challenges in reasoning and implementation. The notion of modularity can beemployed for developing more efficient ontologies, especially in distributed environments.In this paper, we introduce a framework for developing ontologies in a modular manner.We describe the interface-based modular ontology formalism, (IBF), which theoreticallysupports the framework. The main feature of the framework is its support for knowledgeencapsulation, i.e., it allows ontologies to define their main content using well-defined inter-faces, such that their knowledge bases can only be accessed by other ontologies through theseinterfaces. An important implication of the proposed framework is that ontology modules canbe developed completely independent of each other’s signature and languages. Such modulesare free to only utilize the required knowledge segments of the others. We also investigate theissues of inconsistency in the proposed modular ontology framework. We provide solutionsfor isolating inconsistent ontology modules from the other parts of a modular ontology andalso resolve inconsistencies which may be arisen by integrating consistent knowledge bases.

Keywords Ontology · Semantic Web · Modularization · Modular ontology ·Description logics · Encapsulation

1 Introduction

In his seminal paper, Gruber [43] defines an ontology as ‘an explicit specification of aconceptualization’. Ontologies are used by applications, domain experts, and users in orderto reach consensus on various concepts of a domain of discourse for the purpose of collab-oration and communication [49,57,86]. Up until now, a considerable amount of effort hasbeen dedicated to the development of ontologies [20,67], ontological frameworks [27], andontological methodologies [29,31,54].

F. Ensan (B) · W. DuFaculty of Computer Science, University of New Brunswick, Fredericton, Canadae-mail: [email protected]

123

250 F. Ensan, W. Du

OWL-DL has been well established and widely used in the recent years as an expressivedescription logic-based language for representing ontologies. Various reasoning algorithms[46] and query languages [48] are introduced and optimized in order to facilitate the usageof OWL-DL ontologies in the real-world domains and applications. Nonetheless, severalchallenges still exist in efficiently creating large-scale OWL-DL ontologies, especially forcomplex domains. Developing a large monolithic ontology can lead to performance difficul-ties in reasoning, management challenges when some parts of the ontology changes basedon new domain requirements, and also issues in ontology integration when several parts ofan ontology have been developed by different groups of experts.

Recently, the development of ontologies in a modular manner has been proposed to addressthe above mentioned issues [81]. A modular ontology can be more conveniently developed ina distributed environment through the collaboration of different groups of experts as opposedto a monolithic approach. Reasoning in a modular ontology is also more efficient in lightof the fact that reasoning engines need to only process the knowledge bases of the relevantmodules. Through a well-defined formalism for ontology modules, a modular ontology canevolve more efficiently. A module, as a part of an ontology, can be upgraded, replaced orpossess different versions, while the other modules evolve independently.

The idea of modularization can also be seen in the software engineering field and mainlyin Object-Oriented design where complex software systems are modeled as the set of self-contained components [79]. The behavior of these components are defined through theirinterfaces which are separated from their later detailed implementation. Consequently, com-ponents can utilize each other’s functions without being consciously aware of each other’sdetailed implementation. Here, the implementations may change even after the inter-connec-tions between logical component have been specified.

Due to their perceived advantages, the dedicated works on modular ontologies [3,11,24,25,30,38–40,55,74] have been increasing in the recent years. In this paper, we propose aframework for developing modular ontologies. The focus of this framework is to fulfill themodularization requirements like the independency of ontologies in a modular ontology andloose coupling, separating the specification of ontological terms from their exact meaningsand properties, and polymorphism for the process of developing ontologies. These require-ments can be further highlighted using the following example:

Example 1 Motivating exampleConsider a case where an ontology engineer attempts to develop an ontology for the tourismdomain. She has found an ontology describing different places in Canada and another ontol-ogy which covers North America. She desires to utilize these existing ontologies rather thangathering and categorizing geographical information regarding these places in the Tourismontology from scratch. In addition, she wants to have a reliable way to understand and usethe main features of these ontologies without being required to go through their knowledgebases and figure out their taxonomies and axioms. The ontology engineer prefers the Tourismontology to be independent of the syntax of both Canada and North America ontologies, sothat the changes in internal and non-relevant parts of their knowledge bases do not affectthe Tourism ontology. Furthermore, the independency will allow her to replace the placeontology with a new one, e.g., the European places.

Moreover, suppose that she introduces the Sightseeing concept as a notion to repre-sent the places where tourists are interested to visit. Each sight needs to have a name and aspecific address, so that a tourist can easily locate it. However, it is possible to specialize thedefinition of a sight from different perspectives. For example, describing from a scientificperspective, a sight refers to a place that exhibits scientific value. This place may be related to

123

A knowledge encapsulation approach 251

one or more branches of science and can be visited by various scientists. On the other hand,from a natural perspective, a sight relates to a place with natural attractions, such as beaches,mountains, parks, and jungles. Visiting the places listed in this category is most suitable incertain seasons of the year and the visitors may need to take specialized equipments with themto be able to enjoy their visit. In the Tourism ontology, the ontology engineer desires to onlyknow the common sense of the sightseeing concept, while its different specializationscan be later bound to it based on different requirements.

The modular ontology framework which is discussed in this paper is based on the Inter-faces-Based modular ontology Formalism, (IBF). The main feature of the formalism is itssupport for knowledge encapsulation. By knowledge encapsulation, we mean providing sup-port for ontologies to define their main contents using well-defined interfaces, such that theirknowledge bases can only be accessed by other ontologies through these interfaces. Basedon IBF, a modular ontology is defined as a set of ontology modules, which can be developedindependent of each other’s language and signature. The interface-based formalism enjoysa great expressive power, which allows an ontology module to create its knowledge basefrom the other modules’ knowledge expressed through their interfaces. At the same time, itallows for partial reuse, i.e., it allows an ontology module use only the necessary parts of theknowledge base of the other modules. The features of the modular ontology framework canbe enumerated as follows:

– Since ontologies are connected indirectly through their interfaces, they can evolve inde-pendent of each other’s signature and knowledge bases. While the interfaces of an ontol-ogy do not change, its entire knowledge base can change without requiring other connectedmodules to change their signatures.

– An ontology module can express its knowledge content through different interfaces withdifferent levels of complexity and completeness. Hence, ontology modules can accessthose parts of a module they need without being required to go through the complicatedknowledge base.

– Using interfaces, the specification of the knowledge of an ontology module and the exactmeaning of these content can be separated. Consequently, an ontology module can providenew meaning for a concept which is used by other modules through its interfaces.

– Based on the interface-based formalism, an ontology module may use a concept or arole from an interface that has some general properties, while its meaning may be furtherspecialized based on the inter-connections among ontology modules (polymorphism).

One of the most important issues in modular ontologies is dealing with inconsistencies.Up until now different proposals have been given for handling inconsistency in knowledgebases [10]. They mostly attempt to either repair inconsistencies or tolerate them and findmeaningful answers to queries posed to inconsistent knowledge bases. Since each module ina modular ontology is itself a description logic knowledge base, the existing works can beexploited to manage inconsistencies in each module. However, the integration of modulesmay give rise to new inconsistency problems that should be taken into account. Analogousto peer-to-peer systems [16], we can recognize two sources which may yield an inconsistentmodular ontology. First, when an ontology module is not consistent and affects the consis-tency of the modular ontology. Second, when all ontology modules are consistent, but theirintegration leads to an inconsistent modular ontology. In this paper, we investigate the issuesof inconsistency in the modular ontology framework and provide solutions for tolerating andresolving inconsistencies.

123

252 F. Ensan, W. Du

The contributions of this paper are as follows:

1. We introduce the interface-based modular ontology formalism. We give formal defini-tions for the syntax and semantics of the modular ontologies based on the formalism.

2. We investigate the properties of the formalism. We provide proofs showing that theconsistency checking of a modular ontology is decidable even though the modules arepresented in different description logics. In addition, we show that the logical conse-quences of the public part of an ontology module propagate to all of the connectedontology modules, while its private parts do not have such consequence propagation.

3. We investigate both types of inconsistencies which are caused by either integrating con-sistent modules or propagating inconsistency from an inconsistent module to the others.Based on the idea of hole interpretation for inconsistent modules in [74], we propose anew semantic for the interface-based formalism to isolate the source of inconsistency inthe modular ontology. In addition, we present an algorithm for resolving inconsistenciesthat have arisen by integrating consistent modules in the proposed formalism.

4. We study the development of a Friend-of-a-Friend (FOAF) ontology through the pro-posed framework. Using this real-world sample of modular ontologies, we investigatethe properties of the interface-based formalism. We also discuss the potential challengeswe may face when exploiting the framework for creating real-world modular ontologies.These challenges illuminate our direction for future work.

The rest of this paper is organized as follows: Section 2 provides preliminaries regardingbasics of description logics and also epistemic queries. Section 3 introduces the syntax andsemantic of the proposed interface-based formalism. Section 4 presents the important fea-tures of the formalism. In Sect. 5, we study different types of inconsistencies in the formalismand the solutions for resolving them. Section 6 illustrates the application of the frameworkfor creating a real-world case. Section 7 discusses related works. Section 8 presents a com-prehensive discussion on the IBF framework and finally, Sect. 9 concludes the paper.

2 Background

OWL-DL provides expressiveness equivalent to the SHOIN (D) Description Logic (DL)[45]. A DL knowledge base is defined as � = 〈T , A〉, where T denotes TBox and comprisesof a set of general inclusion axioms and A stands for ABox and comprise of a set of instanceassertions. The signature of a DL knowledge base �, which is denoted as Sig(�), is definedas a set of all concept names (CN ), role names (RN ), and individuals (IN ) which are includedin its knowledge base. The semantic of a DL knowledge base is defined by an interpreta-tion I = (�I , ·I) where �I is a non-empty set of individuals and ·I is a function whichmaps each C ∈ CN to CI ⊆ �I , each R ∈ RN to RI ⊆ �I × �I , and each a ∈ IN toan aI ∈ �I . An interpretation I satisfies a TBox axiom C � D iff CI ⊆ DI , satisfies anABox assertion C(a) iff aI ∈ CI and an ABox assertion R(x, y) iff 〈xI , yI〉 ∈ RI . Aninterpretation I is a model of a knowledge base � if it satisfies every TBox axiom and ABoxassertion of �. A concept C is satisfiable if there is a model I for � such that CI �= ∅.A knowledge base is consistent iff it has a model that satisfies all concepts and roles. Aninclusion or assertional axiom α is implied by a knowledge base � and denoted as � | αiff there exists a model for � that satisfies α. We denote all implications of the knowledgebase � by Cn(�).

DL ontologies are based an open-world assumption, i.e., the knowledge base of an ontol-ogy is not considered to be complete and consequently if something cannot be proven, it

123


cannot be assumed to be false based on the knowledge base. Nevertheless, there have beensome proposals in the literature that attempt to augment the semantics of DLs with close-world reasoning capabilities. Epistemic operator K is introduced in [21,22] and allows querieswhose result can be captured by the closed-world assumption approach. K queries ask aboutthe facts that are known to be true to the extent of the information available in the currentknowledge of a given knowledge base. The authors in [17] investigate mechanisms for posingK epistemic queries to expressive DL knowledge bases. Sirin et al. [78] shows the capabilityof the Pellet reasoning engine for answering K queries for concepts and roles that are posedto simple knowledge bases.

To have a formal understanding of K queries, let C be a concept in a description logicknowledge base �, while KC reports a set of individuals which are known to belong to Cin every model of �. An epistemic interpretation for � is defined as I = (J , M), where Jis an interpretation of � with the domain �, and M as a set of interpretations for � over �.The epistemic interpretation for simple epistemic concepts and roles are defined as follows:

(KC)I =⋂

j∈M(C) j

(KR)I =⋂

j∈M(R) j

An epistemic model for a knowledge base � is a maximal non-empty set M such that for everyJ ∈ M, (J , M) satisfies all TBox inclusion axioms and ABox assertions of �. Consideran epistemic query KC(x) posed to a knowledge base �, � � KC(x) if for every epistemicmodel I = (J , M) for �, x ∈ KCI. An epistemic query KR(x, y) is also defined in thesame way as � � KR(x, y) if for every epistemic model I = (J , M) for �, (x, y) ∈ KRI.

3 Interface-based formalism

3.1 Formalization

In this section, we introduce the interface-based formalization of modular ontologies.Through the interface-based modular ontology formalism, a ‘modular ontology’ is definedas a set of ‘ontology modules’(modules) and ‘interfaces’. In this paper we use the termsmodule and ontology module to refer to the same meaning. An interface is a set of knowledgebase expressions, which are used in a module but their exact meaning are provided by otherontology modules. An ontology module may utilize or realize a set of interfaces.

Example 2 For the case of developing a modular ontology for the tourism domain, wecan define the modular ontology as a set of ontology modules: Tourism and CanadianDestination and the interface: InfLocation. The ontology module Tourism has informationabout different tourism destinations, tourist-related activities, and also accommodations. TheCanadian Destination ontology module includes and categorizes the names of Canadian cities,provinces, and areas. The ontology module Tourism needs to utilize the geographic informa-tion of the Canadian Destination ontology module for providing address to its destinations.The interface InfLocation is used to connect these two ontologies. The interface InfLocationincludes the concepts Address, PostalCode, City and Province. Tourism needs toknow the address of its sights, while these information are provided by the Canadian Des-tination ontology. The Tourism ontology module utilizes the InfLocation interface and theconcepts Address, PostalCode, City and Province, while Canadian Destination

123

254 F. Ensan, W. Du

Fig. 1 The modular ontology of Example 2

realizes the interface and its concepts by providing their meaning, properties, and instances.In this configuration, we have assumed that the ontology engineer only wanted to formalizethe tourism information of the Canadian destinations. However, the tourism ontology can beextended if the North American Destination ontology is used for realizing the InfLocationinterface.

Figure 1 shows the modular ontology which is described in Example 2. In addition to theinfLocation interface, the tourism ontology may utilize other interfaces and be connectedthrough them to other realizer modules. For example, the modular ontology can includeanother interface: InfAttraction for representing possible tourist attractions of a given des-tination. We will use this case for explaining different properties of IBF in the followingsections:

Definitions 3 and 5 give the formal specifications of interfaces and modules (ontologymodules) in the proposed formalism.

Definition 3 An interface I is defined as I = 〈CN , RN , T 〉 where T is the TBox of the inter-face and CN and RN are sets of concept and role names used in T . I has no ABox assertions.We say an interface I ′ extends I if C I ′N ⊇ C IN and RI

′N ⊇ RIN and Cn(T I

′) ⊇ Cn(T I ).

It is easy to see that if I ′ extends I and I ′′ extends I ′, I ′′ also extends I . We use Exd(I ) todenote a set of all interfaces that extend I .

Example 4 Consider I be an interface with an empty knowledge base while its signature con-sists of class names of {A, B, C, D}. I ′ with the following knowledge base: {A � B; C � D}is an extension of I .

Definition 5 An ontology module M is defined as M = 〈�, Ir , Iu〉 where � is the knowl-edge base and Ir is the set of all interfaces which is realized by M and Iu is the set of allinterfaces which is utilized by M . M can be in any description logic language.

We define a module M as consistent with regard to its interfaces iff � ∪ (⋃i∈Ir Ti ) ∪(⋃

j∈Iu T j ) is consistent. A module which utilizes or realizes an interface must be consistentwith regard to it. Let P be a concept or role name in an interface I ; it is referred to in theknowledge base of modules which utilize it as I : P . In modules which realize I , P is intheir signature and referred to as P . A module M realizes an interface I , either if I ∈ Ir , orthere is an i ∈ Exd(I ) such that i ∈ Ir .

Given an interface, we refer to the module which uses it as a utilizer module and themodule which gives semantics to its terms as a realizer module. The following remark showsthat the knowledge base of interfaces are part of the TBox of the realizer modules.

123


Remark Let I = 〈CN , RN , T 〉 be an interface and � be the knowledge base of an ontologymodule which realizes I . Sig(I ) ⊆ Sig(�). In addition, T ⊆ Cn(�).

In other words, an interface is the public part of the TBox of a realizer ontology modulewhich is exposed to the utilizer ontology modules. For example, in Fig. 1 suppose that the sig-nature of the Canadian Destination ontology includes classes {Address, PostalCode,City, Province} and a role isLocatedat and its knowledge base includes City �∃isLocatedat.Province. Obviously, Sig(in f Location) is a subset of the signature ofCanadian Destination ontology.

In Sect. 1, we claimed that through the IBF formalism, ontology modules can evolve inde-pendent of each other’s signature and knowledge bases and their entire knowledge base canchange without requiring other connected modules to change their signatures. This featureis reached by means of interface extensions. For instance, in Example 4, consider a utilizermodule Mu which utilizes I . Moreover, consider that there exists an ontology module Mrwith the following knowledge base: {A � B � C; C � D � E} that realizes I ′. In order toform a modular ontology, a configuration function may connect Mu and Mr . Now assumethat the knowledge base of Mr is changed such that A � ¬B is implied by the new revisedknowledge base. Obviously, I ′ cannot be a realized interface for Mr anymore. However, Mrcan still be a realizer for I . Exchanging I by I ′ in the set of interfaces which are realized byMr , Mr and Mu can still be connected to each other and form a modular ontology withoutrequirement of any change in Mu .

A module which utilizes an interface needs to access the instances provided by the realizermodules. In the interface-based formalism, we follow a query-based approach to augmentthe interpretations of a utilizer module with the individuals provided by the realizer modules.For instance, regarding Example 2, the Tourism ontology module may pose a query to theCanadian Destination ontology on the location of an accommodation. Through the proposedformalism, the Tourism KB is augmented with the individuals that are provided by Cana-dian Destination for the Address concept. This augmentation approach brings considerableadvantages for the framework. First, after augmenting a module with appropriate individualsfrom other modules, reasoning engines are not required to take into account the other mod-ules’ knowledge bases anymore. Analogous to the idea of knowledge compilation which isemployed in [81], knowledge augmentation leads to local reasoning instead of reasoning onexternal modules, which entails lower time complexity. Second, the augmentation processdoes not pose any limitations on the semantic of the module which realizes an interface. Thismodule’s semantic can be changed independently of the semantics of those modules whichutilize its interfaces. In other words, those modules which utilize an interface are dependenton the realizer modules, but not vice versa.

In order to augment the domain of a utilizer module, we can consider two approaches forretrieving the individuals of interface concepts and roles from the realizer modules: First,posing epistemic queries to the realizer modules and second using conjunctive queries as anABox query language for retrieving realizer module’s instances.

Using epistemic queries is based on the hypothesis that a utilizer module looks at therealizers as black-boxes whose knowledge about the interface terms are complete enoughfor reasoning. As an explanatory example, assume that in the case of Example 2, the Tour-ism ontology module uses the interface concept infLocation:BiLingualCitywhichrefers to those cities that have exactly two official languages:

infLocation:BiLingualCity ≡ infLocation:City� = 2 infLocation:hasOfficialLang.�

123

256 F. Ensan, W. Du

The Canadian Destination ontology realizes this interface concept with the followingexpressions in its knowledge base:

City(Toronto),hasOfficialLang(Toronto, English),hasOfficialLang(Toronto, French),Language(English)Language(French)

From the point of view of the Tourism ontology module, the knowledge base of CanadianDestination is complete for reasoning about places and cities, so Toronto will be recognizedas a BiLingualCity.

Based on the presented modularity framework, we do not need the knowledge bases to bepresented using epistemic operators. We only need to pose epistemic queries to the ordinaryDL knowledge bases. These two situations,‘epistemic operators in queries’ and ‘epistemicoperators in knowledge bases’, have been distinguished in the literature [22,62]. In [14,15],the authors formulate a subset of epistemic queries, called EQL-Lite queries, and show thatthey can keep the computational complexity of processing and answering these epistemicqueries under control when they are posed to ALCQI or DL-lite ontologies. Note that theepistemic queries which are employed in IBF only retrieve primitive concepts and roles, andhence, EQL-Lite is definitely expressive enough for formulating them. Since no epistemicoperators are used in the utilizer and realizer ontology modules, the reasoning algorithms andconsistency checking methods of ordinary DL knowledge bases can be applied for ontologymodules in IBF modular ontologies.

The second approach for retrieving instances of concepts and roles from the realizermodules is to use conjunctive ABox queries. This approach does not follow the complete-black-box approach for knowledge bases such that the knowledge of the realizer modulemay be incomplete for answering a query coming from a utilizer module. For example, inthe discussed example in previous paragraphs, BiLingualCity would not match any instancefrom the realizer module (Toronto is not returned as the answer of a conjunctive queryfor BiLingualCity posed to the Canadian Destination module). Nonetheless, the applica-tion of conjunctive queries has this advantage that it does not lead to non-monotonicity andreasoning complexities that epistemic operator K as a closed-world approach may induce.In addition, numerous techniques that have been proposed for answering conjunctive queries[37,77,88], different formats that defined for formalizing conjunctive queries [69,72], andvarious reasoning engines such as Pellet [78], KAON2 1 and RacePro 2 that support answer-ing them, make the usage of conjunctive queries more convenient in real-world applicationscompared with epistemic queries.

IBF can be defined based on both epistemic and conjunctive queries. In the following,we use epistemic queries for formalizing IBF. However, IBF can be formalized based onconjunctive queries as well.

Based on the definition of interfaces and modules, we now define a modular ontology asfollows:

Definition 6 A modular ontology is a triple O = 〈M, I, F〉 where M is a set of ontologymodules, I is a set of interfaces whose description logic is less or equally expressive withregard to the description logic of the ontology modules (description constructors of any giveninterface is the subset of the description constructors of any ontology module), and F is a

1 http://kaon2.semanticweb.org.2 http://www.racer-systems.com.

123

http://kaon2.semanticweb.orghttp://www.racer-systems.com


configuration function F : M×I → M which chooses one realizing module for every utilizermodule-Interface pair. F(M, I ) = M ′ if:(Assume that the knowledge base of M and M ′ aredenoted as � and � ′, respectively)

(c1) I ∈ I Mu and ( I ∈ I M ′r or there is an i ∈ Exd(I ) such that i ∈ I M ′r )(c2) M and M ′ are consistent regarding I (or (M is consistent regarding I and M ′ is

consistent regarding i))(c3) Cn(I ) ⊆ Cn(� ′) (or Cn(i) ⊆ Cn(� ′))(c4) Let Ci and R j be the result sets of queries K I : Ci and K I : R j posed to M ′,

�M ∪ ⋃∀Ci ;∀xk∈Ci (I : Ci (xk)) ∪⋃

∀R j ;∀(xk ,yt )∈R j (I : R j (xk, yt )) is consistent.A path, P AT H , in an modular ontology is defined as a set of modules which are con-

nected through the configuration function F . P AT H(M) specifies the path which includesmodule M .

Based on Definition 6, the final form of a modular ontology is specified by the configura-tion function F. This function shows the connected modules through interfaces, and its valuecan be set at configuration time. Introduction of the configuration function F in Definition 6implies that the development and configuration times of a modular ontology are distinguish-able. The development time is when an ontology module is developed, its necessary interfacesas well as those interfaces that it realizes are specialized. The configuration time is the timewhen the required modules are selected to realize the interfaces of a particular module. (e.g.,someone may develop the Tourism ontology through the proposed framework and specifythat it needs the Address concept. Both Canadian Destination and North American ontol-ogies have Address in their signature and can be a realizer for the in f Location interface.However, at configuration time it would be finalized whether the Canadian Destination orthe North American Destination ontology modules will realize the Address concept).

For being connected through the configuration function, both ontology modules must sat-isfy four conditions mentioned in Definition 6. First of all, a module must realize an interfaceor one of its extensions in order to be selected by the configuration function and be con-nected to the utilizer module. Second, two modules must be consistent with regard to theirinterfaces. Third, the knowledge bases of interfaces must be implied by realizer ontologymodules. And finally, the fourth condition ensures that the integration of two modules doesnot entail inconsistencies. Since the domain of the utilizer module would be augmented bythe individuals of the interface terms from the realizer modules through epistemic K queries,condition four ensures that this augmentation does not lead to an inconsistency in the utilizermodule. Example 7 shows the formal representation of the situation which is described inExample 2.

Example 7 Regarding Example 2, let Tourism be an ontology module which utilizes theinterface ‘InfLocation’. Furthermore, let

Accommodation ∈ CT ourismNhasAddress ∈ RT ourismNAddress ∈ Cin f LocationN

The ontology module Tourism can use the interface terms for creating complex concepts andfor defining general inclusion axiom. For instance, the TBox of the Tourism ontology hasthe following axiom:

123

258 F. Ensan, W. Du

Tourism:Accommodation� ∃Tourism:hasAddress.InfLocation:AddressLet ‘Canadian Destination’ (CD) and ‘North American Destination’ (NAD) be two ontol-

ogy modules, which realize the interface InfLocation. Two different values for the configu-ration F lead to two different modular ontologies O1 and O2 as follows:

O1={ { Tourism, CD, NAD},{infLocation}, F1 },where F1(Tourism,infLocation)=CDO2={ { Tourism, CD, NAD},{infLocation}, F2 },where F2(Tourism,infLocation)=NAD

3.2 Augmented interpretations

To give a formal specification for the notion of augmentation for an ontology module, wedefine an augmentation function as follows:

Definition 8 Let PT Box(M) be a set of all axioms in the TBox of all interfaces inP AT H(M) for a given ontology module M , an augmentation function Aug : M → Mis a function such that �Aug(M) is defined as the union of the following elements:

(i) T M ,(ii) PT Box(M),

(iii) ABox assertions with the form of �(I : c1), �(I : c2), . . . and �(I : cn) where ci is amember of the result set of KI : C posed to F(M, I ) for all concepts C in all I ∈ I Mu ,

(iv) ABox assertions with the form of �(I : x1) . . . �(I : xn) and �(I : y1) . . . �(I : ym)where 〈xi , y j 〉 is a member of the result set of KI : R posed to F(M, I ) for all rolesR in all I ∈ I Mu .

Based on Definition 8, the result set of the epistemic queries posed to the realizer moduleis being inserted into the knowledge base of the utilizer module. The following definitiondefines augmented interpretations for ontology modules.

Definition 9 An augmented interpretation for a module M j in a modular ontology O =〈M, I, F〉, is defined as I j = (�I j , ·I j ), where �I j is a non-empty domain for Aug(M j )and a mapping function ·I j which maps each concept of Aug(M j ) to a subset of �I j , eachrole of Aug(M j ) to a subset �I j × �I j and each individual name from Aug(M j ) to anelement aI ∈ �I j . ·I j maps M j concept expressions based on the semantic of concept con-structors of M j . For the concepts and roles of the utilized interfaces, the function developsmapping as follows:

(i) For every interface concept I : C , x ∈ (I : C)I j if {x}I j ⊆ �I j and �k � KC(x),where KC is an epistemic query posed to Mk = F(M j , I ),

(ii) For every interface role I : R, 〈x, y〉 ∈ (I : R)I j if {x}I j ⊆ �I j and {y}I j ⊆ �I j and�k � KR(〈x, y〉), where KR is an epistemic query posed to Mk = F(M j , I ).

An ontology module is augmentedly consistent if there is an augmented interpretationI (augmented model), which satisfies all axioms and assertions in �Aug(M). Let α be aninclusion axiom or an ABox assertion, �Aug(M) | α if for every augmented model I, α issatisfied by I.

In Example 2, suppose the realizer module expresses that {Toronto, Montreal,Vancouver} individuals are of the type of theCity concept. The instances I n f Location :Toronto, I n f Location : Montreal and I n f Location : Vancouver are interpreted

123


in the utilizer ontology module in such way that be instances of the I n f Location : Cityconcept.

Let us make two remarks about the proposed semantic. First, since the augmented inter-pretation is defined for an ontology module, the � and ¬ symbols in a modular ontologyare interpreted from the point of view of each augmented module. For example, ¬I : C ina utilizer module Mi is interpreted as �Ii \(I : C)Ii when I : C has been interpreted toinclude the result set of KI : C posed to F(Mi , I ) as its instances. Second, we do not makea unique name assumption and hence two instances of the domain may refer to the sameindividual.

4 Properties of the interface based formalism

In this section, we describe some of the significant properties of the proposed modularizationframework. The first subsection dedicated to show how the formalism support for sharingand reusing the TBoxes and ABoxes of ontology modules. Subsequently, we point out the‘polymorphism’ feature which has been driven from the interface-based nature of the formal-ism. In the third subsection, we discuss about the decidability of the formalism. Finally, weshow the capability of the formalism for propagating the logical consequences of the publicparts of the interconnected modules to the others.

4.1 TBox and ABox share and reuse

One of the important features of modular ontology formalisms is the mechanisms they pro-vide for sharing and reusing ABox and TBox of ontology modules. Different formalismsemploy various techniques for this purpose. For instance, in P-DL [3,4], ontology mod-ules can import foreign terms that are defined in other modules. This importing relation isone-to-one, i.e., for every imported object in an ontology module, there is a unique pre-image object in the original module where it has been imported from. In DDL [11], a setof inter-modules bridge rules is responsible for setting up links between concepts and roles[35] of different ontology modules. In [80], knowledge sharing is conducted based on theview-based information integration approach. According to [80], a concept in an ontologymodule can be defined to be equal to the intentional result of a conjunctive query, which isposed to another ontology module. For example, A≡ ForeignOntology : ∃x[F(x)∧ E(x)]is a concept definition that defines concept A based on a conjunctive query posed to theForeignOntology ontology module.

In IBF, we follow a different approach for sharing ontology module knowledge bases. Wedistinguish between and employ different methods for TBox and ABox reuse. TBoxes areshared by means of interfaces. Interfaces represent the content of ontology modules fromdifferent perspectives. They are employed to connect ontology modules and shape a modularontology. In addition, interfaces have also another role for sharing the public part of theTBox of the realizer ontology modules. Based on how much of its local knowledge a moduledesires to expose, it may choose different levels of interface extensions for realizations. Thefollowing example clarifies this attribute:

Example 10 Consider the ontology modules Mr with the following TBox: {D � C � B,D �A�E,E � B}. Let I be an interface with the following knowledge base: {D � C,D � A�E}and Mu be an ontology module which utilizes I . Now assume I1 and I2 be two extensionsof I with the following knowledge bases: {D � C � B,D � A � E} and {D � C � B,D �

123

260 F. Ensan, W. Du

A � E,E � B}. In order to set up a modular ontology, Mr , Mu should be connected to eachother through I or one of its extensions. Mr shares more parts of its local TBox to Mu if itrealizes I1 instead of I and even more (its complete TBox) if it realizes I2.

Observably, based on different configurations, realizer modules may expose different partsof their TBoxes and consequently the utilizer modules can access and reuse different portionsof the realizers’ TBox knowledge.

The share and reuse of ABox assertions are achieved by means of epistemic queries in theinterface-based modularity formalism. Accordingly, the ABoxes of the utilizer modules areaugmented by the result set of the epistemic queries, which are posed to the realizer mod-ules. The following example shows how ABox assertions are propagated between ontologymodule:

Example 11 Consider the ontology modules and interfaces presented in Example 10. Assumethe ABox of Mr be as following {D(α), C(ρ)}. No matter which of I , I1, or I2 is realized byMr , the augmented knowledge base of the utilizer module Mu contains these ABox asser-tions: I : D(α), I : C(ρ), I : C(α). The reason is that Mu poses an epistemic query to Mrfor each symbol in the signature of the interface I . The result set of the epistemic query KDposed to Mr is {α}. Moreover, the result set of the epistemic query KC posed to Mr is {α, ρ}.

The realizer ontology modules can share more of their TBoxes by realizing the extensionsof interfaces that expose more taxonomical knowledge. However, realizing different inter-face extensions does not effect ABox sharing and reuse. Assume that in IBF no queries havebeen defined in interfaces. Instead, in the augmentation phase, utilizer ontology modulespose simple epistemic queries for each symbol in their utilized interfaces to the assignedrealizer ontology modules. For instance, in Example 11, Mu poses epistemic queries KD,KC, KA and KE to Mr and augments its ABox according to the result sets. Observably, nocomplicated queries like K(A � E) are posed to Mr .4.2 Polymorphism

The proposed formalism supports polymorphism in the development of modular ontologiesin the sense that the meaning of an interface term is subject to specialization based on theconfiguration of the ontology. When one develops an ontology, she only needs to work withgeneral interfaces, and the specialized meaning of interface concepts would be bound toit at configuration time. For instance, in Example 2, we may define Sightseeing as aninterface concept while Natural Sightseeing, and Scientific Sightseeingare modeled as two extensions of this concept. The Tourism ontology module may be config-ured to use one of the specialized meanings of Sightseeing. Furthermore, it will be possible toextend the meaning of Sightseeing in the future through the introduction of more perspectiveswithout any changes on the syntax of the Tourism ontology module. Example 12 shows thiscapability of the formalism:

Example 12 Regarding Example 1, suppose that the ontology module Tourism utilizes theinterface I n f Attraction which represents the notion of sightseeing and its related propertiesand concepts. The Knowledge base of the Tourism module includes the following axioms:

Tourism:PlaceToGo � InfAttraction:SightseeingLet the I n f Scienti f icAttraction interface be an extension of the I n f Attraction inter-face with the following axiom:

123


InfAttraction:Sightseeing �(∀ InfScientificAttraction:HasScienceBranch.InfScientificAttraction:ScienceBranch)� (∃ InfScientificAttraction:IsVisitedBy.InfScientificAttraction:Scientist)

Further, let the InfNaturalAttraction interface be another extension for the InfAttraction inter-face with the following axioms:

InfAttraction:Sightseeing � (∃InfNaturalAttraction:HaveBestSeason. InfNaturalAttraction: Season)� (∃ InfNaturalAttraction: HavePreCondition.InfNaturalAttraction: Equipment)InfAttraction: Sightseeing � InfNaturalAttraction: Beach �InfNaturalAttraction:Jungle�InfNaturalAttraction: Park� InfNaturalAttraction: Mounts

Here, I n f Scienti f icAttraction and I n f Natural Attraction provide two morphs (forms)for the Sightseeing concept; hence the Tourism ontology module can answer differenttypes of queries related to the concept Sightseeing based on the types of configuration.

4.3 Decidability

Consistency checking is a basic problem in description logic knowledge bases to which theother reasoning problems can be reduced [2]. This issue is more vital in the proposed inter-face-based formalism because different modules can be defined using different descriptionlogics; hence their integration may lead to new inconsistency problems.

In order to show the decidability of IBF modular ontologies, we should consider first theaugmentation process while epistemic queries are posed to the realizer modules and secondthe augmented knowledge bases of utilizer modules. Based on IBF, epistemic queries are inthe form of KP when P is an atomic concept or role in the signature of the modules’ utilizedinterfaces. In [14], it is shown that a set of more expressive epistemic queries (comparedwith the queries employed in IBF) can be answered through standard database technologiesif they are posed to DL-Lite ontologies. Moreover it is illustrated that these queries can beanswered in ALCQI ontologies, although mildly harder than conjunctive queries. Currently,no accomplished research has analyzed the computational complexity of primitive epistemicqueries that are posed to more complicated DL knowledge bases such as SHOIN ontologies.In future work, we intend to focus more closely on analyzing this issue.

In the following, we show that consistency checking of an augmented modules in a mod-ular ontology is decidable in our proposed formalism.

Lemma 13 Let M be an ontology module in a modular ontology that is decidable. Theproblem of consistency checking for Aug(M) is decidable as well.

Proof SketchLet � be the knowledge base of M , according to Definition 8 and 9, Aug(M) comprises

of the following elements:

(1) �,(2) PTBox(M),

123

262 F. Ensan, W. Du

(3)⋃

∀C∈I,∀I∈Iu ;∀I :ci ∈KI :C (I : C(I : ci )) where KI : C is a query posed to F(M, I ) andI : C(I : ci ) assets that I : ci is of type of I : C ,

(4)⋃

∀R∈I,∀I∈Iu ;∀〈I :xi ,I :y j 〉∈KI :R I : R(I : xi , I : y j ) where KI : R is a query posed toF(M, I ) and I : R(I : xi , I : y j ) assets that (I : xi , I : y j ) is an instance of the roleI : R

Elements 3 and 4 ensure that the result sets of the epistemic queries are asserted in Aug(M)as instances of the their relative concepts and roles. These ABox assertions do not lead toundecidability for Aug(M) if M is decidable. The logic of element 2 is less expressive thanthe logic of M (see Definition 6), so this also does not lead to higher complexity. Accordingto this lemma there is a decidable method for consistency checking of M . Based on thediscussed points, we can conclude that such a method can also be exploited for deciding thesatisfiability of the augmented knowledge base. ��

Hence, while the formalism provides expressiveness power, which allows for creatingcomplex concepts using foreign terms, it ensures that the consistency checking of the inte-gration of different ontology modules is decidable.

4.4 Knowledge propagation and partial reuse

In [4], different modular ontology formalisms have been compared with regards to theircapabilities for propagating the logical consequences of ontology modules. In addition, ithas been discussed that a desirable framework for modular ontology should support a direc-tional semantic relations from a source ontology module to a target one. In this subsection,we investigate IBF with regard these features.

The interface-based formalism supports propagating the logical consequences of the pub-lic part of an ontology module to all of the connected ontology modules, while its privateparts do not have such consequence propagation. Hence, the formalism does not require theontology modules to use or import all of the terms of the other connected modules and doesnot require reasoning engines to process the union of all inter-connected modules. The publicsection of each ontology module is the knowledge base of its interfaces. Lemma 14 showsthat the logical consequences of a module’s interfaces propagate to all other modules that areconnected to it.

Lemma 14 1. Let M1 = 〈T , Iu, Ir 〉 be an augmentedly consistent module in a modularontology, I1 = ⋃I∈(Iu , Ir ) I and α be a concept expression (General inclusion axiom)whose signature is a subset of the signature I1. If I1 | α, for all augmentedly consistentmodule such as M2 on P AT H(M1), �Aug(M2) | α.

2. Furthermore, consider an augmentedly consistent module M2 on P AT H(M1) and letI2 be defined for M2 similarly to I1 for M1. Let I : A and I : B be two concepts in I1 andI : C a concept in I2. If I1 | I : A � I : B and I2 | I : B � I : C, for all augmentedlyconsistent modules such as M on P AT H(M1), we have �Aug(M) | I : A � I : C.

Proof 1. Since M1 is augmentedly consistent, there is an augmented model I for Aug(M1)that satisfies all statements in �Aug(M1). From Definition 8, we have I1 � PT Box(M1)� Aug(M1), so I is also a model for I1 and PT Box(M1). From I1 | α PT Box(M1)| α. Now, consider an arbitrary augmentedly consistent module M2 on P . Similar toM1, there is a model J for M2 and PT Box(M2). Since M1 and M2 are connected,PT Box(M2) ≡ PT Box(M1). In the previous paragraph, we showed that for everymodel of PT Box(M1), α is satisfiable, so we can conclude that J is a model for α andsince J is also a model for Aug(M2), we have �Aug(M2) | α.

123


Fig. 2 An example of propagating logical consequences in IBF

2. From I1 | I : A � I : B we have PT Box(M1) | I : A � I : B, and fromI2 | I : B � I : C we have PT Box(M2) | I : B � I : C (see the first part ofthe Lemma). Since PT Box(M1) ≡ PT Box(M2), we can conclude from (1) and (2)that PT Box(M2) | I : A � I : C . For every arbitrary module M on P(M1), wehave PT Box(M) ≡ PT Box(M2); therefore, we have PT Box(M) | I : A � I : C .Since M is augmentedly consistent, there should be a model for Aug(M), and fromPT Box(M) � Aug(M) (Definition 8), we can infer that this model satisfies I : A �I : C . Consequently, Aug(M) | I : A � I : C .

��As an explainer example, consider the situation shown in Fig. 2. According to the

figure, there are three ontology modules: Tourism, Canadian Destination, and UrbanAreas and three interfaces: InfLocation, Inf-Convenient-Location, and Inf-Industrial-Location where the last two interfaces are the extensions of the InfLocation interface.Tourism and Canadian Destination utilize Inf-Attractive-Location and Inf-Industrial-Loca-tion, respectively. Moreover, Canadian Destination realizes Inf-Convenient-Location andUrban Areas realizes Inf-Industrial-Location. Since Inf-Industrial-Location is the public partof the Urban Areas ontology module, all of its axioms are propagated to the connectedontology modules. According to Inf-Industrial-Location InfLocation:RuralPlace�¬InfLocation:UrbanPlace, and since Canadian Destination has InfLocation:BeautifulPlace� InfLocation:RuralPlace in its own interface, its augmentedmodels entail InfLocation:BeautifulPlace� ¬InfLocation:UrbanPlace.

This example depicts that according to IBF, interfaces, which are portion of TBoxes ofthe realizer ontology modules, are propagated to the utilizer ontology modules both directlyand indirectly.

123

264 F. Ensan, W. Du

The following proposition shows that the unsatisfiability of a concept in a realizer modulewill be preserved in all of its utilizer modules:

Proposition 15 Let M be a module which realizes interface I , for all modules M ′ such thatF(M ′, I ) = M, �Aug(M ′) | I : C �⊥, if �Aug(M) | I : C �⊥Proof Sketch For every unsatisfiable concept I : C , the result set of the query KI : C is theempty set. ��

In contrast to the public section, the private section of an ontology module does not nec-essarily propagate monotonically through connected modules. For example, in the case ofFig. 2, consider that Urban Areas module indicates that IndustrialPlace(Toronto),UrbanPlace(Toronto) and UrbanPlace(Montreal) in its ABox. The CanadianDestination ontology module may conclude that IndustrialPlace is a subclass ofUrbanPlace even though this axiom does not necessary hold in the realizer module UrbanAreas.

‘Directed Semantic’ has been introduced in [3] as a desiderata for modular ontologyframeworks. IBF supports for directed semantic in that sense that the realizer modules aresemantically independent from those modules which utilize their interfaces. Observably, if amodule which uses a set of interface terms, gives new semantics to these terms, this semanticdoes not affect their meaning in the original modules. For instance, in the case of Exam-ple 2, suppose that the InfLocation interface has two more concepts: BeautifulPlacesand RuralPlaces. The Tourism ontology module uses these interface concepts and themodular ontology has been configured in such a way that the Canadian Destination realizesthem. The Tourism ontology module may add an inclusion axiom that BeautifulPlaces� RuralPlaces; however, through our formalism, this subsumption does not necessarilyhold in the Canadian Destination ontology.

5 Inconsistency resolution

In this section, we investigate the issue of inconsistency in the interface based modular ontol-ogy framework. Let’s first analyze the situation where a module is inconsistent and causesthe modular ontology to be inconsistent.

Suppose a module which realizes an interface is inconsistent or it is inconsistent withregards to its interfaces. This situation may happen when in a modular ontology, a realizermodule evolves and moves to an inconsistent state. In order to resolve inconsistencies in thissituation, we attempt to isolate the inconsistent ontology module from the other modules.Definition 16 describes the conditions that should hold for isolating an inconsistent module.

Definition 16 Let I be an interface and Mu and Mr be two modules in a modular ontologysuch that F(Mu, I ) = Mr . Mr is isolated from the point of view of Mu if for any given axiomα we have

�Aug(Mu ) | α iff (�Mu ∪ PT Box(Mu)) | αIntuitively, the result sets of queries which are posed to an isolated module must

not have influence on reasoning tasks of the other modules in a modular ontology.For instance, assume that the result set of epistemic query for the concept City hadbeen equal to {Monteal, T oronto, V ancouver}. If Canadian Destination ontology movesto an inconsistent state, City is not required to be interpreted such that includes

123


{Montreal, T oronto, V ancouver} as its instances and can be interpreted as any subsetof the domain of the Tourism ontology module. For isolating inconsistent ontology modules,we use the definition of a hole for a knowledge base from [74] and extend it for epistemicqueries.

Definition 17 A hole for a knowledge base � is an interpretation Ih = 〈∅, ·Ih 〉, wherethe domain is empty. Furthermore, an epistemic hole for a knowledge base is defined asIh=(J , M) where the domain of J ∈ M is the empty set. We say � |h KC if � isinconsistent and has an epistemic hole.

Obviously, the result set of any query posed to an inconsistent knowledge base with a holeinterpretation will be the empty set. We represent this empty set with the ⊥h symbol andmodify the definition of the augmented interpretation, Definition 9, as follows:

(i) For every interface concept I : C , x ∈ (I : C)I j if {x}I j ⊆ �I j and �k � KC(x),where KC is an epistemic query posed to Mk = F(M j , I ) and it is not equal to ⊥h ,

(ii) For every interface role I : R, 〈x, y〉 ∈ (I : R)I j if {x}I j ⊆ �I j and {y}I j ⊆ �I jand �k � KR(〈x, y〉), where KR is an epistemic query posed to Mk = F(M j , I ),and it is not equal to ⊥h .

(iii) (I : C)I j ⊆ �I j iff KC posed to Mk = F(M j , I ) be equal to ⊥h .(iv) (I : R)I j ⊆ �I j ×�I j iff KR posed to Mk = F(M j , I ) be equal to ⊥h .

In this new definition, we emphasize that the utilizer modules are not limited by the inter-pretations of the interface concepts and roles based on the epistemic queries which are posedto the inconsistent modules.

The modification of Definition 9 gives a formal basis for isolating inconsistent modules.When the result set of queries which are posed to the realizer modules are ⊥h , it meansthat the realizer module has an inconsistent knowledge base and the query result sets are notvaluable. In this case, the utilizer modules can interpret their concepts and roles without look-ing at the query results returned by realizer modules. We do not drop an inconsistent module,giving it an opportunity to be revised and be consistent in future. Accordingly, an inconsistentmodule is isolated as long as the queries posed to it retrieve ⊥h . As soon as the query resultsbecome normal sets, other ontology modules take the module into consideration.

Proposition 18 Let Mr be an inconsistent module with an epistemic hole which realizesinterface I ; Mr will be isolated from the point of view of all modules Mu which utilize I andF(Mu, I ) = Mr .Proof Sketch The result set of all epistemic queries are the empty set. Hence, the knowledgebase of the utilizer module is not augmented by the realizer module knowledge base. ��

The second situation is when all modules are consistent but the integration of them resultsin inconsistency. The main issue that we concentrate on for repairing inconsistencies in theinterface based modularity formalism is to weaken the restrictions implied by the realizermodules in order to reach a consistent augmented ontology modules. Note that we do notremove the inserted instances from the domain of ontology module. We only remove thoserestrictions where the interface concept must has this individual as their instance and weakenthe TBox axioms in the knowledge base of problematic interfaces. Having this goal, we addnew definitions for the interface-based modular ontology formalism. We say a module M isconsistently-augmented by an interface I ∈ I Mu if there is a model I = 〈�I ·I〉 for the unionof its knowledge base and the knowledge base of I such that it satisfies the condition (c4) ofDefinition 6 for all concepts and roles in I .

123

266 F. Ensan, W. Du

Algorithm 1 Maximal Consistent Interface Set(MCI)

Input: An ontology module M = 〈T ,I Mu , I

Mr 〉 in a modular ontology O = 〈M, I, F〉.

Output: A set of maximal consistent interfacesfor M

MC I := ∅n := |I Mu |repeat

MC I = I when I ⊆ I Mu and |I | = nn := n − 1

until M is consistently-augmented by MC Ireturn MC I

Based on Lemma 13, we can infer that the consistency checking problem of a modulewhich is augmented by one interface is also decidable:

Proposition 19 Let M be a module in a modular ontology and I ⊆ I MU . It is decidablewhether M is consistently-augmented by I , if the problem of consistency checking for M isdecidable.

For resolving inconsistencies, we try to find the maximum number of interfaces in theutilizing interface set of a module when their realizations do not lead to inconsistencies.Subsequently, we augment the module with this set of interfaces. Obviously, we prefer tokeep as much interface realizations as possible in a module, so the maximality of this set isimportant for us. Definition 20 presents a formal definition for a maximal consistent interfaceset for a module.

Definition 20 A Maximal Consistent Interface set for a module M is defined as MC I (M) ⊆I Mu such that M is consistently augmented by MC I (M) and if |MC I (M)| = n, for eachset I ⊆ I Mu that |I | > n, M cannot be consistently augmented by I . �Aug(M) |MC I α if αholds for every model of M which is consistently augmented by MC I (M).

Algorithm 1 selects a subset of utilizing interfaces for a module M and checks whether Mis consistently augmented by this set. As we have shown in Proposition 19, this is a decidableproblem. If so, the algorithm terminates and returns this set as MC I , else it decreases thesize of the selected subsets by 1 and repeats the process. In the first iteration the size of theselected subset is equal to the size of I Mu , so if the algorithm terminates in this step, it impliesthat there are no conflicts between different interfaces of the module and no problem withaugmentation. Lemma 21 shows that the algorithm always terminates. The algorithm mayresult in multiple different MCIs if for a specific number of interfaces, there exist more thatone combination of interfaces that are consistent with each other.

Lemma 21 Given a consistent ontology module M in an modular ontology O, Algorithm 1always terminates.

Proof The union of the knowledge base of M with the TBox of all of its interfaces is con-sistent due to condition (c4) of Definition 6. In the worst case the algorithm will terminatefor n = 0. ��

The inconsistency resolution algorithms presented in this section show how modularityand the notion of interfaces can facilitate finding of ‘problematic’ and ‘inconsistent’ mod-ules compared with the situations where ontologies are represented as monolithic knowledge

123


bases. However, they are not efficient for pinpointing the smallest part of the knowledgebases, which make modular ontologies inconsistent. As we will mention in Sect. 8.3, we arenow working on change and revision propagation in IBF modular ontologies as a part of ourcurrent research. During the revision process, we should find the smallest parts of knowl-edge bases which give rise to inconsistencies. We are now working on finding more efficientsolutions for IBF inconsistency resolution that not only finds problematic ontology modulesbut also finds a subset of their axioms and assertions that are responsible for inconsistenciesand revises them to make consistent ontologies.

6 Case study

In this section, we study the application of the proposed modular ontology framework fordeveloping a Friend-of-a-Friend (FOAF) ontology. This modular ontology specifies and cat-egorizes the publications of a person and the relationships between different authors based ontheir research publications. Our main intention concerning this case analysis is to investigateIBF and its properties on a real-world sample of modular ontologies. In the following, wefirst introduce different components of the modular ontology which is designed for the casestudy. Subsequently, we analyze the knowledge propagation and polymorphism propertiesin IBF. Finally, we give a discussion of the challenges we faced while designing the modularontology for this case study.

6.1 Modular ontology components

Figure 3 demonstrates the modular ontology. According to Fig. 3, the modular ontology iscomprised of four ontology modules: FOAF ontology, AKT Portal ontology, ISI Journals

Fig. 3 An IBF-based modular ontology for representing people and their publications

123

268 F. Ensan, W. Du

Fig. 4 Publication interface (PI)

ontology, and DRC Locator ontology. It also includes three ontology interfaces: PI (Publica-tion Interface), LI (Location Interface), and ISI.

The FOAF ontology [32] has been provided by the Friend-of-a-Friend (FOAF) [84] pro-ject in order to define and categorize the basic terms which are used for describing peopleand their connections. The FOAF project has been founded in 2000, aiming to support thecreation of machine-readable home pages and documents that describe people linkages. TheFOAF ontology contains basic concepts for representing persons, groups, agents, and doc-uments. It also defines a set of properties for indicating personal information such as name,home pages, web logs, interests, and publications. In addition, the FOAF ontology definesa property: knows, which is used to connect people and their corresponding documentstogether.

The FOAF ontology contains an object property ‘foaf:publications’ for a set ofpublications associated with a person. Nonetheless, this ontology cannot be used for repre-senting more complicated information about publications. Information like the publishingdate, ISSN, or ISBN of the magazine, book or journal that includes the publication, the pub-lisher institute, the references, and vice versa. In the modular ontology which is depictedin Fig. 3, the FOAF ontology has been extended by the AKT Portal ontology in order torepresent more complete information about publications.

AKT portal ontology is the main ontology among the reference ontologies that are devel-oped by the Advanced Knowledge Technologies (AKT) [83] project. This ontology describespeople, publications, projects, and geographical data. The Publication Interface, PI, perspec-tives a part of the portal ontology which illustrates the notion of publications, in view of thefact that the other parts are not necessary for the purpose of the modular ontology. Figure 4shows the class hierarchy as well as some of the object properties of the PI interface.

The other object properties of PI are has-ISBN-number, has-periodicity,has-date, and published-by. In the depicted modular ontology, FOAF ontology mod-ule utilizes the PI interface while AKT portal ontology realizes it. The object property

123


Fig. 5 Location interface (LI)

publications in FOAF ontology module has been redefined in the modular ontologyso that its range is the PI:publication:

foaf:person � ∃ foaf:publications. PI:publicationThe FOAF ontology is also connected to the DRC Locator ontology through the LI inter-

face. DRC Locator ontology [58] is a simple ontology for describing the physical or electroniclocation of something. The LI interface reflects the postal address and phone numbers fromthe ontology (Fig. 5).

FOAF usesPostaladdress for specifying the address of a person as well as the addresswhere his/her publications have been printed.

The following assertion shows how in FOAF the knowledge base of an interface is usedfor representing more accurate information about the knowledge base of the other:

PI:Publication� ∀PI:has-place-of-publication .LI:PostalAddressThe last ontology component in Fig. 3 is the ISI Journal ontology. We developed this ontol-

ogy for representing journals which have been cited by the Institute for Scientific Information(ISI). The two basic properties of a journal in this ontology are its Name and Subject.The name and subject are of the ISI journals have been extracted from [85]. In the modularontology which is shown in Fig. 3, AKT portal utilizes the ISI interface where this interfacehas been realized by the ISI Journals ontology. The ISI interface has been shown in Fig. 6.The interface has just the class hierarchy and does not includes individuals. For instance, thefollowing are some of the instances of the class CompuMath, one of the sub-classes of theSubject that are hidden from the interfaces and other foreign ontologies:

Statistics_Probability,Robotics_Information_Systems, Hardware_Architecture,Artificial_Intelligence, Applied_Mathematics

In the AKT portal ontology , ISI:Journal is defined as a sub-class of the Journal:

ISI:Journal � AKT:Journal

123

270 F. Ensan, W. Du

Fig. 6 ISI interface

6.2 IBF properties analysis

In this section we illustrate the IBF properties by analyzing the described modular ontologyand its ontology components.

6.2.1 Knowledge propagation

The AKT portal ontology utilizes the ISI interface. It asserts that ISI:Journal �AKT:Journal. In addition, the AKT portal ontology has other general inclusion axiomsabout the AKT:Journal class such as

AKT:Journal � ∀AKT:has-author .AKT:Generic-AgentAKT:Journal � ∀AKT:owned-by .AKT:Legal-AgentAKT:Journal � ≥ 1AKT:has-publication-reference

Nonetheless, these necessary conditions are not propagated to ISI Journals. In other words,in the ISI Journal ontology module none of these assertions do not hold. ISI journals do notidentify AKT classes and properties. The change or update in the AKT portal ontology doesnot affect the ISI Journal ontology. On the contrary, if the ISI Journal is updated or modi-fied, the modification may affect the AKT portal ontology. For example, if the list of subjectinstances of a specific subject changes, (for example, the Signal Processing is addedto the CompuMath subject category of ISI journals), the process of augmentation shouldbe performed again and subsequently the change will be propagated to the utilizer module,AKT portal ontology.

6.2.2 Polymorphism

The AKT portal ontology contains classes and properties on the subject of the postal addressin addition to its knowledge categorization about publications and journals. It includesthe following concepts: Address, Postal-Address, Location, Geographical-

123


Fig. 7 Polymorphism in the case study modular ontology

Table 1 The knowledge-base of ELI: an extension to the LI interface

Classes ELI:City, ELI:Country, ELI:State,ELI:PostalCode, ELI:Currency

Properties ELI:hasCity, ELI:hasCountry, ELI:hasState, ELI:hasPostalCode,ELI:has-currency

Axioms ELI:PostalAddress ≡ ≥ 1 ELI:hasCountry � ≥ 1 ELI:hasCity � ≥ 1ELI:hasState � ≥ 1 ELI:hasPostalCodeELI:Country � ∃ ELI:has-currency.ELI:Currency

Region, Geopolitical-Entity, Country, Local -District, Municipal-Unit, City, Town, Village. Moreover, it has address-relevant object properties:address-region, address-country, address-area, address-city-or-village. Conclusively, the AKT portal ontology can be used as a realizer ontologymodule in our case modular ontology. Figure 7 shows two possible configurations for themodular ontology. The first configuration, which is specified by solid lines in Fig. 7, is similarto the modular ontology of Fig. 3. It connects DRC Locator ontology to the FOAF ontologyas a realizer of the LI interface. Alternatively, the second configuration that is specified bythe dashed lines in Fig. 7 connects AKT Portal ontology to FOAF as the realizer of theLI interface. According to this configuration, AKT Portal ontology realizes LEI that is anextension of the LI interface. LEI has the classes, object properties, and axioms in additionto the knowledge base of LI according to Table 1.

All concepts and properties in utilizer modules are augmented by posing querieson terms in the AKT portal ontology. Different interface classes and roles such as

123

272 F. Ensan, W. Du

LI:PostalAddress in the FOAF ontology may have different semantic based on theconfiguration of the modular ontology. There may be other extensions for ELI and thereforefor LI that include more concepts and roles or more limiting conditions for symbols suchas PostalAddress. For example, an interface may require PostalAddress to havea street as well. Conclusively, the configuration of the modular ontology changes themeaning of the LI terms, their properties, and their definitions.

6.3 Discussion

In this section, we discuss various challenges that we faced while designing the IBF-basedmodular ontology for the FOAF domain.

6.3.1 Change propagation

The interface-based modular ontology framework follows a compilation approach for aug-menting the knowledge bases of the utilizer modules. Despite the advantages of this approachfor the framework (see Sect. 3.1), it may lead to some challenges if the realizer moduleschange frequently. In our case study, we designed the ISI journal ontology for being usedby the AKT Portal ontology. Since the database of all ISI cited journals and their subjectsis very large, we desired to develop this ontology gradually, i.e., to populate subjects of theISI cited journals iteratively. This approach enforces high cost of re-augmentation, speciallywhen the new information in ISI Journals is not consistent with the knowledge base of theAKT portal ontology.

6.3.2 Implementation

In [30], we described the implementation of the framework by extending the SWOOP [50]ontology browser and editor. In our implementation, we used Pellet [65] as a reasoner foranswering queries that are posed to the realizer modules. Pellet has some limited capabilitiesfor answering epistemic queries [78], and its support is not mature enough to be employed foranswering complicated queries. In the case of the FOAF modular ontology which is discussedin this section, we could not pose complicated K queries using the current version of Pellet.For example, suppose the AKT:PostalAddress had been defined such that it must haveexactly one city (instead of its current definition the states that the AKT:PostalAddressmust have at least one city). The current implementation of the framework augments theFOAF ontology module using conjunctive queries.

In Sect. 9, we discuss our future work for addressing these challenges so that the frameworkcan be applied more comprehensively to real-world cases.

7 Related work

In the recent years, a considerable amount of research has been conducted on mod-ular ontology formalisms, their reasoning capabilities and integration issues (See e.g.[3,40,52,87]). In the following, we first review the proposals that attempt to decom-pose a large and comprehensive ontology into a set of smaller and self-contained mod-ules or extract meaningful segments from a given ontology. Afterward, we investigatethose proposals that introduce new formalisms for developing modular ontologies. Sub-sequently, we review those works that based on a peer-to-peer infrastructure, manage

123


distributed ontologies and knowledge systems. The last part of this section is dedicatedto inconsistency management and resolution techniques in ontologies and descriptionlogics.

7.1 Extracting modules from ontologies

The first category of the literature review is dedicated to those works that attempt to extractmodules from ontologies [36,51,53,64]. Cuenca Grau et al. [19] proposes an algorithmfor extracting a module from an ontology which describes a given concept. The extractedmodule captures the meaning of that concept and should be ‘locally correct’ and ‘locallycomplete’ which means that any assertions which are provable in a module should alsobe provable in the ontology. Also any assertion which is provable in the ontology andasserted using the signature of a module should be provable in that module. In [42], amodule for an ontology is defined based on the notion of ‘conservative extension’ [56,59].According to [38,42], the ontology Q is a deductive conservative extension of the ontol-ogy P if P ⊆ Q, and for every axiom α with Sig(α) ⊆ Sig(P), P | α iff Q | α.Intuitively, P has the same logical consequences on the vocabulary of P as Q does. Amodule P of Q is defined in such a way that for any arbitrary query on the signatureof P , if any given ontology like O imports P , it has the same results as if it importsQ. In [39], the notion of conservative extension is employed to ensure the safe integra-tion of different modules where a modular ontology is defined as the union of all mod-ules forming a modularity class. According to [39], safe integration means that merg-ing ontologies does not lead to new inconsistencies or subsumptions between importedterms.

Seidenberg and Rector [73] proposes an algorithm for segmentation of an ontology bytraversing through the ontology graph starting from a given concept name. The algorithmtraverses the hierarchy upwards from the given class to the top (�) concept and down-wards from the given class to include its subclasses. In addition, the algorithm takes intoconsideration the properties and their corresponding filler(class) in the segment. Since theextracted segments are not small enough for representing and reasoning, some other meth-ods are proposed in [73] for constraining segments’ size. For instance, following a depthlimiting approach, the recursion depth from the source concept can be limited to a certainnumber. Accordingly, reaching the limited threshold depth, all links of a class are removed.In [82], the authors propose a method for partitioning a large ontology into disjoint sets ofconcepts. It has been assumed that the given ontology is mostly comprised of hierarchal rela-tionships between concepts instead of more complex roles and binary relationships. Doranet al. [23] proposes a methodology for reusing ontology modules. The methodology consistsof the following steps: define competency of module ontology engineers need to identifycompetency questions and express them by SPARQL queries. Ontology selection Ontologyengineers should find appropriate ontologies they want to extract modules from. They mayneed to evaluate different ontologies and select among them. Ontology translation In thisstep the selected ontologies are translated to the representing language which is suitable forthe module extraction process. Extract modules From the selected ontologies, modules willbe extracted by extraction methods. Check Competency In this step, the extracted modulesare examined to see how well they fit the defined competency. If the competency questionsare not satisfied well, in the Refine step, the modules will be refined by either removing oradding more terms or running the extraction methods again. The last step is to Integrate theontology modules.

123

274 F. Ensan, W. Du

7.2 Modular ontology formalisms

There are other category of works that focus on proposing new formalisms for modularontologies. These formalisms mostly provide new extensions to existing description logicssyntax and semantics in order to make automated reasoning over ontology modules feasi-ble. The interface-based modularity formalism introduced in this paper and also DistributedDescription Logics (DDL) [11,76,75], Package Based Description Logics (P-DL) [4,5,9],E-connections [55], and Semantic Import [9] can be categorized in this class of works.

DDL defines a modular ontology as a set of ontology modules which are connected through‘bridge rules’. A bridge rule forms a mapping between two concepts of two different ontologymodules. Further, Context OWL (C-OWL) [12] has been introduced as an extension to OWLto support the syntax and semantics of such bridge rules. E-connections is another formalism,which supports ontology modularization by introducing a new type of roles (called links)whose domain and range belong to different ontology modules. The authors in [41] describetheir extension to OWL for supporting E-connection ‘links’ and also the modification ofthe Pellet reasoning engine to support its semantic. The P-DL formalisms allow ontologymodules to import the knowledge base elements of each other.

Peter Haase [66] describes a new formalism for ontology modularization. Based on [66],a module is described by its identifier, a set of the identifiers of other modules which areimported, a set of interfaces, a set of mapping assertions between different concept names ofimported modules, and its concepts and an export interface. It uses a mapping approach anddefines a mapping function in order to let a module use the others’ elements. Through thisfunction, concepts of different modules are mapped to a global domain. The notion of inter-faces in [66] are different from those that are defined in this paper. Contrary to our approachfor defining interfaces as independent ontology units which ensures indirect connection ofontology modules, in [66] interfaces are a set of concept names of a specific module that canbe imported by others. Furthermore, in [66] a module can only have one export interface;consequently it is not possible to provide different perspectives for describing an ontologymodule.

7.3 Peer-to-peer knowledge bases

There are numerous works in the literature that use peer-to-peer infrastructures for inte-grating distributed knowledge and information. These works can be in the subject of ourinterest in modular ontologies where for peers and their union a set of local, global or dis-tributed semantics are defined. The idea of integrating knowledge of distributed peers basedon their defined semantics can be exploited for defining distributed and modular ontolo-gies. In [1], a distributed consequence finding algorithm, DECA, is proposed for a peer-to-peer setting. The algorithm computes the logical consequences gradually from a givenpeer to other connected nodes. The main characteristic of the P2P systems in [1] is thatthe whole theory (the union of all theories of all existing peers) is not known and eachpeer can answer queries based on its local knowledge and also by posing queries to itsacquaintance peers. The acquaintance nodes in a peer-to-peer system are those that sharevariables in common. Exploiting the DECA algorithm, the ‘Somewhere’ peer to peer datamanagement system is proposed in [1,71] for the Semantic Web. Based on the Somewheredata model, each peer has its own ontology. Furthermore, each peer may have some inclu-sion or equivalence axioms that assert the mapping between its local concepts with theother peers’ terms. Calvanese et al. [18] provides a framework for peer-to-peer systems.According to this framework, each peer has its own information system and exports its

123


data through appropriate schemas. There are local mappings between local information sys-tem and the exported schemas. In addition, there are mappings among exported schemas ofdifferent peers. In [18], the semantics of peers and the peer-to-peer framework are inves-tigated based on a first-order logic (FOL) approach and an epistemic logic approach. Ithas been shown that the epistemic approach provides better support for modularity, gen-erality, and decidability. Modularity criterion states how the semantic of the P2P systemallows peers to be autonomous and the interconnections among peers do not affect others’semantic. The generality property concerns with the support of the framework for defin-ing mapping between peers. Ultimately, decidability is concerned with the support of theframework for processing queries in a limited time. In [33], the authors define global, localand autoepistemic semantics for peer-to-peer systems. Furthermore, they extend the localsemantics in order to handle inconsistencies. They define an empty domain for the inconsis-tent peer to prevent propagating inconsistencies through connected peers. This approach isclose to the notion of holes that is introduced in [74] and is used by our framework in thispaper.

7.4 Inconsistency management and resolution

The problem of inconsistency management and resolution in description logics and ontol-ogies has been addressed by several work in the literature [28,44,47,61,70]. The exist-ing proposals mostly attempt to either tolerate inconsistencies or resolve them and repairthe inconsistent ontology. The tolerating approach attempts to apply a kind of non-stan-dard reasoning strategy on an inconsistent ontology and obtain meaningful results forqueries. Huang et al. [47] introduces a framework for reasoning with inconsistent ontol-ogies. Its idea is that for a given query Q, select a consistent subset of the inconsistentontology which is relevant to Q, and pose the query to it. This idea is also employedin [44] for reasoning with evolving ontologies which have moved to an inconsistentstate.

Repairing inconsistencies is comprised of finding the inconsistent part of an ontology andresolving it. Meyer et al. [61] presents an algorithm for resolving inconsistencies in stratifieddescription logic knowledge bases by weakening the knowledge bases which are found tobe responsible for inconsistency. A stratified description logic knowledge base is defined asK = {S1, . . . , Sn} where Si is a knowledge base while its axioms and assertions have beenassumed to have the same reliability, and for each S j , j > i , Si is more reliable. The notionof stratified DLs prioritize the knowledge bases; hence the less reliable the DL knowledgebase is, the more likely to be weakened by the resolving algorithm. Qi et al. [70] introducesa mechanism for resolving inconsistencies arising by ABox assertions in stratified descrip-tion logic knowledge bases. The mechanism applies a strategy for weakening the conflictingknowledge bases by adding some exceptions to general inclusion axioms. For example, if aknowledge base contains {C � D, C(a),¬D(a)}, the weakening strategy changes C � Dto C � ¬{a} ⊆ D.

The above proposals investigate the inconsistency issues in monolithic ontologies or aset of DLs without any linkage or mapping between them. There are few works for inves-tigating the inconsistency issues in existing modular ontology formalisms [74]. We believethat modularity can ease the process of finding and resolving inconsistencies. For example,in the case of interface-based modular ontology which is proposed in this paper, instead ofexamining the role of each assertional or inclusional axiom in the inconsistency of the inte-grated ontology (as is suggested by the above introduced mechanisms), one can only checkthe utilizer interfaces of a module.

123

276 F. Ensan, W. Du

8 Discussion

8.1 Interfaces in modular ontologies

The centric component of the IBF formalism is the notion of interfaces based onwhich ontology modules can connect and shape modular ontologies. In addition, throughinterfaces, ontology modules (realizers) can share a specific level of their TBox withthe others. Ontology modules (utilizers) can pose queries and reuse the ABox asser-tions of the other modules based on the constituting symbols in the others’ inter-faces. In the software engineering field, the notion of interfaces has been acceptablyestablished for modularization of code and software systems. There, widely acceptedmethodologies, frameworks, and programming languages [13,60,68] have been standard-ized for defining and employing interfaces. On the contrary, in the knowledge engineeringfield and specially in the ontology engineering community, investigating the employment ofinterfaces for knowledge reuse and modularization is limited to some few valuable proposalssuch as [7,8]. In [8], some of important contributions of interfaces to ontology modulariza-tion are enumerated. These motivations include better ontology integration, polymorphism,partial reuse, and more efficient ontology evolution.

Despite existing efforts, we believe that more research is required for establishing andstandardizing the usage of interfaces in the process of ontology development. The importanttopics that need more exploration include, but are not limited to:

– Definition of interfaces Providing an appropriate and precise definition for interfacesis the first step for developing interface-based ontologies. This definition is absolutelydependant on the considered definitions for ontology modules and modular ontologies.Currently, imaginable definitions for interfaces include: a set of conjunctive queries, aset of ontology module terms and their usage scope [8] and a subset of the implicationsof some ontology modules’ TBoxes (IBF).

– Interfaces and knowledge hiding Analogous to software interfaces, ontology interfacescan be used for restricting the access of foreign modules to the local knowledge of anontology module. In [7,8], each term in an interface is accompanied by a scope limitationmodifier where this modifier can be public, protected or private. In IBF, that portion ofthe TBox of an ontology module is accessible by foreigners that has been presented in itsrealized interfaces. In terms of ABox assertional axioms, foreign ontology modules canonly retrieve individuals of those classes and roles of an ontology module that are in thesymbol set of its realized interfaces.

– Semantics of interfaces Another canonical question is how to define appropriate semanticsfor interfaces. In IBF, interfaces do not have independent semantics. In [8], the semanticsof interface terms are defined based on their semantics in the original module where theyoriginate from.

Obviously, because of the limited number of accomplished research on ontology inter-faces, it is hard to find and analyze more conclusive options for the aforementioned issues.It would be desirable to explore, compare, implement, and standardize more solutions in thefuture.

8.2 Semantics of ontology modules and their integration

The definition of appropriate semantics for ontology modules and their integration, whichform modular ontologies depends on how knowledge (concepts, roles and individuals as

123


Fig. 8 Distributed modular ontologies. Definition of concepts, roles and axioms, and their semantics aredistributed in different modules. A higher level semantics, collective semantics, are needed to connect andintegrate local semantics

Fig. 9 Collaborative modular ontologies. Ontology modules augment their local knowledge bases by theknowledge provided by the other modules

well as TBox axioms and ABox assertions) is distributed in different sites and how it isintegrated. Based on existing accomplished work on modular ontologies, we can distinguishtwo approaches for defining knowledge distribution and integration: 1) distributed design;and 2) collaborative design. Figures 8 and 9 better illustrate this distinction.

In a distributed design, the semantic of concepts, roles or even axioms can be distributedamong different ontology modules. For instance, the semantic of a link in the E-connectionformalism is defined based on the semantics of its domain and range from two different ontol-ogy modules. Other than the local semantics of each ontology modules, existing modularityformalisms usually define a distributed [11,55], global [66] or a combination of local, global,and distributed semantics [6] for modular ontology to integrate and connect these distributed

123

278 F. Ensan, W. Du

semanti

a knowledge encapsulation approach to ontology...

Documents