knowledge processes and ontologies

26 1094-7167/01/$10.00 © 2001 IEEE IEEE INTELLIGENT SYSTEMS

K n o w l e d g e M a n a g e m e n t

Knowledge Processesand OntologiesSteffen Staab and Rudi Studer, Institute AIFB—University of Karlsruhe and Ontoprise GmbHHans-Peter Schnurr, Ontoprise GmbHYork Sure, Institute AIFB—University of Karlsruhe

Increases in product complexity, the move toward globalization, the emergence of

virtual organizations, and the increase in focus on customer orientation all demand

a more thorough and systematic approach to managing knowledge. Knowledge man-

agement is a major issue for human resource management, enterprise organization, and

enterprise culture. But IT plays a major supportingrole in managing knowledge.

You typically build IT-supported KM solutionsaround an organizational structure that integratesinformal, semiformal, and formal knowledge to facil-itate its access, sharing, and reuse.1 In such contexts,where knowledge has to be modeled, structured, andinterlinked, ontologies can help formalize the knowl-edge shared by a group of people.2

In this article, we present an approach for ontol-ogy-based KM that includes a suite of ontology-based tools as well as a methodology for developingontology-based KM systems. Our approach, shownin Figure 1, builds on the distinction between knowl-edge process (handling knowledge items) and knowl-edge metaprocess (introducing and maintaining KMsystems).

Ontologies constitute the glue that binds knowl-edge subprocesses together. Ontologies open the wayto move from a document-oriented view of KM to acontent-oriented view, where knowledge items areinterlinked, combined, and used. The method fordeveloping KM systems that we outline in this arti-cle (that is, the knowledge metaprocess) extends andimproves the CommonKADS method3 by introduc-ing specific guidelines for developing and main-taining ontologies.

Our approach shows that you can clearly identifyand handle different subprocesses that drive thedevelopment and use of KM applications. You sup-port these subprocesses by appropriate tools that aretied together by the ontology infrastructure.4

Knowledge items versus documentsCompanies have typically pursued a very simple,

pragmatic approach for introducing KM into theenterprise (moving along the knowledge meta-process in the yellow circle in Figure 1), whichmeans that they have picked only the low-hangingfruit. We summarize this approach in the left columnof Figure 2. What appears preeminent in thisapproach is the focus on handling documents (steps2 and 3) and the existing but minor role of the appen-dix “process.”

In spite of its immediate successes, this approachpresents several disadvantages. In particular, it oftenleads to the consequence that the knowledge processsteps (the blue circle) of creation, import, captur-

This approach for

ontology-based

knowledge management

includes a tool suite and

methodology for

developing ontology-

based KM systems. It

builds on the distinction

between knowledge

process and knowledge

metaprocess and is

illustrated by CHAR, a

knowledge management

system for corporate

history analysis.Figure 1. Two orthogonal processes withfeedback loops illustrate our approach to knowledge management.

Knowledgeprocess

Knowledgemetaprocess

ing, retrieving and accessing, and using areonly very loosely connected, if at all. Theunderlying reason is that for each of thesesteps different types of business documentsplay a major role, which makes “knowledgere-use”—let alone knowledge refinding—extremely difficult .

Relevant knowledge items can appear ina multitude of different document formats:text documents, spreadsheets, presentationslides, database entries, Web pages, con-struction drawings, or email, to name but afew. The challenge lies in how you handlethe knowledge.

At the one extreme, in traditional docu-ment management, IT support for KM can-not take advantage of the document contentsthemselves but only their explicit or implicitclassification. At the other extreme, there areexpert systems that structure and codify allknowledge in the system. However, althoughsuch an approach might sometimes be appro-priate, not everything can be codified. A lotof knowledge is created sporadically, and thevalue of its reuse can only be demonstratedover time. You must therefore search for anadequate balance between reuse, level of for-mality, and cost. For instance, certain helpdesk scenarios imply long-term use ofextremely well-defined knowledge items.5

In these cases, it might be economicallyadvantageous to spend some time and moneyon coding. On the other hand, a hallway dis-cussion is usually not worth codifying at all,because it might not be reusable.

To balance conflicting needs and managevarious degrees of encoded knowledge, itcan be useful to employ the concept of meta-data, which we can define in two comple-mentary ways:

• Data describing issues related to the con-tent of data. We divide this category intotwo orthogonal dimensions: the formalityof the data and the containment of themetadata. In the first dimension, metadatamight range from very informal descrip-tions of documents (like free-text sum-maries of books) to very formal descrip-tions (like ontology-based documentannotation). In the second dimension,parts of metadata might be internal to thedata that is described (like an HTMLauthor tag) while others might be storedcompletely independently from the docu-ment they describe (like a bibliographydatabase that classifies the documents itrefers to but does not contain them).

• Data that describes the structure of data.In our case, you can call this type ofmetadata “meta metadata” because itdescribes the structure of metadata. Thisdistinction boils down to an ontology thatformally describes the domain of the KMapplication, possibly including parts ofthe organization and the informationstructures.6

Metadata can help condense and codifyknowledge for reuse in other steps of the KMprocess. It can also help link knowledgeitems of various degrees of formalitytogether, thus allowing a sliding balancebetween depth of coding and costs.

Knowledge processOnce you fully implement a KM system,

knowledge processes essentially revolvearound the following steps (see Figure 3):

• Creation or import. The contents need tobe created or converted so that they fit theconventions of the company.

• Capture. Knowledge items have to be cap-tured in order to determine their impor-tance and how they mesh with the com-pany’s vocabulary conventions.

• Retrieval and access. This step satisfiesthe searches and queries for knowledge bythe knowledge worker.

• Use. The knowledge worker will not only

JANUARY/FEBRUARY 2001 computer.org/intelligent 27

1.

2.

Find out what the core knowledge needs are.

Document focus Knowledge item focus

Find out whichbusiness documents and databasesdeal with these knowledge needs.

Find out whichknowledge items

deal with these knowledge needs.

3.Build an

infrastructurefor your organizational memory system.

Find out whichknowledge processes

to allow for creation, handling, and process support of and around knowledge items.

4.

Re-organizeprocesses

to deal with creation and distribution ofknowledge.

Build aninfrastructure

for your organizational memory system.

Figure 2. The document focus compared to the knowledge item focus.

Figure 3. The knowledge process.

ApplicationsAnalyzeSummarize Use Create

Retrieve/access Capture

Import

QuerySearch toolsDerive viewsInfer knowledge

DocumentsMetadata

Extract Annotate

recall knowledge items, but will processthem for further use.

Knowledge creationCreation of computer-accessible knowl-

edge typically moves between the twoextremes of formal and informal. Compara-tively deep codification can often be donewithout requiring any extra effort. Businessdocuments, in general, do not arbitrarilychange but often come with some inherentstructure, like engineering requirements forquality management. Our idea is to embedthe structure of knowledge items into docu-ment templates, which are then filled on thefly by doing daily work.7

The granularity of this knowledge then liesin the middle between the extremes ofcoarsely representing business documents andrepresenting them too finely. As Table 1 illus-trates, there are several degrees of formalitybetween formal and informal knowledge.

In Table 1, we use the term content-struc-tured documents to refer to XML structuresthat are tightly (sometimes explicitly, some-times implicitly) linked to a domain model.For instance, XML-EDI documents comewith a predefined structure alluding to a stan-dard framework for exchanging data, such as

invoices, healthcare claims, or project statusreports. By the term document templates, wemean similar structures that come with alarger degree of freedom, including largechunks of informal knowledge items such asthe one found in Figure 4.

Careful analysis of the in-use knowledgeitems lets you add formal knowledge partsinto the process of creating documents.Doing so pushes the degree of formalityslightly upwards without endangering over-all system use.

Knowledge importFor many KM purposes, importing knowl-

edge items into the KM system has the sameor more importance than creating them. Youcan liken the situation to data warehousing,except that the input structures are more var-ied and the target structures are much richerand more complex.

For imported knowledge, accurate accessto relevant items plays an even more impor-tant role than for homemade knowledge. Forhomemade knowledge items, people mightact as a backup index, but they can’t forrecently imported knowledge that no one hasyet seen. In fact, studies have shown that theparts that cover imported knowledge are less

heavily exploited than those covering home-grown ones.8

Knowledge captureOnce you create knowledge items, the next

step is to capture their essential contents.There are several indexing and abstractingtechniques typical of library science. In addi-tion, we provide a means to capture documentexcerpts as well as interlinkage betweenexcerpts by our tool, OntoAnnotate.4

OntoAnnotate, illustrated in Figure 5, letsyou create objects and describe them withtheir attributes and relations. Describingobjects this way helps exploit knowledgefound on Web pages, in spreadsheets, or intext documents. In the example shown in Fig-ure 5, OntoAnnotate captures several facts,such as company M.A. Hanna selling itsShape Distribution Business to GE.

Through this annotation process, you cre-ate metadata that conform to the ontologyand that can be aligned with related infor-mation to yield analyses and derivations likethose we describe in this article. The originsof the metadata may be used to validate theoverall information.

Knowledge retrieval and accessYou typically perform large parts of

knowledge retrieval and access through aconventional GUI. You can use the ontologyto derive further views of the knowledge. Inparticular, you can exploit the ontology fornavigation purposes, offering navigationstructures the way Yahoo does. Knowledgeworkers can explore what is in the organiza-tion’s collective memory without beingrequired to ask a particular question—whichis often a hard task for newcomers.

Also, using an ontology lets you deriveadditional links and descriptions. For exam-ple, the ontology can help you derive statedescriptions for points in time for which noexplicit data exists (such as the currentstructure of a company that has changed itsorganization by mergers or acquisitions).Thus, it can provide new hyperlinks thataren’t explicitly given. Ontologies can helpcomplete views of your captured knowledge

28 computer.org/intelligent IEEE INTELLIGENT SYSTEMS


Table 1. Degrees of formal and informal knowledge.

Degree Model Interface Example

Thoroughly formal Relational Form interface Database interfaceFormal Content-structured document Tight XML structure XML-EDIPartially formal Document template Loose XML structure Investment recommendation templateInformal Free text No predefined structure ASCII text file

<investmentrecommendation><author> Henrik Oppermann </author><plandate> October 18th, 2003 </plandate><interviewpartners>

<name> York Sure </name><name> Hans-Peter Schnurr </name><name> Steffen Staab </name>

</interviewpartners><recommend> strong buy </recommend><details>

<peergroup> … </peergroup><…> … <…>

</details></investmentrecommendation>

Figure 4. An example of a knowledge item, in this case an investmentrecommendation template.

without requiring that all information isactually given.

Knowledge useKnowledge use, which deals with the most

intricate points of KM, is the part that is mostoften neglected. Many KM systems assumethat once some relevant document is found,everything is done. Eventually, however, theway to use knowledge from the organization’scollective memory becomes quite involved.Topics such as proactive access, personaliza-tion, and in particular, tight integration withsubsequent applications play a crucial role forthe effective reuse of knowledge. Very oftenit is not even the knowledge itself that is ofmost interest, but the derivations that can bemade from the knowledge. For instance, inour case study, no single knowledge itemsabout a company might be relevant to a mar-ket analyst, but the overall picture presentedby the analysis can be quite relevant.

In addition, usage data tells a lot about theorganization’s memory and about the organi-zation itself. You can analyze which processes,customers, and techniques are tied to core fig-ures of the organization. In one of our cases,we identified the important role of a sales rep-resentative in South America only by his per-vasive knowledge stored in the organizationalmemory about this market. Without the rep-resentative, the South American market mighthave gotten lost and, hence, the companybegan initiatives to avoid this situation.

Knowledge metaprocessOver more than a decade, CommonKADS

has been generally successful as a methodol-ogy for developing KM systems.3 It took untilthe 1990s for research to begin identifying thevirtues of ontologies for sharing and reusingknowledge. But there is little work that tightlyintegrates ontology development into an over-arching methodology for introducing knowl-edge management systems, such as Com-monKADS. In contrast to seminal related workin the area of ontology development,2,9 ourfocus lies on the application-oriented devel-opment of ontologies, including feedback andrequirements from the KM application.

Our model for ontology developmentranges from the early stages of setting up aKM project to the final rollout of the ontol-ogy-based KM application. In this article, weintegrate some lessons learned from our expe-riences into the steps to be taken to performontology development activities. Figure 6shows the ontology development process.

Feasibility studyAny KM system can only function satis-

factorily if it is properly integrated. Severalfactors other than technology can determinesuccess or failure. To analyze these factors,you have to perform a feasibility study toidentify problem or opportunity areas andpotential solutions. You also perform a fea-sibility study to put these problems oropportunities into a wider organizationalperspective.

The feasibility study can help you deter-mine economical and technical project feasi-bility. It can help you select the most promis-ing focus area and the best solution to anypotential problems. For our purposes, weadopted the kind of feasibility study described

in the CommonKADS methodology. The fea-sibility study should be carried out beforeactually developing ontologies because itserves as a basis for the kickoff phase.

Kickoff phaseThe kickoff phase’s output product is an

ontology requirements specification docu-ment (see Figure 7). The kickoff phasedescribes what an ontology should supportand sketches the planned area of the ontol-ogy application. It should also guide anontology engineer to decide about inclusion,exclusion, and the hierarchical structure ofconcepts in the ontology. In this early stage,you should look for already developed andpotentially reusable ontologies.


Figure 5. How OntoAnnotate works when capturing knowledge about a sale.

Figure 6. The ontology development process or knowledge metaprocess.

• Identify problem and opportunity areas• Select most promising focus area and target solution

• Requirement specification• Analyze input sources• Develop baseline taxonomy

• Concept elicitation with domain experts• Develop baseline taxonomy• Conceptualize and formalize• Add relations and axioms

• Revision and expansion based on feedback• Analyze usage patterns• Analyze competency questions

• Manage organizational maintenance process

Maintenance

Ontology

Feasibilitystudy

Ontologykickoff

Refinement

Ontology developmentProject setting

Evaluation

In summary, the kickoff phase shouldclearly detail several pieces of information:

• the ontology’s goal,• its domain and scope,• the applications it supports,• its knowledge sources (like domain

experts, organization charts, businessplans, dictionaries, index lists, or db-schemas), and

• its potential users and usage scenarios.

It should also include a competency ques-tionnaire like the one shown in Table 2—essentially an overview of possible queriesto the system that can indicate the scope andcontent of the domain ontology. Finally, thekickoff phase should detail any potentiallyreusable ontologies.

Refinement phaseThe goal of the refinement phase is to pro-

duce a mature and application-oriented targetontology according to the specification givenby the kickoff phase. We divide this phaseinto different subphases:

• Gathering an informal baseline taxonomycontaining relevant concepts given duringthe kickoff phase.

• Eliciting knowledge from domain experts

based on the initial input from the base-line taxonomy to develop a seed ontologythat contains relevant concepts anddescribes the relationships between them.The seed ontology is expressed at an epis-temological level.

• Transferring the seed ontology into thetarget ontology expressed in formal rep-resentation languages like Frame Logic,Description Logic, or Conceptual Graphs.

Using potentially reusable ontologies(identified during the kickoff phase) canimprove the speed and quality of the devel-opment during the whole refinement phase.These ontologies might provide useful hintsfor modeling decisions.

Evaluation phaseThe evaluation phase serves as a proof of

the usefulness of developed ontologies andtheir associated software environment. In thisstep, the ontology engineer checks whetherthe target ontology satisfies the ontologyrequirements specification document andwhether the ontology supports or answers thecompetency questions analyzed in the kick-off phase of the project.

In this step you also test the ontology inthe target application environment. Feedbackfrom beta users might be valuable input for

further refinement of the ontology. The pro-totype system should track the ways usersnavigate or search for concepts and relations.You can then trace what areas of the ontol-ogy are used most often.

This phase is closely linked to the refine-ment phase. An ontology engineer might needto perform several cycles until the target ontol-ogy reaches the specified level. Rolling out thetarget ontology finishes the evaluation phase.

Maintenance phaseSpecifications for ontologies often need to

change to reflect changes in the real world. Toreflect these changes, ontologies have to bemaintained frequently. Maintaining ontolo-gies is primarily an organizational process.There must be strict rules for the update-delete-insert processes within ontologies.

We recommend you gather changes to theontology and initiate the switch-over to a newversion of the ontology after thoroughly test-ing possible effects to the application. As inthe refinement phase, feedback from usersmight be valuable for identifying changes.

Knowledge metaprocessinstantiated

Actively tracking and managing relevantknowledge is a major task for knowledge-intensive companies. While the correct analy-sis of market situations and competitors arecritical requirements for success, the failure toprovide adequate knowledge about one’sbusiness environment can invite failure.

Feasibility studyIn the feasibility study we found that man-

agement and professionals have a hard timegathering information, analyzing it, and per-forming their operational work. The task ofthe corporate researcher is to track relevantknowledge and communicate it to stake-holders within the company. Market analysts,consultants, and in-house market researchdepartments try to track their industry’s activ-ities using traditional methods. Corporateresearch typically tracks newspaper articles,online databases, annual company reports,and competitors’ Web pages and then pre-sents the results to management.

There are several problems with the con-ventional research process:

• Information archives are document-based.For a collective gathering of facts, this isa document-centric view that is too coarseto be useful.


Figure 7. Ontology requirements specification document.

Domain: Business strategy in the chemical industryDate: 2000/11/26Ontology Engineer: T. Model

Goal of the ontology: • Tracking and analyzing corporate business historiesDomain and Scope: • Mergers & acquisitions, restructurings, management changes, and other strategic activities in the chemical industrySupported applications: • Web-based corporate history analyzerKnowledge sources: • Research analysts (domain experts) • Related Web sites (company homepages, chemical industry networks) • Newspaper articles • Ad hoc news tickersUsers and use cases: • Users: Research analysts, strategic consultants • Use Case 1: Track strategies of specific companies • Use Case 2: Analyze strategic moves of competitorsCompetency questions: • Attached competency questionnairePotentially reusable ontologies: • Not known


• Typical document management systemsrely almost exclusively on informationretrieval techniques that are inaccurate.

• Implications can only be made transpar-ent if you use background knowledge, butsystems today rarely support backgroundknowledge.

• Different people might contribute knowl-edge.

• Different people might require differentviews of the same basic piece of infor-mation.

A KM system that covers such knowledgeabout the outside world should

• support the collective gathering of infor-mation on the level of facts rather thandocuments,

• integrate the gathering task smoothly intothe common research process,

• allow you to intelligently combine facts,• check new facts against the available back-

ground knowledge,• allow multiple-view access to the knowl-

edge through a single entry portal, and • allow you to route derived facts back into

the common workplace environment.

With these aims in mind, we developed anontology-based application called the Cor-porate History Analyzer (CHAR).

Kickoff phaseThe question was how to bring the required

conceptual structures and reasoning capabil-ities into action following the further steps of our knowledge metaprocess shown in Fig-ure 6. We collected user requirements in therequirements specification phase during struc-tured interviews with corporate research ana-lysts. The Ontology Requirements Specifi-cations Document shown in Figure 7 is theproduct of this first phase.

We specified the ontology and then devel-oped it in detail. We asked the domainexperts what questions they would expect tobe answered by a system supporting theircorporate research work. These competencyquestions helped us find the most importantconcepts and relations between them.

Analyzing the questionnaires helped usconclude that the system should deliveranswers about the acquisitions, mergers, andrestructuring of companies over specific timeperiods. The questionnaire in Table 2 listscompetency questions CQ1 to CQ4 that wecompiled during the ontology kickoff. Wealso recognized the need for a clarificationof organizational wording, so we could moreclearly determine, for example, whether abusiness unit is a division or a department.

Refinement phaseIn the refinement phase, we brought the

concepts into a taxonomic hierarchydesigned for the knowledge engineer. Weshowed the taxonomy—a part of which isshown in Figure 8—to domain experts togenerate additional concepts and relevant


Table 2. Sample competency questionnaire for a business strategy in the chemical industry.

Domain: Business strategy in the chemical industryDate: 2000/11/26Ontology Engineer: T. Model

CQ no. Competency questions Concepts Relation

CQ1 What are the subsidiaries, company, subsidiary, company has subsidiarydivisions and locations of company X? division, location company has division

company has location

CQ2 Which companies acquired company X? company, acquisition company makes acquisitionacquisition has buyer acquisition has seller

CQ3 Which companies merged in 1990 in the company, merger, year, company makes mergerrubber industry? industry company isPartOf industry

merger happensIn year

CQ4 Who is CEO of company X? CEO, company company has CEO

CQ5 Which activity of company X leads to activity, company, company performs activityoperation in region Y? operation, region activity leadsTo operation

operation takesPlaceIn region

CQ6 Is there any regional expansion of company X due expansion, company, region, company makes expansionto the acquisition of company Y? acquisition company makes acquisition

expansion takesPlaceIn region

CQ7 ...

Figure 8. The Corporate History Analyzertaxonomy.

attributes, and to establish relationshipsbetween the concepts. OntoEdit, our ontol-ogy engineering tool, supported this work.10

OntoEdit allows you to model the ontologyand formalize it in different representationlanguages, like F-Logic and DAML+OIL.

We found that in the corporate historydomain, time had to be modeled. A companyhas a beginning time and (potentially) an endtime, which would be when the companygets acquired by another company, mergeswith another company, or goes bankrupt. Sowe found we had to model duration.

One of the key characteristics of CHAR isthat the user provides facts to the system aboutactions like acquisitions and mergers and thesystem then infers the consequences. To dothis, you have to model rules for all possibleactivities that incur such consequences. Forinstance, a rule might read like this: “If twocompanies are merged, a new company witha new name is created, the old companies ceaseto exist, they are from now on subsidiaries ofthe new company” or “If a division is out-sourced it becomes part of a new company orit becomes a company on its own.”

For CHAR, we had to develop a Webinterface that used the ontology for queryingand augmenting the knowledge repository(see Figure 9). We had to perform a querydevelopment step to formalize the views andcompetency questions described earlier. This

development step depended mostly on theactual application setting. It was independentfrom the ontology construction.

Evaluation phaseIn the evaluation and testing phase, we

investigated the ontology’s usability. Withregard to the CHAR ontology, we found thatthe competency questions CQ1 to CQ4(Table 2) could be handled successfully bythe ontology. However, we wanted complexknowledge content to be queried anddepicted on one screen. This kind of contentwould include company purchases, regionsof previous activities, and regions of activi-ties of the purchased company.

The research analyst found that singletonknowledge items were spread over differentscreens of the application. They were veryhard to combine by the research analyst toanswer strategic questions. He wanted bet-ter support from the ontology. Through thediscussion, we came up with additional com-petency questions (CQ5 and following) thatshould be handled by the ontology. We thenadded corresponding axioms to the ontologyand introduced a new query window forstrategic questions.

Maintenance phaseWe are currently in a maintenance phase,

where through a shift in the goal orientation of

the application, we face requirements for con-siderable extension of the ontology and theapplication. In addition to corporate histories,the system must now support the extendedtracking of market circumstances, including amore detailed view of available technology andbetter comparisons with peer groups.

Major problems that we now must faceinclude the documentation and versioningproblems that have so far been neglected bypractically all ontology development tools.We are working toward resolving these issuesin our ontology environment OntoEdit.

We developed our methodology parallelto CHAR. Thus, we could not follow all themethodological steps we’ve presented herefrom the very beginning. Developers who arenew to the project need to reverse-engineersome old ontology parts to find answersabout how these parts actually work. Weexpect that comprehensive use of the pro-posed methodology and its full-fledged sup-port by OntoEdit will mostly prevent theseproblems in the future.

Knowledge process instantiatedCHAR should allow many people to con-

tribute factual knowledge in a way that can beembedded into their common work processand organized around a semantic background.It should also provide multiple views onto thesame knowledge base for different timeframes, for different regional foci, for varyingintra-organizational structures, and for differ-ent strategic questions, to name but a few.

Providing knowledgeProviding new facts for the knowledge

repository should be as easy and as smoothlyintegrated into common work as possible.There are several ways to do this:

• You can enter information through a form-based interface.

• When information is produced during doc-umentation or report-writing, you can usea template approach to generate knowl-edge. Both of these tools affect the knowl-edge creation step.

• You can use wrapper mechanisms to pro-vide data from tables and lists on the Web(import step).

• Most important for CHAR, you can useour annotation tool to add metadata to datagiven in documents, which affects the cap-turing step.

Figure 5 shows a snapshot of OntoAnno-



Figure 9. The Corporate History Analyzer.

tate.4 The user works with documents usinga text or spreadsheet tool or an Internetbrowser. When the user detects some rele-vant change being described in the docu-ment, he or she highlights the word or phraseand uses the annotation tool to select the typeof the phrase (like “M.A.Hanna is a com-pany”) and its relation to other material (like“Hanna sells Shapes Distribution Businessto GE Plastics on 11 May 2000”). Theknowledge repository stores the document,these facts, the time of annotation, and meta-data about the annotator.

Querying for knowledgeWe designed CHAR’s query interface to

deal with organizational and strategic ques-tions that depend on spatiotemporal con-

straints. CHAR renders views that can beseen on a common Web browser. Actually,these views look just like common Web sites.The available menu selections are controlledby the knowledge of the back-end system.For example, you can select companiesknown to exist in the knowledge repository.Figure 9 shows the main views offered byCHAR. These views include Activities,Organization, Know-How, Strategic Ques-tions, and General Query Possibilities (indi-cated by “Search”).

The first major category of queries relevantto the corporate history is about organiza-tional structures and the activities that changeorganizational structures. For instance, theview of “Acquisitions of M.A.Hanna” returnsall its purchases. CHAR offers correspond-

ing views for Sales, Mergers, Restructuring,and Management Changes (see Figure 10).

What is interesting to note at this point isthat it is rather difficult to get a clear picture ofwhat is really happening with M.A.Hanna. Itis difficult and time-consuming for the humananalyst to detect some trend in lists of singleknowledge items. Observations become mucheasier when different types of knowledgeitems can be related and contrasted.

For instance, Figure 10 shows two snap-shots of the organization of M.A.Hanna.They are automatically derived from singleactivities, like acquisitions and restructur-ings, and they can give the analyst a neat pic-ture of how formerly isolated purchases thatM.A.Hanna made before 1994 were moretightly integrated in the company in 1997 (forexample, “Southwest Chemical” having beenreorganized into the Business Area “PlasticCompounding”).

In addition to sophisticated support basedon concrete facts and figures, CHAR sup-ports strategic questions that indicate possi-

Figure 10. Comparing two organizationalstructures using the Corporate HistoryAnalyzer (CHAR).


ble answers to questions about business com-petitors that cannot be answered definitelyand often rely on conjecture. For instance,the purchase of a company from abroadmight lead to a gain of market share in thatarea, and thus to a regional diversification.

In the future, more and more companieswill find that analysis of knowledge

processes will feed back into the knowledgemetaprocess cycle and can help to improveboth. These companies will find that newconcepts that come up during the use of aKM solution can be introduced back into theontology to help it evolve. For this purpose,we investigate the use of semi-automaticontology learning techniques.10

The challenges lie in analyzing KMprocesses and dynamically updating the KMsolution. Our framework can help leveragethese evolving systems by providing a con-cise view of the problem.

Related to this work, we are jointly orga-nizing the first German conference on knowl-edge management, the WM2001 (http://wm2001.aifb.uni-karlsruhe.de). Steffen Staaband Rudi Studer are the cochairs, York Sureis the industrial liaison, and Hans-PeterSchnurr is the finance chair.

AcknowledgmentsWe thank our colleagues and students at AIFB,

University of Karlsruhe, VU Amsterdam, andOntoprise GmbH, including H. Akkermans, J.Angele, S. Decker, M. Erdmann, A. Hotho, A.Maedche, M. Maier-Collin, D. Oberle, and D.Wenke, without whom the research would not havebeen possible. The research presented in this paperwas partially funded by EU in the IST-1999-10132project On-To-Knowledge and by BMBF in theproject GETESS (01IN901C0).

References

1. R. Dieng et al., “Methods and Tools for Cor-porate Knowledge Management,” Int’l J.Human–Computer Studies, vol. 51, no. 3,1999, pp. 567–598.

2. M. Uschold and M. Gruninger, “Ontologies:Principles, Methods and Applications,” TheKnowledge Eng. Rev., vol. 11, no. 2, 1996, pp.93–136.

3. G. Schreiber et al., Knowledge Engineeringand Management: The CommonKADSMethodology, MIT Press, Cambridge, Mass.,1999.

4. S. Staab et al., “Semantic Community WebPortals,” Proc. WWW-9/Computer Networks,Elsevier, New York, vol. 33, 2000, pp.473–491.

5. L. Morgenstern, “Inheritance Comes of Age:Applying Nonmonotonic Techniques to Prob-lems in Industry,” Artificial Intelligence, no.103, 1998, pp. 1–34.

6. A. Abecker et al., “Toward a Technology forOrganizational Memories,” IEEE IntelligentSystems, vol. 13, no. 3, May/June 1998, pp.40–48.

7. S. Staab and D. O’Leary, eds., Bringing

Knowledge to Business Processes, 2000AAAI Spring Symposium technical reportSS-00-03, AAAI Press, Menlo Park, Calif.,2000.

8. D. O’Leary, “Knowledge Management: AnAnalysis Based on Knowledge Use andReuse,” IEEE Intelligent Systems, vol. 16, no.1, Jan./Feb., 2001.

9. M. F. López et al., “Building a Chemical Ontol-ogy Using Methontology and the OntologyDesign Environment,” IEEE Intelligent Sys-tems, vol. 14, no. 1, Jan./Feb. 1999, pp. 37–46.

10. A. Maedche and S. Staab, “Mining Ontolo-gies from Text,” Proc. 12th Int’l Conf. Knowl-edge Eng. and Knowledge Management, Lec-ture Notes in Computer Science, vol. 1937,2000, Springer Verlag, New York, pp.189–202.



Steffen Staab is anassistant professor atthe University of Karl-sruhe and cofounder ofOntoprise GmbH. Hereceived an MSE incomputer science fromthe University of Penn-sylvania and a Dr. rer.

nat. from the University of Freiburg, Computa-tional Linguistics Lab. He has chaired severalinternational workshops, including the AAAI2000 spring symposium on Business Processesand KM. Contact him at Institute AIFB, Uni-versity of Karlsruhe, 76128 Karlsruhe, Ger-many; [email protected].

Rudi Studer is a pro-fessor in applied com-puter science at theUniversity of Karls-ruhe. His research in-terests include know-ledge management,intelligent Web appli-cations, knowledge en-

gineering, and knowledge discovery. Hereceived a doctorate in mathematics and com-puter science and a Habilitation in computer sci-ence at the University of Stuttgart. He is a mem-ber of IEEE, ACM, AAAI, and GI. Contact himat University of Karlsruhe, Institute AIFB, D-76128 Karlsruhe, Germany; [email protected].

Hans-Peter Schnurris managing director ofOntoprise GmbH, acompany providing awide range of semanticWeb technologies. Hiscurrent research inter-ests include semanticWeb and ontology-

based applications. He received a diploma inindustrial engineering and business economicsfrom the University of Karlsruhe. He iscofounder of the German association for knowl-edge management (GfWM) and member of theGerman Association for Computer Science (GI).Contact him at Ontoprise GmbH, Haid-und-NeuStr. 7, 76131 Karlsruhe, Germany; +49(0) 7216635933; Fax +49 (0) 721 6635934; [email protected].

York Sure is a PhDcandidate at the Instituteof Applied ComputerScience and FormalDescription Methodsat the University ofKarlsruhe. His currentresearch interests in-clude knowledge man-

agement, semantic Web, and ontology-basedapplications. He received a diploma in industrialengineering from the University of Karlsruhe.He is a member of the German association forknowledge management (GfWM) and the Ger-man Association for Computer Science (GI).Contact him at Institute AIFB, University ofKarlsruhe, 76128 Karlsruhe, Germany; [email protected].

T h e A u t h o r s