Representing First Aid Problem Solving Knowledge

Karyn A. Moffatt Department of Computer Science University of British Columbia

201-2366 Main Mall Vancouver, BC

V6T 1Z4 Canada +1 604 822 5108

kmoffatt@cs.ubc.ca

ABSTRACT

In this paper a framework for representing problem solving knowledge for the task of solving first aid problems is presented. Although, the current methods for teaching first aid problem solving are vital and irreplaceable, there is a deficiency inherent in them that could be met by augmenting their use with an intelligent tutor. This paper describes the target knowledge domain used to build problem solver, and presents the problem solver in the context of a hypothetical system in which the problem solver could be used.

TABLE OF CONTENTS

1. INTRODUCTION..................................................................................................... 3

2. MOTIVATION ......................................................................................................... 3

3. THE DOMAIN.......................................................................................................... 5

4. RELATED WORK ................................................................................................... 7

5. CONTEXT................................................................................................................. 9

6. IMPLEMENTATION ............................................................................................ 11

7. RESULTS ................................................................................................................ 13

8. FUTURE WORK.................................................................................................... 15

9. CONCLUSION ....................................................................................................... 17

10. ACKNOWLEDGEMENTS ............................................................................... 17

11. REFERENCES.................................................................................................... 17

LIST OF FIGURES

Figure 1: Example of categorized instruction of domain 4

Figure 2: The Priority Action Approach - The knowledge to be represented 6

Figure 3: Relationships between nodes and their parents in the ANDES system 8

Figure 4: The Noisy OR relationship. 8

Figure 5: The Noisy AND relationship. 8

Figure 6: Contrasting the procedural and categorical representations 9

Figure 7: The Architecture of the First Aid Problem Solver 12

Figure 8: Problem Definition 12

Figure 9: Solution Graph showing removal of two hazards 14

Figure 10: Solution Graph showing the use of a strategy node 16

2

1. INTRODUCTION

This paper presents a framework for representing first aid problem solving knowledge. Section 2 presents the motivation for this work, describing the current methods used to teach first aid problem solving skills, and how an intelligent tutoring system could complement and enhance them. Section 3 goes into further detail on the domain describing it in terms of how it is applied in real situations. ANDES is described in section 4. ANDES is an intelligent tutoring system for teaching physics which uses rule based problem solving to generate solution graphs of the problem and Bayesian Networks to model the student’s reasoning. It serves as the basis for much of what has been done here. In order to justify the design of the problem solver, it was deemed necessary to set it in the context of a hypothetical intelligent tutoring system. This is presented in section 5. Section 6 describes the system implementation, and sections 6 and 7 examine the results and explore future directions for the project.

2. MOTIVATION

First Aid problem solving skills are predominately taught via two methods:

1. Study of the conditions, their signs and symptoms, and their treatment

2. Role playing with other trainees pretending to have various conditions in a multitude of situations

Although both of these methods provide rich educational opportunities for students to learn the domain, both suffer from some inherent drawbacks. In the first approach students learn a categorization of the knowledge as shown in Figure 1. This is an important formulation of the information for students to have, as it helps them to understand the rationale behind the procedures. As a result, they act more conscientiously when handling a situation, adapting to new, more complex situations rather then blinding applying the procedures. Regardless of how valuable this information is, however, it is not at all how the students will use the information in real situations; in an emergency it is important to start treatment based on partial information before a complete diagnosis can be made. If a rescuer were to wait until sufficient information had been gathered and then perform a search in memory for the appropriate diagnosis before commencing treatment, too much time would elapse substantially hampering the patient’s potential for recovery. Therefore, students need to not only be capable of categorizing the information based on specific conditions, but also be able to categorize on the appropriate response or action to a given event or piece of evidence.

3

Figure 1: Example of categorized instruction of domain

While the mock setups used in the second approach, do encourage students to apply knowledge in a procedural manner, they are limited in their ability to adequately present the evidence. Often the “patients” lack the ability to perform at a sufficient level to present the required level of realism. Furthermore, much of the most significant evidence - the presence of blood, the condition of the skin, the patients heart and breathing rate, the age/gender/general health, and so on – are impracticable or impossible to control in a mock situation. Nonetheless, the mock setups are an important and essential part of the training as they provide the students with an invaluable opportunity to practice the actual physical skills.

Given the problems inherent in the methods presented above it is evident that although these methods are invaluable, they could be complemented by another method of exercising the student’s knowledge. In the following section, an intelligent tutoring system is proposed to provide students with a medium of practicing first aid problem

4

solving skills. This system is not intended as a replacement to the existing methods but rather as a complement meant to enhance the educational experience.

3. THE DOMAIN

The problem solving strategies used in this system are based on the Canadian standards adopted by the Life Saving Society for the National Lifeguard Service [9]. These are the standards used by Canadian lifeguards for emergency response to non-drowning situations. “The Lifesaving Society is a national volunteer organization …[that] … works to prevent drownings and water-related injuries through its training programs, drowning research, Water Smart® public education and aquatic safety management services” [10]. Realistic situations where lifeguards may use these skills include emergencies occurring in change rooms, lobbies or on the pool deck resulting from medical emergencies (such as heat related injuries, heart attacks, and diabetes complications) or from physical traumas (such as falls, blows or cuts).

The standards mentioned above are commonly proceduralized by what is commonly referred to as the Priority Action Approach [11]. The Priority Action Approach provides a script lifeguards can follow while attending to a scene. It is used because it faster and more reliable to follow a script defining what actions to take rather than to evaluate what should be done based on a large number of competing goals and standards of care1. Figure 2 outlines the Priority Action Approach.

1 The Priority Action Approach should not be confused with the Priority Action Assessment, which is another tool used by lifeguards, but for a different purpose. The Priority Action Approach defines what should be done to care for an individual patient; Priority Action Assessment is similar in function to triage, which is used in nursing, and is used to determine how multiple patients should be cared for and prioritized in a catastrophe situation.

5

Priority Action Approach

Primary Survey • Scene Assessment

o Hazards: Eliminate hazards: blood, broken glass, electricity, gas, fire…

o Environment: Extreme heat/cold, storm… o Mechanism of Injury: What happened? o People: Patients/Bystanders

• Level of Consciousness o Conscious: Alert / Confused o Unconscious: Reacts to voice / pain / nothing

• EMS o Unconscious? Call 911 drainage pos’n, protecting delicate spine

• d – Delicate Spine Suspect spinal injury? Immobilize

• A – Airway o d? Jaw Thrust w/o moving neck o Head Tilt, Jaw Lift

• B – Breathing o Look/Listen/Feel - 10sec o B? Deep/shallow, rapid/slow? o No: 1 full breath A? Another full breath No: Readjust airway, try again

o A? Another full breath o No: choking procedure

• C – Circulation o Check carotid pulse - 10 sec o C? weak/strong, rapid/slow? Yes: B? No: rescue breathing No: CPR

• D/E – Deadly Bleeding/Escaping air o Rapid Body Survey DB? Yes: Rest/Elevate/Direct Pressure EA? Yes: 3 sided seal

• Treat for Shock o Warmth – ensure patient is warm o ABC’s – continue to monitor ABC’s o Rest/Reassurance – provide o Treatment – treat the cause of the shock o Semi – prone/sit – position of comfort o Oxygen: Breathing?

• Yes: 10 liters/min • No: 15 liters/min

• EMS o Call EMS if their assistance is needed

Secondary Survey • Reassess ABC’s after each section: • History – ask the patient/bystander

o Chief Complaint o History of Chief Complaint– Pain Quality Radiate Severity Time

o Allergies – Do you have any allergies? o Medications – Do you take any medications? o Past Medical History –happened before?

• Vitals – assess and record every five minutes o Time o Level of Consciousness o Pulse/Heart Rate o Respiratory Rate o Eyes (equal and reactive) o Skin condition – temp, color, condition

• Head to Toe – careful examination of the body o Conscious? Yes:

• Ask instead when appropriate • Keep patient informed No: Watch face for signs of pain

o Look for medic alert bracelets o Reassess ABC’s after each section o Palpitate scalp o Check Ears for fluid o Press Along cheek bones, sinuses, jaw Along collar bone Down Sternum Along ribs, under back Down on each of the 4 abdominal sections Down on hips

o Squeeze along each arm o Check finger nail beds for circulation o Visually examine between finger joints and at veins for signs of injection

o Squeeze along each leg, knee, and foot o Check toe nail beds for circulation o Visually examine between toes for signs of injection

Treatment • Treat other injuries

o Treat only life-threatening injuries until secondary survey is complete, then treat other injuries

Figure 2: The Priority Action Approach - The knowledge to be represented

6

4. RELATED WORK

Several pieces of existing work served as the basis for designing this system. The most predominate piece is the ANDES system. ANDES is an intelligent tutoring system for college level Newtonian Physics. ANDES uses a Bayesian Network to maintain a student model capable of assessing the student’s long term knowledge, recognizing his or her plan or strategy for solving the current problem and predicting the student’s most likely next action.

The Andes Bayesian Net consists of nodes representing the following [4]:

• Context Rules: which model the probability that the student can apply a particular general physics rule to a specific problem context

• Facts: represent the likelihood the student knows a particular piece of information

• Goals: represent the probability the student is performing actions relevant to a particular goal because he is pursuing that goal

• Rule-Applications: represent the likelihood that a student has applied a particular rule

• Strategies: model points in the solution where the student can choose between different strategies, and specifies the probability for each of the strategy choices that it is the strategy the student is pursuing

Figure 3 shows the relationship between nodes and their parents in the ANDES system [2]. The node type determines how many parents a node can have and the relationship between the node and its parents. Fact and Goal nodes have as many parents as there are ways to derive them, and are related to their parents by a Noisy OR. The Noisy OR models that a fact or goal will be most likely true if any of its parents are true with the noise representing the possibility that it might be true even if none of its parents are true. This might happen for example if the student guesses a fact [4]. Contrastingly, a rule application has exactly one context rule parent and multiple goal and fact nodes. If the rule application represents a choice among different strategies it will also have a strategy node parent. The rule application node relates to its parents with a Noisy AND, which means the node will be most likely true if all its parents are true, and most likely false if any of its parents are false [2]. Figure 4 and Figure 5 show the Noisy OR and the Noisy AND relationships. Epsilon represents the amount of noise in the relationship and is set to 0.05 in the figures below [13].

7

Node Type Parents Relationship Context Rule No parents None Fact 1+ Rule Nodes Noisy OR Goal 1+ Rule Nodes Noisy OR

Rule Application

1 Context Rule Node 1+ Fact/Goal Nodes 0 or 1 Strategy Nodes

Noisy AND

Strategy Node No parents None Figure 3: Relationships between nodes and their parents in the ANDES system

A B C=0 C=1

0 0 1- ε 2 0.9975 ε2 0.0025

0 1 2ε-ε2 0.0975 (1-ε)2 0.9025

1 0 2ε-ε2 0.0975 (1-ε)2 0.9025

1 1 2ε-ε2 0.0975 (1-ε)2 0.9025

Figure 4: The Noisy OR relationship. ε = 0.05

A B C=0 C=1

0 0 1- ε 2 0.9975 ε2 0.0025

0 1 1 - (1-ε)ε 0.9525 (1-ε)ε 0.0475

1 0 1 - (1-ε)ε 0.9525 (1-ε)ε 0.0475

1 1 2ε-ε2 0.0975 (1-ε)2 0.9025

Figure 5: The Noisy AND relationship. ε = 0.05

8

5. CONTEXT

An intelligent tutoring system is often described as being comprised of three main components: “(a) knowledge of the domain (expert model), (b) knowledge of the learner (student model), and (c) knowledge of teaching strategies (tutor)” [14]. In this particular situation, the user interface is also noteworthy given the importance of presenting facts, in as realistic as feasible manner.

Although this stage only implements the knowledge representation, it is imperative that to consider the system as a whole to ensure that adequate provisions be made, to prevent barriers from occurring in the future. Therefore a brief sketch of a viable complete system is provided to a set a context for the design of the knowledge representation.

Expert System

Given the vastness of this domain, and the scope of the information students must learn, it is not feasible for the solution of each problem to be uniquely crafted. Furthermore, by creating a system capable of producing solutions from a problem description, seemingly infinite combinations of conditions can be asserted providing students with a wealth of questions with which to practice.

In order to produce a solution representative of how a student would solve the problem, the expert system must be able to represent the knowledge procedurally, rather than categorically as is commonly done in medical diagnosis systems. Figure 1 contrasts the two representations. Furthermore, in order for the student model to accurately assess the student’s ability to solve the problems, the system must be capable of deriving not just one but all possible solutions to a given problem.

Condition Signs

~~~~~~~~~~~~ Symptoms

~~~~~~~~~~~~ Treatment

~~~~~~~~~~~~

Symptom/Sign/Evidence

Treatment/Next Action

Categorical Representation Procedural Representation Figure 6: Contrasting the procedural and categorical representations

At any given step the problem can be interpreted as a mini problem where the student is presented with the current evidence and is expected to act to either educe new evidence or change the state of the world. However, the situations cannot be random (that is the evidence presented must be related and progress logically), therefore the problems must be formed from conditions to create an appropriate series of symptoms. Heuristic rules can then be used to derive developments in the situation.

It is proposed that a rule-based problem solver be used to dynamically generate a solution graph to each problem. From a solution graph, a Bayesian network representing the

9

solution can be generated. This is the approach used in the ANDES’ [2] and introduced by [5] and [13]. These Bayesian networks allow the system to infer students’ plans and goals while they are solving a problem and can be used to generate appropriate developments in the problem, based on the student’s actions and/or current knowledge state. That is to say, problems could develop into more difficult situations if the system infers that the current problem is too easy for the student.

As the knowledge representation of this domain is the focus of this work, a detailed description of its design and implementation is deferred until the later sections specifically dedicated to these topics.

Student Model

Student modeling can be achieved using the Bayesian network constructed from the Solution Graph. Once a Bayesian network has been constructed that models the goals and knowledge of the domain in addition to the facts and actions required to solve the problem, the system can make inferences regarding the student’s knowledge, based on the actions observe. Additionally, the student model can attempt to predict the student’s next action. This is particularly useful for helping the student overcome an impasse situation. Generally, the student’s next action can be predicted directly from the solution graph, however, when a goal breaks into multiple sub-goals, an appropriate heuristic would be to assume that student tackles goals sequentially, completing one goal before moving to the next.

Tutor System

Before an appropriate tutoring component can be developed a few general issues need to be addressed:

• Should the student be corrected during a scenario or should feedback be reserved until the end?

• How should the scenarios be designed in order to maximize their effectiveness?

One possible solution to question 1 is presented in TRIO [15]. In TRIO daemons are used to provide short succinct immediate feedback designed to keep students from falling too far from an appropriate course of action. Then an in depth analysis of the student’s performance is presented after the simulation has been completed.

For question 2, two obvious possibilities exist: one is to develop the scenario as realistically as possible. Thus, as proper care is given the patient’s condition improves and when conditions are not properly dealt with complications arise worsening the patient’s condition. The second is to use heuristics that define how different developments affect the difficulty of the situation and then use these heuristics to match the problem to the student. This approach has the benefit of presenting situations that are appropriate to the student’s level of expertise.

10

The first possibility has the advantage of presenting the material in a manner, which makes the significance of each action and response visible to the student. However, it has the disadvantage that weaker students are more likely to receive more difficult questions and stronger students may never be exposed to these complicated situations.

The second possibility addresses the weakness of the first by ensuring that students fully explore all possible situations however it lacks the realism presented by the first and does not allow students to form as strong of a connection between their actions and the status of the patient.

User Interface

In order for the system to have any real value, the user interface would need to be at least enhanced with substantial graphics; preferably the interface would be animated in order to present the student with a transferable experience. The interface should provide the following:

• The ability to present information progressively to the student, based on the student’s previous actions and changes in the scenario.

• Input from the user, that represents an action that should be done in the situation. This input may represent an action equivalent to a query that allows the student to gain new information about the scenario.

This system will need an interface that can provide a rich environment of visual cues regarding the environment of the scenario and the features of the patient. It will also need a method for allowing users to elicit information from the problem (such as taking the victims pulse), and for inputting information into system (providing treatment, documenting the incident)

6. IMPLEMENTATION

In order to provide the flexibility required to ensure a wide variety of problems be specifiable, hard coded Bayesian Networks were unsuitable. Therefore, a knowledge solver was used to generate solution graphs representing all the ways of generating the solution.

The problem solver was written in JESS (Java Expert System Shell). JESS was developed at Sandia National Laboratories and is “an expert system shell and scripting language written entirely in Sun Microsystem's Java language” [6]. JESS is based on the CLIPS (C Language Integrated Production System) language [3]; it allows you to develop java applications with the ability to reason. JESS uses declarative rules as the basis for producing new knowledge.

Figure 7 shows the system architecture. The problem solver consists of the solution generator module, which uses the collection of available rules and the problem definition to determine the solution graph of the problem. The solution generator takes the

11

information given in the problem definition about what is initially known and true in the environment and applies the available (known) rules to the current situation to elicit further information about the world and perform actions to solve the problem. The problem definition defines the problem by asserting relevant facts.

Figure 7: The Architecture of the First Aid Problem Solver - ellipses represent data structures and rectangles represent system modules

Problems are defined in terms of the scene, the patient, and bystanders. Figure 8 gives a sample problem – characteristics of each of the objects are asserted to define the problem, which doesn’t mean that they are known or given, only that they are true and can be determined by with the correct set of actions. For example, the problem given in Figure 8 asserts that the patient’s circulation is weak and rapid. Although this is true from the start of the problem, it will not be known until the student checks the patient’s pulse. One final note is that at no point in the example given, is the actual cause of injury defined. That is, although it might be apparent from reading the problem definition, that the patient suffered from an electrical shock injury, it is not explicitly stated anywhere in the problem, and thus the problem solver cannot reason on that information when determining a solution. This is desirable, since we want the problem solver to work out the problem using the same rules as the student [13].

(defrule problem-definition "" => (assert (scene (hazards electrical blood) (environment hot) )) (assert (patient (loc unconscious) (circulation weak rapid))) (assert (bystander (knowledge "He grabbed the electrical wire") (facts electrical-hazard))))

Figure 8: Problem Definition

To ease debugging of the problem solver, a module was developed to produce an actual graphical rendering of the solution graph. This was accomplished using Dot, a program for generating directed graphs as hierarchies, developed at AT&T Bell Laboratories [8]. For each node in the solution graph the appropriate text is written to a file to represent that node in the graph. An example of this output is provided in the next section.

12

Finally, the Bayesian network is constructed from the solution graph. Priors are attached to the nodes and the file is reformatted to fit the BIF file format, which is used in JavaBayes [6]. JavaBayes is a program written in Java by Fabio Gagliardi Cozman that provides a full implementation of Bayesian Networks. With the Bayesian Network, actions can be observed and their consequences on the probabilities of goals and facts being known inferred.

7. RESULTS

The system can currently determine correctly the first few steps of the solution. As it is essential that the structure of the system be correct - to ensure that the system is robust enough to handle to different problem definitions – the bulk of the effort was placed on implementing a small subset of the entire knowledge space, ensuring that it can handle complex situations. Figure 9 shows a portion of a generated solution graph. Similar to as was done in [2] and [1] the graph consists of the following types of nodes:

• Goal Nodes: These are intended to represent the student’s goals and subgoals.

• Rule Nodes: These represent the rules that the student has available to use while solving the problem (i.e. they represent the likelihood the student knows the rule

• Action Nodes: These represent the application of a rule to the problem

• Fact Nodes: These represent the facts that are true in the world. The probabilities associated with them represent the likelihoods that the student knows the fact

• Strategy Nodes: These represent points in the solution where multiple paths are possible towards a solution

In this portion of the problem the problem solver is pursuing the subgoal: check-hazards. While checking for hazards two hazards are located in the scene: electrical hazard and blood hazard. Each is dealt with appropriately as a precondition to the next action2. Thus, as was done in ANDES, the parents of an action have a Noisy AND relationship with the action itself.

2 For simplicity a temporary check-hazard complete node is used as the next action. As the further steps are added this node will probably be replaced by the next real action)

13

Figure 9: Portion of the solution graph showing removal of two hazards as part of a scene analysis

You will notice that the graph presented in Figure 9 does not contain any strategy nodes. A more complex example is presented in Figure 10. In this portion of the problem the problem solver is pursuing the subgoals: check-hazards and check-environment. The check-hazards portion of the problem is the same as in Figure 9 above. The check-environment segment demonstrates how a strategy node is added to the solution. Two environment problems are present: hot-environment and stormy-environment3. The hot-environment problem has two possible strategies. From the graph, you can see how the strategy node breaks the solution graph into two paths. The stormy-environment problem joins up with both of the solution paths to complete the preconditions of the next action. The solution graph breaks into multiple paths to keep the paths independent (we don’t want the probabilities associated with one path influencing the other path). However,

3 These two environment problems make a very unrealistic are combination. They are not intended as a realistic example but rather merely as way of demonstrating the effect of having multiple subgoals with one of the subgoals having multiple strategies possible.

14

strategies denote multiple approaches to attaining a particular goal. This goal should be modeled in the strategy and used to bring both actions together when the goal is complete. In the example of Figure 9, this would mean that there should only be one node for the fact hot-env-problem-solved and both actions should point to it. This is what is done in ANDES [2] and is where the Noisy OR relationship between facts and their parents arises. Currently, the system provides a one to one correspondence between facts and how they are derived – thus a fact only ever has one parent.

8. FUTURE WORK

There are still many areas that could benefit from additional work.

The Solution Generator currently only solves problems up through the scene assessment, some work has been done on adding rules to assess the level of consciousness, call EMS, and perform dABCDE (delicate spine, airway, circulation, deadly bleeding, and escaping air) management. These rules are still very rough and need a lot of work, however, now that the framework has been defined they should be simpler to implement that the existing rules were.

When the problem solver is focused on a set of subgoals it currently addresses each of the subgoals independently without considering how acting on one subgoal might affect the choices available for another. This is most prevalent when multiple subgoals can be achieved with the same rule – the figurative “killing two birds with one stone”. The solution should represent this, however, the system is currently unable to recognize multiple occurrences of the same action and amalgamate them into one. This is a pressing concern as it means that if the problem solver were used as it stands to evaluate a student’s solution it would expect the student to repeat steps each time they are needed, regardless if they have already been done. Fortunately it is not a difficult problem, and should be fairly straightforward to add.

The Priority Action Approach generally predicts an appropriate action, however there are exceptions. Furthermore, although it guides the user to apply appropriate care, it is not always sufficient for optimal care. Particularly as students become more experienced, they are bound to start making some of their decisions based on the higher-level goals or standards of care, and not using the Priority Action Approach. The Solution Generator should be capable of handling this; it currently models some higher-level goals but only coarsely.

On a similar note, solutions are currently only evaluated on the basis of correctness. However, as we saw in the preceding paragraph, some correct solutions are better than others, and this should be represented in the domain model. This would require modeling high level goals. For example, consider this high level goal: start life preserving procedures as soon as possible. It is inherently ambiguous, but if it could be modeled and if scores could be attached to different values of fulfilling the goal, actions could be evaluated based on how well they achieve the goal.

15

Figure 10: Solution Graph showing the use of a strategy node

16

9. CONCLUSION

This paper presented a framework for a first aid problem solver. The problem solver was defined within the context of a complete intelligent tutoring system in order to justify the design choices made. Currently the system defines a structure for crafting the rules, and can produce the first few steps of the solution graph. The focus has not concentrated on knowledge coverage, but rather on producing a representation with the flexibility required for adapting to the various conditions possible in the domain. While there are still a few issues that have arisen while experimenting with the solver, it demonstrates a fair capability of dealing with the possible variations and combinations required.

10. ACKNOWLEDGEMENTS

This work would not have been possible without the help of numerous people. Most specifically, thanks to Kasia Muldner for her help with the JESS language, the example code she provided, and most importantly for the times she patiently sat with me and helped figure things out. Also, thanks to Andrea Bunt for her help with Bayesian Networks and JavaBayes and to many others who listened to me hash through problems, helped me figure things out, and provided infinite amounts of support.

11. REFERENCES

1. Conati, C., A. Gertner and K. VanLehn (2002). “Using Bayesian Networks to Manage Uncertainty in Student Modeling”. To appear in: Journal of User Modeling and User-Adaptive Interaction.

2. Conati, C., A. Gertner, K VanLehn, and M. Druzdzel (1997). On-Line Student Modeling for Coached Problem Solving Using Bayesian Networks” In Jameson A., Paris C., Tasso C., (eds.) User Modeling; Proceedings of the sixth International Conference UM97. SpringerWienNewYork.

3. CLIPS, A tool for building Expert Systems Web page. Available on line at http://www.ghg.net/clips/CLIPS.html.

4. Gertner, A., C. Conati, and K. VanLehn (1998). “Procedural help in Andes: Generating hints using a Bayesian network student model” In Proceedings of the 15th national Conference on Artificial Intelligence, Cambridge, MA: The MIT Press, (pp. 106-111).

5. Huber, M. J., E. H. Durfee, and M.P. Wellman (1994). “The Automated Mapping of Plans for Plan Recognition” Tenth Conference on Uncertainty in Artificial Intelligence.

6. JavaBayes - version 0.346 Website. Available on line at http://www-2.cs.cmu.edu/~javabayes/Home/

17

7. Jesss, the Expert System Shell for the Java Platform Website. Available on line at http://herzberg.ca.sandia.gov/jess/.

8. Koutsofios, E., and S. North (1999). “Drawing graphs with Dot” AT&T Bell Laboratories, Murray Hill, NJ

9. Lifesaving Society, “Alert: Lifeguarding in Action.” Published by the Lifesaving Society, 2nd Edition, 1999.

10. Lifesaving Society Web Page. Available on line at http://www.lifesaving.ca.

11. LIT Aquatics Website. Available on line at http://www.litaquatics.com

12. Mahoney, S.M., and K.B. Laskey (1998). “Constructing Situation-Specific Belief Networks”. 14th Conference on Uncertainty in AI, Morgan Kaufmann.

13. Martin, J., and K. Vanlehn (1995). “Student Assessment using Bayesian Nets.” International Journal of Human-Computer Studies 42: 575-591.

14. Shute, V.J. and J. Psotka (1996). “Intelligent tutoring systems: Past, Present and Future”. In D. Jonassen (Ed.), Handbook of Research on Educational Communications and Technology: Scholastic Publications, p. 1 – 99.

15. Ritter, F. and W. Feurzeig (1988). “Teaching real-time tactical thinking (pp. 285 –301). In J. Psotka, L.D. Massey & S. A. Mutter (Eds.) Intelligent Tutoring Systems: Lessons Learned. Hillsdale, NJ: Erlbaum.

18