I n t e l l i g e n t I n f o r m a t i o n P r o c e s s i n g

Ontologies for
Enterprise Knowledge
Management
Alexander Maedche, Boris Motik, Ljiljana Stojanovic, Rudi Studer, and Raphael Volz,
Research Center for Information Technology, University of Karlsruhe

O ntologies are increasingly seen as a key technology for enabling semantics-dri-

ven knowledge processing. Communities establish ontologies, or shared con-

ceptual models, to provide a framework for sharing a precise meaning of symbols

exchanged during communication. Many applications benefit from semantically enriched

information, including knowledge management and
e-business applications. Next-generation knowledge
Several challenges management systems will likely rely on conceptual
models in the form of ontologies to precisely define
exist related to the meaning of various symbols. For example,
FRODO (a Framework for Distributed Organiza-
applying ontologies tional Memories) uses ontologies for knowledge
description in organizational memories,1 CoMMA
in real-world (Corporate Memory Management through Agents)
investigates agent technologies for maintaining
environments. The ontology-based knowledge management systems,2
and Steffen Staab and his colleagues have discussed
authors present an the methodologies and processes for building ontol-
ogy-based systems.3
integrated enterprise- Here we present an integrated enterprise-knowl-
edge management architecture for implementing an
knowledge ontology-based knowledge management system
(OKMS). We focus on two critical issues related to
management working with ontologies in real-world enterprise
applications. First, we realize that imposing a single
architecture, focusing ontology on the enterprise is difficult if not impossi-
ble. Because organizations must devise multiple
on how to support ontologies and thus require integration mechanisms,
we consider means for combining distributed and het-
multiple ontologies erogeneous ontologies using mappings. Additionally,
a system’s ontology often must reflect changes in sys-
and manage ontology tem requirements and focus, so we developed guide-
lines and an approach for managing the difficult and
evolution. complex ontology-evolution process.
Bringing ontologies to real-world
enterprise applications
For several reasons, the development of real-world
enterprise-wide OKMSs is still in the early stages.
First, despite much research on ontology represen-
tation, engineering, and reasoning, features such as
scalability, persistency, reliability, and transactions—
standardized and widely adopted in classical data-
base-driven information systems—are typically not
available in ontology-based systems. So, using
requirements analysis from several applications, we
recently developed a conceptual-modeling approach4
suitable for business-wide applications. Our design
goals were to express and access ontology-based
conceptual models in a natural and easily under-
standable way, with a small gap between the model
conceptualization and its implementation. At the
same time, we wanted to realize an enterprise-wide
ontology-based system using existing and well-
established technologies such as relational databases.
Second, a large body of information in an enter-
prise typically already exists outside the knowledge
management system—for example, in other applica-
tions such as groupware, databases, and file systems.
To reuse information from these sources, we must
integrate the sources and the OKMS, which typically
involves creating wrappers that lift these sources’con-
tent to the ontology level—not an easy task.5
Third, providing metadata is a time-consuming
and difficult process that users tend to avoid. So, we
must develop ways to easily assign fine-grained
metadata (based on ontologies) to the different
resources available in the enterprise. This would
require enhancing tools used daily (such as text
processors) so that they could extract as much meta-
data as possible semiautomatically.

2 1094-7167/03/$17.00 © 2003 IEEE IEEE INTELLIGENT SYSTEMS

Published by the IEEE Computer Society
 These requirements, among others, have
served as input for developing our enterprise
architecture for implementing an OKMS. We
developed the architecture in the context of
the Ontologging project (www.ontolog-
ging.com), which aims to develop a working
OKMS prototype. This EU-funded research
project focuses on distributed ontology-based
knowledge management applications and is
investigating how ontologies can improve tra-
ditional knowledge management systems.
Important research challenges include scala-
bility, managing multiple ontologies, ontol-
ogy evolution, and embedding ontologies in
daily work tools. Figure 1 presents the
Ontologging OKMS architecture.
The system’s front end is organized into
several different applications, each targeted
at different user groups. The ontology man-
agement GUI provides the facilities that sys-
tem administrators need to set up and evolve
the ontology. Additionally, it provides means
for defining mappings between autonomous
ontologies. The enterprise knowledge portal
provides an integrated platform for the dif-
ferent knowledge management tools avail-
able for the end user. With the user-profile
editor, users can express their interests in
some part of the domain, which lets the sys-
tem select potentially interesting content for
the user. With the query, browsing, and
knowledge-editing GUI, users can search and
navigate through the knowledge base, upload
documents, and create new instances.
Finally, to integrate the Ontologging system
with the tools users use daily, the front end
includes several plug-ins for MS Office,
enabling easy creation of metadata from
Office applications.
All GUI applications are realized on top
of the core integration layer, which coordi-
nates the interaction of various system com-
ponents. To bridge the gap between different
implementation languages and technologies,
the system uses Web Service technology to
realize this integration layer. This layer also
hosts a set of intelligent services and agents
that improve user interaction with the system
by tracking the user’s behavior. On the basis
of analysis of the user’s activities, the system
generates a personalized view of its infor-
mation and presents it to the user.
The core integration layer is realized on
top of two other systems—the ontology
server and the document server. The docu-
ment server stores the documents and pro-
vides mechanisms that let users concurrently
access and modify them. However, the doc-
MARCH/APRIL 2003
Front-end applications
Enterprise knowledge portal
Ontology
management
User profile Query, browsing,
GUI
Knowledge editor
officers
Core integration layer
(including agents and intelligent services)
Ontology User profile
API API
Ontology server
Production
Development Groupware
Database server
Figure 1. The architecture of the Ontologging ontology-based knowledge
management system.
uments are annotated using the Ontologging
domain ontology, and the ontology server
then stores this information. Both servers
provide appropriate APIs for accessing their
functionality. Additionally, the system can
access information about users in the system
through the user-profile API, which relies on
the ontology API for information storage.
Finally, the system it is possible to define
wrappers that lift the content of the different
relevant, existing applications to the ontol-
ogy level. For example, we have developed a
wrapper for integrating Lotus Notes with the
ontologies using a set of rules that the admin-
istrator defines. So, the OKMS gains access
to a large volume of information already
available in an enterprise.
Managing multiple ontologies
Large organizations often don’t centrally
create and manage knowledge management
systems. Rather, individual departments typ-
ically create smaller systems satisfying their
own needs, which over time accumulate
valuable information. At some point, other
departments want to reuse this information
in their systems. This has often proven diffi-
cult, because target systems are typically
based on different conceptual models, so to
integrate them, we must solve the problem
of semantic heterogeneity between these
models. Because ontologies define the
computer.org/intelligent
MS Office
plugin
and editing End
users
Document
API
Document
Wrapper
server
Relevant, existing applications
File
Databases Human
system
resource
applications
semantics of data more accurately, spotting
correspondences between two ontologies is
easier. We can generally consider the fol-
lowing three approaches for combining dis-
tributed, heterogeneous ontologies.
The first approach is ontology inclusion,
which simply includes the source ontology
in the target ontology. All definitions from
the source ontology are immediately visible
in the target ontology—it is not possible to
include only parts of the source ontology.
The drawback is that the information can
only be reused as is—it can’t be adapted.
A more complex approach is ontology
mapping, which relates a portion of the
source ontology to the target ontology’s enti-
ties, tranforming instances from the source
ontology into instances in the target ontol-
ogy. The technical challenge is providing
flexible mechanisms for information trans-
formation while enabling desired character-
istics such as scalability and flexibility. How-
ever, nontechnical aspects, such as a
methodology for establishing mappings, are
no less important.
The most complex approach combines
several data sources—each using a different
ontology—into a common, integrated ontol-
ogy. A dedicated knowledge management
system component—mediator6—is typically
introduced, whose main task is to answer
queries manages this integrated ontology.
3
I n t e l l i g e n t I n f o r m a t i o n P r o c e s s i n g

tion sources that are not ontology based. In

addition, it must realize a wrapper for the infor-
Mapped target mation source at hand, whose task is to trans-
ontology instances form the desired information source to the
ontology level. If the source information is
Postprocessing
already ontology based, you can skip this step.

Execution Similarity extraction

Semantic mapping
Instance similarity Similarity extraction
matrix
Lift and normalization
Database
Source ontology
Information source
Figure 2. The ontology-mapping process.
The main technical challenge in building
mediators is query rewriting—the mediator
must rewrite a query expressed over elements
of ontologies of each source. After the
sources answer the rewritten queries, the
mediator integrates their responses. Method-
ological aspects of ontology integration
relate primarily to how correspondence
between source ontologies and the integrated
ontology is established. The global-as-view
approach, applied within the TSIMMIS sys-
tem,7 creates the integrated ontology as a
view over individual sources. The drawback
is that, for n sources, the integrated ontology
might need to express n2 interactions
between source ontologies. Another
approach is the local-as-view approach,
applied in the Information Manifold system,8
which specifies each source as a query into
the integrated ontology. In this case, writing
only one query for each source ontology is
sufficient.
The rest of this section focuses on ontol-
ogy mapping, which can transform informa-
tion but doesn’t require building an inte-
grated view. So, although it’s more powerful
than simple inclusion, it avoids the com-
plexity and overhead of integrating multiple
sources. For example, let’s assume that both
the sales and research departments manage
information about documents and their
authors. However, because these departments
approach the domain from different stand-
points, the ontologies for these two systems
Mapping ontology
instance
Source ontology
instances
Target ontology
do not match. The research department will
have a fine classification of documents, with
research papers explicitly classified as
instances of the Research Paper concept.
However, the sales department might clas-
sify all papers as Documents.
At some point, the research department
might want to include information from the
sales department in their knowledge manage-
ment system. To facilitate this, the informa-
tion must be transformed (some Documents
might need to be reclassified as Research
Papers), so simple inclusion of instances from
the sales department will not suffice. On the
other hand, building an integrated view of both
systems is certainly more difficult than pro-
viding a unidirectional mapping. In this exam-
ple, you need only provide a set of mapping
rules. The rules should ensure that when
someone queries the target ontology for
instances of the Research Paper concept, the
result includes all instances of the Document
concept from the sales department system that
have a research-topic property instantiated and
thus classify as research papers.
We use a five-step process (see Figure 2)
to address methodological issues in ontology
mapping.9
Lift and normalization
The first step addresses bringing existing
information to the ontology level. It extends
the ontology-mapping problem somewhat to
the problem of integrating existing informa-
Extracting ontology mapping rules is typ-
ically difficult. Ontologies being mapped are
often very large, so establishing correspon-
dences is not easy. By analyzing the ontol-
ogy and its associated instances, we can spot
correspondences between ontologies that are
not immediately apparent. To help the user
create more accurate ontology-mapping
rules, the similarity extraction phase applies
heuristic algorithms and machine learning
techniques.10 It produces a similarity matrix
reflecting the similarities between concepts
and instances in ontologies being mapped.
Semantic mapping
This step creates the mappings that define
how to transform source-ontology instances
into target-ontology instances. These map-
pings are represented as instances of a map-
ping ontology, which defines all possible
types of associations between ontology enti-
ties. We can distinguish the mappings
according to
• Type of related entities. Mapping rules can
be established between concepts, attrib-
utes, and relations.
• Cardinality. Mapping rules can have 1:1,
1:n, or n:1 cardinality. We deliberately
omit the n:m case, because we can always
represent this case as n 1:m rules.
• Condition. Mapping rules can include con-
ditions on the instances being transformed.
• Transformation function. A mapping rule
can include a transformation function that,
when applied to the source information in
the source ontology, will produce the
required information in the target ontology.
For example, to map documents to research
papers, we must instantiate a mapping with
1:1 cardinality between Document and
Research Paper concepts, with the condition
that the Document concept must have a
research-topic property instantiated.
Execution
Execution takes as input instances of the
source ontology and the mapping ontology
from the previous step and executes the map-

4 computer.org/intelligent IEEE INTELLIGENT SYSTEMS


Discovery Representation
Figure 3. Ontology evolution.
pings. Two execution modes are provided:
static and virtual. The static-execution mode
transforms the source ontology’s instances
once and then stores them in the associated
knowledge management system—changes
to instances in the source ontology are not
visible in the mapped ontology.
In the virtual-execution mode, the map-
ping-ontology instance transforms every
query from the target ontology into a query
over the source ontology. The system then
executes the transformed query and trans-
forms the obtained information back into the
target ontology. With this approach, changes
to the source ontology’s instances are imme-
diately visible in the target ontology. How-
ever, because the system performs a trans-
formation at each request, performance is
worse than in the static case.
Postprocessing
Postprocessing applies only to static exe-
cution, where the goal is to improve the
results of the execution phase. For example,
it deals with the problem of object identity
(identifying, for example, that “A. Maedche”
and “Alexander Mädche” are the same per-
son). For virtual execution, this phase is not
applicable for two main reasons. First, the
system performs the execution only on small
subsets of information, so it is not possible
to apply complex algorithms that require
access to entire source and target ontologies.
Second, the virtual mapping’s performance is
already critical, and introducing another
phase would further aggravate it.
Managing evolving ontologies
Knowledge management systems gener-
ally are not developed to remain stable.
Rather, several factors make them subject to
continual change.
First, the environment in which the knowl-
edge management systems operate can
change unpredictably, thereby invalidating
MARCH/APRIL 2003
Semantics
Propagation
of change
assumptions made when the system was built.
For example, acquiring a new subsidiary in
an enterprise adds new business areas and
functionalities to the existing system.
Knowledge management systems
generally are not developed to
remain stable. Rather, several
factors make them subject to
continual change.
Second, user requirements often change
after the system has been built, warranting
system adaptation. For example, hiring new
employees might lead to new competencies
and greater diversity in the enterprise, which
the system must reflect.
Third, some changes in the domain are
implicit and can be discovered only by ana-
lyzing user interaction with the system. For
example, let’s say many users are interested
in two topics in conjunction (for example,
“debugging” and “Java”) and no knowledge
resource matches this criterion. In this case,
an efficient knowledge management system
should signal that it needs a knowledge
resource about the combination of these top-
ics (for example, a document on how to
debug Java code).
Ad hoc management of the changes in
knowledge management systems might work
in the short term, but to avoid unnecessary
complexity and failures in the long run, man-
agement must be interpreted at the concep-
tual level. Therefore, we can identify two
computer.org/intelligent
Implementation Validation
Core component
types of change generation in OKMSs.11 In
top-down change generation, the knowledge
officer or end user explicitly defines the
requirements for ontology changes. These
changes cover business strategy evolution,
modification in the application domain, new
user needs, additional functionality, and so
forth and are captured in a variety of ways:
direct discussion or interviews, customer
specifications, surveys, or observations. Alter-
natively, some changes might be discovered
by analyzing log files that track interaction of
users with the system, which is known as bot-
tom-up change generation.
We might also view the processing of
these changes as ontology evolution, which
we can define as timely adaptation of the
ontology to changing requirements and the
consistent propagation of changes to the
dependent artifiacts. Modifying one part of
the ontology might generate subtle inconsis-
tencies in other parts of the same ontology,
in the instances, dependent ontologies, and
applications. For example, Michel Klein and
his colleagues12 discuss this variety of causes
and consequences of the ontology changes.
So, we observe that ontology evolution is a
complex operation that should be realized as
an organizational process (see Figure 3). Fur-
thermore, ontology evolution is clearly dis-
tinguished from the problem of schema evo-
lution in relational databases, which has
already been extensively studied.13,14 For
example, Natalya Noy and her colleagues
have discussed these differences and identi-
fied that they stem from different knowledge
models and usage paradigms of ontologies,
contrary to relational databases.15
Our ontology-evolution process comprises
the following six phases.
Representation
To resolve changes, we must identify and
represent them in a suitable format. Elemen-
tary changes in the ontology (such as adding
5
I n t e l l i g e n t I n f o r m a t i o n
a concept, removing a property, or setting a
property range) are derived from our con-
ceptual model. However, this granularity of
ontology changes is not always appropriate.
Often, the intent of a change might be better
expressed at a higher level.
For example, the user might need to move
a concept form one parent to another. He or
she might bring the ontology into the desired
state through a successive application of a
list of elementary evolution changes (such as
“remove subConceptOf” and “add subCon-
ceptOf” elementary changes). However, the
system might perform unnecessary changes
if it applies each change alone. To avoid that
drawback, it should be able to express
changes on a coarser level, with the intent of
making a change directly visible. So, we
introduce composite changes (such as “move
concept”) representing a group of elemen-
tary changes applied together.
Semantics of change
Changing an ontology can induce incon-
sistencies in other parts of the ontology.
Semantic inconsistency arises if an ontology
entity’s meaning changes. Syntactic incon-
sistency arises if undefined entities are used
at the ontology or instance level or ontology
model constraints are invalidated. For exam-
ple, removing a concept that is the only ele-
ment of a domain set for some property
results in syntactic inconsistency. We can
resolve that problem by requesting a new
change in the ontology, which can induce
new problems that cause new changes and so
on. If an ontology is large, fully compre-
hending each induced change’s extent and
meaning might be difficult.
The semantics-of-change phase aims to
resolve induced changes systematically,
ensuring the consistency of the whole ontol-
ogy. To help in better understanding the effects
of each, this phase should contribute to the
maximum transparency, providing detailed
insight into each change. For each change in
the ontology, it is possible to generate a set of
additional changes, leading to different final
consistent states. Evolution strategies are
mechanisms used in this phase that let users
customize ontology evolution according to
their needs.11 Consequently, users can trans-
fer the ontology in the desired consistent state.
Propagation
This phase should automatically bring all
dependent elements to a consistent state after
the system has updated the ontology.
6 computer.org/intelligent
P r o c e s s i n g
When a user modifies the ontology, ontol-
ogy instances must change to preserve con-
sistency with the ontology. An ontology
update might also corrupt ontologies that
depend on the modified ontology and, con-
sequently, all artifacts based on these ontolo-
gies. We can solve this problem recursively
by applying ontology evolution process to
these ontologies. However, apart from syn-
tax inconsistency, semantic inconsistency
can also arise when, for example, the depen-
dent ontology already contains a concept that
is added to the original ontology.
When an ontology changes, applications
based on the changed ontology might not
work correctly anymore. An ontology evo-
lution approach must recognize which
Changing an ontology can induce
inconsistencies in other parts of
the ontology. Semantic
inconsistency arises if an ontology
entity’s meaning changes.
change in the ontology can affect the func-
tionality of dependent applications and react
correspondingly.
Implementation
To avoid performing undesired changes,
before the system applies a change to the
ontology, it should generate and present to
the user a list of all implications affecting the
ontology. The user should be able to com-
prehend the list and approve or cancel the
changes. Once approved, the system could
perform changes by successively resolving
changes from the list. Because it is necessary
to perform several changes together, they
must be performed within a transaction. If
the user cancels the changes, the ontology
should remain intact.
Validation
When working on an ontology collabora-
tively, different parties might have different
ideas about how to change it. Furthermore,
one party might fail to understand the effect
of some change and thus approve a change
that shouldn’t be performed. Moreover,
changing the ontology for experimental pur-
poses might be desirable. To enable recover-
ing from these situations, we introduce the
validation phase. Validation concerns an
ontology’s truthfulness regarding its prob-
lem domain—does the ontology correctly
represent reality and user requirements? It
lets the user acknowledge performed changes
and request that they be undone.
Reversibility means undoing a change’s
effects, which might not be the same as sim-
ply requesting an inverse change manually.
For example, if a user deletes a concept from
a concept hierarchy, the subconcepts will
either need to be deleted as well or attached
to the root concept or the deleted concept’s
parent. Reversing such a change is not equal
to recreating the deleted concept—we also
need to revert the concept hierarchy to the
original state. Creating evolution logs typi-
cally solves the problem of reversibility. An
evolution log tracks information about each
change, allowing the reconstruction of the
sequence of changes leading to the ontol-
ogy’s original state.
Discovery
The validation phase results in an ontol-
ogy that, although consistent, either might
contain redundant entities or could be better
structured with respect to the domain. For
example, multiple users might work on dif-
ferent parts of an ontology without enough
communication. They could delete subcon-
cepts of some concept at different times to
fulfill their immediate needs. Thus, it is pos-
sible that only one subconcept might remain.
Because classification with only one subclass
violates the classification’s original purpose,
we consider such an ontology to have a sub-
optimal structure. To help users detect such
situations, we investigated applying self-
adaptive-system principles and proactively
making suggestions for ontology refine-
ments—changes to the ontology with the
goal of improving it. This would make mak-
ing the ontology easier to understand and
cheaper to modify. We have identified three
ways to discover changes.
Structure-driven change discovery exploits
a set of heuristics to improve an ontology on
the basis of the analysis of the ontology’s
structure. For example, if all subconcepts
have the same property, the property may be
moved to the parent concept.
Data-driven change discovery detects the
IEEE INTELLIGENT SYSTEMS
changes induced through the analysis of exist-
ing instances. For example, if no instance of
concept C uses any of the properties defined
for C but only properties inherited from the
parent concept, we can assume that C is not
necessary.
Usage-driven change discovery considers
the ontology’s use in the knowledge man-
agement system. It is based on analyzing the
users’ behavior in two phases of a knowledge
management cycle. First, it provides knowl-
edge by analyzing the annotations’ quality.
Second, it searches for knowledge by ana-
lyzing the users’ queries and the responses
from the knowledge repository. For exam-
ple, by tracking when a query last retrieved
the concept, we might be able to discover that
some concepts are out of date and should be
deleted or updated.
KAON—The Karlsruhe ontology
and Semantic Web framework
We based the Ontologging OKMS’s core
ontology-management component—the
ontology server—on the Karlsruhe ontology
and Semantic Web framework (http://kaon.
semanticweb.org). KAON is an open-source
ontology-management infrastructure tar-
geted for semantics-driven business applica-
tions, developed and maintained at the FZI
(Research Center for Information Technolo-
gies) and AIFB (Institute of Applied Infor-
matics and Formal Description Methods) at
the University of Karlsruhe. It includes a
comprehensive tool suite allowing easy ontol-
ogy management and application. KAON
focuses on integrating traditional technolo-
gies for ontology management and applica-
tion with those typically used in business
applications, such as relational databases. It is
based on an ontology model,4 derived as an
extension of RDF Schema, with some pro-
prietary extensions (such as inverse, sym-
metric, and transitive relations), cardinalities,
modularization, metamodeling, and repre-
sentation of lexical information. Figure 4 pre-
sents the KAON architecture.
The KAON architecture’s core is its ontol-
ogy API (KAON API), consisting of a set of
interfaces for access to ontology entities. For
example, there are Concept, Property, and
Instance interfaces, which contain methods
for accessing ontology concepts, properties,
and instances, respectively. The API incor-
porates other elements required for ontology
management:
• The evolution strategy ensures that all
MARCH/APRIL 2003
User interface
Ontology-interface KAON portal
Modeler
KAON API
Evolution Change Concurrency
strategy reversibility conflict detection
RDF-based
access
Back-end
File-based RDF server
RDF
sources
Figure 4. The Karlsruhe ontology’s architecture.
changes applied to the ontology leave the
ontology in a consistent state and prevents
illegal changes.
• Change reversibility tracks ontology
changes in an evolution log so that the sys-
tem can reverse them at a user’s request.
The evolution log is based on the evolu-
tion ontology (http://kaon.semanticweb.
org/ontos/evolution.kaon) that models
what happens and by whom, and why,
when, and how it happens.
• Concurrency conflict detection detects and
resolves conflicts resulting in concurrent
updates from different users. For example,
if one user updates the ontology, then the
system must notify the update’s other
active users. Alternatively, if a user
attempts to update the ontology using stale
information, the system must detect the
conflict. To achieve atomicity, the system
performs all updates within a transaction.
• Optimized loading loads and transports
several ontology entities to the client in
one request, thus significantly improving
system performance.
• Query answering locates the ontology’s
elements according to given criteria and is
the key to providing scalable systems.
KAON API has several implementations,
each using a different back end for informa-
tion storage. One implementation of the
KAON API is based on the RDF API and
thus allows access to RDF repositories.
Although it offers capabilities for accessing
remote RDF repositories, such as RDF
Server, it primarily manages local RDF
ontologies stored as files.
computer.org/intelligent
Optimized Query
loading answering
Engineering Legacy Mapping
server server engine
Relational databases
The Engineering Server implementation
uses relational databases for ontology per-
sistence. We call it the Engineering Server
because the server is optimized for ontology
engineering, where creating and deleting
concepts are common. So, the Engineering
Server has a fixed number of tables in the
schema, rather than allocating one table per
concept for storing the concept’s extension.
We have heavily optimized and tested the
server on an ontology consisting of 100,000
concepts, 66,000 properties, and 1,000,000
instances, where loading related information
about 20 ontology entities takes less than 3
seconds, while deleting a concept in the mid-
dle of the concept hierarchy takes less than 5
seconds. It works on a typical single-proces-
sor desktop computer running Windows XP
with 256 Mbytes of RAM.
The Legacy Server implementation lets us
lift existing relational databases to the ontol-
ogy level. To do so, tables in the database
must be mapped to concepts and relation-
ships in the ontology. Based on these map-
pings, the system must modify all operations
on the KAON API according to these map-
pings into appropriate database operations.
The virtual mapping engine is an imple-
mentation realizing a virtual ontology mapped
from some source ontology. It transforms
queries into the mapped ontology using an
instance of the mapping ontology (see http://
kaon.semanticweb.org/ontos/mapping.kaon).
Various applications have been realized on
top of the KAON API. Within Ontologging,
the KAON portal presents and browses
ontologies on the Web. The OI Modeler real-
izes a graph-based user interface for ontol-
7
I n t e l l i g e n t I n f o r m a t i o n
Figure 5. Ontology evolution in the OI modeler.
ogy creation and evolution. Figure 5 shows
how we’ve implemented ontology evolution
at the user level. The figure shows a modeling
session where the user attempted to remove
the Person concept. Before applying this
change to the ontology, the system computes
the set of additional changes that must be
applied to keep the consistency. It presented
the tree of dependent changes to the user, thus
letting the user comprehend the change’s
effects before applying it. Only when the user
agrees will the system apply the changes.
I n the future, we plan to evaluate more for-
mally the expressiveness of our mapping
rules and identify which classes of mapping
problems we can solve using our approach.
Furthermore, we plan to extend our approach
for ontology evolution to not only compute
the necessary changes realizing user’s
requirements but to also realize secondary
goals, such as minimizing the total number of
changes in the ontology. In such a way we
hope to provide an easier way for the user to
specify and execute composite changes.
In the scope of the Ontologging project,
our main goal is to evaluate our system’s
8 computer.org/intelligent
P r o c e s s i n g
practicality by applying it to project man-
agement. From that we hope to elicit the
technical requirements that are crucial for
successfully applying ontologies in knowl-
edge management.
Acknowledgments
We thank our colleagues and students at the FZI
(Research Center for Information Technologies)
and AIFB (Institute of Applied Informatics and
Formal Description Methods) at the University of
Karlsruhe. This research has profited from fruit-
ful discussions with our Ontologging project part-
ners: Archetypon (Greece), Deltatec (Belgium),
Indra (Spain), Insead (France), and Meta4 (Spain).
The European Commission partially financed our
research through the IST-2000-28293 Ontologging
and IST-2001-33052 WonderWeb projects.
References
1. A. Abecker et al., “Toward a Technology for
Organizational Memories,” IEEE Intelligent
Systems, vol. 13, no. 3, May/June 1998, pp.
40–48.
2. F. Gandon et al., “Semantic Web and Multi-
Agents Approach to Corporate Memory Man-
agement,” 17th IFIP World Computer Con-
gress, IIP Track—Intelligent Information
Processing, Kluwer Academic Publishers,
2002, pp. 103–115.
3. S. Staab et al., “Knowledge Processes and
Ontologies,” IEEE Intelligent Systems, vol.
16, no. 1, Jan./Feb. 2001, pp. 26–34.
4. B. Motik, A. Maedche, and R. Volz, “A Con-
ceptual Modeling Approach for Building
Semantics-Driven Enterprise Applications,”
Proc. 1st Int’l Conf. Ontologies, Databases,
and Application of Semantics (ODBASE-
2002), Springer-Verlag, 2002, pp. 1082–1099.
5. M.T. Roth and P. Schwarz, “Don’t Scrap It,
Wrap It! A Wrapper Architecture for Legacy
Data Sources,” Proc. 23rd Int’l Conf. Very
Large Databases, Morgan Kaufmann, 1997,
pp. 266–275.
6. G. Wiederhold, “Mediators in the Architec-
ture of Future Information Systems,” Com-
puter, vol. 25, no. 3, Mar. 1002, pp. 38–49.
7. H. Garcia-Molina et al., “The TSIMMIS
Approach to Mediation: Data Models and Lan-
guages,” J. Intelligent Information Systems,
vol. 8, no. 2, Mar./Apr. 1997, pp. 117–132.
8. A.Y. Levy, A. Rajaraman, and J.J. Ordille,
“Querying Heterogeneous Information
Sources Using Source Descriptions,” Proc.
23rd Int’l Conf. Very Large Databases, Mor-
gan Kaufman, 1996, pp. 251–262.
9. A. Maedche et al., “MAFRA—Mapping Dis-
tributed Ontologies in the Semantic Web,”
Proc. 13th European Conf. Knowledge Eng.
and Management (EKAW 2002), Springer-
Verlag, 2002, pp. 235–250.
IEEE INTELLIGENT SYSTEMS
10. A. Doan et al., “Learning to Map between
Ontologies on the Semantic Web,” Proc. World-
Wide Web Conf.,ACM Press, 2002, pp. 662–673.
11. L. Stojanovic et al., “User-Driven Ontology
Evolution Management,” Proc. 13th Euro-
pean Conf. Knowledge Eng. and Management
(EKAW 2002), Springer-Verlag, 2002, pp.
285–300.
12. M. Klein et al., “Ontology Versioning and
Change Detection on the Web,” Proc. 13th
European Conf. Knowledge Eng. and Man-
agement (EKAW 2002), Springer-Verlag,
2002, pp. 197–212.
13. E. Franconi, F. Grandi, and F. Mandreoli, “A
Semantic Approach for Schema Evolution
and Versioning in Object-Oriented Data-
bases,” Proc. 1st Int’l Conf. Computational
Logic (CL 2000), LNCS 1861, Springer-Ver-
lag, 2000, pp. 1048–1062.
14. J.F. Roddick, “A Survey of Schema Version-
ing Issues for Database Systems,” Informa-
tion and Software Technology, vol. 37, no. 7,
July 1995, pp. 383–393.
15. N.F. Noy and M. Klein, Ontology Evolution:
Not the Same as Schema Evolution, tech.
report SMI-2002-0926, Stanford Medical
Informatics, Stanford Univ., 2002.
For more on this or any other computing topic,
see our Digital Library at http://computer.org/
publications/dlib.

T h e A u t h o r s
Alexander Maedche is department manager of the Knowledge Management
Research department at the FZI (Research Center for Information Technologies),
University of Karlsruhe. His research interests cover knowledge discovery in data
and text, ontology management and learning, and using ontologies in enterprise
applications and the Semantic Web. He received a Diploma in industrial engi-
neering and his PhD in applied informatics, both from the University of Karl-
A vertical
sruhe. He is a member of the IEEE and Gesellschaft für Infomatik. Contact him
at the FZI Research Center for Information Technology, Univ. of Karlsruhe, Haid-
fill here
und-Neu-Str. 10-14, 76131 Karlsruhe, Germany; maedche@fzi.de.

Boris Motik is a research assistant in the Knowledge Management Research

department at the FZI (Research Center for Information Technologies), Uni-
versity of Karlsruhe. His research interests include conceptual modeling lan-
guages, querying of conceptual models, and model mappings in the context
of enterprise applications. He received his BS in electrical engineering and
MS in computer science, both from the University of Zagreb. Contact him at
the FZI Research Center for Information Technology, Univ. of Karlsruhe,
Haid-und-Neu-Str. 10-14, 76131 Karlsruhe, Germany; boris.motik@fzi.de.

Ljiljana Stojanovic is a research assistant in the Knowledge Management

Research department at the FZI (Research Center for Information Technologies),
University of Karlsruhe. Her research interests include ontology development,
evolution, and evaluation, and using ontologies for the continual improvement of
knowledge management systems. She received her BS in electrical engineering
and MS in computer science from the University of Nis. Contact her at the FZI
Research Center for Information Technology, Univ. of Karlsruhe, Haid-und-Neu-
Str. 10-14, 76131 Karlsruhe, Germany; ljiljana.stojanovic@fzi.de.

Rudi Studer ’s biography appears in the Guest Editors’ Introduction on page

XXXX.

Raphael Volz is a research assistant at the University of Karlsruhe’s Institute

of Applied Informatics and Formal Description Methods. His current research
interest is the intersection of traditional database theory and Semantic Web
technologies, and he is involved in several international Semantic Web research
projects. He is also active in W3C efforts on the standardization for a Web
ontology language. He studied informatics and life sciences at the University
of Heidelberg and at the University of Karlsruhe. Contact him at Institute
AIFB, Univ. of Karlsruhe, 76128 Karlsruhe, Englerstr. 11, 76128 Karlsruhe,
Germany; volz@aifb.uni-karlsruhe.de; www.aifb.uni-karlsruhe.de/WBS/rvo.

MARCH/APRIL 2003 computer.org/intelligent 9