Ontologies are increasingly seen as a key technology for enabling semanticsdriven

Transcription

1 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 Ontologies are increasingly seen as a key technology for enabling semanticsdriven knowledge processing. Communities establish ontologies, or shared conceptual models, to provide a framework for sharing a precise meaning of symbols exchanged during communication. Many applications benefit from semantically enriched Several challenges exist related to applying ontologies in real-world environments. The authors present an integrated enterprise-knowledge management architecture, focusing on how to support multiple ontologies and manage ontology evolution. information, including knowledge management and e-business applications. Next-generation knowledge management systems will likely rely on conceptual models in the form of ontologies to precisely define the meaning of various symbols. For example, FRODO (a Framework for Distributed Organizational Memories) uses ontologies for knowledge description in organizational memories, 1 CoMMA (Corporate Memory Management through Agents) investigates agent technologies for maintaining ontology-based knowledge management systems, 2 and Steffen Staab and his colleagues have discussed the methodologies and processes for building ontology-based systems. 3 Here we present an integrated enterprise-knowledge management architecture for implementing an ontology-based knowledge management system (OKMS). We focus on two critical issues related to working with ontologies in real-world enterprise applications. First, we realize that imposing a single ontology on the enterprise is difficult if not impossible. Because organizations must devise multiple ontologies and thus require integration mechanisms, we consider means for combining distributed and heterogeneous ontologies using mappings. Additionally, a system s ontology often must reflect changes in system requirements and focus, so we developed guidelines and an approach for managing the difficult and 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 representation, engineering, and reasoning, features such as scalability, persistency, reliability, and transactions standardized and widely adopted in classical database-driven information systems are typically not available in ontology-based systems. So, using requirements analysis from several applications, we recently developed a conceptual-modeling approach 4 suitable for business-wide applications. Our design goals were to express and access ontology-based conceptual models in a natural and easily understandable 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 wellestablished technologies such as relational databases. Second, a large body of information in an enterprise typically already exists outside the knowledge management system for example, in other applications 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 content 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 metadata as possible semiautomatically /03/$ IEEE IEEE INTELLIGENT SYSTEMS Published by the IEEE Computer Society

2 Knowledge officers Core integration layer (including agents and intelligent services) Ontology API Development Ontology management GUI Ontology server Production Enterprise knowledge portal User profile API Database server 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 ( 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 traditional knowledge management systems. Important research challenges include scalability, managing multiple ontologies, ontology 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 management GUI provides the facilities that system 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 different knowledge management tools available for the end user. With the user-profile editor, users can express their interests in some part of the domain, which lets the system 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 coordinates the interaction of various system components. 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 information 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 document server stores the documents and provides mechanisms that let users concurrently access and modify them. However, the documents 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 makes it possible to define wrappers that lift the content of the different relevant, existing applications to the ontology level. For example, we have developed a wrapper for integrating Lotus Notes with the ontologies using a set of rules that the administrator 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 typically 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 difficult, 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 Front-end applications User profile editor Query, browsing, and editing Wrapper Relevant, existing applications Groupware Databases MS Office plugin Human resource applications Figure 1. The architecture of the Ontologging ontology-based knowledge management system. End users Document API Document server File system semantics of data more accurately, spotting correspondences between two ontologies is easier. We can generally consider the following three approaches for combining distributed, 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 entities, transforming instances from the source ontology into instances in the target ontology. The technical challenge is providing flexible mechanisms for information transformation while enabling desired characteristics such as scalability and flexibility. However, 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 ontology. A dedicated knowledge management system component a mediator 6 is typically introduced, whose main task is to answer queries, manages this integrated ontology. The main technical challenge in MARCH/APRIL 2003 computer.org/intelligent 27

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 Instance similarity matrix Postprocessing Execution Semantic mapping Similarity extraction Lift and normalization Mapped target ontology instances Source ontology Target ontology Information source Mapping ontology instance Source ontology instances 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 information sources that are not ontology based. In addition, it must realize a wrapper for the information source at hand, whose task is to transform the desired information source to the ontology level. If the source information is already ontology based, you can skip this step. Similarity extraction Extracting ontology mapping rules is typically difficult. Ontologies being mapped are often very large, so establishing correspondences is not easy. By analyzing the ontology 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. Figure 2. The ontology-mapping process. 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. Methodological 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 system, 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 n 2 interactions between source ontologies. Another approach is the local-asview 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 ontology mapping, which can transform information but doesn t require building an integrated view. So, although it s more powerful than simple inclusion, it avoids the complexity 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 standpoints, the ontologies for these two systems 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 classify all papers as Documents. At some point, the research department might want to include information from the sales department in their knowledge management system. To facilitate this, the information 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 providing a unidirectional mapping. In this example, 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 Semantic mapping This step creates the mappings that define how to transform source-ontology instances into target-ontology instances. These mappings are represented as instances of a mapping ontology, which defines all possible types of associations between ontology entities. We can distinguish the mappings according to Type of related entities. Mapping rules can be established between concepts, attributes, 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 conditions 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- 28 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

4 Discovery Representation Semantics of change Propagation Implementation Validation Core component 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 mapping-ontology instance transforms every query from the target ontology into a query over the source ontology. The system then executes the transformed query and transforms the obtained information back into the target ontology. With this approach, changes to the source ontology s instances are immediately visible in the target ontology. However, because the system performs a transformation at each request, performance is worse than in the static case. Postprocessing Postprocessing applies only to static execution, 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 person). 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 generally are not developed to remain stable. Rather, several factors make them subject to continual change. First, the environment in which the knowledge management systems operate can change unpredictably, thereby invalidating 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. Second, user requirements often change after the system has been built, warranting Knowledge management systems generally are not developed to remain stable. Rather, several factors make them subject to continual change. 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 analyzing 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 topics (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, management must be interpreted at the conceptual level. Therefore, we can identify two 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. Alternatively, some changes might be discovered by analyzing log files that track interaction of users with the system, which is known as bottom-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 artifacts. Modifying one part of the ontology might generate subtle inconsistencies in other parts of the same ontology, in the instances, dependent ontologies, and applications. For example, Michel Klein and his colleagues 12 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). Furthermore, ontology evolution is clearly distinguished from the problem of schema evolution in relational databases, which has already been extensively studied. 13,14 For example, Natalya Noy and her colleagues have discussed these differences and identified 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. Elementary changes in the ontology (such as adding a concept, removing a property, or setting a property range) are derived from our conceptual model. However, this granularity of MARCH/APRIL 2003 computer.org/intelligent 29

5 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 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 from 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 subconceptof 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 elementary changes applied together. Semantics of change Changing an ontology can induce inconsistencies in other parts of the ontology. Semantic inconsistency arises if an ontology entity s meaning changes. Syntactic inconsistency arises if undefined entities are used at the ontology or instance level or ontology model constraints are invalidated. For example, removing a concept that is the only element 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 comprehending 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 ontology. 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 transfer 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. When a user modifies the ontology, ontology instances must change to preserve consistency with the ontology. An ontology update might also corrupt ontologies that depend on the modified ontology and, consequently, all artifacts based on these ontologies. We can solve this problem recursively by applying ontology evolution to these ontologies. However, apart from syntax inconsistency, semantic inconsistency can also arise when, for example, the dependent 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 evolution approach must recognize which change in the ontology can affect the functionality of dependent applications and react correspondingly. Changing an ontology can induce inconsistencies in other parts of the ontology. Semantic inconsistency arises if an ontology entity s meaning changes. 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 comprehend 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 collaboratively, 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 purposes might be desirable. To enable recovering from these situations, we introduce the validation phase. Validation concerns an ontology s truthfulness regarding its problem 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 simply requesting an inverse change manually. For example, if a user deletes a concept from a concept hierarchy, the subconcepts will need to be either 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 typically solves the problem of reversibility. An evolution log tracks information about each change, allowing the reconstruction of the sequence of changes leading to the ontology s original state. Discovery The validation phase results in an ontology 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 different parts of an ontology without enough communication. They could delete subconcepts of some concept at different times to fulfill their immediate needs. Thus, it is possible 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 suboptimal structure. To help users detect such situations, we investigated applying selfadaptive-system principles and proactively making suggestions for ontology refinements changes to the ontology with the goal of improving it. This would make 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 changes induced through the analysis of existing instances. For example, if no instance of concept C uses any of the properties defined for C but only properties inherited from the 30 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

6 parent concept, we can assume that C is not necessary. Usage-driven change discovery considers the ontology s use in the knowledge management system. It is based on analyzing the users behavior in two phases of a knowledge management cycle. First, it provides knowledge by analyzing the annotations quality. Second, it searches for knowledge by analyzing the users queries and the responses from the knowledge repository. For example, 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 ( semanticweb.org). KAON is an open-source ontology-management infrastructure targeted for semantics-driven business applications, developed and maintained at the FZI (Research Center for Information Technologies) and AIFB (Institute of Applied Informatics and Formal Description Methods) at the University of Karlsruhe. It includes a comprehensive tool suite allowing easy ontology management and application. KAON focuses on integrating traditional technologies for ontology management and application 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 proprietary extensions (such as inverse, symmetric, and transitive relations), cardinalities, modularization, metamodeling, and representation of lexical information. Figure 4 presents the KAON architecture. The KAON architecture s core is its ontology 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 incorporates other elements required for ontology management: The evolution strategy ensures that all changes applied to the ontology leave the ontology in a consistent state and prevents illegal changes. Change reversibility tracks ontology User interface Ontology Instance Modeler KAON API Evolution strategy Back end File-based RDF sources Change reversibility RDF-based access KAON portal RDF server Concurrency conflict detection changes in an evolution log so that the system can reverse them at a user s request. The evolution log is based on the evolution ontology ( 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. The KAON API has several implementations, each using a different back end for information 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. The Engineering Server implementation uses relational databases for ontology persistence. We call it the Engineering Server because the server is optimized for ontology Engineering server Figure 4. The Karlsruhe ontology s architecture. Optimized loading Relational databases Legacy server Query answering Mapping engine 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 middle of the concept hierarchy takes less than 5 seconds. It works on a typical single-processor desktop computer running Windows XP with 256 Mbytes of RAM. The Legacy Server implementation lets us lift existing relational databases to the ontology level. To do so, tables in the database must be mapped to concepts and relationships in the ontology. The system must modify all operations on the KAON API according to these mappings into appropriate database operations. The virtual mapping engine is an implementation realizing a virtual ontology mapped from some source ontology. It transforms queries into the mapped ontology using an instance of the mapping ontology (see 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 Ontology Instance Modeler realizes a graph-based user interface for ontology creation and evolution. Figure 5 shows how we implemented ontology evolution at the user level. The figure shows a modeling session where the user attempts to MARCH/APRIL 2003 computer.org/intelligent 31

7 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 Figure 5. Ontology evolution in the Ontology Instance Modeler. 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 presents 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. In the future, we plan to evaluate more formally 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 practicality by applying it to project management. From that we hope to elicit the technical requirements that are crucial for successfully applying ontologies in knowledge 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 fruitful discussions with our Ontologging project partners: Archetypon (Greece), Deltatec (Belgium), Indra (Spain), Insead (France), and Meta4 (Spain). The European Commission partially financed our research through the IST Ontologging and IST 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 F. Gandon et al., Semantic Web and Multi- Agents Approach to Corporate Memory Management, 17th IFIP World Computer Congress, IIP Track Intelligent Information Processing, Kluwer Academic Publishers, 2002, pp S. Staab et al., Knowledge Processes and Ontologies, IEEE Intelligent Systems, vol. 16, no. 1, Jan./Feb. 2001, pp B. Motik, A. Maedche, and R. Volz, A Conceptual 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 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 G. Wiederhold, Mediators in the Architecture of Future Information Systems, Computer, vol. 25, no. 3, Mar. 2002, pp H. Garcia-Molina et al., The TSIMMIS Approach to Mediation: Data Models and Languages, J. Intelligent Information Systems, vol. 8, no. 2, Mar./Apr. 1997, pp A.Y. Levy, A. Rajaraman, and J.J. Ordille, Querying Heterogeneous Information Sources Using Source Descriptions, Proc. 23rd Int l Conf. Very Large Databases, Morgan Kaufmann, 1996, pp computer.org/intelligent IEEE INTELLIGENT SYSTEMS

8 10. A. Doan et al., Learning to Map between Ontologies on the Semantic Web, Proc. World-Wide Web Conf., ACM Press, 2002, pp E. Franconi, F. Grandi, and F. Mandreoli, A Semantic Approach for Schema Evolution and Versioning in Object-Oriented Databases, Proc. 1st Int l Conf. Computational Logic (CL 2000), LNCS 1861, SpringerVerlag, 2000, pp J.F. Roddick, A Survey of Schema Versioning Issues for Database Systems, Information and Software Technology, vol. 37, no. 7, July 1995, pp L. Stojanovic et al., User-Driven Ontology Evolution Management, Proc. 13th European Conf. Knowledge Eng. and Management (EKAW 2002), Springer-Verlag, 2002, pp N.F. Noy and M. Klein, Ontology Evolution: Not the Same as Schema Evolution, tech. report SMI , Stanford Medical Informatics, Stanford Univ., M. Klein et al., Ontology Versioning and Change Detection on the Web, Proc. 13th European Conf. Knowledge Eng. and Management (EKAW 2002), Springer-Verlag, 2002, pp For more on this or any other computing topic, see our Digital Library at publications/dlib. T h e A u t h o r s Alexander Maedche is the 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 his Diploma in industrial engineering and his PhD in applied informatics, both from the University of Karlsruhe. 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-undNeu-Str , 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), University of Karlsruhe. His research interests include conceptual modeling languages, 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 , 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-NeuStr , Karlsruhe, Germany; ljiljana.stojanovic@fzi.de. Rudi Studer s biography appears in the Guest Editors Introduction on page 17. 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 Inst. AIFB, Univ. of Karlsruhe, Karlsruhe, Englerstr. 11, Karlsruhe, Germany; volz@aifb.uni-karlsruhe.de; MARCH/APRIL 2003 computer.org/intelligent SUBSCRIBE NOW! 9. A. Maedche et al., MAFRA Mapping Distributed Ontologies in the Semantic Web, Proc. 13th European Conf. Knowledge Eng. and Management (EKAW 2002), SpringerVerlag, 2002, pp IEEE Pervasive Computing delivers the latest peer-reviewed developments in pervasive, mobile, and ubiquitous computing. The quarterly publication acts as a catalyst for progress in this emerging field by bringing together leading researchers and practitioners, such as hardware designers, wireless engineers, human-computer interaction specialists, and software agent developers. For more information, visit 33