Towards An Algebraic Formulation of Domain Definitions using Parameterised Machines

1. Towards An Algebraic Formulation of Domain Definitions usingParameterised Machines T. L. McCluskey and R. M.Simpson School of Computing and Engineering The University of Huddersfield

2. Issues in Knowledge Engineering for Planning • Knowledge engineers naturally would like to re-use domain descriptions when creating newones, rather than creating descriptions from scratch. • models of the same domain may differ in small details without rationale. For example, howmany, and what parameters, should a predicate have? How is this determined? What predicatesthat are implicitly true should be stated explicitly in the conditions of an operator?

3. Point of Paper • introduce an algebraic form of domain definition – an alternative to PDDL • Domain engineers can use GIPO III to build up a domain model by drawing a graph of nodes and arcs - PDDL is auto generated from the graph. The algebraic formalism gives an abstract (but not completely formal) semantics for the graph diagrams in GIPO III.

4. Algebras • A homogeneous algebra is a set ofvalues (called the ’carrier’ set) together with a set of totally defined, closed operators. • For example, the set of numbersknown as the ’Natural Numbers’, together with the operators ’+’ and ’*’.

5. A heterogeneous algebra • there are a set of carrier sets, with one particular set representingthe values of the algebra being defined. • carrier sets that are not the type of interest can be thought of as valuesfrom ’imported’ algebras. • The behaviour of stack data structure can be readily captured by a heterogeneousalgebra, with operators such as pop, push, initialise, and top, and the values within thestack taken from one of the imported algebras.

6. An algebraic specification • An algebra is often abstractly defined by a set of operators together with a set of axioms relating those operators. • “Values” are implicit – they are generated by the constructor operators A PLANNING DOMAIN DEFINITION ~ VALUE OF AN ALGEBRA Domain description languages are ‘models’ of an algebraic specification

7. Machines – Basic Building Blocks • Each machine is parameterised by a single object sort Lmsort:non-empty list of state names => Macsort Lms : [s1,s2,s2] = Machine1

8. Machine1 in PDDL (:action t1 :parameters ( ?S - s) :precondition (s1 ?S) :effect (and (not (s1 ?S)) (s2 ?S))) (:action t3 :parameters ( ?S - s) :precondition (s2 ?S) :effect))) (define (domain examples) (:requirements :strips :equality :typing) (:types s) (:predicates (s1 ?s1 - s) (s2 ?s1 - s)) (:action t2 :parameters ( ?S - s) :precondition (s2 ?S) :effect (and (not (s2 ?S)) (s1 ?S)))

9. Operators on Machines prop: Macx x N x Sorty=> Macx prop takes a machine of sortx,a property nameNand a sorty, and adds a property suchthat at every state in the given machine, individuals will be related to some value of sortythatconstitutes the value for the propertyof the object in this state. An axiom on this constructoris that xmust not equaly

10. Prop prop: Machine1, location, loc creates a machine as in figure 1 but where location(s), is afunction returning values of type loc where s is an object of the sort referenced in machine1

11. merge merge: Macx x Macx x [a1,a2/a3,…] => Macx merge takes two machines of the same sort and a list of pairs of state names where the first nameis a state in the first machine and the second is a state in the second machine.merge makesthese states identical and renames them with the provided name in the combined machine. merge preserves the transitions of both machines.

12. Example - merge merge: Machine1(lm:[a1,a1])[s1,a1/b1] = Machine2

13. Property Changing Transitions Chg: Macx x T x P x PC => Macx Chg takes a machine, a transition identifier, a property nameand a propositionalconstraint on the property and produces a new machine of the same sort where the propertychangesvalue in accordance with the propositional constraint whenever the machine makes the identifiedtransition.

14. Property change Example chg: (prop : lms [s1,s1], location,loc),s1 -> s1, location, next = Machine3

15. Property Change in PDDL (define (domain examples) (:requirements :strips :equality :typing) (:types s loc) (:predicates (s1 ?s1 - s) (location ?s1 - s ?loc1 - loc) (next ?loc1 - loc ?loc2 - loc)) (:action t1 :parameters ( ?S - s ?LocA - loc ?LocB - loc) :precondition (and (s1 ?S) (location ?S ?LocA)(next ?LocA ?LocB)) :effect (and (not (location ?S ?LocA))(location ?S ?LocB))))

16. Domains on Multiple Sorts • Domain definitions are formed from machines/domain definitions and operators on domain definitions. • Any machine specification is a domain definition. • There is an invisible operator promote thatcan be applied to any machine to produce a Domain Definition.

17. Union U: DD x DD => DD • Union simply joins two domain definitions preserving all states and transitions.

18. Coordinating Transitions • Transitions on one machine typically require to be coordinated with transitions of other machines. • Variations on three operators are used to provide for such coordination. • Prevail • Necessary • Conditional

19. Prevail prevail: DD x T x S => DD prevail +: DD x T x S => DD prevail -: DD x T x S => DD prevail c: DD x T x S => DD • Prevail requires that an object making the Transition T identified in the Domain DD requires (some other object) to be in state S drawn from the domain. That object persists in state S for the duration of the transition.

20. Extended Prevail Example (1) • In a “logistics” type domain with packages and trucksloading a package into a truck may involve the package changing state from waiting to loaded. The truck may however be required to persist in the state available while the package is loaded.

21. Extended Prevail Example (2) prop: (lmpackage:[waiting,loaded,loaded]),location,loc = Mac1 prop: (lmtruck:[available,available]),location,loc = Mac2 prevail: (U Mac1 Mac2) (waiting ->loaded), available = DD1 • In the example so far a truck is required to be available but we have not specified that the package and truck must share the same location. To do this we need the constraint form of the prevail operator.

22. Extended Prevail Example (3) prevail c: (U Mac1 Mac2), (waiting ->loaded), available, location,location,eq = DD1 • In this version of Domain Definition 1 DD1 in addition to requiring the truck to be available we require that the location property of the object making the transition and the location property of the object in the available state take on the same value (eq). • Constraint clauses require the properties of coordinating objects to be related in determinate ways

23. Extended Prevail Example (4) prevail+c: (U Mac1 Mac2), (waiting ->loaded), available, location,location,eq = DD1 • The add association annotation(+) additionally requires that the association between the package and truck be remembered until such time that the package makes a transition that removes (-) the association. This we would expect to be done when the package is unloaded from the truck prevail-c: DD1, (loaded ->waiting), available, location,location,eq = DD2

24. Example: Making the truck mobile chg:prop: ((lmtruck:[available,available]),location,loc), (available -> available), location, neq = Mac2 • We needed to add a property changing constraint to the truck machine definition allowing the truck to change location when the transition from available to available is made. • A similar alteration to Mac1 should be made to allow the package to change location.

25. Example: Coordinating the movements of the truck and package. conditional c: DD2, (available -> available), (loaded -> loaded), location,location,eq = DD3 • We apply a conditional constraint on the two transitions such that the second transition can only be made when the first is made and where the location properties of the objects concerned are the same (eq)

26. Complete simple Logistics domain - DD3 chg:prop: ((lmpackage:[waiting,loaded,loaded]), location,loc),(loaded -> loaded), location, neq = Mac1 chg:prop: ((lmtruck:[available,available]),location,loc), (available -> available), location, neq = Mac2 prevail+c: (U Mac1 Mac2), (waiting ->loaded),available, location,location,eq = DD1 prevail-c: DD1, (loaded ->waiting),available, location,location,eq = DD2 conditional c: DD2, (available -> available), (loaded -> loaded), location,location, eq = complete domain definition

27. Conclusions - Addressing Knowledge Engineering Issues? • Reuse • Machine and Partial Domain definitions could be imported into new domains. • May be issues of how imported fragments retain their identity as they are modified by the application of domain operators. No mechanism equivalent to OO classes to preserve the integrity of re-used ‘code’.

28. Conclusions - Addressing Knowledge Engineering Issues? (2) • Canonical Forms – • Roles of predicates (as translated to PDDL) restricted to well defined purposes. • Identify states • record property values • record associations • define relations between property values. • Allows choice about how these are recorded.

29. Conclusions - Problems & Opportunities • Quantification? • [related to 1.] What is the expressiveness of the current formulation eg compared to PDDL? • Yet to formalise semantics axiomatically • Interpreter for algebraic formalism – not quite finished yet.. • Analysis: we plan to look into automated transformation of machines (establish and transform created machines into a normal form …).

30. Conclusions – Algebraic form vs PDDL • Currently PDDL – ADL is more expressive • In the domains we have considered, size of algebraic spec << PDDL • Re-use – pddl – understand original PDDL description Algebraic – understand graphic machine using GIPO, then apply algebraic ops to create new domain descriptions