Towards An Algebraic Formulation of Domain Definitions using Parameterised Machines

1 / 30

# Towards An Algebraic Formulation of Domain Definitions using Parameterised Machines - PowerPoint PPT Presentation

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

## PowerPoint Slideshow about 'Towards An Algebraic Formulation of Domain Definitions using Parameterised Machines' - camila

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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

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

Lmsort:non-empty list of state names => Macsort

Lms : [s1,s2,s2] = Machine1

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

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

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

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.

Example - merge

merge: Machine1(lm:[a1,a1])[s1,a1/b1]

= Machine2

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.

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

U: DD x DD => DD

• Union simply joins two domain definitions preserving all states and transitions.
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: 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.
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.
Extended Prevail Example (2)

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

location,location,eq = DD2

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.

conditional c: DD2, (available -> available),

• 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)
Complete simple Logistics domain - DD3

= 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

location,location,eq

= DD2

conditional c: DD2, (available -> available),

= 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
• 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 …).
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