Modeling Expertise Using KADS and MODEL-ECS

Roberto A. Flores-Méndez
Knowledge Science Institute
University of Calgary, Canada
robertof@cpsc.ucalgary.ca

Pim van Leeuwen
Faculty of Mathematics & Computer Science
Vrije Universiteit, Amsterdam, The Netherlands
pvleeuw@cs.vu.nl

Dickson Lukose
Department of Mathematics & Computer Science
University of New England, Australia
lukose@peirce.une.edu.au

Abstract

In this paper, the authors will outline the knowledge level modeling of a simple diagnosis task in the Audio System Diagnosis domain. The Knowledge Analysis and Design Support (KADS) (Schreiber, Wielinga, and Breuker, 1993) methodology is adopted in carrying out the knowledge modeling activity, and MODEL-ECS is used as the implementation of the model. This paper attempts to demonstrate that by using a sophisticated graph-based executable modeling language (i.e., MODEL-ECS), we are able to construct an executable conceptual model of the problem solving behaviour of a domain expert. This is, indeed, a major advantage in comparison to the conventional approach that involves transforming the conceptual model into a design model, and then implementing this design model as a knowledge-based system. The approach outlined in this paper enables rapid prototyping of problem-solving behaviour (i.e., problem-solving methods (PSM)) of domain experts.

1. Introduction

In the mid-1980s, the idea of transferring knowledge from domain experts into computers to develop knowledge-based systems was replaced by the notion of modeling the behaviour of the domain expert. This fundamental shift in knowledge engineering motivated the development of a large number of knowledge modeling languages, ranging from "specification" to "programming" languages. Figure 1.1 depicts some of the methodologies and the modeling languages that have been developed in the last five years.

Knowledge Modeling Methodology	Knowledge Modeling Language
	Algorithmic
KADS (Wielinga, Schreiber and Breuker, 1992) Component of Expertise (Steels, 1990) Generic Tasks (Chandrasekaran and Johnson, 1993)	MODEL-K (Karbach and Vob, 1993) TroTelC (Vanwelkenhuysen et al., 1990) TIPS (Punch and Chandrasekaran, 1993)
	Graphical Modeling
DESIRE (Brazier et al., 1996) KADS (Wielinga, Schreiber and Breuker, 1992) KADS (Wielinga, Schreiber and Breuker, 1992)	CG-DESIRE (Moller and Willems, 1995) [CG]->(ON)->[KADS] (Moller, 1995) MODEL-ECS (Lukose,1995)

Figure 1.1. Knowledge Modeling Methodologies and Languages.

KADS is one of the knowledge modeling methodology developed in Europe (Wielinga et. al., 1993). Even though many modeling languages were developed (and to a large extent used successfully), these languages are quite difficult for domain experts to use. This is mainly due to the non-graphical nature of many of the earlier tools developed for modeling KADS.

The significance of the contribution of this paper is in our attempts to demonstrate that one should be able to execute the conceptual model, without necessarily proceeding to the "transformation" and "implementation" of the knowledge-based system. This cannot be achieved only by using a highly sophisticated declarative knowledge representation formalism (like Conceptual Graphs (Sowa, 1984)), but we also require an equivalently sophisticated representation scheme to model "processes" that can be executed. Lukose (1995, 1996, 1997) developed a graph based executable conceptual modeling language that is based on Conceptual Graphs and Executable Conceptual Structures (Lukose, 1993). Figure 1.2 shows a view of categorizing modeling languages (with a typical modeling language that fits into each of the quadrants). MODEL-ECS falls into the bottom-right quadrant (the most sophisticated type of modeling language).

	Formal Specification	Executable
Algorithmic	ML2 (van Harmelen and Balder, 1993)	MODEL-K (Karbach and Vob, 1993)
Graphical	[CG]->(on)-[KADS] (Moller, 1995)	MODEL-ECS (Lukose, 1995)

Figure 1.2. Categorization of Modeling Languages for KADS.

The outline of this paper is as follows: Section 2 will briefly describe the KADS methodology, while Section 3 will outline MODEL-ECS. In Section 4, we will show the application of KADS to the Audio System Diagnosis domain, and in Section 5, we will show how this is done using MODEL-ECS. Finally, Section 6 concludes this paper by outlining the limitations of this approach and future research directions to overcome some of these limitations.

2. KADS Methodology for Modeling Problem Solving Methods

Figure 2.1. Knowledge Categorization.

KADS is an implementation independent methodology for developing Knowledge-Based Systems (KBS). KADS views a KBS not as a container filled with knowledge extracted from an expert, but an operational model that exhibits some desired behaviour observed in terms of real-world phenomena. KADS attempts to reduce the complexity of the knowledge-modeling process by the use of multiple models (i.e., organizational model, application model, task model, model of expertise, model of cooperation, conceptual model, and design model). These models emphasize certain aspects of the system to be built, and abstracts from others. Models of expertise distinguish between four different knowledge categories: Strategic Knowledge, Task Knowledge, Inference Knowledge, and Domain Theory. Figure 2.1 depicts this knowledge categorization. Strategies are adopted to control the tasks that apply the inference that uses the domain knowledge. Lukose (1995) demonstrated the successful use of MODEL-ECS to carry out the knowledge level modeling of KADS. In the next section, the authors will briefly outline the syntax and semantics of the modeling constructs of MODEL-ECS that will enable us to build sophisticated problem solving methods.

3. MODEL-ECS

MODEL-ECS is a graphically based (i.e., visual) conceptual modeling language that is made up of Conceptual Graphs (Sowa, 1984) and Actors (Lukose, 1993). It is composed of two forms of abstractions, and a set of complex modeling constructs (Kremer, Lukose and Gaines, 1997). The two forms of abstractions are Primitive Conceptual Structures and Executable Conceptual Structures. There are two types of Primitive Conceptual Structures: Conceptual Graphs and Actors. There are also two types of Executable Conceptual Structures: Actor Graphs and Problem Maps. In addition to being highly formal, the PSMs resulting from modeling using MODEL-ECS is executable (i.e., it provides executable prototypes). This enables the knowledge engineer to immediately test, and if necessary re-design his knowledge model. This is a major advantage to the contemporary approach of performing the modeling process, and then carrying out the prototyping activity (where the prototype knowledge-based system is built).

In-depth description of MODEL-ECS is beyond the scope of this paper. A detailed description on the constructs available in MODEL-ECS can be found in Lukose (1997).

4. Application of the KADS Methodology in the Audio System Diagnosis Domain

In this paper, the authors model the Audio Systems Diagnosis task using MODEL-ECS and following the KADS methodology. Below, a detailed description is given of this knowledge modeling process. Basically, knowledge in any particular domain can be categorized into "objects" in the domain and "processes" that manipulate these objects. The KADS model of expertise distinguishes this as "control" and "domain theory". Control is further sub-divided into "strategies", "tasks" and "inference" (Wielinga, Schreiber and Breuker, 1993).

4.1. Control Knowledge

4.1.1. Task Decomposition

The main task in the Audio System Diagnosis is called systematic_diagnosis. The goal of this task is to find a faulty sub-system based on a complaint received from the user. This goal is fulfilled by generating and testing hypotheses until a sub-system can be identified that is responsible for the audio system's fault. The systematic_diagnosis task is composed of two sub-tasks: generate_hypotheses and test_hypotheses. The generate_hypotheses sub-task generates a set of (sub) systems as hypotheses to verify. This set of hypotheses is called the differential. The sub-task test_hypotheses generates tests for each one of the hypotheses contained in the differential until a difference in the expected and actual behaviour of a sub-system is found. The systematic_diagnosis task will repeat the process of generating and testing hypotheses until a non-decomposable sub-system is selected as the component showing inconsistent behaviour. Figure 4.1 depicts this task decomposition.

Figure 4.1. Systematic Diagnosis task decomposition.

4.1.2. Task Interdependencies

Once the task decomposition process is completed, the next activity is to determine the interdependencies between the leaf nodes (i.e., primitive tasks). Additionally, one needs to determine the "objects" that are manipulated by each of the primitive tasks. Each of these primitive tasks will have a set of input objects and a set of output objects. The interdependencies of each of these primitive tasks are very much determined by the object that is processed by each of them. In other words, if task T2 takes as input object OT2, and task T1 takes as input OT1 and produces object OT2, then the sequence of operation is T1 followed by T2 (where the input of T1 is OT1, and its output is OT2), and the input of T2 is OT2. In a similar manner, by analyzing the Audio System Diagnosis domain (and its primitive tasks) one could illustrate its interdependencies as depicted in Figure 4.2.

Figure 4.2. Task Interdependencies.

4.1.3. Task Distribution

The next step followed by the authors was to specify what agents are responsible for the execution of the sub-tasks included in the task structure. Figure 4.3 presents the list of sub-tasks and the agents that are responsible for these tasks. Note that only two agents are involved: the system and the user. While all the sub-tasks performed by the system conform to knowledge sources in the inference knowledge, the sub-tasks performed by the user are classified as transfer tasks (in KADS terminology).

Figure 4.3. Task Distribution.

4.2. Inference Structure

The next step is concerned with the dependencies between the primitive tasks shown in Figures 4.2 and 4.3. An inference structure for the system is created based on the inputs and outputs required by these primitive tasks. The names given to these inputs and outputs reflect the roles the information plays in the inference process: they are the meta-classes of the inference knowledge. The primitive tasks are mapped onto knowledge sources during the specification of the inference knowledge. The inference structure for the audio system example is illustrated in Figure 4.4. In this figure, the rectangles denote meta-classes and the ellipses stand for knowledge sources. This inference structure forms the problem solving method that is used by domain experts.

Figure 4.4. Inference Structure.

5. Implementing the Audio System Diagnosis PSM using MODEL-ECS

In order to represent procedural behaviour in MODEL-ECS the authors made use of the executable conceptual structures that are offered by this language: Problem Maps and Actor Graphs. Actor graphs are used to represent inference steps (knowledge sources), and problem maps are used for representing the temporal ordering of actor graphs. This temporal ordering can be created using two relations: finish before start (FBS) and start before start (SBS). These relationships are used to represent a temporal ordering between actor graphs, or no temporal ordering at all, respectively. Thus, actor graphs can be ordered in a sequential or a concurrent manner, respectively.

5.1. MODEL-ECS Representation

The task systematic_diagnosis, which is depicted in Figure 5.1, is a problem map that contains actor graphs and other problem maps. The knowledge source SELECT represents the first executable construct in this problem map. This knowledge source selects a system model for diagnosis based on a complaint received from the user. The system model selected can be either a sub-system of a specific model or an entire audio system model. Following this knowledge source is a node representing a problem map for the sub-task generate_hypothesis, which takes the selected (sub) system model and generates a set of hypotheses called the differential. Next in the sequence is a problem map containing the problem maps test_hypotheses and generate_hypotheses. This problem map is the body of a loop, which repeats the testing and generation of hypotheses until no more hypotheses can be generated for a specific (sub) system model. In the last problem map, a test is performed to decide whether to enter again or to exit the repeat loop. This problem map contains the TRUE_TEST and FALSE_TEST knowledge sources, which test for the same condition: the existence of elements in the differential. As it can be inferred, an empty set in the differential ends the execution of the systematic_diagnosis problem map.

Figure 5.1. MODEL-ECS representation of the systematic_diagnosis Task.

Figure 5.2 shows a problem map for the sub-task generate_hypothesis. This problem map takes a system model as input and applies the DECOMPOSE knowledge source to obtain a new hypothesis that is added to the differential using the INCREMENT knowledge source. Since these knowledge sources will be executed repeatedly until no more hypotheses are produced, a loop construct is required. First, the knowledge sources DECOMPOSE and INCREMENT are enclosed in a problem map which then becomes the body of the loop.

Figure 5.2. MODEL-ECS representation of the generate_hypotheses sub-task.

Second, a problem map is added to enable conditional testing of the loop. This problem map contains a TRUE_TEST and a FALSE_TEST for testing the existence of a new generated hypothesis. If such a new hypothesis is not generated, the FALSE_TEST knowledge source will be true and the system will exit the generate_hypothesis problem map. If a new hypothesis is generated, then the problem map containing DECOMPOSE and INCREMENT is executed again. Note that if DECOMPOSE does not generate a new hypothesis, the INCREMENT knowledge source will not change the contents of the differential.

Figure 5.3. MODEL-ECS representation of the test_hypotheses sub-task..

The test_hypothesis problem map, which is illustrated in Figure 5.3, contains a while loop using a conditional construct and a body problem map. The conditional construct consists of a problem map containing four knowledge sources: two TRUE_TESTs and two FALSE_TESTs. These knowledge sources check whether the differential is empty OR whether a difference between a norm and an observation has been found. If so, the while loop can be exited; if not - meaning that there are still more hypotheses to be tested AND no difference between norms and observations has been found - the loop is entered again. The body problem map of the loop contains four knowledge sources: DECREMENT, SELECT, SPECIFY and COMPARE. The first knowledge source to be executed is DECREMENT, which extracts one hypothesis from the differential. This hypothesis is then used as input for the SELECT and SPECIFY knowledge sources, which are executed concurrently. SELECT produces a finding based on the selected hypothesis and the observation of the behaviour observed in the real world. SPECIFY generates a norm defining the expected behaviour for the hypothesis. After these knowledge sources have been executed, the knowledge source COMPARE will be allowed to execute. The goal of this knowledge source is to compare the norm generated by SPECIFY with the finding that is the output of SELECT. If a difference is found, it can be concluded that the hypothesis tested is - or comprises - the faulty system part.

5.2. Inference Knowledge Revisited

The next step is to specify the knowledge sources in detail. Every knowledge source produces new knowledge based on old knowledge. Knowledge sources are represented in MODEL-ECS as Actor Graphs. Actor Graphs are composed of a conceptual graph describing the knowledge source in terms of the domain, a procedural knowledge (which specifies how the new knowledge is to be created from the old knowledge), and a pre-condition, post-condition, and delete lists (which are sets of graphs describing the conditions for the actor graph to execute, the result of execution, and the graphs that have to be erased from memory after execution, respectively). An example of an actor graph identified for the diagnosis task is specified as in Figure 5.4. The actor graph SELECT selects an appropriate system_model based on a complaint. Note that the procedural part of these actor graphs is not specified here: this procedural knowledge is inherited from the ACT type, from which all actor graphs are subtyped. Note also, that names are introduced that will have to conform to certain concepts in the domain. These names are the meta-classes in the inference knowledge.

[ACT: *x]-
         ->(ARG) ->[COMPLAINT: *c]
         ->(RSLT)->[SYSTEM_MODEL: *a]

        Method for Select

PRE -CONDITIONS: [COMPLAINT: *c]
POST-CONDITIONS: [SYSTEM_MODEL: *a]
         DELETE: [COMPLAINT: *c]

Figure 5.4. Actor Graph for SELECT.

5.3. Domain Knowledge Revisited

A next step is to define the domain knowledge. The meta-classes of the inference knowledge will have to refer to graphs existing in the domain. In MODEL-ECS, domain knowledge can be specified by a cannon, which consists of a type hierarchy, a set of individual markers, a conformity relation (which relates individual markers to types), and a canonical basis (which is a set of conceptual graphs from which all canonical graphs can be derived). The type hierarchy, as well as the set of conceptual graphs that forms the canonical basis for the domain, are presented ahead in this section. Individual markers and the conformity relation do not need to be defined, since they play no role in the problem solving process. Note that the canonical basis should contain all the graphs that are referred to in the definition of the meta-classes.

META-CLASS	DOMAIN GRAPHS
Complaint	[PRODUCE]- ->(agnt)->[COMPONENT] ->(rslt)->[ENTITY]->(stat)->[STATE] [NOT: [ENTITY]] [COMPONENT]->(stat)->[STATE]
System_Model, Hypothesis	[COMPONENT]
Observable, Norm, Finding, Difference	[ANT:[[COMPONENT: c]->(stat)->[STATE: x]]->(and)-> [[COMPONENT: c]->(stat)->[STATE: x]]->(and)-> [[COMPONENT: c]->(stat)->[STATE: x]]] ->(caus)-> [CON:[PRODUCE]- ->(agnt)->[COMPONENT] ->(rslt)->[ENTITY]] [COMPONENT]->(stat)->[STATE]

Table 5.1. Examples of Domain Theory Used by the Meta-Classes in the Knowledge Sources.

Table 5.1 shows examples of graphs in the domain theory that can be related to the meta-classes used in the definition of the knowledge sources. Examples of specific graphs conforming to meta-class COMPLAINT may include:

[TAPE-PLAYER] -> (STAT) -> [JAMMED]

[PRODUCE]-
         -> (AGNT) -> [AMPLIFIER]
         -> (RSLT) -> [OUTPUT-SIGNAL] -> (STAT) -> [DISTORTED]

Two examples for the meta-classes OBSERVABLE, NORM, FINDING or DIFFERENCE are:

[ANT: [PROP: [AMPLIFIER] -> (STAT) -> [ON]]        -> (AND) ->
      [PROP: [AMPLIFIER] -> (STAT) -> [CONNECTED]] -> (AND) ->
      [PROP: [AMPLIFIER-VOLUME-KNOB]  -> (STAT) -> [ON]]
                         -> (CAUS) ->
[CON: [PROP: [AMPLIFIER] <- (AGNT) <- [PRODUCE] -> (RSLT) -> [OUTPUT-SIGNAL]]

[AMPLIFIER-POWER-SWITCH] -> (STAT) -> [ON]

Meta-classes are related to conceptual graphs in the domain. Some knowledge about the domain is needed to relate the meta-classes to the domain, and domain theories have to be defined. For example, SOUND is an ENTITY produced by another ENTITY. This can be defined as follows:

type SOUND (x) is:
[ENTITY: *x]-
           <- (RSLT) <- [PRODUCE] -> (AGNT) -> [ENTITY:*y]

Figure 5.5. Type Hierarchy for the Audio Diagnosis Domain.

A type hierarchy tree (as illustrated in Figure 5.5) shows the IS-A relationships that may exist between the different types discerned in the domain. In addition, the "objects" in the domain are required to conform to the concept types. This information is maintained in the Conformity Relations Table. For all components (and the audio system is a component as well), knowledge of the parts that constitute a component should exist. For an amplifier, for example, this knowledge can be represented as follows:

[AMPLIFIER]-
           ->(PART)->[AMPLIFIER-VOLUME-KNOB]
           ->(PART)->[AMPLIFIER-BALANCE-KNOB]
           ->(PART)->[AMPLIFIER-POWER-SWITCH]

This domain knowledge is necessary for the DECOMPOSE knowledge source to decompose hypotheses - the meta-class name for a component - into sub-components. Next to this, domain knowledge is also needed about the behaviour of different components. This knowledge is necessary to find the norm for a certain component: the norm is a meta-class name for the normal behaviour of a component. For example, the following knowledge about the behaviour of an amplifier may be necessary:

[AMPLIFIER]-
           <-(AGNT)<-[AMPLIFY]-
           ->(RSLT)->[OUTPUT_SIGNAL]
           ->(OBJ) ->[INPUT_SIGNAL]

Having derived these types of domain knowledge, they can be combined into complete type definitions. For example, the type definition for an amplifier could be as follows:

[AMPLIFIER]-
           -> (PART) -> [AMPLIFIER-VOLUME-KNOB]
           -> (PART) -> [AMPLIFIER-BALANCE-KNOB]
           -> (PART) -> [AMPLIFIER-POWER-SWITCH]
           <- (AGNT) <- [AMPLIFY]-
                                       -> (RSLT) -> [OUTPUT_SIGNAL]
                                       -> (OBJ)  -> [INPUT_SIGNAL]

5.4. Strategic Knowledge

Finally, the strategic knowledge is specified. As mentioned, this type of knowledge is concerned with the dynamic strategy to be used to solve the main problem. Goals are associated with tasks in the task hierarchy, and the strategic knowledge specifies what (sub) goal the system should attempt to achieve and under what conditions. Strategic knowledge specifies which goals the system should try to reach based on for example the success or failure in reaching other goals. However, it is possible for the system to fail to generate a new hypothesis. In such an event, a new goal for the system could be get_hypo_from_user, a goal which has a task associated with it in which the user is asked to provide a hypothesis. This rule could be represented in MODEL-ECS by means of the following Actor Graph:

actor graph specify_new_goal_for_generate_hypotheses (x) is:
[ACT: *x]-
         -> (ARG)  -> [FAIL] -> (OBJ) -> [GOAL: generate_hypo's]
         -> (RSLT) -> [GOAL: get_hypo's_from_user]

For this to work, a type definition of fail should exist that defines FAIL as a subtype of ACT, and another type definition has to be brought into existence in order to define goal in terms of an entity. The pre- and post-conditions and the delete list of this actor graph could become:

PRE -CONDITIONS: [GOAL: generate_hypo's]
POST-CONDITIONS: [GOAL: get_hypo's_from_user]
DELETE         : [GOAL: generate_hypo's]

Note that this newly created actor graph can be seen as a knowledge source that produces strategic knowledge: knowledge on what (new) goal the system should try to achieve. Note also, that generate_hypo's and get_hypo's_from_user are instances that conform to the meta-class-type GOAL.

6. Conclusion

In this paper, the authors briefly described the KADS methodology to carry out knowledge level modeling of expertise, and how this is done using MODEL-ECS. This process was demonstrated using the example of an Audio System Diagnosis. We demonstrated how the model of expertise is represented using Conceptual Graphs (to represent the basic concepts and instances) and Executable Conceptual Structures (to represent Knowledge Sources). We further used the complex modeling constructs of MODEL-ECS to represent the executable model of the "Systematic Diagnosis" problem-solving method. Note further that the strategic knowledge is also represented using MODEL-ECS.

Even though MODEL-ECS is a sophisticated conceptual modeling tool, the graphical notation is fairly complex, difficult to understand by non-knowledge engineers, and somewhat cumbersome to handle. Since knowledge-modeling languages have to be usefully employed by (non-knowledge engineer) domain experts, simplicity and ease of use are two primary requirements. It therefore seems worthwhile to investigate the possibility of combining the power of a language like MODEL-ECS with the simplicity and ease of use of a simpler, but not-quite-so-expressive, language. Kremer, Lukose and Gaines (1997) attempt to use annotated flow chart diagrams as such a simpler graphical notation to be combined with MODEL-ECS. Another line of research is concerned with enabling several knowledge engineers (from different geographical locations) to interact and synchronously model problem-solving methods. This may require the use of client-server models of computation, such as WWW-based applications. An example of such a WWW-based collaborative system can be found in (Flores-Méndez, 1997).

7. References

Brazier, F., Dunin-Kepliczb, B., Treura, J. and Verbruggea, R. (1996). Beliefs, Intentions and DESIRE, in Gaines, B. and Musen, M. (Eds.), Proceedings of the 10th Workshop on Knowledge Acquisition and Knowledge Base Systems (KAW�96), Voyager Inn, Banff, Alberta, Canada, November 8-14, 1996.

Chandrasekaran, B. and Johnson, T. (1993). Generic tasks and Tasks Structures: History, Critique and New Directions, in J.M. David, J.P. Krivine, and R. Simmons (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany.

Flores-Méndez, R. (1997). Java Concept Maps for the Learning Web, in Proceedings of the World Conference on Educational Multimedia and Hypermedia (ED-MEDIA �97), Calgary, Alberta, Canada, June 14-17, 1997.

Karbach, W., and Vob, A. (1993). MODEL-K for Prototyping and Strategic Reasoning at the Knowledge level, in J.M. David, J.P. Krivine, and R. Simmons (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany.

Kremer, R., Lukose, D., and Gaines, B. (1997). Knowledge Modeling using Annotated Flow Chart, in Proceedings of the International Conference on Conceptual Structures (ICCS '97), Seattle, Washington, USA, August 4-8, 1997.

Lukose, D. (1993). Executable Conceptual Structures, in G.W. Mineau, B. Moulin and J.F. Sowa (Eds.), Conceptual Graphs for Knowledge Representation, Lecture Notes in Artificial Intelligence, Springer-Verlag, Berlin, Germany.

Lukose, D. (1995). Using Executable Conceptual Structures for Modeling Expertise, in Gaines, B. and Musen, M. (Eds.), Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop (KAW�95), Banff Conference Centre, Banff, Alberta, Canada, 1995.

Lukose, D. (1996). MODEL-ECS: Executable Conceptual Modeling Language, in Gaines, B. and Musen, M. (Eds.), Proceedings of the 10th Knowledge Acquisition for Knowledge Based Systems Workshop (KAW'96), Voyager Inn, Banff, Alberta, Canada, November 9-14, 1996.

Lukose, D. (1997). Complex Modeling Constructs in MODEL-ECS, in Proceedings of the International Conference on Conceptual Structures (ICCS'97), Seattle, Washington, USA, August 4-8, 1997.

Moller, J-U. (1995). Operationalisation of KADS Models by using Conceptual Graph Modules, in Gaines, B. and Musen, M. (Eds.), Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop (KAW �95), Banff Conference Centre, Banff, Alberta, Canada, 1995.

Moller, J-U. and Willems, M. (1995). CG-DESIRE: Formal Specification Using Conceptual Graphs, in Gaines, B. and Musen, M. (Eds.), Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop (KAW �95), Banff Conference Centre, Banff, Alberta, Canada, 1997.

Punch, W.F. and Chandrasekaran, B. (1993). An Investigation of the Roles of Problem-Solving Methods in Diagnosis, in David, J.M., Krivine, J.P., and Simmons, R., (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany.

Schreiber, G., Wielinga, B. and Breuker, J. (1993). KADS: A Principled Approach to Knowledge-Based System Development. Academic Press, London, UK.

Sowa, J.F. (1984). Conceptual Structures: Information Processing in Mind and Machine. Addison Wesley, Reading, Mass., USA.

Steels, L. (1990). Components of Expertise. AI Magazine, 11(2).

van Harmelen, F. and Balder, J. (1993). (ML)2: A Formal Language for KADS Models of Expertise, in G. Wielinga, B., Schreiber, A.T. and Breuker, J.A. (Eds.), Modeling Expertise in KADS: A Principled Approach to Knowledge-Based System Development, Academic Press, London, UK.

Vanwelkenhuysen, J. and Rademakers, P. (1990). Mapping a Knowledge Level Analysis onto a Computational Framework, in Proceedings of the 9th European Conference on Artificial Intelligence, Pitman Publishing, London, UK.

Wielinga, B., Schreiber, A.T. and Breuker, J.A. (1992). KADS: A Modeling Approach to Knowledge Engineering, in The KADS Approach to Knowledge Engineering Special Issue, Knowledge Acquisition, 4(1), Academic Press, London, UK.

Wielinga, B., Schreiber, A.T. and Breuker, J.A. (1993). Modeling Expertise. KADS: A Principled Approach to Knowledge-Based System Development, Academic Press, London, UK.

[Top of Page]