INTELLIGENT STRUCTURES FOR LEARNING

This chapter deals with the emerging systems that currently form the backbone for learning technology. All of these systems share a common basis in that they are intelligent programs that are meant to help a user learn. Each, however, has typical characteristics which provide it, and the interaction it sustains, with a certain flavor that distinguishes it from the others. It is this set of flavors that I will be exploring in this chapter.

INTELLIGENCE IN A PROGRAM

It is useful to start by asking ourselves what makes a program 'intelligent'. How is an intelligent system different from a non-intelligent one -one that just blindly follows simple instructions on a computer? Already, there's the beginning of an answer in that last characterization of a non-intelligent system.

It is sometimes said that the field of intelligent systems for learning is rather difficult to evaluate, and that seems quite true given the diversity of current models of such programs, the technicalities that are involved in programming these systems, and the relative recency of the emergence of the field, with all that is implied in terms of the lack of precision of our notions and concepts to describe its achievements. This makes the issue of defining an intelligent program difficult, and certainly risky, but nevertheless important and useful.

Intelligent systems for learning are often associated with some of the following characteristics, although of course, any individual program will not have all, or perhaps even most, of these characteristics:

programmed in LISP, PROLOG, or some other artificial intelligence (AI) language;

represented through sophisticated graphics on a computer workstation;

involving some form of simulation;

enabling a greater degree of learner control;

potentially providing for natural language interaction;

enabling diverse instructional strategies;

making use of a large knowledge base;

including a sophisticated student model;

generative as opposed to pre-specified;

capable of inferential processing.

Now, some of these features can be seen upon examination to be rather unimportant to a characterization of intelligence in a program, while others are more important but secondary, and others, finally, come close to what could be considered the central features of intelligent systems for learning.

The first three features listed above, for instance, while sometimes associated with intelligent systems, are not for that reason constitutive of it. Intelligent programs can be, and have been, written in non-AI languages, just as simulations can be intelligent or not depending on other factors.

Some of the features in the list concern capabilities made possible because of the intelligence of a program. The next three features in the list are of this sort.

Finally, the last four features in the list come closer to primary constituents of intelligent systems for learning, without however constituting necessary features.

The reason for this seeming confusion regarding a definition is the diversity of interests and approaches which are found under the rather wide conceptual umbrella which is AI. The usual core element of AI is knowledge, such that all AI systems are knowledge-based systems. However, what constitutes knowledge, as opposed to mere information, is itself open to discussion. My intent here is not to attempt any strict definition of knowledge and information, but rather to simply indicate that core definitional concepts are difficult to come by for both AI generally, and for intelligent systems for learning more specifically.

We can also say that what constitutes intelligence in a program (and indeed in humans as well) is very much a matter of using knowledge processing skills to process knowledge in order to respond dynamically to some context in an autonomous way. That last element, autonomy, is central here. The more intelligent a program will be, the more autonomous (and hence unpredictable) its behavior will be. And that is very directly related to the extent of its knowledge of various kinds.

ENCAPSULATED KNOWLEDGE

Thus, we see that intelligence in a program is related to two central notions: that of knowledge, and that of processing knowledge. Let's consider each in turn.

I will be dealing in Chapter 5 with what human learning is and discussing at that time the shape that knowledge takes as it is learned by humans. For the moment, we are concerned with machine cognition and therefore with the status of knowledge in computer systems.

Computer knowledge is structured information, i.e. symbolic data elements interrelated among themselves within what is known as a knowledge base. It matters little for now what the form of representation is. Let's consider a portion of a semantic net (a type of knowledge formalism) from a geography tutor called SCHOLAR, which was developed many years ago at MIT.

Bolivia

Superconcept > Country

Superpart > South America

Area > Approx 465000

Population > Approx 4000000

Language > Spanish

Capital > La Paz

Cities > La Paz Sucre Potosi Cochabamba Santa Cruz

Buenos Aires

Superconcept > City (Capital of Argentina)

Superpart > Argentina

Location > On Rio de la Plata

Population > 6000000

Now, is SCHOLAR's knowledge base true knowledge by virtue of its structure? What about the fact represented as 'Buenos Aires is a city'? SCHOLAR has absolutely no notion of what Buenos Aires might look like, nor does it have any inkling at all of what a city is. But it does know that something called Buenos Aires is connected to something called 'city'. That is the extent of its knowledge of this aspect of Buenos Aires.

The knowledge base then is simply a set of connections following a set of structural constraints. Importantly for our discussion, these constraints are imposed from outside; indeed, they come from the head of the person who built the knowledge base. What are these constraints? Well, some of them are purely logical, e.g.. Buenos Aires cannot have more than one population figure (it can't be both 6 million and 9 million); most of them, however, are semantic, i.e.. based on the logic of meaning (which simply means that they involve other elements of knowledge, not explicitly represented), e.g.. if Buenos Aires is represented as a city, then it won't have a capital as one of its features. These constraints are external for the simple reason that SCHOLAR has no knowledge whatever of them: no one ever told it that population figures are unique, or that countries, provinces and states have capitals, but that cities do not. Only its knowledge engineer knew that!

What this is getting at is that a knowledge base is merely information stored in a certain way such that it can be used in symbolic processing. There is no inherent meaning hidden within the symbols, nor within the symbol structures, constituting the knowledge base. This means that a knowledge base is not essentially different from a data base.

We sometimes think of a data base as information structured along syntactic lines: data elements are associated with a given row and column in the data base, and they derive their usefulness (their 'meaning') from that association, i.e.. from being located at a particular spot in the structure ( a particular row/column coordinate). And we think of a knowledge base as information structured along semantic lines: information elements are associations involving object/attribute/value combinations (e.g.. Bolivia/capital/La Paz or Buenos Aires/population/6 million). The meaning of these triads does not involve a particular location in the data base (it does not matter where they are located), i.e.. they are not spatially constrained, as are elements in a standard data base.

That matters little, however, because both syntactic constraints and semantic constraints are simply two forms of structural constraints and indeed, quite interchangeable. SCHOLAR's knowledge for instance can easily be represented in a standard coordinate data base:

Name | type | population | capital | ...

Buenos Aires | city | 6 million | not applicable | ...

Bolivia | country | 4 million | La Paz | ...

Likewise, a standard data base can easily be represented as a semantic net:

Flight 303

departure > 1030h

arrival > 1158h

service > hot meal

Flight 906

departure > 1530h

arrival > 1742h

service > snack

Both of these alternate forms of representation are of course very awkward ways of structuring the information. The implications, however, are purely economical (more or less computer space or computer search time), but not cognitive: the information can be retrieved and reasoned with irrespective of how it is represented. This is analogous to the situation with programming languages: anything can be done in any language, it's just less cumbersome to program something in a particular language rather than in another. We are merely dealing, here, with an issue of appropriateness.

Now, let's turn to the processing of knowledge. When SCHOLAR is asked by a student whether Buenos Aires is in South America, it answers 'yes', but yet, nowhere in its knowledge base is this fact stored. Here is globally the process that SCHOLAR engages in:

first, it checks in its Buenos Aires structure to see if there is a 'superpart' attribute, and finds one ('Buenos Aires /superpart/ Argentina');

it then checks to see if the value stored there alongside the attribute is South America, and it finds that it is not South America, but Argentina;

it then restarts the process, this time substituting Argentina for Buenos Aires (thus deriving the question 'Is Argentina in South America?');

it does find a correct match ('Argentina /superpart/ South America'), and so reports 'yes' to the original question.

What SCHOLAR did was to simply activate a procedure corresponding to the transitive logic of 'If A is in B, and B is in C, then A is in C'. This procedure is not in this instance part of the knowledge base (as it could well have been in a fully declarative representation), but that is not too relevant here. What is important is that the reasoning performed by the system is simply due to the presence of this procedure. By extension, the collection of such procedures in a system constitute together its intelligent abilities.

As with the elements of the knowledge base, the system is simply dealing here with uninterpreted symbol structures: it has no idea of what logic is, or of what 'in' means, or of the validity of the syllogistic procedure it is performing. The procedure was just planted there by the program designer and it is simply activated under given circumstances. The lack of deep meaning in the system matters little for our goal of technological design, even if it is of very real concern in philosophical circles.

In sum, there is nothing mystical about an intelligent program. Such a program simply manipulates symbol structures, just like any program. However, what gives it its power (its intelligence) is the fact that these symbol structures mimic our own knowledge structures, i.e.. they parallel our own knowledge (actually, a very small part of it) including some of our logical procedures. Because of that, a knowledge-based system can perform intelligent actions, such as to correctly answer questions involving inference. Furthermore, the reason intelligent systems are not as intelligent as humans is quite simply that they do not possess the vast knowledge possessed by humans.

The key to an intelligent system is thus knowledge. What that provides is flexibility and autonomy. The system does not have to be totally pre-programmed: give it some knowledge and give it some logic, and it will react logically and somewhat independently, in the sense that if its knowledge is quite vast and complex, its behavior will tend to be varied, if not perhaps even unpredictable. Just as with people! Autonomy is the sign of an intelligent program: the decisions the program makes as it operates are its own rather than those of the programmer who fashioned the program. For that's a general feature of any intelligence: responding appropriately to unforeseen circumstances. Do keep in mind, however, that all this is relative: any particular program will only be more or less intelligent. Here as well, it's just like with people.

A PROTOTYPICAL INTELLIGENT TUTORING SYSTEM (ITS)

All computer-assisted instruction (CAI) systems, whether they are intelligent or not, have in common the fact that they are reactive learning environments. What that means is that they are interactive, i.e. they involve an exchange of information between student and system. The basic process is the following: the student attempts some task (which invariably involves checking the validity of her developing knowledge), and the computer reacts in some way that informs the student about her performance on the task (and hence on the validity of her knowledge). This is a very bare-bones description of the pedagogical act. And it applies to traditional drill-and-practice CAI, to classical tutorial CAI, to simple simulation and games, to LOGO, etc., just as it applies to all forms of ITS.

Each program constitutes an informational environment which can foster learning, and learning essentially occurs through the interchange between the program and the student. What characterizes an intelligent program in this context is a greater sophistication in the program's reactions, its the flexibility I was talking about in the previous section. As a result, an intelligent program will be more adaptive to the student's needs and interests. That, after all, is the whole reason for designing computer tutors, and especially intelligent computer tutors.

Now, what allows ITSs to be more sophisticated, flexible, and adaptive than their CAI counterparts is the way they are designed. More specifically, it is their use of AI techniques of design, AI being, in this view of the field, no more than a programming methodology, or if one prefers, a set of techniques for programming cognitive actions -- remember the semantic net / database distinction considered in the previous section.

So an ITS, just like any computer tutor, is a reactive learning environment. The student pokes it (e.g.. with 'Is Lima in Bolivia?') and it reacts (with 'No, Lima is in Peru.'). What makes such a sophisticated reaction possible is the fact that an ITS contains a model of the environment which makes up its subject matter. It has within it a simulated world corresponding to some reality. For instance, an ITS for Canadian geography will have an internal informational model of Canadian geography corresponding to the real state of affairs in Canada (it's a model in the same sense that a map is an analogue model of the land). Likewise, an ITS for electronic troubleshooting will have a model of electronic circuits, an ITS for medical diagnosis will have a model of the diagnostic process, and so on. This model is what is known interchangeably as the domain model, the expertise model, or the knowledge base of the system. The model is represented in some form internally in the computer, generally in one of the various AI formalisms developed explicitly for that purpose (SCHOLAR's model of South American geography for instance takes the form of a semantic net).

The reason such a model is interesting is that, as a student, you can poke it and see how it reacts. You can manipulate it and wander through it, to the full extent that the system is structured to let you do that. In a profound sense, an ITS is a simulation, albeit a symbolic one rather that the numerically-based simulation commonly found in science and in traditional CAI. The user provides the system with some particular symbolic input, which the system then manipulates to determine how that fits in with its model of the domain, and once done, it lets the user know the result, either directly by telling her or indirectly by guiding her to some other task which will reveal the answer. This, in effect, is pedagogy, and the strategies implemented in the system are found in what is known as the tutorial module.

The degree to which the computer tutor is a directive one, as opposed to merely an open-ended learning environment inviting student exploration, is an issue of task-setting: in the first case, the tutor sets the tasks for the student to pursue, while in the second, the student sets her own tasks as the exploration evolves. Now, bear in mind that there are more or less directive tutors and that it is not therefore a case of all or none in task setting. Furthermore, independent of this task-setting, the student may be more or less free to wander and explore, depending on how the system is set up and on how restricted or not the interface is. Thus, ITSs are not committed to one form of pedagogy, but can be fashioned instead according to multiple pedagogical views.

As the student pokes the ITS, it will react, and for that reaction to be fully appreciated by the student, it should be as adaptive as possible. It should mold itself to the student's current frame of mind. If I ask a geography tutor where Winnipeg is, it doesn't help for it to tell me it is in Canada (I already know that), but it would help to tell me that it is in Manitoba (since I am unsure about that). Likewise, if the tutor hopes to teach my child some Canadian geography, it had better start by teaching her the different provinces (she hardly knows them), but I myself wouldn't care much for that (since I know them well enough already). We're talking here about adaptation, and adaptation hinges on knowing whom you are teaching, in as much detail as possible. Just like a human tutor, an ITS gradually builds up a picture of just who the student is so that it can adapt its strategies appropriately. The resulting picture of the student, constantly evolving as learning takes place and as new interactions make more precise the initial picture, is what is known as the student model.

The final element of an ITS is the interface. This is the actual environment in which all this teaching and learning takes place through communication between the student and the ITS. There are two interface levels involved in an interaction. The first level, corresponding to communication channels, is the most evident: the interaction can take place via natural language dialogue, via direct manipulation and option selection (as with a mouse for instance), via voice, etc. The second level is less evident, for it is closely tied to the system's pedagogical strategy: it consists of the general medium (sometimes called a metaphor) through which the interaction occurs: a mixed-initiative dialogue is a different didactic medium than is an instructional game, for instance, and both are different again than a graphical simulation. Combinations of forms are possible, of course, for the interface design field is wide open to mixed-media and multiple communication channels, and eventually, to novel forms of both.

These four modules thus make up a prototypical ITS: the domain model, the tutorial module, the student model, and the interface design. Given that each of these modules can be designed in a number of different ways, and that they can interrelate to each other in yet further varied ways, it is easy to see that a great many forms of ITSs are possible. Some typical forms are emerging, however, and that's what I will turn to now.

STRUCTURES FOR INTELLIGENT TUTORING

This section presents an overview of the different kinds of system that are emerging currently in the field of intelligent programs for learning and that will continue to develop and be applied to a variety of learning tasks. These systems include the following:

expert systems;

intelligent tutors;

instructional coaches;

advisor systems;

assimilatory tools.

Articulate expert systems.

An expert system is not in itself a teaching program. Its function is problem solving leading to the provision of expert advice in situations involving uncertain knowledge and that thus require heuristic processing. An expert system is a performance program in which domain expertise is represented and used, and therefore, it may well be possible for a trainee to learn aspects of this expertise through observation of the expert at work, solving particular problems.

Various human-computer interface aspects of expert systems have evolved specifically to assist the user in understanding the `expert at work'. The various possibilities of asking the system how it derived some conclusion, why it is requesting some item of information, or why a given conclusion is not possible illustrate these interface features. The motivation behind these features is primarily to boost the credibility of the advice offered by the program, but these features also assist the user in learning something about the resolution process itself.

An interesting add-on feature to an expert system is a prediction/correction procedure which uses breakpoints within the expert system to interrupt the resolution process at interesting junctures and engage the user in the task of predicting what decision the system is about to come up with. This in effect constitutes a tutorial process directly aimed at exercising the user in the proper use of the domain knowledge.

The advantage of this situation is that expert systems are both numerous and popular, and will be all the more so over time. If they can easily be taken advantage of for training purposes, much can be gained. The difficulty, however, lies in the articulateness of the expertise contained in the system's knowledge base. The more that knowledge is compiled in smooth and efficient rules (as it often is in complex domains based on long-term expertise), the less articulate a novice will find it and thus the less she will be able to relate to it. Near-experts using such a system, however, may find the knowledge more articulate, and will more assuredly profit from it. Likewise, novices using expert systems that incorporate simpler domains of expertise will find them all the more articulate because of this relative simplicity.

Specific tutors.

Computer tutors are very explicitly instructional programs. Their function is clearly didactic and people use them because they want to increase their knowledge of a specific domain or augment a given skill. Tutors are the core exemplars of intelligent systems for learning and the basic framework of an ITS serves as the starting point for the design of variants such as coaches, advisor systems, etc. There is a notion of generality, therefore, involved in the definition of an ITS, and that makes it somewhat difficult to corner the specificity of the category of tutors which are not one of the variants.

That specificity lies perhaps most explicitly in the aim of specific tutors to introduce new knowledge elements to the learner or have her practice new skills, always within the framework of a structured view of the particular domain of knowledge. In effect, such instruction will take place within a curriculum, ie. through a planned sequence of topics or hierarchy of skills. A complex skill or an intricate domain is broken down into its constituent elements, such that it can be tackled in a progressive manner by the student. This is what most directly distinguishes a computer tutor from an expert system. How the domain knowledge is represented for didactic purposes (in effect, how it can be made articulate) is the key issue for any specific tutor.

Indeed, the nature of the interface (whether it is mixed-initiative or not, whether it is based on natural language or on graphics, etc.), how the tutor handles incorrect knowledge (the student's misconceptions), and all else in the operation of the system is, in the end, subordinated to the key issue of the structural features of the domain knowledge. We will examine later in this chapter the core tutorial processes involved in dynamically structuring the instructional interaction, so as to maximize the learner's involvement with the domain knowledge base, and hence her gain from it.

Instructional Coaches.

The essential idea behind coaching is opportunistic intervention, i.e. using one's judgement regarding the timing of a tutorial intervention. The reason why this particular consideration is so important is that a coach is a tutorial component grafted onto another system, usually a computer game involving some form of cognitive skill development. The avowed aim of the system, and its appeal to the user, lies in its entertainment value. The user is not there to learn, but rather to play. In her eyes, learning is a rather secondary aspect of the activity, and it must not therefore interfere with her primary reason for being there, game playing. Hence, the tutorial challenge of soft intervention, which, if carried off successfully, results in a powerful instructional situation of great appeal.

The coach's main task is to observe the user's behavior and seek opportunities for comment which will forward the user's goals while at the same time furthering her mastery of the cognitive skills involved in the task. A functional marriage occurs between the entertainment goals of the user (who does not care explicitly about learning) and the instructional goals of the tutorial system (which does not care about the gaming aspect). The result is that coaching involves explicit consideration of the motivational aspects of the situation.

Advisor systems.

An advisor system is a coach of sorts, for it too emphasizes opportunistic tutoring of a soft kind. Like a coach, an advisor system is hosted by another system. However, the host system in this instance is no longer a game, but rather a practical computer software product, such as a word processor or an electronic mailing system. The task involved in the situation is no longer a cognitive task embedded in an entertainment software product; rather, it is an information processing task embedded in real-world practical interactions, such as sending an electronic memo to a colleague or formatting a document in a particular way.

An advisor system is an active help system. It observes the user's behavior with the host system, infers the user's goals, determines whether the user needs help or would profit from some advice with respect to the task at hand, and finally, decides whether it is opportune to intervene or not. As in the case of a coach, that last decision is a crucial one, for a user whose task-oriented activity is interrupted too frequently or for matters which she considers minor will not be greatly pleased, nor is she likely to be very receptive to the advice offered. The task of the advisor system is to make fine judgements, then, regarding intervention possibilities.

Active help does not fully cover the functionality of an advisor system, however. Indeed, such a system has two complementary goals: first is the goal of assisting the user with overcoming the immediate problem at hand, then is the longer-term goal of providing the user with a better grasp of the functioning of the host system so that problems do not reoccur. Thus, there is a local immediate goal as well as a far-term didactic goal. The balance between the two may well be a delicate one to achieve.

Assimilatory tools.

This type of tool is geared to encouraging the learner to explore easily accessed electronic information in the spirit of interest-driven informal learning. It contrasts in this respect with the `power tools' discussed previously which are more concerned with structural aspects of learning and with guiding the learner in overcoming errors and misconceptions.

Assimilatory tools are characterized by features aimed at ease of access, such as the features of hypermedia and of concept maps, which invite exploration by the learner in terms of her own interests and perceived needs. Learner initiative is central to these tools, so that information assimilation can occur on the learner's own terms, rather than on those of a tutor. Unlike the tools previously discussed, there is no task-setting involved in the system and no close guidance of the learner-system interaction.

Because of these features, assimilatory tools are particularly appropriate for use in informal learning settings, where a learner interacts with information on the basis of evolving curiosity, rather than on that of achievement needs. These tools are not particularly proactive, nor adaptive, and could therefore be termed `enabling access tools' to highlight their particular features.

An interesting aspect of the systems which were just reviewed in this section is the pedagogical context within which they operate. Students interact with a specific tutor with the intent of learning the knowledge it encompasses. With the other systems, however, the learning intent is less explicit and sometimes even conflicts with another intent of more primary concern to the user. Coaches involve entertainment, advisors involve some real-time task, assimilatory tools hinge on curiosity. Even articulate expert systems often instruct while being used for practical consultations. In line with the view of the future presented in chapter 2, we see an evolving emphasis on informal learning and informal settings in the design of ITSs.

TUTORIAL PROCESSES

The previous section described various learning tools that illustrate the diversity of design possibilities within intelligent systems for learning, both in functional terms and in structural ones as well. Lest this diversity seem overwhelming, it is useful at this point to engage a converging process which will enable us to focus on the core features of intelligent tutoring. Just as we attempted in the beginning of this chapter to focus on the essence of intelligence in ITSs, so now we must attempt to do the same with respect to tutoring. It becomes important for two reasons, one theoretical and one practical: theoretically, are we faced with multiple types of learning, each requiring specific and distinct tutorial strategies?; and practically, can we aspire to genericity in ITS design, ie. can we design a generic tutoring shell? These two questions are of course interlinked.

The theoretical issue is an important one with respect to current forces at play in intelligent systems for learning and in cognitive psychology. On the one hand, one is struck in the field of learning technology more by the differences between existing systems than by their commonalities, the latter being sometimes hard to find, except a very global level. There seems to be little likeness, for instance, between SCHOLAR and SOPHIE, or between GUIDON and WEST, four well-known ITSs. There are procedural / declarative distinctions that crop up in the picture, as there are distinctions between varying objects of learning. In educational psychology, there is a tendency to classify the objects of learning and to associate distinct processes with each. For instance, knowing of something, understanding it, and being able to apply it can be considered three distinct learning objects. Alternatively, a classificatory scheme can distinguish between facts, concepts, rules, strategies, etc., each with particular conditions of learning. But there are also attempts to build a cognitive science which treats learning as a unified process within a larger architecture of cognition, taking a more systemic approach, although a more lower-level one as well, to portraying human cognitive functioning. Our task here, and especially in chapter 5 where learning is discussed, is to examine this issue and see where it can lead us.

As for the practical issue, it is essentially a technological one. There certainly exists the hope that all the on-going experimentation in the design of learning technologies will lead in the end to general principles of design which can have generic value across disciplinary domains. One would like in the end to move away from the extensive and costly handcrafting of systems to the use of generic shells that can be quickly adapted to particular domains while retaining their tutorial precision and expressiveness. The importance of the latter caveat is illustrated by the generic shells found in traditional CAI: these authoring languages are certainly generic, but many feel that their genericity was bought at the expense of pedagogical sophistication, the type of instruction resulting from their use often being bland, routinized, and generally unexciting. The question for learning technology, then, is whether the tutorial sophistication currently acquired through painstaking handcrafting can survive an evolution to genericity. The answer is probably yes, but then, will the eventual generic tools be of such complexity as to prove unwieldy, or can they retain a simplicity that will lead to a widespread usefulness?

To recap, our task is to see if we can synthetically describe tutorial processes in such a way that they may prove both theoretically and practically useful. In other words, at a general level of analysis, what's involved in tutoring?

Let's first consider some of the tutorial specifics. The following are some of the actions that can be involved in tutoring:

tasking the learner to make a hypothesis;

presenting an overview;

answering a question from the learner;

providing feedback;

summarizing.

What becomes apparent is the necessity to make a distinction, a strong one at that, between tutorial processes and information content. In colloquial terms, it amounts to distinguishing between how to teach and what to teach. For instance, presenting an overview involves both a process (that of presenting something) and some content (the overview), despite the fact that we often tend to view the presentation of an overview as a tutorial strategy in itself, thus confounding process and content.

As we remove content from our tutorial actions, we see that presenting an overview, presenting a specific fact, presenting an example or a counter-example, etc. are all instances of the tutorial process of presenting information. This illustrative tutorial process, resulting in what could be called information communication, is a good example of our converging process in seeking to characterize the essence of tutorial processes -- even though, as we will presently see, we can converge even further in describing tutoring processes.

Let's start at the top and ask ourselves what is involved in tutoring. At a global level, there are two core instructional decisions that are constantly made: focus selection and cognitive tasking. Focus selection involves deciding what to teach next; cognitive tasking centers on deciding how to teach it. These are core processes, which are pervasive in a truly flexible tutor, and which operate at various levels of detail with respect to content.

Focus selection results in a content decision, irrespective of how that content will be introduced to the learner. For instance, it amounts to concluding that it is now appropriate to consider concept X, or that misconception Y needs to be dealt with right away, or that counter-example Z would be profitable for the learner to consider at this moment, or that it is now time to focus on the relationship of concept X to the larger picture ABC, and so on. Two things should be noted. First, the process of focus selection occurs at varying levels of detail: selecting the next example to delimit a concept is very detailed, while selecting to situate a concept within its larger conceptual structure is very global; both are important content decisions, differing only in the grain size of the object to which they apply. Second, we should note that the scope of focus selection, its pervasiveness, depends directly on what domain knowledge is represented in the system: if a cognitive rule has associated with it only one counter-example, once that counter-example has been invoked, then that's it for counter-examples with respect to that particular cognitive rule. Both of these aspects relate to the relationship within an ITS between the domain knowledge base and the tutorial module.

We need to turn now to cognitive tasking, the core tutorial process concerned with how to teach what has been selected as the focus of instruction. Cognitive tasking is a decision regarding the extent to which the tutor should communicate the knowledge selected as opposed to letting it be discovered by the learner. To tell the learner, or to guide the learner, that is the central question. How socratic one should be as a tutor is the essence of the question. As we shall see, the issue is a complex one, for a number of reasons. First, however, we should consider the term cognitive tasking itself.

The choice of term relates to how a learner interacts with information, and hence, in tutorial terms, to how the tutor sets up the task for cognitive processing by the learner. If the learner is told an item of information, her task is to integrate it within her existing knowledge; on the other hand, if she is put in a situation where she must discover the solution, then her task is more intensively one of problem-solving. In each case, she is involved in cognitively processing information, but the task differs in emphasis, if not in nature, from one case to the other. And, generally, it is the tutor that must decide on the form of the task.

Let's consider cognitive tasking in more detail and examine some of the complexity of the process. First, cognitive tasking does not merely involve a nominal distinction between knowledge communication on the one hand and guided discovery on the other; rather, it involves these two aspects of tutorial intervention as bipolar concepts which anchor a dimension along which we can find varying degrees of telling and guiding. For instance, giving the learner a strong hint to a solution may not be exactly telling her the answer, but in certain circumstances, it may well be nearly equivalent to doing just that. Furthermore, in tackling the learning of particular content, we may start off on one side of the dimension and gradually shift toward the other, as when we present a task, then give a general hint, then go on to a more specific hint, and finally provide the answer if the learner has not yet caught on.

Second, cognitive tasking can at times be constrained by the nature of the knowledge being selected for tutorial action. If one has never had occasion to learn about Lima before, it is rather difficult to discover out of the blue that the capital of Peru is a city whose name is Lima. One must tread carefully here, however, for it would not be wise to hastily conclude that certain types of knowledge are open to discovery whereas others are not. To go back to Lima to illustrate, it could well be appropriate to set up a situation in which the learner has to explore a set of on-line maps which contain the necessary information to discover what the capitals of different countries are. To be sure, such a task setting involves both active learner exploration and some direct telling, and it may not always be quite clear where it is situated on the cognitive tasking dimension discussed just a moment ago.

Third, earlier in this chapter, I talked of ITSs, and indeed of all interactive instructional computing, including traditional CAI, as being basically reactive learning environments which can be poked and which then react. That is certainly the case in guided discovery environments, where the learner generally exercises a lot of initiative. But is it the case in more directive circumstances involving a greater degree of direct knowledge communication? Yes it is, from the perspective of the learner, for whatever is told to her results from her actions in responding to the interspersed questions put to her by the tutor. The tutor, in effect, reacts to her pokes. We must be careful here, though, not to get carried away with this idea of the learner poking the learning environment to get a reaction from it; a better conception of the instructional process may be that of two systems (the learner and the ITS) each poking the other for a reaction, these actions taking place according to the particular circumstances involved in the interactive protocol unfolding at that moment in time. We will have occasion in chapter 4 to come back to this expanded view of reactive systems.

Fourth and finally, the complexity of the issue of cognitive tasking derives from the fact that it builds on the process of focus selection we saw earlier, and thus occurs at varying levels of detail. For instance, a global summary can either be presented to the learner, or she may be required to construct one herself, with or without help, depending on the sophistication of the system. Likewise, at a very detailed level, we can have something as simple as giving the learner a particular fact (remember the case of Lima), or as direct as the learner doing an easy exercise so that her mastery level can be diagnosed. There remains nevertheless a gulf of cognitive processing between doing an easy exercise and constructing a summary of the domain from the knowledge that was acquired.

To conclude with respect to the two core tutorial processes that are focus selection and cognitive tasking, I am certainly not suggesting that their consideration removes the complexity involved in tutoring in multi-faceted and varying domains. What it does do, though, is offer a perspective which hopefully clarifies the notion of instructional strategy in ITS design (telling versus guiding) and which may poise us to tackle the genericity issue of ICAI without getting lost in the diversity of knowledge domains.

What has not been done here is to flesh out the full scope of tutorial processes as these interact and vie for the attention of the tutor as tutorial planning and re-planning takes place, both before instruction and dynamically during it. We will be getting more involved with this topic as we delve into design issues in the next chapter.