Generic Task Modeling As a Basis for ITS

Generic and Specific Process-OrientedModels

using Knowledge Types for Learning and Advising

Gilbert Paquette

LICEF Research Center, TŽlŽ-universitŽ

1001 Sherbrooke est, MontrŽal H2X 3M4

Phone (514) 522-3540; Fax: (514) 522-3608

E-Mail: gpaquett @ teluq.uquebec.ca

Abstract

The constructivist view of learning still lacks an operational framework for the design of learning environements. Although some progress have been made from a research point of view, most commercial learning tools still rely on a methodology of information transmission. Strictly concept-oriented modeling is largely responsible for this situation. The construction of knowledge by the learner implies that he/she should get involved mainly in problem-solving activities. Through these activities, the learner will search for information and come to master the main concepts, procedures and principles in an application domain, as well as in a generic process. Problem solving is essentially a process, so we should model the application domain accordingly using different knowledge types integrated in a unique multi-layered model. Qualitative models for learning and advising are process oriented instead. They model put more emphasis on procedural and strategic knowledge that forms the core of a problem solving method. The generic task and specific knowledge in a learning environment should be related through the learning scenario, which is also a process-oriented model of the learning activities.

Qualitative Models and Process Oriented Modeling

Qualitative models were introduced early in the ITS field. Simulation-based reasoning has been the central theme of the SOPHIE project (Brown et al., 1973). The representation scheme focused on qualitative process models rather than quantitative simulations on the facts and. The causal knowledge on electronic circuit troubleshooting processes is represented in finite-state automata in which sequences of events are simulated by transitions between states. Thus, the emphasis is on the chain of inference followed by the learner (and the tutor) in the problem-solving process, rather than on a declarative description of the solution set.

Causality between actions in a problem solving process if pedagogically important because it is based on the learner’s activity and it favors the construction of explanations to the learner. In other words, it is coherent with the constructivist view of learning, where a pre-existing mental model is seen as being transformed by the learner’s activity.

Of course, simulation-based models and finite automata representations are not the only way to represent qualitative of process models. In the WHY project (Stevens and Collins, 1977), the knowledge about rainfall is stored in a hierarchy of scripts that represent stereotypical sequences of events. These are used to capture both the temporal and the causal relations between events in a way that is easily amenable to inspection by a tutor or an advisor. Later on Stevens and al, 1979) remark that the script-based representation is limited to the linear relations between events and captures only the global aspects of processes like rainfall.

Other viewpoints are needed on the domain knowledge , for example a functional perspective. Functional relations hold between factors, and explain the results of processes. For example, in the meteorology domain, the temperature of an air mass is inversely related to its altitude and therefore the rising of the mass will result in its cooling. Such functional relations cannot be captured by the temporal and causal sequences embedded in a script-like representation. As (Wenger, 1987) summarizes: “the script viewpoint tends to influence the sequencing of major teaching episodes, whereas the functional viewpoint tends to guide local interactions”.

The representational problem is further complicated by the fact that there can be other viewpoints such as spatial structures, physical principles or heuristic principles that often require knowledge from other domains. It then becomes important to show how these viewpoints interact and how they are integrated in a unified representation of a domain. This leads to the idea that the global mental model of a learner can be viewed as a combination of different component models for different processes and different viewpoints, learning being seen as a transformation of this mental model.

The issue of providing learning environment designers with a usable and integrative system of representation is thus important, both on the theoretical and on the operational level where a simple, while comprehensive and integrative, representation technique is needed to ease the design and development process. On the theoretical side, it is not sufficient to be able to represent qualitative models by processes that can be inspected and reified in an a computer interface. If a learner or a tutor has to cope with four or five different loosely related model, each with its own representation language, the very complexity of the representation might defeat the purpose of reification, which is to enable learners to think about knowledge to transform their mental model.

Modeling Processes using Object Types

We propose to cope with this representation complexity problem by using knowledge types within a single unified and integrated model.

The distinction between three basic types of abstract knowledge, concept, procedures and principles, is now well established. Conceptual vs procedural knowledge has been a traditional distinction in artificial intelligence. Rather recently a third knowledge category, referred to as conditional or strategic knowledge, has been proposed (Paris et al., 1983).

The ontological analysis developed by (Alexander et al.,1987) also classifies problem-solving knowledge in three categories. The Çstatic ontologyÈ describes the primitive objects, their properties and relations; the Çdynamic ontologyÈ describe states and operations within the problem state; finally, the Çepistemic ontologyÈ encompass the methods controlling the use of the other two categories.

In KADS (Schreiber et al., 1993) and CommonKADS (Breuker et al., 1994), a software engineering methodology, these three categories correspond roughly to the domain knowledge, the inference knowledge, and the task and strategic knowledge.

In the Education Sciences, one can find similar categories of knowledge, the intention being here to assign learning/teaching strategies to each category. This is the case of theÒComponent Display TheoryÓdeveloped par (Merrill, 1994), as well as in the knowledge categories described in (Romiszowski, 1981), a widely used educational technology reference book. Other works in Education (Tennyson et al., 1988;West et al., 1991) also stress the importance of knowledge types, particularly the importance of strategic knowledge for education.

Using these widely accepted views, we have developed MOT a knowledge modeling technique based on the representation of three kind of knowledge types, concepts, procedures and principles, plus their instances (facts), and six kinds of basic links between them: composition C, specialization S, instanciation I, precedence P, input-output IE and regulation R. A graphic editor based on the technique has been constructed and used in different kinds of applications in the last three years(Paquette, 1996).

There are of course many knowledge representation graphical techniques. Our field experiments show that MOT is a technique that can be mastered by education designers, as opposed to elaborate software engineering techniques like OMT (Rumbaugh and al, 1993) where three separate models (domain, functional and dynamic models) must be developed, each with their own representation language. The specific interest of the MOT technique lies in its ability to integrate different types of knowledge within a unique model, making explicit the interelations between different viewpoints (factual, conceptual, procedural and strategic) within the model, instead of separating them in different models.

This is important for learning and advising because the pedagogical strategy will be very different if the knowledge takes the form of facts, concepts, procedure or principles. For example, if a concept needs to be learned, the learner might construct it by a generalization - specialization process using examples, counter-examples or near-example, to use Winston’s terms. If the knowledge is a procedure, it could be learned by simulating the procedure using different inputs and outcomes. If the knowledge is a principle, it will probably entail an emphasis on the strategic planning of problem solutions that use the principle.

Furthermore, different types of knowledge will necessitate the use of different problem solving tools: data base tools for facts, knowledge base or hypertext tools for concepts, solution planning or production tools for procedures, or interaction with an expert or advising system for the acquisition of heuristic principles.

Using the primitive set of knowledge types and links in MOT, it is possible to build the following twelve major categories of models than can be used in learning environments:

• conceptual models: class/sub-class hierarchies, “parts-of” hierarchies
• procedural models: sequential procedures, parallel procedures, iterative procedures
• prescriptive models: integrity constraints, laws and theories, decision trees, control structures
• processes and methods: analysis, synthesis and collaborative (distributed) processes

To develop the model of a process, we first identify the main task and represent it as a procedure; we then decompose this main procedure into sub-procedure (using C links) until terminal procedures (or operations) are reached. These first modeling operations provide the backbone on which conceptual knowledge can be linked to each procedure as input or output (using the IE links). These concepts can be described through their components and/or these subclasses (using S links) can be developed as deep as necessary to describe the process clearly. Finally, strategic knowledge (principles) can be added to rule any of the procedure (using R links), thus defining the control structure between its sub-procedures. This strategic knowledge can be embedded in intelligent advisor agents in different forms: advisors, wizards, tutors.

Generic Tasks and Object Types

The notion of a generic task (or a problem type) was defined early in the expert system field (Hayes-Roth et al, 1983). Then, it began to develop through the work of researchers like (Chandrasekaran, 1983,1987), (Clancey, 1985), (McDermott, 88), (Steels, 90) and others. The KADS project (Scheiber et al, 1993)aim at providing a common framework to these achievements.

Figure 1 - A generic task model with an interpretation in a specific model

Figure 1 presentsan application of the MOT technique used to describe a diagnosis task in a way similar to the KADS approach.This example illustrates how the different categories of knowledge can interact in process-oriented modeling.

First the main task is decomposed into sub-tasks (oval shapes) until terminal operations (or inferences) are reached. For one of these, an associated inference schema is shown, with its input and output concepts (rectangular shapes).

Principles (hexagonal shapes) are provided for some of the tasks. The general diagnosis principles regulate the flow of control between the three main sub-tasks: select-model, generate-hypothesis and evaluate-hypothesis. The decomposition principles regulate the terminal decomposition sub-process while the evaluation principles regulate the evaluation sub-process, a complex generic task by itself. One can see these groups of principles as control agents that can be implemented in a multi-agent system providing generic advice (or tutoring) on diagnosis.

In KADS terms, these principles correspond to the strategic knowledge, and some of the task (control) knowledge, the rest the task knowledge being represented by the main procedure decomposition tree. The terminal procedures, together with their inputs and outputs correspond to the inference knowledge, while the interpretation applied to each terminal inference inputs and outputs (roles) produces knowledge units in the specific domain model.

Generic and Specific Knowledge in an Advisor System

The lower part of figure 1 shows how generic and domain-specific knowledge are related through an interpretation mapping from generic concepts in an inference schema to domain-specific knowledge. This domain-specific knowledge can take the form of a conceptual structure, for example a “parts-of”description of a HI-FI system up to its smallest components. But it can also take the form of more or less complex local models of specific processes such as ÇTest the HI-FI system”, ÇTestthe amplifierÈ, ÇTestthe tunerÈ and ÇTestthe speakersÈ, all of them being processes, thus extending the process-oriented approach to the application domain as well and enabling a qualitative modeling of the application domain as well.

The interpretation mapping between generic and specific knowledge is implicit behind MerrillÕs Instructional Transaction Shells (Merrill et al., 1992), and also the XAIDA system developed at the USAF Armstrong Laboratory (Spector et al., 1993). In these shells, generic knowledge is embedded for tasks like component identification or process monitoring. The designer then adds specific domain knowledge and the system automatically generates a learning environment, for example to learn the components of a particular machine or system. The shells do not provide intelligent advice or tutoring to the learner, but they offer an environment that can be used to support learning through problem solving.

In some of our work, there is a similar generic approach (Paquette, 1992). Four prototypes have been developed on subjects like law induction from observations (COPERNIC), identifying a physiotherapy treatment (SONODOSE), planning a set of employment projects (PLANIF), and classifying individuals in a taxonomy (LINNƒ). These learning environments were not built automatically like in MerrillÕs or SpectorÕs work, but they are the result of the interaction between a designer and an EPSS called LOUTI. They use some generic knowledge embedded in a pre-defined library of problem solving tools, assembled by the designer to build the learnerÕs environment. On the other end, they go further by adding advising agents to the tool set using the generic task knowledgeto monitor the learnerÕs progress. For example, in the law induction shell, each advice is a generic statement in which the variables are interpreted in domain specific terms, so the advisor can act on different application domains like astronomy or chemistry.

More recently, we have applied the same general approach to build a course design environment called AGD (Paquette et al, 1994) in which the conceptual and procedural instructional design (ID) knowledge help define the tools’ functions and interface, and the strategic knowledge (or principles) help define the advisor that provides guidance to the designer. These principles can give directions on how to proceed within the design process, from context and learning needs analysis, to the definition of the learning activities and the didactic instruments. They can also verify the coherence of the designer’s production resulting from a terminal operation within the tools of the design environment. For example, they can advice to choose a problem solving scenario, or concept attainment scenario, depending if the learning needs aim at mastering the domain or, on the contrary, at providing a surface introduction to the field.

To demonstrate the generality of the approach, we have developed a new version of the law induction environment: COPERNIC-2. Here again, the conceptual and procedural law induction knowledge serve to define the learner’s problem-solving tools, basically data generation tools, table and graphic construction tools and mathematical expressions building and validating tools. On the other end, the law induction strategic knowledge has been used to define the advisor of the learning environment.

Figure 2 - A law induction generic task and its advisor

Figure 2 presents the law induction generic problem. We have omitted the input and output concepts to the procedures in the process description but these are important to check on the coherence of the learner’s production. The left part of the figure presents part of the procedural decomposition tree, while the right part present the associated principles that regulate the procedures at different levels. These principles will provide the advisor’s knowledge at corresponding levels of generality.

The generic task here is to solve a law induction problem selected by the learner, a trainer or an advisor system. The learner starts with the problem definition, a certain unknown law to “discover” and a list of the variables involved, and she has to produce a simple mathematical relation between the variables. This main process is decomposed in four first-level sub-tasks: “Define the experiment”, “Analyze the data”, “Search for an invariant expression of the variables”, “Validate the hypothesis”. Each of these tasks is further decomposed in second-level sub-tasks. For example, “Analyze the data” is decomposed into “Build a table”, “Select a data set”, “Obtain a graph”, and “Identify a dependency”.

The right part of figure 2 shows the principles associated to each task at different level of the tasks tree. Each set of principles can regulate the control between the sub-tasks of the associated task thus providing directions for progress within the task. The principles can also provide heuristic advice on the coherence of the actions and production of the learner within the generic task. The association of an isomorphic principles tree to a task tree is the basis of the ÉpiTalk architecture for advising we are developing (Paquette et al., 1996).

The interpretation of the generic task in specific domain terms will enable the advisor to present the advice component of the principle using application domain terms. For example, consider a low level principle assigned to the “Select a data set” task like

“if A, B , C are variable in the selected data set ,

advice that one of the variable A, B or C should be kept constant”.

Using the interpretation mapping in an application domain like the Perfect gas law, the advice component will become:

“One the variable Volume, Temperature or Pressure should be kept constant”.

Principles and advisors higher in the advisor’s tree will be more abstract and general, providing suggestions like:

“You have validated the hypothesis H,

but not enough experiments (only N) have been generated”

thus providing for causal explanation linking the “Define the experiments” sub-task to the “Validate the hypothesis” sub-task.

Of course, such a global principle can only be embedded in the parent node of both tasks, that is, in the Law induction advisor group of principles at the root of the principles tree. Interpreted in the Perfect gas law domain, this advice might become