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

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

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.

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

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

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

Machines – Basic Building Blocks Each machine is parameterised by a single object sort Lm sort :non-empty list of state names => Mac sort Lm s : [s1,s2,s2] = Machine1

Machine1 in PDDL (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))) (:action t1 :parameters ( ?S - s) :precondition (s1 ?S) :effect (and (not (s1 ?S)) (s2 ?S))) (:action t3 :parameters ( ?S - s) :precondition (s2 ?S) :effect)))

Operators on Machines prop takes a machine of sort x, a property name N and a sort y, and adds a property such that at every state in the given machine, individuals will be related to some value of sort y that constitutes the value for the property of the object in this state. An axiom on this constructor is that x must not equal y prop: Mac x x N x Sort y => Mac x

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

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

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

Property Changing Transitions Chg takes a machine, a transition identifier, a property name and a propositional constraint on the property and produces a new machine of the same sort where the property changes value in accordance with the propositional constraint whenever the machine makes the identified transition. Chg: Mac x x T x P x PC => Mac x

Property change Example chg: (prop : lm s [s1,s1], location,loc),s1 -> s1, location, next = Machine3

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))))

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 that can be applied to any machine to produce a Domain Definition.

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

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

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

Extended Prevail Example (1) In a “logistics” type domain with packages and trucks loading 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.

Extended Prevail Example (2) 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. prop: (lm package :[waiting,loaded,loaded]),location,loc = Mac1 prop: (lm truck :[available,available]),location,loc = Mac2 prevail: (U Mac1 Mac2) (waiting ->loaded), available = DD1

Extended Prevail Example (3) 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 prevail c: (U Mac1 Mac2), (waiting ->loaded), available, location,location,eq = DD1

Extended Prevail Example (4) 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: (U Mac1 Mac2), (waiting ->loaded), available, location,location,eq = DD1 prevail-c: DD1, (loaded ->waiting), available, location,location,eq = DD2

Example: Making the truck mobile 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. chg:prop: ((lm truck :[available,available]),location,loc), (available -> available), location, neq = Mac2

Example: Coordinating the movements of the truck and package. 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) conditional c: DD2, (available -> available), (loaded -> loaded), location,location,eq = DD3

Complete simple Logistics domain - DD3 chg:prop: ((lm package :[waiting,loaded,loaded]), location,loc),(loaded -> loaded), location, neq = Mac1 chg:prop: ((lm truck :[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

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

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.

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

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