TASK MODEL - CiteSeerX

9th AAAI sponsored Knowledge Acquisition for Knowledge Based Systems Workshop, KAW'94, Banff, Canada, S R D G Publications, University of Calgary. 1994.

T ASK M ODEL : a framework for the design of Models of Expertise and their operationalization Christine PIERRET-GOLBREICH LRI, CNRS URA 410 Intelligence Artificielle & Systèmes d'Inférence Université Paris Sud 91405 Orsay Cedex, France Tel. : (33-1) 69. 41. 64. 99 Email: pierret @ lri.lri.fr

The claim of TASK MODEL approach is that the construction of knowledge based systems at the Knowledge Level requires a coherent framework, which takes into account the implicit interactions between knowledge modelling, representation, and acquisition. The objective of TASK MODEL, therefore consists in dealing with these questions in a global manner so as to provide a framework including both (i) a conceptual modelling paradigm, Task Oriented Modelling, (ii) a high level representation language, the Task language, and (iii) a knowledge acquisition method, Task Oriented Acquisition. An original point of TASK MODEL is that the same Task language is used both to represent Generic Models, Meta-scheme of expertise, and also to operationalize the Model of Expertise of an application. 1. INTRODUCTION It is nowadays clearly recognized that many difficulties often arise with knowledge based systems (KBS). Part of these difficulties originate in the conceptual distance between the level of natural expression of expertise and the level of computational representation of knowledge. Issued from different motivations, two trends of work aim to tackle this problem in a different manner (Fig.1). (1) "Knowledge Representation" - "NEW ARCHITECTURES" Kowledge level =>

high level formalisms

TASK, CARMEN, TIPS

BB, SOAR

GTs - TSA - RLM - CE, etc. (2) " Knowledge Acquisition" Level Knowledge natural expression

informal

INTERMEDIATE Model e.g. KADS Conceptual Model

knowledge

Symbol knowledge representation

facilitate knowledge acquisition =>

implementation

Language natural specifications formalisms

specifications languages (ML2, KARL, MODEL-K etc.)

Fig. 1 : Two trends of work within the knowledge level hypothesis.

A first category of works, addressed it from the Knowledge Representation perspective. Such works were mainly motivated by the limits encountered with first generation expert systems : the implicit control due to classical formalisms (rules, frames, logic), the limited explanations, the problems met with knowledge acquisition, updating etc. So this trend enhanced architectures designed so that knowledge may be explicitly represented at a "better" level of abstraction, the knowledge level (Newell, 1982). Thus, they proposed either high level formalisms or high level

1

shells (Chandrasekaran, 1988). Another category of works, addressed the problem from the Knowledge Acquisition perspective. Mainly motivated by the limits encountered with classical acquisition techniques consisting of passing directly from expert knowledge to an executable representation, they recommend an alternate approach, the model driven approach of knowledge engineering. Rather than high level formalisms, this trend suggests on its part to tackle the 'gap' problem, the construction of intermediate high level models. These approaches being mainly focused on knowledge modelling methodologies, these models were first only informal, since not implemented. More recently, several projects have moved to their operationalization, and proposed languages which make them executable KARL (Fensel, 1991), MODEL-K (Karbach &, 1991), OMOS (Linster, 1992) are such executable specifications languages. Formal languages like ML2 (Harmelin, 1992) have also been suggested. The TASK MODEL approach, is merging these two perspectives : it proposes a high level language, intended both for the design of models of expertise based on the specialization and instanciation of intermediate high level models and for the implementation of the final KBS. After a quick survey over the modelling view (§2), the main characteristics of the T ASK MODEL perspective of knowledge engineering and their implications for Architecture and Acquisition are presented (§3). Examples of generic Diagnosis Models and of a real life diagnosis are given (§ 4). TASK MODEL is finally compared with other significant knowledge engineering approaches (§ 5). 2. THE MODELLING VIEW OF KNOWLEDGE ENGINEERING The construction of a KBS is a long and complex process referred by the term of knowledge engineering. Knowledge engineering (KE) has conventionally been viewed as an extraction/transcription process. Nowadays an opposite view, the modelling view, considers it as a knowledge modelling process involving the construction of a series of models (Breuker, 1989). The term model is largely employed in the AI and KBS literature but is sometimes confusing. Steels uses the term model in "... its broadest possible sense : a model makes abstraction from certain aspects of reality. It identifies objects, relationships, properties and attributes of the objects, relationships between properties of objects, and so on" (Steels, 1992). For (Karbach, 1991), a model is "a purposeful abstraction that allows to reduce complexity for focusing on certain aspects". For (DeMarco, 1982) "a model reflects, through abstraction of detail, selected characteristics of the empirical system in the real world that it stands for. Thus, in spite of different uses of the word, it is generally agreed that a model usually refers to the common notion of abstraction or idealization of a real world system. However, it is important to underline that although a great attention has been paid, specially by KADS, to the analysis of the different intermediate models involved in the overall knowledge engineering task, other models are also concerned by the KE process but those are not always elicited, sometimes neglected or confused. In fact, the KE involves a lot of models of different nature and one question often arises : what model is it about ? For instance, owing to the knowledge level hypothesis, much care has naturally been mainly devoted to the distinction between the design model, a model of the final system implemented in a given computational architecture and the conceptual model (or model of expertise), a model independent of a special implementation, which specifies the behaviour of the final system (Wielinga &, 1992, p.12). But, less attention has often been paid to investigate the underlying assumptions of the knowledge engineering approach itself from which these models derive, i. e. the "meta-model" of the knowledge modelling, and its implications both for the model of the architecture used to implement the final KBS, and for the model of the acquisition process. The assumption of this work is that a KE approach for KBS construction at the knowledge level is supported by three basic elements : a knowledge modelling theory, a target computational architecture providing representation data structures and associated control mechanisms and finally a knowledge acquisition method. Each of these components implies its own specific model, depending on the KE choices. A KE approach must then be analysed along three dimensions, each one being characterized by its own model : (i) the first one is the meta-model i.e. the model underlying the modelling theory (e.g. four layers theory of KADS, multi-points of view of Components of Expertise etc.); (ii) the second one is the architecture model, i.e. the model of the architecture i.e. the general computational model type underlying the architecture used for the final

2

implementation. Such classical models are for instance, rule based model, blackboard model, or hybrid models supporting more complex architecture 1; (iii) the third one is the acquisition process model, i.e. the model of the knowledge acquisition process when building a KBS in accordance to a specific KE approach e.g. "KADS by KADS", that is the KADS model of the problem "Knowledge Acquisition" itself in accordance to the KADS perspective. Then, an interesting question to ask is what are the relations between these different models. Are they interrelated or not ? Are the meta-model and the architecture model really independent, as postulated by some knowledge engineering approaches arguing of the knowledge level hypothesis formulated by Newell which states the existence of knowledge independent of its representation ? Otherwise what are their links ? Different knowledge modelling approaches have been developed such as KADS, Generic Task, Method-to-Task, Role-limiting-method, Components of Expertise (CoE) etc. They are not unanimous about the answers. In (Pierret, 1993) KADS and CoE approaches have been selected to look into these questions. A careful investigation has brought to light that the theoretical independence between knowledge and representation was not as obvious as affirmed. Though KADS and CoE do not have the same opinion about when the operationalization step should take place (conceptual modelling and implementation are separate steps within KADS whereas not within CoE), they however have converging views about the target architecture. They both assert a theoretical indifference towards the final architecture but nevertheless at the same time the needs of a mapping relation between the conceptual structures and the computational ones is recognized. In fact, KADS explicitly mentions it, since recommending "structure-preserving design", whereas CoE applies it in practice, since knowledge level descriptions are related to the code level by some mechanisms insuring the interdependence (through application kit-managers). In conclusion, both in KADS and CoE there exists some dependency link between the meta-model and the target architecture model. Finally, the conceptual modelling, representation and acquisition independence is relative and should be cautiously considered. The own position of TASK MODEL about these issues is now presented. 3. THE TASK MODEL PERSPECTIVE T ASK M ODEL more generally asserts that as soon as a final KBS is intended to be built at the Knowledge Level, the meta-model, the architecture model and the acquisition process model are interfering during the overall KE process. This point will be discussed and much argued thereafter (§3.3). One basic idea of TASK M ODEL , thus consists in dealing with the questions of (i) conceptual modelling, (ii) computational representation, (iii) acquisition, in a global manner which takes their interactions right away into account. As the aim of TASK MODEL is to propose a global coherent framework in accordance with the Knowledge Level hypothesis, a feedback to this hypothesis is first required. The TASK MODEL perspective is then reported. Its basic components (Fig.3), the Task Oriented Modelling (§3.2), the Task Oriented Representation (§3.3), the Task Oriented Acquisition (§3.4), and their interrelations are described. 3.1. Implications of the knowledge level principle for Knowledge Engineering The Knowledge Level hypothesis (KL) appeared in the context of a level description of systems. One of the main motives of the KL definition was to clearly separate the notions of knowledge and of representation. Thus, Newell has postulated that : "there exists a distinct computer systems level, lying immediately above the symbol level, which is characterized by knowledge as the medium and the principle of rationality as the law behaviour" (Newell, 1982). The implications of this hypothesis for knowledge modelling, are now considered. Various interpretations of Knowledge Level implications for KE. D i v e r s e interpretations or distortions have been made from this definition (Ganascia, 1991) and for instance, the practical interpretation of KL made by KADS or Components of expertise for KBS development, are somewhat different. 1 this is not to say that these classical architecture models are the right models for the final KBS implementation

3

"KADS" interpretation:. within KADS, "the conceptual models are abstract descriptions of the objects and operations that a system should know about, formulated in such a way that they capture the intuitions that humans have of this behaviour… The term conceptual model denotes, according to KADS acceptance, "a combined, implementation-independent, model of both expertise and co-operation". Thus, the KADS conceptual model is often considered as an intermediate model of expertise designed at the KL (Fig.2). Abstraction Knowledge Level Epistemological Conceptual

C. M.

interpret

transform

D.M. Logical implement Implementational

Linguistic PS behavior

SBC System realisation

Fig. 2 : The role of conceptual model (CM) and design model (DM) in Knowledge Acquisition (adapted from (Breuker &, 1989))

Though the separation between conceptual modelling and implementation is recognized to be the strength of KADS and of its success, it is not exact to deduce from that point that KADS conceptual model really belongs to the KL. On one hand, it must be noted first that the level of KL is ambiguous in itself, for instance what means "immediately above the symbol level"? On the other hand, it must be also noticed that a KADS conceptual model merges different levels of genericity in the problem solving knowledge description : the knowledge of the upper three layers (that make up the interpretation models) are generic i.e. at least theoretically domain-independent, while the lowest layer knowledge are domain-dependant. Moreover, KADS conceptual model is explicitly viewed as "a functional specification of the behaviour of the artefact to be built" (Wielinga &, 1992). So, the level addressed by a conceptual model is also ambiguous in itself. Therefore, in regards to all these observations, because of the ambiguity about both the KL and conceptual model meanings and their level of genericity (or abstraction), and even though KADS layers may be viewed as an extension of the characterization of knowledge given in the KL (medium and law behaviour), the membership of the conceptual model of KADS to the so called KL is not a so straightforward evidence… "CoE" interpretation : in contrast, the CoE approach presents a different interpretation of the KL : "the KL has been introduced by Newell as a level to talk about the knowledge implied in an intelligent system, rather than in terms of physical object with particular properties and relations. The KL is there viewed as "the level at which users interact with the system" (Steels, 1992). Rather than completing the KL structure like KADS, the CoE approach has a more operational view : CoE unlike KADS, aims to make KL models operational. Thus, though the knowledge description of a task is independent of the implementation (symbol level) like in KADS, on the contrary its level of description is domain-dependent, at least according to the examples presented in (Steels, 1992), which are completely instantiated on the domain. In conclusion, the converging interpretation of the knowledge level which seems to come out from the KE engineering practice, is that it is mainly defined by opposition to the symbol level : the "right" level for the problem solving expertise modelling is the KL opposed to the symbol level. This level is also often referred as the "conceptual modelling level" independent from "representation". So, the KL hypothesis implications for knowledge modelling concerns the LEVEL of modelling, but does not seem to imply any special view about WHAT knowledge should be described at this level or HOW the knowledge concerning the system to be modelled, should be organized. Therefore, competing approaches have been proposed in respect with the KL hypothesis, while corresponding to different types and organization of modelling or addressing

4

knowledge with various level of genericity. These approaches may be classified according several dimensions such as their meta-model, the knowledge genericity or possibility of reuse etc. For instance, in regards to the knowledge organization point of view, it is possible to classify the metamodels into layers based models (e.g. KADS), task based models (e.g. Generic Tasks), viewpoints based models (e.g. CoE) etc. As regards to genericity, it has just been related that conceptual modelling is mostly focused on real tasks at the knowledge user level2 within CoE, whereas the KADS conceptual model is hybrid and partly concerned by generic knowledge. In fact, the term "conceptual modelling" is also ambiguous and often confusing, since it may be used either in a meaning similar to that of the conceptual model for database, which then only implies implementation-independence, or it may also be used in a meaning similar to the interpretation models, generic tasks, role-limiting methods etc, which then implicitly imply domain-independence, genericity or reusability. Thus, several questions are still open and would merit some precision : what level of genericity, the Knowledge Level or the so called "conceptual modelling" and the respective underlying meta-models, should in practice really address ? How the KL knowledge should be organized ? T ASK M ODEL viewpoint about "Problem Solving" at the knowledge level. In spite of differences about the categories of knowledge related to different meta-models and of vocabulary, it however appears that some converging view concerning modelling at the knowledge level may however be found. Indeed, it can be noted that in practice, when modelling at the KL, knowledge are distinguished between different categories, according to the ROLE they play in the problem solving process. TASK MODEL perspective is grounded on a similar view and has proposed on its part its own categorization of knowledge based on a functional analysis of problem solving knowledge. The "problem solving" problem may be modelled at the knowledge level as follows : the 'problem solving' task encompasses a goal to be achieved by means of some (i) resolution knowledge which tells how this goal may be satisfied, (ii) according to some context indicating what are the given domain knowledge (input knowledge) and the consequent results of this achievement (output knowledge), (iii) control knowledge which states when and which resolution knowledge should be applied on domain knowledge for that purpose. This analysis exhibits three different roles of knowledge within a single problem solving task : domain knowledge, resolution knowledge, control knowledge3 (§3.2). The knowledge level concept of TASK-MODEL has been defined so that to refer to the global knowledge involved in problem solving according to a typology of knowledge matching the different ROLES described just above. This concept refers to any type of problem solving module and does not presupposes a particular level of genericity. Thus, TASK -M ODEL looks to be the right knowledge level concept for modelling in an implementation independent fashion any domain dependant or independent problem solving task 3.2. Task Oriented Modelling Depending on KE approaches and their underlying meta-model, different types of conceptual modelling have been distinguished : layer oriented modelling (e.g. KADS), multiple viewpoints oriented modelling (e.g. CoE), task oriented modelling (e.g. Generic Tasks) etc. Each approach, has defined its own primitive modelling components and has its opinion about the independence between these categories. For KADS, they do not interact4 : "generic types of knowledge can be 2 The only thing pointed out here, is that in [20], the KL is assimilated with the user level or application level and

does not include generic knowledge. This does not imply that generic problem solving methods have become obsolete within CoE, but their use within COMMET is not yet so well defined at the present state of the paper. 3 In fact, this categorization seems not so far from the epistemological categories of CoE (domain, problem solving methods, task) or KADS (domain, inference, task, strategy) and offers similarities with the presently categorization proposed by KADS II (domain, inference, task), when focusing on these categories roles within problem solving. Perhaps some agreement will be possible to be found. 4 However, this point seems not to be in reality completely clear even in KADS itself, since it is said at the same time in [23] : "...there are distinct advantages in separating the domain theory from the way it is used by the inferences. This is not to say that we claim that a domain theory can in general be defined completely independent of

5

organized in layers which have limited interactions" (Breuker &, 1989). In contrast, for the Generic Tasks approach, the different components of knowledge are strongly intertwined since according to the Interaction Hypothesis of Chandrasekaran. For CoE, the degree of independence between the task, method, domain perspectives is not clearly specified, at least in (Steels, 1992) and it is difficult to conclude. TASK MODEL suggests on its part a Task Oriented Modelling approach which is grounded on the following principles : The first one corresponds to a functional view of problem solving. The idea is that expertise is modelled as several tasks which cooperate to solve a global problem, each task being assigned with a specific competence corresponding to a typical goal. The second one distinguishes three primary (epistemological) categories of knowledge: domain, resolution and control. Domain knowledge expresses the static knowledge that a task is about (the concepts, their properties, relations and organization) while resolution and control concern the dynamic knowledge that play a control role during the problem solving process. Resolution, on its part refer to the problem solving knowledge which operate on domain knowledge, while control controls the resolution i.e. operates on resolution or control knowledge. The last and essential hypothesis of Task Oriented Modelling considers that the different categories of knowledge involved in solving a problem, constitute a global bundle of interdependent knowledge. Thus, the third principle joins the Interaction Hypothesis of Generic Tasks (Bylander &, 1988) (Chandrasekaran, 1988) : knowledge form and use are interdependent. To support this hypothesis, an additional fourth epistemological category has been defined, the 'TASK-MODEL', which binds the three previous interrelated categories concerned by a task, thus encapsulating domain, resolution, and control knowledge into a single package . Task Oriented Modelling shares nevertheless some characteristics with KADS and CoE modelling combining their strong points : first, the benefit of modelling (and even more, eliciting) the expertise at a conceptual level5 which prevents from being influenced during the modelling by computational constraints, is clearly recognized ; next, it agrees with CoE opinion about the benefit for the construction of an application model to combine problem solving components Lastly, it is important to notice that a TASK-M ODEL is used to model an expertise module, whatever its level of genericity or abstraction may be. For instance, a real-life application in the field of cytological diagnosis which goal is "to find a set of cytological faults (lesions types) that accounts the best for observed specimen complaints (morphological evidences)" is modelled by the 'Cytological_diagnosis' T ASK -M ODEL . As well, the generic task 'Diagnosis by Heuristic Classification' is also modelled by a TASK-MODEL (§4). At the same time, TASK-MODELS are used for modelling both modules that can be further decomposed into sub-modules or that are primitive inferences. 3.3. Task Centered Representation. The TASK language is the formalism of the TASK-M ODEL architecture under progress, TM architecture. It is a TASK Centered Representation, based on the object encapsulation principle, intended to reduce the gap between the expertise expression and representation. Its main objective is to allow the explicit representation of problem solving expertise at a conceptual level, i.e. independently of classical representations. TM -architecture is based on several principles : structural isomorphism, hybrid control and reflexivity. The T ASK language is used both as a representation formalism for the KBS final implementation and as a specification language for describing the meta-model of expertise (§3.4), an intermediate between the informal level and the its use in the problem solving process... We are convinced however, that it is useful to document them at least separatly...". 5 conceptual may be understood here both as domain and implementation independent (more precisely independent from classical implementation using languages of first generation such as rules, frames or logic)

6

final KBS. This architecture could thus be qualified as an architecture for the "operationalization" of the conceptual model. 1. Task Oriented Modelling

TASK MODEL

2. Task Centered Representation

ARCHITECTURE based on structural isomorphism

lu n tio

Co nt

1 representation construct

so Re

ro l

1 K. category

< TASK-MODEL> ::=

Domain



3. Task Oriented Acquisition

Fig. 3 : The TASK MODEL global framework

Advantages of knowledge level structures preserving. The benefits of such an architecture are multiple. It is now generally accepted that in order to give satisfying answers to the problems of KBS development, maintenance, explanation, validation, it is necessary to preserve in the implementation the structure of the conceptual model describing the expertise at the knowledge level (further called MCE). An example concerning explanation can be for instance found in (Wielinga &, 1992). It relates the advantage and interest of providing explanations at the KL, i.e. within the KADS framework, to trace the reasoning in terms of task and/or inference structures, rather than to give explanations at the code level, as it was done before in first generation systems. The same advantage of preserving the KL structures is valid for acquisition, development, or validation etc. For instance, in the acquisition field, a lot of work has recently been devoted to the development of acquisition tools leading to sophisticated workbenches such as SHELLEY, KADS tool, OPEN KADS etc. These tools are focused on the conceptual modelling considered as a separate step from implementation. Therefore, the problem of how finally implement the resulting specification is entirely left unsolved. These tools are really very useful, mainly for the "interpretational" step of the KE process, but presently they lead in the end to classical KBS implementations, where the conceptual model structure is dissolved and finally lost. Yet, preserving the conceptual model structure is necessary to make it possible the indispensable iterations between the symbol level and knowledge level required by the iterative nature of acquisition (resp. validation, maintenance etc.). As KADS said it : "it should be possible to relate the conceptual model elements to identifiable computational constructs" but vice-versa, it should be useful to be able to relate computational constructs to identifiable elements of the conceptual model. This reverse track back to the conceptual elements is needed, for instance in case of the discovery at the symbol level of incompletude, inconsistency etc., in order to be able to continue the acquisition process (resp. validation etc). At present, such reverse engineering is entirely left to the knowledge engineer responsibility. For all these reasons, an architecture which makes it possible to preserve the structure of the conceptual modelling is an essential issue. A solution for the operationalization : the structural isomorphism principle. Preserving the conceptual model structure of the expertise in the implementation, so that it should be possible to the user or developer to identify the conceptual elements in the final KBS implementation, and vice versa to retrieve them from the computational constructs, may be obtained in different manners. It is either possible to define a high level architecture based on high level constructs that make it possible to realize an isomorphism between the elements of the MCE and these computational constructs, or to have any mechanism which make it possible to preserve at least the mapping link between computational chunks6 of code and conceptual elements. The research direction which has being chosen in this work is the first one. Thus, TM-architecture is 6 borrowed from Steel's denomination

7

based on the following structural isomorphism principle : for each knowledge type, a suited representation data structure (Fig.3). This principle, has very strong implications : first, it obviously implies that any architecture respecting it, has necessarily a model which is directly depending on the theory of conceptual modelling. Therefore, in consideration to the structural isomorphism principle, the meta-model underlying the conceptual modelling and the architecture model are strongly interrelated. For instance, according to this principle, with regards to KADS perspective such an architecture should provide some structures such as concept, relation etc. for domain knowledge, knowledge source, meta-class, domain view for the inferences, task-structure, goals for the tasks, meta-rule, plan for the strategic knowledge etc, while with regards to the CoE such an architecture should rather provide structures such as model, methods, task etc. A high level complex language. T M -architecture is an architecture intended for the "operationalization" of the conceptual models of expertise designed according to the Task Oriented Modelling theory. The structural isomorphism principle implies to propose adequate computational structures so that to represent the different knowledge models involved in such a conceptual model and among those, the resolution modules and their organization into sub-modules, i.e. the T ASKSMODELS corresponding to the problem solving knowledge. In order to implement this principle, it is necessary to define a high level complex language, consisting of a task language which calls to diverse sub-languages respectively dedicated to each type of knowledge : domain, resolution, control. This work requires therefore to define : 1° the task language providing the required structures involved in the description of the model of a Problem Solving Task. Thus the present priority of the work is to define an architecture providing a declarative computational model for the representation of the Problem Solving Task models. This model is based on the syntactical representation unit of Task-Model proposed to describe in a uniform fashion the Task-Models. A TASK-MODEL is a data structure which makes it possible to aggregate within a single structured and coherent syntactical unit the different components of knowledge involved in a problem : domain, resolution, control knowledge. It is defined as a 3_uple associating context, resolution, control as follows : ::= ::= ::= ::= ::= ::= etc

2° a domain language providing the required data-structures for describing a domain model, i.e. the static knowledge, whatever their nature, factual or conceptual knowledge, (the domain concepts, their properties and their "epistemological" organization according to the generalize/specialize relation), relational knowledge (according to a causal, structural, functional, temporal, spatial etc. link) such as ::= | 3° a resolution language providing the required data-structures for describing the problem solving activity model at the domain level, i.e to represent the dynamic knowledge operating on the domain model, also called the reasoning knowledge. This language is devoted to represent the reasoning knowledge, whatever the nature of the problem to be solved. Three cases have been distinguished. If the problem to be solved is considered as a primitive one as regards to the modelling grainsize, the resolution knowledge is described by a primitive action. (inference or procedure). If the problem is more complex but nevertheless has a determinist type, the control plan is known in

8

advance and thus for instance the sub-tasks plan operating on the domain is predetermined (this is not to say that the solving method itself for each of those sub-tasks is known). In such a case, the resolution knowledge will be represented by means of a data-structure called a method,7 because of the ordinary meaning of the term method which usually refers to an algorithmic method. Thus a method correspond to a fixed chaining of solving knowledge 8,expressed by means of control constructs combining resolution knowledge modules (tasks, methods or actions). If the problem involves a non determinist resolution, the resolution knowledge then consist of a set of tasks, the tasks base, composed of the subtasks cooperating to achieve the main task and the solving plan is dynamically generated thanks to the control knowledge. Thus the resolution language may be defined as follows : ::=

| | | | |

The informal description of a method might be : METHOD ::=

[Application CONDITIONS] RESOLVE_K Combination [Stop CONDITIONS]

The proposed syntax for a specification language of resolution methods is : ::=

defmethod Method-name EXP end

::= Method-name | Task-name | Action- name | if CONDITION then EXP end | repeat EXP until CONDITION end | EXP ; EXP | EXP // EXP 4° a control language providing the required data-structures for describing the problem solving activity model at the resolution level, i.e. the dynamic knowledge which operate on the resolution knowledge. The control activity of the problem resolution enables to solve the choice problems that arise at the domain level. The control activity is responsible of choosing at any moment the next resolution activity to be achieved. As for any other problem, the control problem is modelled by Task-Models, the control tasks which cooperate to solve the control problem. The way to achieve a control task may be represented by means of resolution knowledge, the own K_RESOLVE of the control task (generic or specific control tasks i.e. Choice-Tasks, control method or control action), devoted to guide the choice of methods, tasks or actions and of dynamic generation of plans. The isomorphism principle implies to define control language constructs in order to make it possible the elicitation of the different categories (domain, resolution, control) of control knowledge, e.g. the selection features involved in the choice problems resolution. Such a language should thus propose in particular constructs for representing the control domain concepts, their properties, relations and organization at the knowledge level, such as those expressing for instance notions of strategy, heuristic, preference, focus, plan etc. Although recognizing the importance of supplying a suited language to express the domain knowledge like for instance the OMOS domain language (Linster, 1992), the work in progress is firstly focused on the task and control languages.

7 a method is a knowledge base solving method, and not an algorithm 8 referred as task-structure in (Pierret &, 1990)

9

An hybrid control adapted for controlling a reflective task-based architecture. TM architecture is a modular architecture based on an hybrid control devoted to combine hierarchical and opportunistic controls, because the claim is that the control type suited for an application depends on the application class. TM-architecture wants to allow a hierarchical control in order to keep the benefits of a problem solving conceptual structuration in hierarchical levels, when it is possible, (known resolution plan resulting for instance from the conceptual modelling of the application). TM -architecture wants also to allow an opportunistic control in order to handle applications for which a fixed plan is not a priori known and which requires a dynamical update of the control strategy, according to the current context of resolution. The considered approach is on the borderline between two trends of works, aiming to combine their advantages : on one hand the flexibility of general architectures of Distributed Artificial Intelligence (Fensel &, 1991) and on the other hand the efficiency and the right level of resolution which characterizes the Task Specific Architectures because of being driven by the conceptual task modelling. However, the originality of TM-architecture is to be aimed for permitting the problem solving elicitation at the KL. Thus, the main difference between TM -architecture and DAI architectures precisely lies in the possibility of elicitating at the KL the structuration of the knowledge modules base (the Task-Models), according to their conceptual links of decomposition, specialization etc. The comparison of the TASK-MODEL (TM) definition with that of a blackboard Knowledge Source (KS) points out this difference : considering the "Problem-solving" generic task (i.e considering Problem-Solving as an application to be modelled at the KL), the TASKMODEL concept is a basic knowledge level concept of the domain theory for this task, while the Knowledge Source is closer to the symbol level. Indeed, a KS usually have a more computational connotation, in terms of "Trigger, Pre-conditions, Condition-vars, Scheduling-vars" etc, while the TM syntax rather refers to KL notions reflecting the roles that knowledge play within the solving problem that is conceptual terms such as "input, output, goal, method, strategy " etc. Such an architecture providing the required constructs for the resolution and control knowledge elicitation at the KL, is able to make explicit its own problem solving behaviour. Therefore, it should be qualified as a knowledge level reflective architecture for problem solving. This is clearly the objective of TM-architecture which then should fall into the reflective architecture category. TASK (Pierret, 1990, 1991) was the first precursor of this type of architecture. TM -architecture is intended to extend TASK in particular by the achievement of an opportunistic control and of a control language. In conclusion, the main benefits of TM-architecture compared with DAI architectures will be to provide suited constructs so that to permit the combination of opportunistic and hierarchical reasoning. The reflective character and the opportunistic control of this architecture are also main differences both with KADS and CoE related languages or frameworks since those are devoted to model only hierarchical reasoning. 3.4. Task Oriented Acquisition Method The objective of the work on Acquisition is to realize ™KAT, a Task-Model Knowledge Acquisition Tool, based on a TASK Oriented Acquisition method. The basic idea of Task Oriented Knowledge Acquisition is to consider that the Knowledge Acquisition process (KA), viewed as a modelling activity, should be task-driven. The conceptual features of the problem solving task to be modelled i.e. its type and structure provide precious information about the knowledge to be acquired. The presented approach for KA relies on the task-oriented modelling which has just been described (§ 3.2). The KA method is first considered, then the possibility of a future acquisition tool ™KAT based on the automatization of some KA steps is discussed. The Task Oriented Knowledge Acquisition Method. The modelling view of KA (§2.1) is now applied to the Knowledge Acquisition process itself, considered as any other application, thus generating a conceptual model of KA. The KA model obviously depends on the meta-model underlying the modelling theory. Because of the task-oriented modelling assumption, KA is now modelled as a TASK-MODEL consisting of domain, resolution, control knowledge specific to the

10

KA task. The KA model, corresponding to the Task Oriented Knowledge Acquisition Method, is composed as follows : (i) the different concepts and models concerning the KA domain knowledge The first concept which has been identified to be relevant for KA is that of Model of Expertise, which is used to represent the model of both static or dynamic knowledge composing the expertise relative to an application, described in a high-level language, implementation-independent but application dependent (i.e. with the application's own vocabulary). With regards to the taskoriented modelling, this model is called the Application TASK-MODEL (A-TM) Another concept has been distinguished, the Meta-scheme of Expertise, an intermediate model between implementation and the know-how of expert, which allows to specify in an applicationindependent high level language, the types of both static and dynamic knowledge involved in the problem to be modelled (in other words, with a generic vocabulary, specific to a generic type of task but application domain independent). With regards to the task-oriented modelling , it is called the Meta TASK-MODEL (M-TM) The last important concept is that of Generic Model of Expertise used to represent a model of expertise common to a category of problems. Generic models denote models of both static and dynamic knowledge specific to a class of problems, expressed in a high level language using a specific abstract vocabulary proper to this class. Such generic models are found under diverse appellations. The Interpretation models of KADS (Wielinga &, 1992), the Role-limiting methods (McDermott, 1988), the Generic Task (Chandrasekaran, 1988), the Problem Solving Methods (Steels, 1990) are instances of such generic models. For example for Chandrasekaran, "A Generic Task is characterized by the kinds of inference it takes as input and the inference produced, the knowledge constructs that reasoner uses (data-structures or generic actions), the problem solving process that uses the knowledge constructs". Several generic tasks have been identified such as diagnosis (CSPL), design (DSPL), etc. Role-limiting methods, such as cover and differentiate, propose and revise, acquire and present, also are kinds of generic models. These ones have strong potential to guide knowledge collection and encoding by defining a limited set of roles that knowledge elements play within the method . With regards to the task-oriented modelling , these are called Generic TASK-MODEL (G-TM). A library may gather the predefined G-TM which may be hierarchically organized as proposed by KADS (Breuker &, 1989) : diagnosis --- single_fault_diagnosis --- heuristic_classification --- systematic_diagnosis --- causal_tracing --- localization --- multiple_fault_diagnosis

(ii) the different resolution tasks concerning the KA resolution knowledge. The resolution tasks correspond to the different (sub)tasks which cooperate to solve the KA problem. The KA process is a complex process which implies successive iterations alternating the construction of a Meta TASK-MODEL (M-TM), and its instanciation into an Application TASKMODEL (A-TM) modelling the tasks of the "real world" (Fig. 4). The different tasks involved all along the resolution of the KA process are sketched as follows : (T1) Acquisition, Analyze, Formalization of the model of the application task. This task T1 means to pass, from an informal description of the problem data and problem resolution, to their formalization in terms of T ASK-MODEL, that is to acquire the tasks features so that to define the application TASK-MODEL (A-TM), expressed in the application's own vocabulary.

11

(T2) Abstraction of a Meta TASK-MODEL (M-TM). This task T2 means to construct from the ATM (by selecting or combining generic models), a meta-scheme of the expertise considered as an abstract specification of the A-TM, that is to define the M-TM (T3) Instanciation of the Meta TASK-MODEL (M-TM). This task aims to complete, refine the ATM, by instantiating the missing knowledge being inferred from the M-TM (T4) Validation of the A-TM Tasks Meta-scheme Abstract Tasks

3

2

-1- acquire -2- abstract -3- instantiate -4-validate

1 Expertise 4 Real Tasks

Application Tasks Application Tasks

KBS

Fig. 4 : The different steps of the KA cycle

(iii) the different concepts concerning the KA control knowledge The control is presumed to be hybrid, combining opportunistic and hierarchical types. The control knowledge which govern this complex iterative process and the iterations between the previous different tasks have not already been completely identified. The precise definition both of the overall control and of the elementary acquisition cycle to be applied for acquiring a task, are the object of future work. ™KAT, a Task Model Knowledge Acquisition Tool. Some directions have been proposed in (Pierret, 1992) for future automatization of the KA process. They are now quickly recalled. ™KAT has not been already implemented. These ones presume that all the knowledge are represented with the TM-architecture task language, in particular that both the A-TM, M-TM related to the application and all the G-TM are represented with TASK-MODELS. (T1) the 1st KA Task This step should generate an A-TM representing the features which are known about the application task to be modelled. Thus the goal of (T1) is to fill in a TASK-MODEL data-structure (i.e. assign values), so that to reflect the application task. According to the TASK-MODEL datastructure, the knowledge to be acquired are organized into different categories, so this step can consequently be decomposed into different sub-tasks responsible for one knowledge category acquisition : domain modelling, resolution modelling, control modelling. Automatic tools may be provided to help these activities. For instance, concerning the resolution knowledge of the task (Kresolution), a tree-editor may facilitate its modelling, helping to build the task decomposition graph, when it is known (Fig.5). Next, concerning the Task features (K-context), a Task editor based on the task language (Fig.5) such as the task editor in (Pierret, 1990) may help to acquire the T ASK-MODEL features : its goal, input, output, etc.(a dependency diagram editor such as the model dependency diagrams proposed in (Steels, 1992) might also be used). As the Task editor is based on the task language it may ensure syntactic coherence verification (e.g. input/output coherent link. Semantic coherence verification about the different acquired knowledge should also be possible thanks to the M-TM. Indeed, TASK -MODEL has precisely been defined so that to make it possible to gather in a structured and semantically coherent way the different categories of models concerning a given task. For instance, a TM "CAR_DIAGNOSIS" should get together coherent information concerning a car model, a diagnosis method, and a control model : a structural model of a car based on a part-of link should be related with a diagnosis method based on the car-system structure

12

(Wielinga &, 1992) and of a set of mappings faults → sub-component, and with strategies such as "prefer the tasks which test hypothesis on the engine parts rather than on the carburettor parts etc". Thus the TASK-MODEL is a central pivot of an incremental process of KA Tas kET an d ST 1

ST ET 2or

ST1 ST2 ST2 .1 .2 CT RL ST2. ST2. 2.1 ST2.1 2.2

T Task T ET and ST 3 et ST2 ST2. ET or 3 ST2. ST2.2 2.3

Task ST2.2 K-cont ext ST3 K-resolu tion K-cont

:

Task ST2.2

: :

K-context

:

rol

ST2. 3

K-resolution

:

K-control

:

CTRL

ST2.2.1

ST2.2.2

ST2.2.3

Fig. 5 : Structuring and formalizing the resolution knowledge (T2) the 2nd KA Task This step is devoted to the definition of the Meta TASK-MODEL (M-TM), from the A-TM which has previously been defined. The M-TM plays the role of A-TM specification, and therefore presents a double interest : it may be used either to complete an incomplete A-TM (which is the most frequent after the step T1), or to verify its semantic coherence. Therefore, this task T2 may be considered as the real heart of the acquisition process. The method proposed to achieve it, is standard in modelling, since it is suggested to rely on a library of generic models for the construction of a relevant model. Thus, the M-TM might be created by selecting an existing G-TM or by combining several generic models G-TM of the library. The G-TM selection might be aided by a tool specialized in an abstraction task (in fact a G-TM), for instance based on the heuristic classification method so that to classify the A-TM : a class in the G-TM hierarchy might be identified from the information already encoded in the A-TM (e.g. the task goal, the input or output data, the domain model type). Such a tool presumes a G-TM hierarchy represented in the task language. Otherwise, the G-TM construction might be aided by a tool specialized in a design task based on a models combination method. (T3) the 3rd KA Task This step is devoted to the Application TASK-MODEL (A-TM) completion. The method proposed to achieve this task T3 can be qualified to be model driven since the acquisition is guided by the GTM. Indeed, once a G-TM has been found, it is possible to infer by inheritance a set of knowledge attached to the G-TM class : either its domain (i.e. the type and organization of knowledge), solving (set of subtasks), or control model, depending on the A-TM available knowledge. For instance, if the A-TM has been recognized from its goal to be a representative (an instance) of the "Diagnostic" G-TM, then different permissible solving methods can be derived (e.g. Establish&Refine, Cover&Differentiate, Heuristic Classification etc.). If a specific domain model is available, e.g. a hierarchical model, the Heuristic Classification is then deduced, its sub-tasks decomposition therefore inherited. These sub-tasks have then to be instantiated. This instantiation may be helped by tools such as those already being proposed like MOLT, SALT, AQUINAS etc. In the same manner, when the M-TM is a complex combination of M-TM, a more general instantiation tool should be defined which should recursively examine the different G-TM composing it. Its realization should be an interesting work, because of the coherence problems which may then arise between the different G-TM . Thus the presented KA approach relies on the development of three major components :

13

1. an architecture providing a high level language to make the task models operational (§ 3.3). 2. a library of generic T ASK-MODELS G-TMs, represented in this architecture (a kind of "a generic tasks models toolset", or "library of components of expertise") 3. an acquisition module, based on the KA tasks just described. As the KA as been identified as a task to be modelled at the KL, this module might be itself constructed in the same architecture by use of the library models. Task Oriented Acquisition is driven by the Task-Models of expertise. A main difference between TASK MODEL approach and KADS or CoE Acquisition methodology is to aim an architecture so that to support a TASK-MODEL BASED Acquisition process. This method relies on a clear and distinct representation of the Application, Meta-scheme and Generic Task-Models related to the considered expertise, by means of the same TASK language This is the key point to support a cyclic acquisition process combining acquisition which is driven both by generic components and by the TASK language primitives. 4. EXAMPLES OF TASK MODEL USE Two examples are now presented to illustrate the T ASK M ODEL approach advantages. They demonstrate how the same TASK language is used both to represent and organize Generic Models in a library such as the Diagnosis Models library (§4.1), and also to design and operationalize the Model of Expertise for a real-life application (§4.2). 4.1 A library of Generic Models of Diagnosis Several models of Diagnosis are found in the literature (Breuker &, 1987) (Clancey, 1985) (Eshelmann, 1988) etc. Nevertheless, they share common features concerning both the goal, the static and dynamic (operative) knowledge types involved in this task, so that it is possible to give a general informal definition of the generic 'Diagnosis' task. Generic Model 'Diagnosis' definition. First, it is possible to specify what must be done in a diagnostic problem, whatever the solving strategy may be to achieve it. Diagnosis is a task where a case description (input) is mapped onto faults classes (outputs) according to a system model (resource) (Fig. 6a). A case description CASE_K includes both particular complaints that initially triggered the diagnosis task and complementary observables. The fault classes must account the initial complaints and then be confirmed by the observables (Fig.6c). Moreover, it is also possible to define how such a type of problem is generally solved, that is a resolution method for diagnostic problems. complaint

Diagnosis

Case description

System model

fault class a

Generate

Generate & Test

Diagnose HYPOTHESIS GENERATION

HYPOTHESIS TESTING

b

case description

Hypothesis Test

c

truth value

Fig 6 : (a) Basic Configuration of the Diagnosis task (b) Diagnosis decomposition c) Expnanded Diagnosis decomposition

Diagnosis is a complex process basically abductive (Pople, 83) which therefore implies in principle two lines of reasoning : 'Hypothesis Generation' and 'Hypothesis Testing'. A careful analysis of several classical models of diagnosis, Systematic Diagnosis (Wielinga & 1987), Heuristic Classification Method (Clancey, 1985) etc., confirms this sub-tasks decomposition into : HYPOTHESIS GENERATION and HYPOTHESIS TESTING. Thus it turns out that a general method to perform Diagnosis is the generic method Generate &Test (Fig 6b). So it is possible to give a basic definition of Diagnosis, as a Generic Model characterized by some :

14

• Contextual knowledge Goal : Diagnosis is a task which goal is to "infer faults (output) from observables (input) using a domain model (resource) so as to account some complaints (inputs)" Input : the input of the diagnosis task is a description of the case to be diagnosed. Such a case description usually includes some complaints and complementary observables values Output : the output of the diagnosis task are some faults classes (or malfunction by opposition to normal state or functions) diagnosed for the case Domain_models : the resources of the diagnosis task are some domain models • Resolution knowledge Decomposition : diagnosis in principle involves at least HYPOTHESIS GENERATION, and HYPOTHESIS TESTING. As the number of potential hypothesis is often enormous (in particular in medecine), this process often requires an other component : HYPOTHESIS SELECTION.

Formalized in the TASK Language, basic 'Diagnosis' is a Generic TASK-MODEL repesented by : {Diagnosis kind-of : Task-Model; context : case_K : [goal : "infer faults from observables according to a domain model. so as to account complaints"; input : COMPLAINTS , OBSERVABLES; output : FAULTS]; domain_models : DOMAIN MODELS ; resolution : (HYPOTHESIS-GENERATION, HYPOTHESIS-SELECTION, HYPOTHESIS-TESTING); control : Sequential (by default)}

Generic methods for Diagnosis. Several methods have been identified to achieve Diagnosis : Heuristic Classification, Systematic Decomposition, Cover&Differentiate, Case-based etc. (Table 2). Heuristic Classification is one of the most famous. Compared with the basic decomposition (Fig.6b), it appears that this method may need a complementary sub-task : Data Abstraction (Fig. 7). But its most characteristical feature is the heuristic match performed for hypothesis generation which requires heuristic knowledge to be provided. Systematic Diagnosis

Heuristic Diagnosis

Systematic Decomposition

Heuristic Classification Data Absraction Abstract

Hypothesis Generation Heuristic Match Norm prediction Faults Model Selection

System model Selection

Hypothesis Testing

Select

Refine Test selection

Difference Comparison

Direct Observation

Hypothesis Generation Decompose

Hypothesis Testing Empirical Test

Norm prediction Specify

Test selection

Difference Comparison

Observation Acquisition Compare

Compare Observable Specification Finding Obtention

is-composed-of is-perfomed-by

Select

Obtain

Fig 7 : Different methods used to perform diagnosis : Heuristic Diagnosis vs Systematic Diagnosis (task in normal style, method in italic)

Interdependence between Domain Models and Method types. More generally, each generic method is connected with a specific domain type : the use of the Heuristic Classification method for Diagnosis obligatory requires a predefined set of symptoms-faults heuristic associations, i.e. an 'Heuristic Model' to be available, while C&D obligatory presupposes a 'Causal Model' which relates faults and symptoms, a 'Behavioural model' which relates fault and manifestation , an 'Observation model' for observed manifestations9, Systematic Diagnosis presumes a 'System Model' etc. (Table 1). A focus on the Hypothesis Generation sub-task of 9 inspired from simplified version of the C&D method proposed in (Wielinga & , 1993)

15

'Diagnosis' for three Diagnosis Models exhibits the interdependence between types of methods and types of domain models (Table 1). Method Domain Model

Systematic Diag. Decomposition Structural Model

Heuristic Diag. Heuristic Matching Heuristic Model

C & D. Diag. Cover Causal Network

Herachical Diag. Classify Class Hierarchy Model

Table 1 : Domain Model associated with a Method used to perform the Hypothesis Generation Task .

TASK-MODEL precisely makes it possible to capture this relation between Domain Model Types and Method Types, as it provides a data-structure where they are encapsulated into a single entity. It is thus possible to represent any generic task, such as for example the Diagnosis Models, by a Generic TASK-MODEL where generic methods and related generic domain schema are associated, like for instance the G-TM Heuristic-Diagnosis : {Heuristic-Diagnosis {Heuristic-Classification kind-of : Diagnosis; kind-of : Method; input : complaints, observables10 input : data output : faults output : solutions domain_models : Fault - Symptom MODEL; resource : HEURISTIC MODEL resolution : Heuristic-Classification } combine: Abstraction, H._matching, Refinement}

Library organization of Diagnosis Models. These Diagnosis G-TMs may differ at various levels, either at a first level, being performed by a different global method (e.g. Diagnosis performed by Heuristic Classification, Cover & Differentiate, Systematic decomposition, etc) which implies a different sub-tasks decomposition (Fig.7). For each method, the Generate and Test sub-tasks are achieved by a specific method (Table 2). DIAGNOSIS MODEL SPECIALZATION

Systematic Diagnosis Heuristic Diagnosis Cover & Differentiate Diagnosis Hierarchical Diagnosis Case-based Diagnosis Propose & Revise Diagnosis

Specific SUB-TASK

HYPOTHESIS GENERATION specific method

HYPOTHESIS TESTING specific method

System Model Selection Data Abstraction*

Decompose System Model Heuristic Match

Empirically Validate Refine

Causal Model Selection Data Abstraction*

Cover

Differentiate

Establish

Refine

Similar Cases Match (Cases Retrieve) Propose

Similarity Assess

Case base Selection Indexes Assignation

Revise

Table 2 : Different Generic Models of DIAGNOSIS.

Or they differ at a lowest level, as regards to the method used for some of the next sub-tasks which can on their turn be achieved by various methods. Some models also imply additional specific subtask (e.g. Diagnosis by Heuristic Classification may need Abstraction, while Systematic Diagnosis requires System Model Selection). Therefore, each specific Diagnosis G-TM is a specialization of the basic Diagnosis G-TM, as using a more specific method at some level of decomposition or implying more sub-tasks. The Diagnosis G-TMs are organized in a hierarchy of Task-Models according to a task specialization link defined as in (Pierret & 1989]. A possible entry point for the choice of a Diagnosis Model in the library is the type of Domain Model : a G-TM is selected if the A-TM Domain Models have the right G-TM Domain Model types . 10 input, ouput data types are inherited from the generic context of the Diagnosis Task-Model

16

In conclusion, TASK-MODEL and Methods are appropriate data-structures to represent, store and retrieve G-TMs. As it enables at the same time to capture the interdependence between domain models and methods and to organize libraries of both prebuilt models and predefined methods, according to a specialization link, it provides an efficient fashion to retrieve them. 4.2 A real-life task : cytological diagnosis The real-life application concerns diagnosis in cytology which consists in gathering morphological evidences allowing to identify the lesions that might appear on a specimen as benign or malign. Cytological specimen investigation involves three main steps. The first one, conducted by cytotechnicians, consists in validating the specimen significance. The second one, assumed by cytopathologists, implies the achievement of three different tasks, namely morphological analysis, cell identification, and finally diagnostic formulation. The latest task is aimed at validating the inferred diagnosis hypothesis : it takes into account clinical data related to the patient. Such process leads the pathologist to evaluate the proposed diagnosis hypothesis as fully coherent or not and eventually, to examine again the slide. A simplified scenario has been abstracted from this real task to illustrate the TASK M ODEL approach. In this sample scenario the Diagnosis is obtained by performing three main tasks : Specimen Preparation, Diagnosis Interpretation, Diagnosis Validation (Fig. 8). Diagnosis Interpretation on its turn is performed by achieving cell identification and diagnosis formulation. The available expertise for the cell identification task consists of a matrix associating morphological descriptors of the cells and the cell types (noted ç_types) while for the diagnosis formulation task a matrix associating cell types frequency on the slide and corresponding pathology is available. Modelling the Cytological Diagnosis Sample Problem Three types of models are concerned by the modelling process (Fig. 8). The first type models are Application TASK-MODELS. Firstly, the 'Cytological_diagnosis' A-TM, reflects the global real-life application. It is composed of the application (i) domain, (ii) resolution (iii) control, knowledge corresponding to the three categories of cytological expertise pointed out in (Ovalle, 1991]11. Thus, its resolution knowledge is composed of three A-TMs corresponding to the three steps of resolution described in the scenario, which cooperate to solve the global Cytological_diagnosis A-TM. Its Domain Models include a 'features-class mapping Model', materialized by a matrix [descriptors, cell-types] and a Heuristic Model materialized by a matrix [cell-types, pathologies], the control of the overall task is to long to be described. Recursively, each next A-TM has its own domain, resolution, control (e.g. the 'Cell identification' and 'Diagnosis Formulation' A-TMs cooperate to perform the 'Diagnostic Interpretation') (Table3). The second type of models are Generic TASK-MODELS, at a similar level of genericity as the Diagnosis G-TMs presented (§4.1) or other generic tasks (e.g. Simple Classification, Refinement etc.) but of any grainsize, complex (e.g. Heuristic Diagnosis) or primitive (e.g. Matching).

Simple Classification

H.C. Matching

G-TMs

Library

M-TM Cytological_Diagnosis Specimen Preparation

Diagnostic Interpretation

Cell-type Identification

Diagnosis Validation

Diagnosis Formulation

A-TM

Fig. 8 : Task-Models at different levels of abstraction : A-TMs, G-TMs, M-TMs 11 (i) association matrix depicted by mapping tables synthesizing domain models such as for instance heuristic

relations between cellular types and pathologies, hierarchical relations between pathologies [Ovalle 91, PP. 94-95], (ii) tasks table (Table 1), (iii) tasks dependency graph.

17

Finally, the last type of models are the Meta TASK-MODELS. A M-TM is an abstract specification of an A-TM obtained by combining several generic components (G-TMs of any grainsize, composite or primitive) selected in the G-TMs library (§3.4). For example, the A-TM 'Cell identification' is recognized as an instanciation on the cytological domain of the G-TM 'SIMPLE Classification', while 'Diagnosis Formulation' as an instanciation of the G-TM Heuristic Matching (Table 3), then the generic M-TM for the real task 'Diagnosis Interpretation' is the result of the combination of these two G-TMs instanciated on the cytological domain.

Goal Input Output Domain K. concepts properties domain model Resolution K.

Control K.

G-TM n°1 A-TM n°1 G-TM n°2 A-TM n°2 Simple Classification Cell Identification Heuristic Matching Diagnosis Formulation Identify concepts that Identify the cell types Find solution that Find the pathology for match the instance in presence match data abstraction the cell types instance, {classes} cell, {ç_types} data abstractions ç_types classes ç_types abstract solutions pathologies • instance, {classes} • observables. • mapping relations (properties, concept) T1: obtain findings T2 : macthing T1 then T2 (by default)

• cell, {ç_types} • cell_descriptors • matrix (descriptors, ç_type) T1 : morphological analysis T2: cell recognition T1 then T2 if fails, look at atlas

• data abstractions • { ç_type }, {abstract solution } (pathologies) • heuristic relations • matrix (data., solution) (ç_types,pathologies) heuristic match

Table 3 : G-TMs for the Data-Abstraction and Hypothesis Generation sub-tasks of the Cytological diagnosis

It must however be noted that the A-TM 'Cytological_diagnosis' modelling the global application could have been directly recognized as an instance of the 'Heuristic Diagnosis' G-TM (with its three typical sub-tasks : Data-abstraction corresponding to 'Cell Identification', Hypothesis Generation to 'Diagnosis formulation', and Hypothesis Testing to 'Diagnosis Validation'. But most often, real-life applications are rather concerned by several generic components. Therefore, it has been preferred to enhance the "bottom-up" approach so as to give a flavour of what is a M-TM for an application. Each time a top-down approach is possible, it is preferred to a bottom-up one. 5. RELATIONS TO OTHER APPROACHES TASK MODEL has similarities but also important differences with the approaches used in other projects, concerning both the modelling, operationalization and acquisition dimensions. From the operationalization point of view, two categories of work are distinguished depending on their position about the separation or integration of the conceptual modelling and implementation steps. The first one, based on separation, is illustrated by KARL or MODEL-K, languages strictly devoted to the implementation step of KADS Conceptual Models. Then, a Conceptual Model can only serve as a documentation or specification but does not permit a feedback for its evaluation during the KBS development. TASK MODEL on the opposite, falls in a second category of works which is based on integration (e.g. OMOS) and suggests the direct construction of operational systems. Indeed, the Models of Expertise represented with the TASK language will be executable, as the architecture will provide the control mechanisms necessary to operate on these models, in a similar way as previously done by the systems TASK (Pierret & 90) or LISA (Delouis, 1993). From the modelling theory point of view, different trends are distinguished depending on their opinion about the interdependence of the (epistemological) categories of knowledge. While sharing several principles with KADS or the more recent developments of the CommonKADS approach (Wielinga & 92) such as the Modelling principle, Knowledge-Level principle, Knowledge Typing Principle etc, TASK M ODEL however differs from it on the subject of the Relative Interaction Hypothesis. Indeed, TASK MODEL rather joins the Generic task approach of

18

(Chandrasekaran, 1988) or PROTEGE-II (Puerta &, 1992), since its key concept is 'T ASKMODEL', specially defined so as to model knowledge as a 'package' in which different sub-models may be distinguished but not separated. Nevertheless, as the 'T ASK-MODEL' epistemological primitive is used to model either complex or primitive modules, it seems to be in some manner similar to the recent concept of function introduced in KADS II used for modelling either tasks or inferences. Moreover, T ASK M ODEL also differs from KADS and CoE, as being intended to support both hierarchical and opportunistic reasoning, while these latter are both based on an a priori hierarchical decomposition of problem into sub-problems : each problem is assigned with a single method (inference-structure in KADS, method in CoE) to solve it. Within TASK MODEL it is possible to define several methods for a task, the relevant method, sub-task, or action (RESOLVE_K) being dynamically chosen according to each context. From the acquisition point of view, model driven approaches have different opinion about the connection between domain and generic knowledge, proposing either a projection, mapping, relation (e.g. OMOS, KADS), or the instanciation of a problem solving method on the domain (e.g. PROTEGE-II, Spark; Burn). For TASK M ODEL , an Application TASK-M ODEL is a real instanciation (in the object oriented meaning of a class-instance relation ) of a Meta TASK-MODEL which is an abstract model to be designed by selection or combination of generic components (Models or Methods). Such an instanciation between TASK-MODELS is a much stronger relation than a mapping or simple instanciation of a problem solving method on a domain since implying both the domain and resolution types of knowledge to be acquired. So in spite of some differences (e.g. the encapsulation principle), the Interaction hypothesis, and the instanciation make feel that the approach is quite close to PROTEGE-II. But, perhaps more flexible since permits to combine bottom-up and top-down acquisition methods because of the existence of specific data-structures for each type of knowledge. Task Oriented Acquisition presents some common features with CoE as compounding components of expertise or Task-Models refers obviously to the same idea of a "bottom-up" model construction by combining appropriate sub-models (classical for any modelling problem). Finally, TASK MODEL has also similarities with the GDM approach (Terpstra &, 1993), as the generalized knowledge sources would correspond to the T ASK-MODELS, while the Generic TASK-MODEL would be associated with Generalised Directive Models. However, it differs from it since TASK M ODELS libraries are organized according to a specialization link between T ASKMODELS (in the object oriented meaning of a class-subclass relation), and the design of a Model of Expertise is based, combination and instanciation rather than on expansion and rewrite rules. 6. CONCLUSION The aim of this article was to propose a global framework for KBS development at the knowledge level which takes into account the interactions between the meta-model of modelling, the model of representation and the model of acquisition. TASK MODEL framework encompasses three elements which have been successively described : Task Oriented Modelling, TM-architecture supported by the TASK language, and Task Oriented Acquisition with an appropriate suggested tool ™KAT. At present, the developments have mainly concerned the two former aspects. The first TASK modelling language was proposed in (Pierret &, 89) but is still in permanent evolution. This language was then supported by the EMAD environment which has been used a lot to catch the expertise of different applications, in particular in the aerial navigation control field (El Farouki &, 91). At present, TASK Oriented Modelling has progressed and distinguishes between three categories of knowledge, domain, resolution, control encapsulated into a single entity : a TASK-MODEL. To deal with the operationalization, a high level architecture, TM-architecture, aims to provide data-structures for the elicitation of each type of knowledge. This architecture could be qualified to be a knowledge level reflective architecture for problem solving. Indeed, providing the required constructs for the resolution and control knowledge representation at the KL, TM architecture will enable to make explicit its own problem solving behaviour. As being devoted to the problem solving elicitation, TM -architecture may serve to represent both application task models, generic task models, its own control model, and also the acquisition process model, all being modelled at the KL. Two systems inspired by similar principles as those of TASK MODEL have yet been realized : TASK (Pierret &, 1990) and more recently LISA, which is being used to

19

develop a KBS in electrical networks planning (Delouis, 1993). A tool corresponding to ™KAT description is still in project but not yet available. In conclusion, TASK MODEL is a global framework concerning both a modelling theory, an architecture for knowledge level systems, and knowledge acquisition. It is an ambitious project. REFERENCES Bylander T , Chandrasekaran, B. (1988). Generic Tasks in knowledge-based-reasoning : the right level of abstraction for knowledge acquisition, in B. Gaines, J. Boose Eds, Knowledge Acquisition for Knowledge Based Systems, vol I, P.65-77, London : Academic Press. Breuker, J, Wielinga, B.(1989). Models of expertise in Knowledge Acquisition, In Guida and Tasso Eds., Topics in Expert System Design, Nort-Holland : Elsevier Science Publishers. Clancey, W.J. (1985). Heuristic Classification, Artificial Intelligence, 27, 1985, pp 289-350 Chandrasekaran, B. (1988). Generic Tasks as building blocks for knowledge-based-reasoning : The diagnosis and routine design exemples, Knowledge Engineering Review, 3 (3). Delouis, I. (1993). LISA : un langae reflexif pour la modélisation du contrôle dans les systèmes à base de connaissances. Application à la planification de réseaux électriques. These Universite Paris Sud. Demarco, T. (1982). Controlling Software Projects. New York : Yourdon Press (1982) Eshelmann, L. (1988). Mole : A knowledge Acquisition Tool for cover and differentiate systems, in Marcus, S. Eds., Automating KA for expert systems : Kluwer Academic Publishers. El Farouki, L., Scapin D.,Sebillotte S. (1991). Prise en compte des tâches du contrôleur pour l'ergonomie des interfaces.Rapport final CENA/Note 91223, Rapport INRIA, Août 1991. Fensel, D., Angele, J., Landes, D. (1991). KARL : A Knowledge Acquisition and Representation Language, 11th International Conference Expert Systems & their Applications, Avignon, France, May 27-31. Ganascia G. (1991). Hypothèse du "Knowledge Level" : théorie et pratique, Sciences Cognitives, un débat, Edition CNRS 91 Harmelin, F., Balder, J. (1992). (ML)2 : A formal language for KADS models of expertise,.in Knowledge Acquisition, March : Academic Press. Karbach, W.,Voß, A., Shukey, R., Drouwen, U. (1991). Model-K : prototyping at the knowledge level, 11th International Conference Expert Systems & their Applications, Avignon, France, May 27-31. Linster M., (1992). Knowledge Acquisition Based on Explicit Methods of Problem Solving, Thesis Universitat Kaiserslautern. Mc Dermott, J. (1988). Prelimenary steps towards a taxonomy of problem solving methods, in Marcus, S. Eds., Automating Knowledge Acquisition for Expert Systems, Boston : Kluwer Academic Publishers. . Newell, A. (1982). The knowledge level, Artificial Intelligence, 18 : 87-127 Ovalle, A., Garbay, C. (1991) : KIDS : a distributed expert system for biomedical images interpretation. In Information Processing in Medical Imaging, Colchester & Hawkes (Eds), pp 419-433. Lecture Notes in Computer Science : Springer Verlag. Pierret, C., Delouis, I., Scapin, D. (1989). Un outil d'acquisition et de représentation des tâches orienté-objet, Rapport de Recherche 1063.: INRIA Eds Pierret-Golbreich, C., Delouis, I. (1990). TASK : Task Architecture for Structuring Knowledge, General Conference Second Generation Expert Systems, Tenth International Conference Expert Systems & their Applications, Avignon , May 28-June 1st. Pierret-Golbreich , C. (1991). Task Centered Representation for expert systems at the Knowledge Level, in AISB'91: Springer Verlag Pierret-Golbreich, C. (1992). Acquisition des connaissances orientées modèles de tâches, in JAC'92, Dourdan, France. Pierret-Golbreich, C. (1993). Task Model Perspective of Knowledge Engineering, in EKAW'93, Toulouse. Puerta, A., Edgar, J., Tu, S., Muse, M. (1992). A multiple-method knowldege Acquisition shell for the automatic generation of knowledge acquisition tools. Knowledge Acquisition 4, 171-196: Academic Press Steels, L., (1990). Components of expertise, AI Magazine, Summer 90. Steels, L., (1992). Reusability and configuration of applications by non-programmers, VUB AI Memo 92-4. Terpstra, P., van Heijst, G., Shadbolt, N., Wielinga B. (1993), Knowledge Acquisition Process support through Generalised Directive Models. In Second Generation Expert Systems : Springer-Verlag Wielinga, B., Breuker, J. (1986 ). Models of Expertise, in Proceedings ECAI' 86 pp.306 - 318 Wielinga, B., Schreiber, G., Breuker, J. (1992). KADS : A modelling approach to knowledge engineering, Knowledge Acquisition Journal 4(1) 1-162. Wielinga, B., Van de Velde W., Schreiber, G., Akkermans H. (1993). Towards a Unification of Knowledge modelling Approaches, In Second Generation Expert Systems : Springer-Verlag

20

21