ieee-is-maedcheetal

8/7/2019 ieee-is-maedcheetal

1/8

2 1094-7167/03/$17.00 2003 IEEE IEEE INTELLIGENT SYSTEMSPublished by the IEEE Computer Society

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

Ontologies for

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

Ontologies 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 ande-business applications. Next-generation knowledgemanagement systems will likely rely on conceptualmodels in the form of ontologies to precisely definethe meaning of various symbols. For example,FRODO (a Framework for Distributed Organiza-tional Memories) uses ontologies for knowledgedescription in organizational memories, 1 CoMMA(Corporate Memory Management through Agents)investigates agent technologies for maintainingontology-based knowledge management systems, 2

and Steffen Staab and his colleagues have discussedthe methodologies and processes for building ontol-ogy-based systems. 3

Here we present an integrated enterprise-knowl-edge management architecture for implementing anontology-based knowledge management system(OKMS). We focus on two critical issues related toworking with ontologies in real-world enterpriseapplications. First, we realize that imposing a singleontology on the enterprise is difficult if not impossi-ble. Because organizations must devise multipleontologies and thus require integration mechanisms,we consider means for combining distributed and het-erogeneous ontologies using mappings. Additionally,a systems ontology often must reflect changes in sys-tem requirements and focus, so we developed guide-lines and an approach for managing the difficult andcomplex ontology-evolution process.

Bringing ontologies to real-worldenterprise 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 asscalability, persistency, reliability, and transactionsstandardized and widely adopted in classical data-base-driven information systems are typically notavailable in ontology-based systems. So, usingrequirements analysis from several applications, werecently developed a conceptual-modeling approach 4

suitable for business-wide applications. Our designgoals were to express and access ontology-basedconceptual models in a natural and easily under-standable way, with a small gap between the modelconceptualization and its implementation. At thesame time, we wanted to realize an enterprise-wideontology-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 knowledgemanagement system for example, in other applica-tions such as groupware,databases, and file systems.To reuse information from these sources, we mustintegrate the sources and the OKMS, which typicallyinvolves creating wrappers that lift these sourcescon-tent to the ontology level not an easy task. 5

Third, providing metadata is a time-consumingand difficult process that users tend to avoid. So, wemust develop ways to easily assign fine-grainedmetadata (based on ontologies) to the differentresources available in the enterprise. This wouldrequire enhancing tools used daily (such as textprocessors) so that they could extract as much meta-data as possible semiautomatically.

Several challenges

exist related to

applying ontologiesin real-world

environments. The

authors present an

integrated enterprise-

knowledge

management

architecture, focusing

on how to support

multiple ontologies

and manage ontology

evolution.


2/8


3/8

The main technical challenge in buildingmediators is query rewriting the mediatormust rewrite a query expressed over elementsof ontologies of each source. After thesources answer the rewritten queries, themediator integrates their responses. Method-ological aspects of ontology integrationrelate primarily to how correspondencebetween source ontologies and the integratedontology is established. The global-as-viewapproach, applied within the TSIMMIS sys-tem, 7 creates the integrated ontology as aview over individual sources. The drawback is that, for n sources, the integrated ontologymight need to express n2 interactionsbetween source ontologies. Anotherapproach is the local-as-view approach,applied in the Information Manifold system, 8

which specifies each source as a query intothe integrated ontology. In this case, writingonly one query for each source ontology issufficient.

The rest of this section focuses on ontol-ogy mapping, which can transform informa-tion but doesnt require building an inte-grated view. So, although its more powerfulthan simple inclusion, it avoids the com-plexity and overhead of integrating multiplesources. For example, lets assume that boththe sales and research departments manageinformation about documents and theirauthors. However, because these departmentsapproach the domain from different stand-points, the ontologies for these two systems

do not match. The research department willhave a fine classification of documents,withresearch papers explicitly classified asinstances of the Research Paper concept.However, the sales department might clas-sify all papers as Documents.

At some point, the research departmentmight want to include information from thesales department in their knowledge manage-ment system. To facilitate this, the informa-tion must be transformed (some Documentsmight need to be reclassified as ResearchPapers), so simple inclusion of instances fromthe sales department will not suffice. On theother hand, building an integrated view of bothsystems is certainly more difficult than pro-viding a unidirectional mapping. In this exam-ple, you need only provide a set of mappingrules. The rules should ensure that whensomeone queries the target ontology forinstances of the Research Paper concept, theresult includes all instances of the Documentconcept from the sales department system thathave a research-topic property instantiated andthus classify as research papers.

We use a five-step process (see Figure 2)to address methodological issues in ontologymapping. 9

Lift and normalizationThe first step addresses bringing existing

information to the ontology level. It extendsthe ontology-mapping problem somewhat tothe problem of integrating existing informa-

tion sources that are not ontology based. Inaddition, it must realize a wrapper for the infor-mation source at hand, whose task is to trans-form the desired information source to theontology level. If the source information is

already ontology based,you can skip this step.

Similarity extractionExtracting ontology mapping rules is typ-

ically difficult. Ontologies being mapped areoften very large, so establishing correspon-dences is not easy. By analyzing the ontol-ogy and its associated instances, we can spotcorrespondences between ontologies that arenot immediately apparent. To help the usercreate more accurate ontology-mappingrules, the similarity extraction phase appliesheuristic algorithms and machine learning

techniques.10

It produces a similarity matrixreflecting the similarities between conceptsand instances in ontologies being mapped.

Semantic mappingThis step creates the mappings that define

how to transform source-ontology instancesinto target-ontology instances. These map-pings are represented as instances of a map-ping ontology, which defines all possibletypes of associations between ontology enti-ties. We can distinguish the mappingsaccording to

Type of related entities . Mapping rules canbe established between concepts, attrib-utes, and relations.

Cardinality . Mapping rules can have 1:1,1:n , or n:1 cardinality. We deliberatelyomit the n:m case, because we can alwaysrepresent this case as n 1:m rules.

Condition . Mapping rules can include con-ditions on the instances being transformed.

Transformation function. A mapping rulecan include a transformation function that,when applied to the source information inthe source ontology, will produce therequired information in the target ontology.

For example,to map documents to researchpapers, we must instantiate a mapping with1:1 cardinality between Document andResearch Paper concepts, with the conditionthat the Document concept must have aresearch-topic property instantiated.

ExecutionExecution takes as input instances of the

source ontology and the mapping ontologyfrom the previous step and executes the map-

4 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

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

Postprocessing

Execution

Semantic mapping

Lift and normalization

Information source

Mapping ontologyinstance

Mapped targetontology instances

Source ontologyinstances

Source ontology

Instance similaritymatrix

Similarity extraction

Database Target ontology

Figure 2. The ontology-mapping process.


4/8

pings. Two execution modes are provided:static and virtual. The static-execution modetransforms the source ontologys instancesonce and then stores them in the associatedknowledge management system changes

to instances in the source ontology are notvisible in the mapped ontology.In the virtual-execution mode, the map-

ping-ontology instance transforms everyquery from the target ontology into a queryover the source ontology. The system thenexecutes the transformed query and trans-forms the obtained information back into thetarget ontology. With this approach, changesto the source ontologys instances are imme-diately visible in the target ontology. How-ever, because the system performs a trans-formation at each request, performance isworse than in the static case.

PostprocessingPostprocessing applies only to static exe-

cution, where the goal is to improve theresults of the execution phase. For example,it deals with the problem of object identity(identifying, for example, that A. Maedcheand Alexander Mdche are the same per-son). For virtual execution, this phase is notapplicable for two main reasons. First, thesystem performs the execution only on smallsubsets of information, so it is not possibleto apply complex algorithms that requireaccess to entire source and target ontologies.Second, the virtual mappings performance isalready critical, and introducing anotherphase would further aggravate it.

Managing evolving ontologiesKnowledge management systems gener-

ally are not developed to remain stable.Rather, several factors make them subject tocontinual change.

First, the environment in which the knowl-edge management systems operate canchange unpredictably, thereby invalidating

assumptions made when the system was built.For example, acquiring a new subsidiary inan enterprise adds new business areas andfunctionalities to the existing system.

Second, user requirements often changeafter the system has been built, warrantingsystem adaptation. For example, hiring newemployees might lead to new competenciesand greater diversity in the enterprise,whichthe system must reflect.

Third, some changes in the domain areimplicit and can be discovered only by ana-lyzing user interaction with the system. Forexample, lets say many users are interestedin two topics in conjunction (for example,debugging and Java) and no knowledgeresource matches this criterion. In this case,an efficient knowledge management systemshould signal that it needs a knowledgeresource about the combination of these top-ics (for example, a document on how todebug Java code).

Ad hoc management of the changes inknowledge management systems might work in the short term, but to avoid unnecessarycomplexity and failures in the long run, man-agement must be interpreted at the concep-tual level. Therefore, we can identify two

types of change generation in OKMSs. 11 Intop-down change generation , the knowledgeofficer or end user explicitly defines therequirements for ontology changes. Thesechanges cover business strategy evolution,

modification in the application domain, newuser needs, additional functionality, and soforth and are captured in a variety of ways:direct discussion or interviews, customerspecifications, surveys, or observations. Alter-natively, some changes might be discoveredby 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, whichwe can define as timely adaptation of theontology to changing requirements and theconsistent propagation of changes to thedependent artifiacts. Modifying one part of the ontology might generate subtle inconsis-tencies in other parts of the same ontology,in the instances, dependent ontologies, andapplications. For example, Michel Klein andhis colleagues 12 discuss this variety of causesand consequences of the ontology changes.So, we observe that ontology evolution is acomplex operation that should be realized asan organizational process (see Figure 3). Fur-thermore, ontology evolution is clearly dis-tinguished from the problem of schema evo-lution in relational databases, which hasalready been extensively studied. 13,14 Forexample, Natalya Noy and her colleagueshave discussed these differences and identi-fied that they stem from different knowledgemodels and usage paradigms of ontologies,contrary to relational databases. 15

Our ontology-evolution process comprisesthe following six phases.

RepresentationTo resolve changes, we must identify and

represent them in a suitable format. Elemen-tary changes in the ontology (such as adding

MARCH/APRIL 2003 computer.org/intelligent 5

Semanticsof change ImplementationRepresentation Propagation

Core component

ValidationDiscovery

Figure 3. Ontology evolution.

Knowledge management systemsgenerally are not developed toremain stable. Rather, severalfactors make them subject tocontinual change.


5/8

a concept, removing a property, or setting aproperty 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 movea concept form one parent to another. He orshe might bring the ontology into the desiredstate through a successive application of alist of elementary evolution changes (such asremove subConceptOf and add subCon-ceptOf elementary changes). However, thesystem might perform unnecessary changesif it applies each change alone. To avoid thatdrawback, it should be able to expresschanges on a coarser level, with the intent of making a change directly visible. So, we

introduce composite changes (such as moveconcept) representing a group of elemen-tary changes applied together.

Semantics of changeChanging an ontology can induce incon-

sistencies in other parts of the ontology.Semantic inconsistency arises if an ontologyentitys meaning changes. Syntactic incon-sistency arises if undefined entities are usedat the ontology or instance level or ontologymodel constraints are invalidated. For exam-ple, removing a concept that is the only ele-ment of a domain set for some propertyresults in syntactic inconsistency. We canresolve that problem by requesting a newchange in the ontology, which can inducenew problems that cause new changes and soon. If an ontology is large, fully compre-hending each induced changes extent andmeaning might be difficult.

The semantics-of-change phase aims toresolve induced changes systematically,ensuring the consistency of the whole ontol-ogy. To help in better understanding the effectsof each, this phase should contribute to themaximum transparency, providing detailedinsight into each change. For each change inthe ontology, it is possible to generate a set of additional changes, leading to different finalconsistent states. Evolution strategies aremechanisms used in this phase that let userscustomize ontology evolution according totheir needs. 11 Consequently, users can trans-fer the ontology in the desired consistent state.

PropagationThis phase should automatically bring all

dependent elements to a consistent state afterthe system has updated the ontology.

When a user modifies the ontology, ontol-ogy instances must change to preserve con-sistency with the ontology. An ontologyupdate might also corrupt ontologies thatdepend on the modified ontology and, con-

sequently, all artifacts based on these ontolo-gies. We can solve this problem recursivelyby applying ontology evolution process tothese ontologies. However, apart from syn-tax inconsistency, semantic inconsistencycan also arise when, for example, the depen-dent ontology already contains a concept thatis added to the original ontology.

When an ontology changes, applicationsbased on the changed ontology might notwork correctly anymore. An ontology evo-lution approach must recognize which

change in the ontology can affect the func-tionality of dependent applications and reactcorrespondingly.

ImplementationTo avoid performing undesired changes,

before the system applies a change to theontology, it should generate and present tothe user a list of all implications affecting theontology. The user should be able to com-prehend the list and approve or cancel thechanges. Once approved, the system couldperform changes by successively resolvingchanges from the list. Because it is necessaryto perform several changes together, theymust be performed within a transaction. If the user cancels the changes, the ontologyshould remain intact.

ValidationWhen working on an ontology collabora-

tively, different parties might have differentideas about how to change it. Furthermore,one party might fail to understand the effect

of some change and thus approve a changethat shouldnt 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 anontologys truthfulness regarding its prob-lem domain does the ontology correctlyrepresent reality and user requirements? Itlets the user acknowledge performed changesand request that they be undone.

Reversibility means undoing a changeseffects, which might not be the same as sim-ply requesting an inverse change manually.For example, if a user deletes a concept froma concept hierarchy, the subconcepts willeither need to be deleted as well or attachedto the root concept or the deleted concepts

parent. Reversing such a change is not equalto recreating the deleted concept we alsoneed to revert the concept hierarchy to theoriginal state. Creating evolution logs typi-cally solves the problem of reversibility. Anevolution log tracks information about eachchange, allowing the reconstruction of thesequence of changes leading to the ontol-ogys original state.

DiscoveryThe validation phase results in an ontol-

ogy that, although consistent, either mightcontain redundant entities or could be betterstructured with respect to the domain. Forexample, multiple users might work on dif-ferent parts of an ontology without enoughcommunication. They could delete subcon-cepts of some concept at different times tofulfill their immediate needs. Thus, it is pos-sible that only one subconcept might remain.Because classification with only one subclassviolates the classifications original purpose,we consider such an ontology to have a sub-optimal structure. To help users detect suchsituations, we investigated applying self-adaptive-system principles and proactivelymaking suggestions for ontology refine-ments changes to the ontology with thegoal of improving it. This would make mak-ing the ontology easier to understand andcheaper to modify. We have identified threeways to discover changes.

Structure-driven change discovery exploitsa set of heuristics to improve an ontology onthe basis of the analysis of the ontologysstructure. For example, if all subconceptshave the same property, the property may bemoved to the parent concept.

Data-driven change discovery detects the



Changing an ontology can induceinconsistencies in other parts of the ontology. Semanticinconsistency arises if an ontologyentitys meaning changes.


6/8

changes induced through the analysis of exist-ing instances. For example, if no instance of concept C uses any of the properties definedfor C but only properties inherited from theparent concept, we can assume that C is not

necessary.Usage-driven change discovery considersthe ontologys use in the knowledge man-agement system. It is based on analyzing theusersbehavior in two phases of a knowledgemanagement cycle. First, it provides knowl-edge by analyzing the annotations quality.Second, it searches for knowledge by ana-lyzing the users queries and the responsesfrom the knowledge repository. For exam-ple, by tracking when a query last retrievedthe concept, we might be able to discover thatsome concepts are out of date and should be

deleted or updated.

KAON The Karlsruhe ontology and Semantic Web framework

We based the Ontologging OKMSs coreontology-management component theontology server on the Karlsruhe ontologyand Semantic Web framework (http://kaon.semanticweb.org). KAON is an open-sourceontology-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) atthe University of Karlsruhe. It includes acomprehensive tool suite allowing easy ontol-ogy management and application. KAONfocuses on integrating traditional technolo-gies for ontology management and applica-tion with those typically used in businessapplications, such as relational databases. It isbased on an ontology model, 4 derived as anextension 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 architectures core is its ontol-ogy API (KAON API), consisting of a set of interfaces for access to ontology entities. Forexample, there are Concept, Property, andInstance interfaces, which contain methodsfor accessing ontology concepts, properties,and instances, respectively. The API incor-porates other elements required for ontologymanagement:

The evolution strategy ensures that all

changes applied to the ontology leave theontology in a consistent state and preventsillegal changes.

Change reversibility tracks ontologychanges in an evolution log so that the sys-tem can reverse them at a users request.The evolution log is based on the evolu-tion ontology (http://kaon.semanticweb.org/ontos/evolution.kaon) that modelswhat happens and by whom, and why,when, and how it happens.

Concurrency conflict detection detects andresolves conflicts resulting in concurrentupdates from different users. For example,if one user updates the ontology, then thesystem must notify the updates otheractive users. Alternatively, if a userattempts to update the ontology using staleinformation, the system must detect theconflict. To achieve atomicity, the systemperforms all updates within a transaction.

Optimized loading loads and transportsseveral ontology entities to the client inone request, thus significantly improvingsystem performance.

Query answering locates the ontologyselements according to given criteria and isthe key to providing scalable systems.

KAON API has several implementations,each using a different back end for informa-tion storage. One implementation of theKAON API is based on the RDF API andthus allows access to RDF repositories.Although it offers capabilities for accessingremote RDF repositories, such as RDFServer, it primarily manages local RDFontologies stored as files.

The Engineering Server implementationuses relational databases for ontology per-sistence. We call it the Engineering Serverbecause the server is optimized for ontologyengineering, where creating and deletingconcepts are common. So, the EngineeringServer has a fixed number of tables in theschema, rather than allocating one table perconcept for storing the concepts extension.We have heavily optimized and tested theserver on an ontology consisting of 100,000concepts, 66,000 properties, and 1,000,000instances,where loading related informationabout 20 ontology entities takes less than 3seconds, while deleting a concept in the mid-dle of the concept hierarchy takes less than 5seconds. It works on a typical single-proces-sor desktop computer running Windows XPwith 256 Mbytes of RAM.

The Legacy Server implementation lets uslift existing relational databases to the ontol-ogy level. To do so, tables in the databasemust be mapped to concepts and relation-ships in the ontology. Based on these map-pings, the system must modify all operationson the KAON API according to these map-pings into appropriate database operations.

The virtual mapping engine is an imple-mentation realizing a virtual ontology mappedfrom some source ontology. It transformsqueries into the mapped ontology using aninstance of the mapping ontology (see http:// kaon.semanticweb.org/ontos/mapping.kaon).

Various applications have been realized ontop of the KAON API. Within Ontologging,the KAON portal presents and browsesontologies on the Web. The OI Modeler real-izes a graph-based user interface for ontol-


Back-end

KAON API

Evolutionstrategy

Concurrencyconflict detection

RDF-basedaccess

Engineeringserver

Optimizedloading

RDF server

Relational databases

Mappingengine

Queryanswering

File-basedRDF

sources

Changereversibility

User interface

Ontology-interfaceModeler KAON portal

Legacyserver

Figure 4. The Karlsruhe ontologys architecture.


7/8

ogy creation and evolution. Figure 5 showshow weve implemented ontology evolutionat the user level. The figure shows a modelingsession where the user attempted to removethe Person concept. Before applying thischange to the ontology, the system computesthe set of additional changes that must beapplied to keep the consistency. It presentedthe tree of dependent changes to the user, thusletting the user comprehend the changeseffects before applying it. Only when the useragrees will the system apply the changes.

In the future, we plan to evaluate more for-mally the expressiveness of our mapping

rules and identify which classes of mappingproblems we can solve using our approach.Furthermore, we plan to extend our approachfor ontology evolution to not only computethe necessary changes realizing usersrequirements but to also realize secondarygoals, such as minimizing the total number of changes in the ontology. In such a way wehope to provide an easier way for the user tospecify and execute composite changes.

In the scope of the Ontologging project,our main goal is to evaluate our systems

practicality by applying it to project man-agement. From that we hope to elicit thetechnical requirements that are crucial forsuccessfully 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 andFormal 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 ourresearch through the IST-2000-28293 Ontologgingand IST-2001-33052 WonderWeb projects.

References1. A. Abecker et al., Toward a Technology for

Organizational Memories, IEEE Intelligent Systems , vol. 13, no. 3, May/June 1998, pp.4048.

2. F. Gandon et al., Semantic Web and Multi-Agents Approach to Corporate Memory Man-agement, 17 th IFIP World Computer Con-gress, IIP Track Intelligent InformationProcessing , Kluwer Academic Publishers,2002, pp. 103115.

3. S. Staab et al., Knowledge Processes andOntologies, IEEE Intelligent Systems , vol.16, no. 1, Jan./Feb. 2001, pp. 2634.

4. B. Motik,A. Maedche, and R. Volz, A Con-ceptual Modeling Approach for BuildingSemantics-Driven Enterprise Applications,Proc. 1st Intl Conf. Ontologies, Databases,and Application of Semantics (ODBASE-2002), Springer-Verlag, 2002, pp. 10821099.

5. M.T. Roth and P. Schwarz, Dont Scrap It,Wrap It! A Wrapper Architecture for LegacyData Sources, Proc. 23 rd Intl Conf. VeryLarge Databases , Morgan Kaufmann, 1997,pp. 266275.

6. G. Wiederhold, Mediators in the Architec-ture of Future Information Systems, Com-puter , vol. 25, no. 3, Mar. 1002, pp. 3849.

7. H. Garcia-Molina et al., The TSIMMISApproach to Mediation: Data Models and Lan-guages, J. Intelligent Information Systems ,vol. 8, no. 2, Mar./Apr. 1997, pp. 117132.

8. A.Y. Levy, A. Rajaraman, and J.J. Ordille,Querying Heterogeneous InformationSources Using Source Descriptions, Proc.23 rd Intl Conf. Very Large Databases , Mor-gan Kaufman, 1996, pp. 251262.

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. 235250.



Figure 5. Ontology evolution in the OI modeler.


8/8

10. A. Doan et al., Learning to Map betweenOntologies on the Semantic Web, Proc. World-Wide Web Conf. ,ACM Press,2002,pp. 662673.

11. L. Stojanovic et al., User-Driven OntologyEvolution Management, Proc. 13th Euro-pean Conf. Knowledge Eng. and Management

(EKAW 2002), Springer-Verlag, 2002, pp.285300.

12. M. Klein et al., Ontology Versioning andChange Detection on the Web, Proc. 13thEuropean Conf. Knowledge Eng. and Man-agement (EKAW 2002), Springer-Verlag,2002, pp. 197212.

13. E. Franconi, F. Grandi, and F. Mandreoli, ASemantic Approach for Schema Evolutionand Versioning in Object-Oriented Data-

bases, Proc. 1 st Intl Conf. ComputationalLogic (CL 2000),LNCS 1861,Springer-Ver-lag, 2000, pp. 10481062.

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. 383393.

15. N.F. Noy and M. Klein, Ontology Evolution:Not the Same as Schema Evolution , tech.report SMI-2002-0926, Stanford MedicalInformatics, 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 sAlexander Maedche is department manager of the Knowledge ManagementResearch department at the FZI (Research Center for Information Technologies),University of Karlsruhe. His research interests cover knowledge discovery in dataand text, ontology management and learning,and using ontologies in enterpriseapplications and the Semantic Web. He received a Diploma in industrial engi-neering and his PhD in applied informatics, both from the University of Karl-sruhe. He is a member of the IEEE and Gesellschaft fr Infomatik. Contact himat the FZI Research Center for Information Technology,Univ. of Karlsruhe,Haid-und-Neu-Str. 10-14, 76131 Karlsruhe, Germany; [email protected].

Boris Motik is a research assistant in the Knowledge Management Researchdepartment 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 andMS in computer science, both from the University of Zagreb. Contact him atthe FZI Research Center for Information Technology, Univ. of Karlsruhe,Haid-und-Neu-Str. 10-14, 76131 Karlsruhe, Germany; [email protected].

Ljiljana Stojanovic is a research assistant in the Knowledge ManagementResearch 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 engineeringand MS in computer science from the University of Nis. Contact her at the FZIResearch Center for Information Technology,Univ. of Karlsruhe, Haid-und-Neu-Str. 10-14, 76131 Karlsruhe, Germany; [email protected].

Rudi Studer s biography appears in the Guest EditorsIntroduction on pageXXXX.

Raphael Volz is a research assistant at the University of Karlsruhes Instituteof Applied Informatics and Formal Description Methods. His current researchinterest is the intersection of traditional database theory and Semantic Webtechnologies, and he is involved in several international Semantic Web researchprojects. He is also active in W3C efforts on the standardization for a Webontology language. He studied informatics and life sciences at the Universityof Heidelberg and at the University of Karlsruhe. Contact him at InstituteAIFB, Univ. of Karlsruhe, 76128 Karlsruhe, Englerstr. 11, 76128 Karlsruhe,Germany; [email protected]; www.aifb.uni-karlsruhe.de/WBS/rvo.

A verticalfill here