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

Slides:



Advertisements
Similar presentations
Knowledge Engineering for Planning Domain Design Ron Simpson University of Huddersfield.
Advertisements

ARCHITECTURES FOR ARTIFICIAL INTELLIGENCE SYSTEMS
Verification and Validation
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
So What Does it All Mean? Geospatial Semantics and Ontologies Dr Kristin Stock.
Opmaker2: Efficient Action Schema Acquisition T.L.McCluskey, S.N.Cresswell, N. E. Richardson and M.M.West The University of Huddersfield,UK
Of 27 lecture 7: owl - introduction. of 27 ece 627, winter ‘132 OWL a glimpse OWL – Web Ontology Language describes classes, properties and relations.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
ISBN Chapter 3 Describing Syntax and Semantics.
CS 355 – Programming Languages
1 Introduction to Computability Theory Lecture12: Reductions Prof. Amos Israeli.
Towards An Algebraic Formulation of Domain Definitions using Parameterised Machines T. L. McCluskey and R. M.Simpson School of Computing and Engineering.
GIPO II: HTN Planning in a Tool- supported Knowledge Engineering Environment Lee McCluskey Donghong Liu Ron Simpson Department of Computing and Mathematical.
Knowledge and Systems Research Group, University of Huddersfield B vs OCL: Comparing Specification Languages for Planning Domains Diane Kitchin, Lee McCluskey,
The Semantic Web Week 13 Module Website: Lecture: Knowledge Acquisition / Engineering Practical: Getting to know.
Knowledge Acquisitioning. Definition The transfer and transformation of potential problem solving expertise from some knowledge source to a program.
Lee McCluskey, University of Huddersfield - EKAW'04 Knowledge Formulation for AI Planning Lee McCluskey Ron Simpson Artform research group Department of.
School of Computing and Mathematics, University of Huddersfield An Interactive Method for Inducing Operator Descriptions Lee McCluskey Beth Richardson.
GIPO [Graphical Interface for Planning with Objects] Demonstration case-tool for Knowledge Engineering to support Domain Independent Planning Ron Simpson.
PDDL: A Language with a Purpose? Lee McCluskey Department of Computing and Mathematical Sciences, The University of Huddersfield.
School of Computing and Mathematics, University of Huddersfield Knowledge Engineering: Issues for the Planning Community Lee McCluskey Department of Computing.
Software Requirements
Knowledge Acquisition. Knowledge Aquisition Definition – The process of acquiring, organising, & studying knowledge. Identified by many researchers and.
School of Computing and Mathematics, University of Huddersfield PDDL and other languages.. Lee McCluskey Department of Computing and Mathematical Sciences,
Informatics Research Group University of Huddersfield Tool Support for Planning and Plan Analysis within Domains embodying Continuous Change Lee McCluskey.
School of Computing and Mathematics, University of Huddersfield Week 21: Knowledge Acquisition / GIPO Lee McCluskey, room 2/09
Describing Syntax and Semantics
MCA –Software Engineering Kantipur City College. Topics include  Formal Methods Concept  Formal Specification Language Test plan creation Test-case.
Data Structures and Programming.  John Edgar2.
Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.
Verification and Validation Yonsei University 2 nd Semester, 2014 Sanghyun Park.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
CHA2555 Week2: Knowledge Representation, Logic and Planning Lee McCluskey First term:
Requirements Engineering Requirements Elicitation Process Lecture-8.
Building Tools by Model Transformations in Eclipse Oskars Vilitis, Audris Kalnins, Edgars Celms, Elina Kalnina, Agris Sostaks, Janis Barzdins Institute.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
Conceptual Modelling – Behaviour
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Major objective of this course is: Design and analysis of modern algorithms Different variants Accuracy Efficiency Comparing efficiencies Motivation thinking.
Problem Solving Techniques. Compiler n Is a computer program whose purpose is to take a description of a desired program coded in a programming language.
1 Introduction to Software Engineering Lecture 1.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
VDM++ Tutorial Model Quality. Overview Introduction Assessing internal consistency Assessing external consistency.
Requirements Engineering Methods for Requirements Engineering Lecture-30.
Chapter 3 Part II Describing Syntax and Semantics.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
OilEd An Introduction to OilEd Sean Bechhofer. Topics we will discuss Basic OilEd use –Defining Classes, Properties and Individuals in an Ontology –This.
Scientific Debugging. Errors in Software Errors are unexpected behaviors or outputs in programs As long as software is developed by humans, it will contain.
Chapter 4 Automated Tools for Systems Development Modern Systems Analysis and Design Third Edition 4.1.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Using Symbolic PathFinder at NASA Corina Pãsãreanu Carnegie Mellon/NASA Ames.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Program Design. Simple Program Design, Fourth Edition Chapter 1 2 Objectives In this chapter you will be able to: Describe the steps in the program development.
Integrating SysML with OWL (or other logic based formalisms)
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
ece 720 intelligent web: ontology and beyond
Objective of This Course
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
CS310 Software Engineering Lecturer Dr.Doaa Sami
Department of Computer Science Abdul Wali Khan University Mardan
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Modern Systems Analysis and Design Third Edition
Presentation transcript:

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

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

PART A: Some Problems with Teaching AI

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.

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 ….

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.

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

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

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

GIPO 'Graphical Interface for Planning with Objects‘ 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

/

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…

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

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.

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

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

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

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

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

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.

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

PART C: Student Learning Experience with GIPO

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

Conclusions

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

Some advertising…