This paper gives an overview about the development of the field of Knowledge Engineering over the last 15 years. We discuss the paradigm shift from a transfer view to a modeling view and describe two approaches which considerably shaped research in Knowledge Engineering: Role-limiting Methods and Generic Tasks. To illustrate various concepts and methods which evolved in the last years we describe three modeling frameworks: CommonKADS, MIKE, and PROTÉGÉ-II. This description is supplemented by discussing some important methodological developments in more detail: specification languages for knowledge-based systems, problem-solving methods, and ontologies. We conclude with outlining the relationship of Knowledge Engineering to Software Engineering, Information Integration and Knowledge Management. Knowledge Engineering, Knowledge Acquisition, Problem-Solving Method, Ontology, Information Integration In earlier days research in Artificial Intelligence (AI) was focused on the development of 2 formalisms, inference mechanisms and tools to operationalize Knowledge-based Systems (KBS). Typically, the development efforts were restricted to the realization of small KBSs in order to study the feasibility of the different approaches. Though these studies offered rather promising results, the transfer of this technology into commercial use in order to build large KBSs failed in many cases. The situation was directly comparable to a similar situation in the construction of traditional software systems, called "software crisis" in the late sixties: the means to develop small academic prototypes did not scale up to the design and maintenance of large, long living commercial systems. In the same way as the software crisis resulted in the establishment of the discipline Software Engineering the unsatisfactory situation in constructing KBSs made clear the need for more methodological approaches. So the goal of the new discipline Knowledge Engineering (KE) is similar to that of Software Engineering: turning the process of constructing KBSs from an art into an engineering discipline. This requires the analysis of the building and maintenance process itself and the development of appropriate methods, languages, and tools specialized for developing KBSs. Subsequently, we will first give an overview of some important historical developments in KE: special emphasis will be put on the paradigm shift from the so-called transfer approach to the so-called modeling approach. This paradigm shift is sometimes also considered as the transfer from first generation expert systems to second generation expert systems [43] . Based on this discussion Section 2 will be concluded by describing two prominent developments in the late eighties: Role-limiting Methods [99] and Generic Tasks [36] . In Section 3 we will present some modeling frameworks which have been developed in recent years: , and PROTÈGÈ-II [123] . Section 4 gives a short overview of specification languages for KBSs. Problem-solving methods have been a major research topic in KE for the last decade. Basic characteristics of (libraries of) problem-solving methods are described in Section 5. Ontologies, which gained a lot of importance during the last years are discussed in Section 6. The paper concludes with a discussion of current developments in KE and their relationships to other disciplines. In KE much effort has also been put in developing methods and supporting tools for knowledge elicitation (compare [48]  Historical Roots In this section we will first discuss some main principles which characterize the development of KE from the very beginning. "This transfer and transformation of problem-solving expertise from a knowledge source to a program is the heart of the expert-system development process." [81] In the early eighties the development of a KBS has been seen as a transfer process of human 3 knowledge into an implemented knowledge base. This transfer was based on the assumption that the knowledge which is required by the KBS already exists and just has to be collected and implemented. Most often, the required knowledge was obtained by interviewing experts on how they solve specific tasks [108] . Typically, this knowledge was implemented in some kind of production rules which were executed by an associated rule interpreter. However, a careful analysis of the various rule knowledge bases showed that the rather simple representation formalism of production rules did not support an adequate representation of different types of knowledge [38] : e.g. in the MYCIN knowledge base [44] strategic knowledge about the order in which goals should be achieved (e.g. "consider common causes of a disease first") is mixed up with domain specific knowledge about for example causes for a specific disease. This mixture of knowledge types, together with the lack of adequate justifications of the different rules, makes the maintenance of such knowledge bases very difficult and time consuming. Therefore, this transfer approach was only feasible for the development of small prototypical systems, but it failed to produce large, reliable and maintainable knowledge bases. Furthermore, it was recognized that the assumption of the transfer approach, that is that knowledge acquisition is the collection of already existing knowledge elements, was wrong due to the important role of tacit knowledge for an expert's problem-solving capabilities. These deficiencies resulted in a paradigm shift from the transfer approach to the modeling approach. Nowadays there exists an overall consensus that the process of building a KBS may be seen as a modeling activity. Building a KBS means building a computer model with the aim of realizing problem-solving capabilities comparable to a domain expert. It is not intended to create a cognitive adequate model, i.e. to simulate the cognitive processes of an expert in general, but to create a model which offers similar results in problem-solving for problems in the area of concern. While the expert may consciously articulate some parts of his or her knowledge, he or she will not be aware of a significant part of this knowledge since it is hidden in his or her skills. This knowledge is not directly accessible, but has to be built up and structured during the knowledge acquisition phase. Therefore this knowledge acquisition process is no longer seen as a transfer of knowledge into an appropriate computer representation, but as a model construction process ([41], [106] ). This modeling view of the building process of a KBS has the following consequences: • Like every model, such a model is only an approximation of the reality. In principle, the modeling process is infinite, because it is an incessant activity with the aim of approximating the intended behaviour. • The modeling process is a cyclic process. New observations may lead to a refinement, modification, or completion of the already built-up model. On the other side, the model may guide the further acquisition of knowledge. • The modeling process is dependent on the subjective interpretations of the knowledge engineer. Therefore this process is typically faulty and an evaluation of the model with respect to reality is indispensable for the creation of an adequate model. According to this feedback loop, the model must therefore be revisable in every stage of the modeling process. 4 In [39] Clancey reported on the analysis of a set of first generation expert systems developed to solve different tasks. Though they were realized using different representation formalisms (e.g. production rules, frames, LISP), he discovered a common problem solving behaviour. Clancey was able to abstract this common behaviour to a generic inference pattern called Heuristic Classification, which describes the problem-solving behaviour of these systems on an abstract level, the so called Knowledge Level [113]. This knowledge level allows to describe reasoning in terms of goals to be achieved, actions necessary to achieve these goals and knowledge needed to perform these actions. A knowledge-level description of a problemsolving process abstracts from details concerned with the implementation of the reasoning process and results in the notion of a Problem-Solving Method (PSM). A PSM may be characterized as follows (compare [20]): • A PSM specifies which inference actions have to be carried out for solving a given task. • A PSM determines the sequence in which these actions have to be activated. • In addition, so-called knowledge roles determine which role the domain knowledge plays in each inference action. These knowledge roles define a domain independent generic terminology. When considering the PSM Heuristic Classification in some more detail (Figure 1) we can identify the three basic inference actions abstract, heuristic match, and refine. Furthermore, four knowledge roles are defined: observables, abstract observables, solution abstractions, and solutions. It is important to see that such a description of a PSM is given in a generic way. Thus the reuse of such a PSM in different domains is made possible. When considering a medical domain, an observable like "41 0 C" may be abstracted to "high temperature" by the inference action abstract. This abstracted observable may be matched to a solution abstraction, e.g. "infection", and finally the solution abstraction may be hierarchically refined to a solution, e.g. the disease "influenca". In the meantime various PSMs have been identified, like e.g. Cover-and-Differentiate for solving diagnostic tasks [99] or for parametric design tasks. PSMs may be exploited in the knowledge engineering process in different ways:
The ontology, originally defined as "a formal, explicit specification of a shared conceptualization" REF , has been considered as a key technology in knowledge engineering.
Knowledge Engineering: Principles and Methods
Data Knowl. Eng.
Computer Science