• No results found

Chapter 4 Domain and Task Representation for Tutorial Process Models

4.3 Task specification

4.3.2 Domain and task separation

One way of separating out domain and task considerations is to set up a transition net representing legal operations within the domain and then overlaying permissible or impermissible operations for each task. For example, given the gear unit introduced in Section 4.2. 1 we could overlay the domain description by indicating choices that cannot lead to its correct assembly (see Figure 4. 10). The two operations that lead to the state 'S _ D' are flagged as impermissible as denoted by the crossed lines on the corresponding transitions.

The problems with using transition nets in domain modelling are still present when they are applied to task representation. For example, the incorrect action can easily be detected but telling the student why it is not allowed will have to be provided as a

separate annotation. It would not be helpful to tell the student that a particular move is not allowed because it 'leads to an impermissible state'.

Figure 4.10 Task overlay in the gearing assembly problem

Given that a Strips-style representation is more user-oriented and economical than the transition net approach, the question arises, how can permitted task moves be computed and represented in such a system? Drummond ( 1 989) considers this problem in the planning context but his results are equally relevant for teaching.

His approach is to consider possible sequences of actions that may be carried out and to pinpoint ones that are critical to the completion of a given task. As an intermediate step in this process he gives an algorithm for producing a projection graph of possible 'behaviours' of the system (Drummond, 1989, p 1 07). Basically, from a given start situation, all the possible next situations may be produced in turn by checking preconditions of operators . The main complication is checking for c au sal independence. If two or more operators are 'free from interference' (that is, the postconditions in one do not change the preconditions for the others) then their order of application is irrelevant, and this can be indicated in the corresponding graph. The projection graph for the gearing problem is given in Figure 4. 1 1 .

It may be noted that the projection graph is only marginally different from a transition net but the distinction is crucial. In the former, some transitions encompass more than one step: So, for example, to move from ' _ __ ' to 'S _ D' two actions have to be taken: placing S in position and placing D in position. These actions are independent, however, and so can be carried out in either order. By grouping together such sets of

independent actions we can distinguish situations where the order of execution may be crucial and those where it is not.

Figure 4.11 Projection graph for gearing problem

Once a projection graph has been produced we can overlay the routes that a user may select to achieve a specific goal. Consider the task of getting all three parts in position and allowing any sequence of actions to be taken that achieves this goal. The possible alternatives for this are highlighted as thick solid lines in Figure 4. 12. Given this information, three critical points can be identified from which the user may make an incorrect selection (or sequence of selections): ' _ _ _ ', 'S _ _ ' and ' _ _ D'. Drummond ( 1 989, p 1 1 0) gives an algorithm for generating the conditions satisfied at each of these points and the possible actions that may be taken from here. These give 'situated control rules' (SCRs).

Figure 4.12 Highlighted task routes in gearing problem projection graph

The SCR algorithm is fairly straightforward. For a given situation and set of acceptable paths through a graph, tpe conditions in this situation that are relevant to the traversal of these paths are generated. This is done by tracing along the paths, noting the preconditions of the operators encountered. The resulting set of conditions form

the antecedent for a rule. The consequent is generated by accumulating all the sets of operators that can be applied from the given situation to get to an adj acent one. For example, in figure 4. 1 2, the acceptable next situations from ' _ _ _ ' are 'S _ _ ', ' _ _ D', '_ R D', '_ R _' and 'S R _' . The sets of operators leading to these situations form the consequent for the SCR rule from ' _ _ _ '.

The S CRs for the critical points in the gearing problem are shown in Figure 4. 1 3 . Column 1 entries denote the current situation, column two shows the list of conditions that all have to be satisfied before the rule can be invoked (the rule antecedent), and column three lists alternative paths that can be followed if the corresponding SCR conditions are satisfied (rule consequents). The conditions in the first rule correspond to the situation ' _ _ _ ' from which point there are several alternative actions. Note that, in addition to the single steps such as placing S in position, there are multiple steps such as inserting D and placing R in position from the edge. These multiple steps denote sets of independent actions that can be taken. The second rule corresponds to the situation 'S _ _ ' and, from this point, the only action that ensures the goal is still achievable is to place R in position from the middle. The third rule is similar in form to the second one.

situation conditions acceptable moves

- - - available($) place(S) available(R) Eplace(R) available(D) Mplace(R) -inplace(S) place(D)

-inplace(R) { place(S), Mplace(R) } -inplace(D) { place(D), Eplace(R) }

s - - inplace(S) Mplace(R) available(R) available(D) -inplace(R) -inplace(D) - -D available($) Eplace(R) available(R) inplace(D) -inplace(S) -inplace(R)

Consider how these rules may be used in a teaching environment. In a dialogue, the user is at some point: for example, with all three parts available but none in position. Once the user reaches this situation all the conditions in SCR rule 1 are satisfied and so the rule becomes applicable. Various forms of guidance are now feasible for the user. For example, a list of all the actions that will lead to the required goal can be given or we can check whether a choice made by the user can possibly lead towards the goal. Alternatively, the conditions under which a particular operation is possible may be specified.

This representation of guidance rules fits in with the Strips-style domain description and is again economical in storage. An intermediate transition graph-like structure is needed, but -only temporarily, to generate the SCRs. Also, various economies of storage c an be employed during this generation. Once the SCRs have been produced for a given task then only the original domain table and the task SCRs themselves need to be retained.

Using an analogy with finding one's way through a maze, the SCRs may be viewed as signposts at various points to ensure that bear pits and monsters are avoided. Generally, methods that employ some sequencing control are constrained to pull the user back to the place where they went wrong. They may be told right away, or only after they have wandered around for a while, but they will usually be required to join the path where they left it. In this alternative approach, they may be led back to the optimal path at some other point since local context is used for guidance. This gives extra flexibility and may improve the convenience.

SCRs can be used in more complex domains in a similar fashion. In the next chapter, the production of S CRs for tasks in the VCR domain will be considered.

4.4 Summary

Various possible frameworks for building procedural tutorial systems have been examined . The goal has been to determine a scheme that is powerful, consistent, flexible, easy to apply and could be used as a basis for providing helpful feedback to students.

Transition nets have the expressibility required but at the expense of clarity and economy. They do not lend themselves to clear expression of cause-effect steps, do not have any natural hierarchical structure and can become quite cumbersome to handle.

TWEAK is a consistent version of the Strips model and is able to represent cause-effect relationships quite succinctly. It is limited in expressibility, however, and can become quite cumbersome for complex domains.

Tenenberg's formulation of Strips is both economical and powerful. It has been carefully formulated to be consistent, and has the bonus of static axiom tables for representing relationships that do not change. These tables can be used to include hierarchical information.

Although domain constraints can be readily described using Tenenberg's method, there is no obvious way of including task information. A method for providing this has been described. It involves adapting a method of planner guidance devised-by Drummond. His situated control rule formulation can be used for denoting task information, overlaying it on the domain description.

What has been proposed in this chapter is a scheme for building teaching systems that employs techniques adapted from AI planning. The cause-effect scheme and hierarchical features allow appropriate feedback to be provided as necessary. Distinguishing domain and task issues permits these aspects to be considered separately. The situated control rule formulation facilitates the provision of appropriate task information. Lastly, partitioning into sub-domains is simple and not only allows further enhancements to the feedback but permits economies of storage and significant improvements in speed to be made (Smith and Kemp, 1995).

Although the modified strips representation is convenient for modelling certain kinds of domains and tasks it has its limitations. It is based on a state-space approach and so in domains where this is inappropriate (for instance, mathematical modelling of computer circuits) it would be difficult to use in isolation. Another potential problem is the size of the proj ection graph for large domains. This latter problem is one that is still being addressed (Smith, 1 994f).

Chapter 5

Interactive Learning Environments for

Procedural Tutors

5.1 Introduction

What has been described so far has been a succinct knowledge representation method for procedural tutors that facilitates the provision of feedback. In order to provide a system built along these lines, various other problems have to be solved. Addressing these problems provides the focus for this chapter. In Section 5.2, models of procedural simulators are presented, including results from programs. Task specifications are added in Section 5 . 3 . In Section 5.4, a way in which a graphics interface could be employed to aid the building of a procedural task teaching system is considered. Although this project does not address the issue of what kind of feedback is most effective, some of the different forms that guidance might take are considered in Section 5.5. Finally, in Section 5.6, a scheme for system development is proposed.

5.2 Implementing domain models