1. Using GIPO to support learning in knowledge acquisition and automated planning Lee McCluskey and Ron Simpson

2. Contents >Part A: Some Problems with Teaching AI >Part B: GIPO >Part C: Student Learning Experience with GIPO >Part D: Comparison to other ‘similar’ tools used in UG computing teaching >Part E: Conclusions

3. PART A: Some Problems with Teaching AI

4. Problems with AI Teaching in practical work We all know that areas such as.. knowledge representation automated reasoning are difficult for students to grasp.. to make it easier practical examples in symbolic AI often start with cleaned, crafted knowledge structures [abstracting out the knowledge acquisition and formulation process] >Eg in ATP we start with exactly the axioms we need to do a proof. >Eg in AI planning we start with exactly the right action structures we need to form a plan.

5. Problems with AI Teaching – in practical work (define (domain rocket-domain) (:requirements :typing :equality) (:types rocket place cargo) (:predicates (at ?x - (either rocket cargo) ?p - place) (has-fuel ?r - rocket) (in ?c - cargo ?r - rocket)) (:action move :parameters (?r - rocket ?from ?to - place) :precondition (and (at ?r ?from) (has-fuel ?r) (not (= ?from ?to))) :effect (and (not (at ?r ?from)) (at ?r ?to) (not (has- fuel ?r)))) ETC ….

6. Problems with AI Teaching - use of declarative programming languages in AI practicals Declarative PLs have their role in teaching AI practicals – we can use them to rapidly implement AI search methods and algorithms But.. they are still ‘low level’ in the context of the range of AI topics – its not easy to lead students to build or integrate advanced AI functions from the basis of a programming language. The tutor would implement AI algorithms to expose their workings, but knowledge intensive issues such as domain modelling are be harder to illustrate using a declarative language on its own.

7. Summary >Acquiring, debugging and crafting knowledge bases is another factor as to why the teaching of AI is difficult >The process of how knowledge is acquired is not easy for a student to grasp without practical experience of the process [just explaining the theory can be boring for the student]. This is difficult to explain using a declarative PL

8. PART B: using GIPO the 'Graphical Interface for Planning with Objects’

9. One possible solution.. Use of an integrated tools environment Such a tool should: >Have a simple, familiar look and feel - make it easier to learn >connect together a range of theory taught during lectures with the application of the theory during practical classes - students haven’t time to learn many tools >relate AI to other subject areas taught at undergraduate level computing - students need the curriculum to fit together

10. GIPO 'Graphical Interface for Planning with Objects‘ http://scom.hud.ac.uk/planform/gipo is the name of a family of experimental tools environment for building planning domain models, and doing automated planning GIPO won the first knowledge engineering for planning competition (ICKEPS’05) in the general tools class at ICAPS 2005, Monterey, California

11. /

12. Knowledge Representation The object metaphor guides the domain designer in structuring the domain definition - plan execution involves changing the state of a subset of objects within the sphere of interest from an initial state to a desired goal state Potential student learning is the use of logic/object representations, in the area of dynamic systems - representing time and change, representing actions, events, processes…

13. Knowledge Acquisition / Formulation >Multiple methods >Follow “manual” Object Centric Method. >Define: Object Types - Predicates - Object State Invariants– Operators - Methods >Operator Induction (GIPO II) – “OpMaker” >Define: Object Types - Predicates - Object States >Input: plan examples >Output: operator schema >Draw “Object Life Histories” (GIPO III) >Draw stylised state transition diagrams defining the possible state transitions for each type of object and define the connections between the transition diagrams. >Use re-usable fragments of domains stored in library

14. Domain Analysis >Static Analysis >Syntax / structural consistencies checked >Only legal domain specification will be produced when checks passed. The formulation of state invariants exclude potential errors. >Semantics >Eg State usage analysis reveals states that form dead-ends and states that cannot be generated. >Eg Transparency analysis in hierarchical models guarantees that methods do achieve their post-conditions when their pre-conditions are met. >Dynamic Testing >Animators to help inspect generated plans produced by integrated planning engines. >Manual steppers to allow developer to check that domain definition does support known plans.

15. Example: The Lazy Hiking World Imagine Sue and Fred want to have a hiking holiday in the Lake District in North West England. They walk in one direction, and do one ``leg'' each day. But not being very fit, they use two cars to carry them / the tent / their luggage to the start/end of a leg. They must have their tent up already so they can sleep the night, before they set off again to do the next leg in the morning. Actions include walking, driving, moving and erecting tents, and sleeping. The requirement for the planner is to work out the logistics and generate plans for each day of the holiday. Helvelyn Fairfield Coniston

16. Object Centric View >Plans are strategies to bring about changes in the states of objects within the domain problem. >Objects have state and properties. >Actions bring changes of state and/or property values. >Properties are present in all states Tent State Descriptors Transition Descriptors

17. Hiking Domain – Example Tent Property : Location Value present in all identified states. Transition of Tent: Property Value Changing Location to Location Transition State Changing Transition Property Value Changing Satisfies next(x,y) nextStage(w,v) Constraint – Number Satisfies couple(x,y) Person Car Tent Person Properties: Location Stage

18. Transition Co-ordination Transitions Requires Object at State Transition Dependent on Source Both satisfy next(x,y) Transitions mutually dependent Both satisfy next(x,y) Add Association Record car Break Association Forget Car

19. Libraries of Generic Types >Object Life Histories share common structure that are re-usable. >Define Public interface i.e states and transitions that support merges. >Complexity of structures such as block stacks can be hidden in packages. >Users can save fragments of their own domains to the library

20. Richer Representations >Durative Actions >PDDL Level 5 equivalent >Processes. >Events. >Numeric Properties. >Supports >Domain Design using Life Histories. >Manual Plan stepping >No integrated planner at present time.

21. Dynamic Testing >Static Analysis may Indicate problems otherwise Manual Stepping may reveal source of problem.

22. PART C: Student Learning Experience with GIPO

23. Student Learning - Caveat GIPO >was not designed for teaching, but as an experimental platform for KE for planning >assumes that the user has to “shoe horn” the planning problem into its own object centric world view

24. Student Learning GIPO >provides learning support for >knowledge acquisition and formulation, validation and maintenance of (planning) domain models, >inductive learning >automated plan generation and plan execution. >has online documentation >tutorial introductions, >a user manual, >a more in-depth language manual which defines the underlying knowledge representation language. >has been used with intermediate and final year undergraduates (typically 15-20). Anecdotal evidence indicates that GIPO helps students integrate AI knowledge learned in lectures, and to reach a deeper level of understanding of 'dry' subject matter on say the acquisition of knowledge.

25. Student Learning - method We have found it useful to present the student with two paths through the material: >an online tutorial on how to construct domains: the student is led through a staged method of domain development >analysis and execution of a 'ready-cooked' domain model: this way the student can at an early stage see the result of domain building - being able to bind the model with a planner of choice and being able to solve planning problems.

26. Student Learning – some examples >Using the online tutorial the students learns the difficulty in formulating knowledge about actions >Using ‘OpMaker’ the student learns the potential/problems of machine learning techniques >- one can avoid the process of hand crafting action knowledge >- the problems and limitations of learning from examples to do with convergence of generalisations, the need for knowledge refinement and the importance of 'good' examples in learning. >Using GIPO’s DYNAMIC and STATIC testing tools the student learns about validation – how to uncover and fix two main types of errors >Type 1. checking the model for inconsistencies between component parts >Type 2. checking the model's accuracy with respect to what is being modelled.

27. Student Learning – connections to other computing areas >Object metaphor and staged acquisition process akin to the use of UML/OOAD >Pre- and post-condition, deterministic, instantaneous actions in terms of predicate descriptions version of a GIPO operator similar to formal specifications of actions eg in B. >Verification and validation in general software design

28. PART D: Comparison to other ‘similar’ tools used in UG computing teaching

29. Comparison: The B-Tool >The B-toolkit has been successfully used in teaching formal methods in our own curriculum for several years to MSc, BSc and HND students. >Supporting the method are tools that alleviate some of the problems in the onerous task of constructing and discharging proof obligations. >The student can understand the need for rigor and view the effects of proof tools, without the need for them to produce hand proofs themselves.

30. Comparison: The B-Tool Similarities with GIPO/AI Planning >the concept of a 'state' >the need to construct operators in terms of pre- and post-conditions and state transitions >the underlying assumptions of default persistence and the 'closed world' >the use of invariants to help in validation and model documentation.

31. Comparison: The B-Tool Differences with AI Planning >the objectives of both tools are different - one to rigorously develop software, the other to develop an application that solves planning problems. >In general the B-tool allows the user to input more precise details of a domain, and is more meticulous at uncovering errors. >On the other hand, GIPO's range of dynamic tools (the stepper and the use of plan generators) give it an extra dimension that both stimulates students and allows more scrutiny of the domain model components. >One can simulate operator execution using the B-tool (and hence this gives a primitive plan stepper), but not plan generation as with GIPO.

32. Comparison: Protégé >is a well established knowledge acquisition tool which aids the user in building up domain models in description logic. As with the B- tool/GIPO, it was not designed originally for use in teaching and learning >Our final year undergraduate students are exposed to Protégé-OWL in a module entitled "The Semantic Web". >Protégé’s interface is similar in some ways to GIPO - the usual array of GUI features can be used to build up object hierarchies and input propositions and class constraints.

33. Comparison: Protégé >Has very good online tutorials that slowly build up a student's knowledge of relevant features >A DL theorem prover such as RACER can be hooked up to check classes for consistency >Class hierarchies can be re-assembled as more properties of the classes are input. This relies on the use of subsumption to check whether one class subsumes another. >the OWLViz plugin can be used to visualise the class hierarchy of the developing DL theory.

34. Comparison: Protégé >While there are similarities with GIPO in the initial stages of domain (ontology) acquisition, Protégé-OWL lacked the facilities to 'execute' the model in any way. >Students seemed to find GIPO more satisfying as they could build, view, validate and then execute the model. >The ability to involve the model in some kind of constructive operation (ie plan generation) helped the student to see what the point of the knowledge acquisition process was.

35. Conclusions

36. Concluding Remarks >Teaching KA/DM etc in AI is sometimes overlooked as it is hard enough teaching reasoning/representation >Teaching KA/DM etc needs a tool!! But one which can be used to teach a ‘wide’ area of the subject.. And one which allows the student to perform synthetic tasks >Teaching KA/DM (with a tool such as GIPO) can help integrate parts of the computing curriculum

37. Some advertising…