CHA2555 Week2: Knowledge Representation, Logic and Planning

1. CHA2555 Week2:Knowledge Representation,Logic and Planning Lee McCluskey Email lee@hud.ac.uk First term: http://scom.hud.ac.uk/scomtlm/cha2555/

2. Introduction • What is Knowledge Representation? • Does a book represent knowledge? • Does a database represent knowledge? • What are the requirements for representing knowledge? • Separation of behaviour and knowledge – implement ‘generic’ behaviours • Maintaining knowledge needs to be easy - add more knowledge and behaviour improves • Which ways are used to represent knowledge? • Why do we want to represent knowledge? Can we have AI without it?

3. Symbolic Knowledge Representation • Databases – represent sets of facts • “Knowledge” tends to be represented using “Logic”, where facts are considered as simple assertions • E.g. current law on marriage / gender etc male(fred), married(fred,hilary) [FACTS] For all people x,y : married(x,y) and male(x) => female(y) male(x) v female(y) not (male(x) and female(x)) [LOGIC about people – properties and relations] Encode “reasoning” into programs => hilary is female

4. Deeper example of Knowledge Representation: Representing an Action in “PDDL” Example - moving a block from x to z PDDL uses an “operator schema” or simply operator: (:action move :parameters (?x – block ?y – block ?z - block) :precondition (and (clear ?x) (clear ?z) (on ?x ?y) (not (= ?x ?z))) :effect (and (not (clear ?z)) (clear ?y) (not (on ?x ?y)) (on ?x ?z)))

5. Implementing “AI” behaviour Application Domain Languages for implementing behaviours Symbolic Conceptualisation and/or Model Including knowledge representation Java Prolog “Semantic difference” LISP C++ Haskell

6. Automated (AI) Planning The scope of ‘AI Planning’ is the synthesis (generation) and execution of PLANS. That is, AI Planners reason with actions and generate plans.

7. Automated Planning i/o definition Input: a Goal or Task, Current Situation Process: Reasoning with [knowledge representations] of Actions, Objects Goal, States, Constraints, Resources etc Output: an ordering of specific actions [= plan] which achieves/solves/enacts the Goal or Task

8. Planning: Example Applications • AUTOMATIC CONTROL: of industrial processes, traffic, industrial robots, spacecraft, underwater robots • Eg NASA’s Remote Agent Experiment • CRISIS MANAGEMENT: in military applications, accidents, evacuations, forest fire fighting • USER SUPPORT: for project planning, web search, web service composition • SIMULATION: games software AI Planning has to be cost effective - • makes plans more quickly than people? more reliable plans? more efficient plans?

9. 0: MOVE_TO_PASSAGE P67 BOROMIR R7        1: MOVE_TO_PASSAGE P45 ARAGORN R4        2: MOVE_INTO_ROOM P45 ARAGORN R4 R5        3: GET_PROTECTION ARAGORN R5 SHIELD        4: MOVE_INTO_ROOM P67 BOROMIR R7 R6        5: KILL_SLEEPING_MONSTER BOROMIR R6 P56 KNIFE TROLL        6: PICK_UP_TREASURE BOROMIR R6 LOCKET        7: MOVE_TO_PASSAGE P67 BOROMIR R6 r1 r2 p12 spell ring orc lock-1 lock-1 p24 r3 p25 lock-2 p35 bracelet r5 +Sword +Cudgel r4 p45 shield Aragorn p56 Key-2 r6 golem    8: MOVE_INTO_ROOM P67 BOROMIR R6 R7        9: MOVE_TO_PASSAGE P67 BOROMIR R7       10: EXCHANGE BOROMIR R7 P67 LOCKET KEY1 11: MOVE_INTO_ROOM P67 BOROMIR R7 R6   12: MOVE_TO_PASSAGE P56 BOROMIR R6       13: MOVE_INTO_ROOM P56 BOROMIR R6 R5       14: UNLOCK_PASSAGE BOROMIR R5 P25 KEY1       15: MOVE_TO_PASSAGE P25 ARAGORN R5       16: MOVE_INTO_ROOM P25 ARAGORN R5 R2       17: FIGHT_AND_KILL_MONSTER ARAGORN R2 P12 SHIELD SWORD ORC       18: MOVE_TO_PASSAGE P12 ARAGORN R2       19: MOVE_INTO_ROOM P12 ARAGORN R2 R1       20: PICK_UP_TREASURE ARAGORN R1 RING locket troll Sample Goal = Boromir kills Troll Aragorn acquiresThe Ring p57 p67 Key-1 PLAN generated by AI is shown opposite (its not optimal!) r7 p47 +Knife Boromir

10. Usual (abstract) Architecture of Planners Knowledge representation “Behaviour” generation DOMAIN MODEL PLANNING ENGINE INTERFACE

11. Simple Planning Domain Models • Domain models typically contain Types or classes of objects + Actions (represented by Operators) that change state of objects A TASK associated with a domain model is defined by: An INITIAL STATE + a GOAL CONDITION or STATE (:action move :parameters (?x – block ?y – block ?z - block) :precondition (and (clear ?x) (clear ?z)(on ?x ?y) (not (= ?x ?z))) :effect (and (not (clear ?z)) (clear ?y) (not (on ?x ?y)) (on ?x ?z)))

12. Simple Planning Domain Models • Domain models typically contain • Types or classes of objects • Actions (represented by Operators) that change state of objects A TASK associated with a domain model is defined by: • An INITIAL STATE • GOAL(S)

13. Environmental Assumptions • In simple ‘applications’ we ASSUME: • finite world (rather than infinite) • deterministic actions (rather than non-deterministic) • completely observable (rather than partially observable) • instantaneous (rather than durative actions) • unchanging, closed world (rather than open, dynamic world) • infinite resources

14. Environmental Assumptions • The “FRAME PROBLEM” is a source of concern in AI planning – the logic of stating what is not affected by an action • Often we assume an action satisfies the RULE of DEFAULT PERSISTENCE: If an action specification does not specify that a fact / object changes then it does not change .. things persist by default

15. PLANS in AI Planning Are what planners generate. They are partial orders or sequences of instantiated operator schemas. They should be: • CORRECT - preconditions are satisfied • COMPLETE - achieve the final goal • OPTIMAL - no shorter or more efficient plan exists

16. Summary Knowledge Representation – encoding knowledge so that it can be updated and used by reasoning processes Planning is an important subarea of AI. Planning programs input “domain models” (often lists of operator schema), problem specifications (often initial states and goal conditions) and generate plans.