-
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
-
A knowledge encapsulation approach 253
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
-
A knowledge encapsulation approach 255
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
-
A knowledge encapsulation approach 257
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
-
A knowledge encapsulation approach 259
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
-
A knowledge encapsulation approach 261
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
-
A knowledge encapsulation approach 263
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
-
A knowledge encapsulation approach 265
{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
-
A knowledge encapsulation approach 267
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
-
A knowledge encapsulation approach 269
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
-
A knowledge encapsulation approach 271
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
-
A knowledge encapsulation approach 273
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
-
A knowledge encapsulation approach 275
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
-
A knowledge encapsulation approach 277
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