Action description language

Pednault observed that the expressive power of STRIPS was susceptible to being improved by allowing the effects of an operator to be conditional. This is the main idea of ADL-A, which is roughly the propositional fragment of the ADL proposed by Pednault,[2] with ADL-B an extension of -A. In the -B extension, actions can be described with indirect effects by the introduction of a new kind of propositions: ”static laws". A third variation of ADL is ADL-C which is similar to -B, in the sense that its propositions can be classified into static and dynamic laws, but with some more particularities.[3]

The sense of a planning language is to represent certain conditions in the environment and, based on these, automatically generate a chain of actions which lead to a desired goal. A goal is a certain partially specified condition. Before an action can be executed its preconditions must be fulfilled; after the execution the action yields effects, by which the environment changes. The environment is described by means of certain predicates, which are either fulfilled or not.

Contrary to STRIPS, the principle of the open world applies with ADL: everything not occurring in the conditions is unknown (Instead of being assumed false). In addition, whereas in STRIPS only positive literals and conjunctions are permitted, ADL allows negative literals and disjunctions as well.

An ADL schema consists of an action name, an optional parameter list and four optional groups of clauses labeled Precond, Add, Delete and Update.

The Precond group is a list of formulae that define the preconditions for the execution of an action. If the set is empty the value "TRUE" is inserted into the group and the preconditions are always evaluated as holding conditions.

The Add and Delete conditions are specified by the Add and Delete groups, respectively. Each group consists of a set of clauses of the forms shown in the left-hand column of the figure 1:

1. The R represents a relation symbol
2. τ₁, ..., τ_n represents terms
3. ψ represents a formula
4. The sequence z₁, ..., z_k are variable symbols that appear in the terms τ₁, ..., τ_n, but not in the parameter list of the action schema
5. x₁, ..., x_n are variable symbols that are different from the variables z₁, ..., z_n and do not appear in τ₁, ..., τ_n, ψ, or the parameter list of the action schema

The Update groups are used to specify the update conditions to change the values of function symbols. An Update group consists of a set of clauses of the forms shown in the left column of the figure 2:

The formal semantic of ADL is defined by 4 constraints. The first constraint is that actions may not change the set of objects that exist in the world; this means that for every action α and every current-state/next-state pair (s, t) ∈ a, it must be the case that the domain of t should be equal to the domain of s.

The second constraint is that actions in ADL must be deterministic. If (s, t₁) and (s, t₂) are current-state/next-state pairs of action ∃, then it must be the case that t₁ = t₂.

The third constraint incorporated into ADL is that the functions introduced above must be representable as first-order formulas. For every n-ary relation symbol R, there must exist a formula Φ^a_R(x₁,... ,x_n) with free variables x₂, ..., x_n such that f^a_R(s) is given by:

${\displaystyle t(R)=f_{R}^{a}(s)=(d_{1},\ldots ,d_{n})\in \operatorname {Dom} (s)^{n}\mid s[d_{1}/x_{1},\ldots ,d_{n}/x_{n}\models \Phi _{R}^{a}(x_{1},\ldots ,x_{n})]}$

Consequently, F(n₁, ..., x_n) = y will be true after performing action |= if and only if Φ^a_R (x₁, ..., x_n,y) was true beforehand. Note that this representability requirement relies on the first constraint (domain of f should be equal to domain of s).

The fourth and final constraint incorporated into ADL is that set of states in which an action is executable must also be representable as a formula. For every action α that can be represented in ADL, there must exist a formula Π^a with the property that s |= Π_a if and only if there is some state t for which (s, t) ∈ α (i.e. action α is executable in state s)

In terms of computational efficiency, ADL can be located between STRIPS and the Situation Calculus.[4] Any ADL problem can be translated into a STRIPS instance – however, existing compilation techniques are worst-case exponential.[5] This worst case cannot be improved if we are willing to preserve the length of plans polynomially,[6] and thus ADL is strictly more brief than STRIPS.

ADL planning is still a PSPACE-complete problem. Most of the algorithms polynomial space even if the preconditions and effects are complex formulae.[7]

Most of the top-performing approaches to classical planning internally utilize a STRIPS like representation. In fact most of the planners (FF, LPG, Fast-Downward, SGPLAN5 and LAMA) first translate the ADL instance into one that is essentially a STRIPS one (without conditional or quantified effects or goals).

1. The STRIPS language only allows positive literals in the states, while ADL can support both positive and negative literals. For example, a valid sentence in STRIPS could be Rich ∧ Beautiful. The same sentence could be expressed in ADL as ¬Poor ∧ ¬Ugly
2. In STRIPS the unmentioned literals are false. This is called the closed-world assumption. In ADL the unmentioned literals are unknown. This is known as the Open World Assumption.
3. In STRIPS we only can find ground literals in goals. For instance, Rich ∧ Beautiful. In ADL we can find quantified variables in goals. For example, ∃x At (P1, x) ∧ At(P2, x) is the goal of having P1 and P2 in the same place in the example of the blocks
4. In STRIPS the goals are conjunctions, e.g., (Rich ∧ Beautiful). In ADL, goals may involve conjunctions and disjunctions (Rich ∧ (Beautiful ∨ Smart)).
5. In STRIPS the effects are conjunctions, but in ADL conditional effects are allowed: when P:E means E is an effect only if P is satisfied
6. The STRIPS language does not support equality. In ADL, the equality predicate (x = y) is built in.
7. STRIPS does not have support for types, while in ADL it is supported (for example, the variable p : Person).

The expressiveness of the STRIPS language is constrained by the types of transformations on sets of formulas that can be described in the language. Transformations on sets of formulas using STRIPS operators are accomplished by removing some formulas from the set to be transformed and adding new additional formulas. For a given STRIPS operator the formulas to be added and deleted are fixed for all sets of formulas to be transformed. Consequently, STRIPS operators cannot adequately model actions whose effects depend on the situations in which they are performed. Consider a rocket which is going to be fired for a certain amount of time. The trajectory may vary not only because of the burn duration but also because of the velocity, mass and orientation of the rocket. It cannot be modelled by means of a STRIPS operator because the formulas that would have to be added and deleted would depend on the set of formulas to be transformed.[8]

Although an efficient reasoning is possible when the STRIPS language is being used it is generally recognized that the expressiveness of STRIPS is not suitable for modeling actions in many real world applications. This inadequacy motivated the development of the ADL language.[9][10] ADL expressiveness and complexity lies between the STRIPS language and the situation calculus. Its expressive power is sufficient to allow the rocket example described above to be represented yet, at the same time, it is restrictive enough to allow efficient reasoning algorithms to be developed.

As an example in a more complex version of the blocks world: It could be that block A is twice as big as blocks B and C, so the action xMoveOnto(B,A) might only have the effect of negating Clear(A) if On(A,C) is already true, or creating the conditional effect depending on the size of the blocks. This kind of conditional effects would be hard to express in STRIPS notation without the conditional effects.

Consider the problem of air freight transport, where certain goods must be transported from an airport to another airport by plane and where airplanes need to be loaded and unloaded.

The necessary actions would be loading, unloading and flying; over the descriptors one could express In(c, p) and At(x, A) whether a freight c is in an airplane p and whether an object x is at an airport A.

The actions could be defined then as follows:

Action (
  Load (c: Freight, p: Airplane, A: Airport)
  Precondition: At(c, A) ^ At(p, A)
  Effect: ¬At(c, A) ^ In(c, p)
)

Action (
  Unload (c: Freight, p: Airplane, A: Airport)
  Precondition: In(c, p) ^ At(p, A) 
  Effect: At(c, A) ^ ¬In(c, p)
)

Action (
  Fly (p: Airplane, from: Airport, to: Airport)
  Precondition: At(p, from)
  Effect: ¬At(p, from) ^ At(p, to)
)

• Action language
• Action selection
• Hierarchical task network
• Planning Domain Definition Language (PDDL)