Towards An Algebraic Formulation of Domain Definitions usingParameterised Machines

T. L. McCluskey and R. M.SimpsonSchool of Computing and EngineeringThe 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 sortLmsort:non-empty list of state names => Macsort

Lms : [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: Macx x N x Sorty => Macx

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: Macx x Macx x [a1,a2/a3,…] => Macx

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: Macx x T x P x PC => Macx

Property change Example

chg: (prop : lms [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 => DDprevail +: DD x T x S => DDprevail -: DD x T x S => DDprevail 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: (lmpackage:[waiting,loaded,loaded]),location,loc= Mac1

prop: (lmtruck:[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: ((lmtruck:[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: ((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

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