It is possible to represent a plan as a domain that follows slightly different rules from ordinary domains. This document describes how plans can be written using a variant of the LTF language. That language, and its use for ordinary domains, is described separately, and that document provides a more complete account of the language. The file syntax for LTF plans as domains uses the file-type "lpad".
The usual representation for plans, which is described using the XML syntax, is already quite domain-like, since it uses a kind of refinement to describe how activities are constrained and expanded into sub-activities. However, it turns out that domains can be used as well. Such domains don't have to be written as LTF, but for now that's the only syntax that's been given a file type.
The main differences from ordinary domains are as follows:When nodes (activities) are specified in refinements, they must be given IDs that are unique within the whole domain, rather than just within each refinement.
The top level of the plan becomes a refinement named plan-top-level. Constraints in that refinement (and only in that refinement) are allowed to refer to any nodes in the domain. The plan's world-state information is attached as an annotation that has the symbol world-state as its key, and a map of pattern-value entries as its value.
Each other refinement in the domain describes how a node (activity) in the plan is expanded into sub-activities and how it is "locally" constrained by constraints that do not refer to any nodes other than those listed in the refinement. (Other constraints have to be given by the plan-top-level refinement.)
The patterns in the refinements are not significant. By convention, a refinement is given the same pattern as the node it refines, but that is just to help someone reading the domain. Variables in those patterns should not be declared and cannot be used within the refinement.
A refinement is associated with the node (activity) it refines by giving the node's ID as the value of an annotation that has the symbol expands as its key. By convention, the refinement also has the name expands-id using that ID.
Another annotation, with the symbol expansion-refinement-name as its key, is used to record the name of the refinement that was used to refine the node when planning, if there was one and it's known what name it had. That refinement would have come from an ordinary domain which shouldn't be confused with the one being used to represent the plan. The example below should make this clearer.
At present, the domain description of plans leaves out some of the information that's normally contained in plans, either because it couldn't be represented in a sufficiently natural way or because there wasn't time to implement a representation. Issues, activity priorities, and most activity annotations are among the things that are missing. The limitations of plans-as-domans should be reduced in future versions of I-X.
To set up the planning problem for I-Plan, we provide an initial plan and a domain.
| The initial plan |
|---|
(refinement plan-top-level ("Top level of the plan")
(nodes
(node-0 (get-to-work)))
(annotations
(world-state =
(Map
((location me) = home)
((have-paper Scotsman) = true)))))
|
The initial plan contains one activity, (get-to-work), and its world-state model says that the location of me is home, and that one newspaper, The Scotsman, is available. Note that no weather is specified, which matters for one of the refinements in the domain.
| The domain |
|---|
(domain
(name "get-to-work-example"))
(refinement get-up-and-go (get-to-work)
(variables ?paper)
(nodes
(1 (get-dressed))
(2 (eat-breakfast))
(3 (read-paper ?paper))
(4 (travel home work)))
(orderings
;; Each of 1, 2, and 3 must finish before 4 starts.
((1 2 3) 4))
(constraints
(world-state condition (have-paper ?paper) = true)))
(refinement walk (travel ?from ?to)
(variables ?from ?to)
(constraints
(world-state condition (weather) = sunny)
(world-state condition (location me) = ?from)
(world-state effect (location me) = ?to)))
(refinement take-bus (travel ?from ?to)
(variables ?from ?to)
(constraints
(world-state condition (location me) = ?from)
(world-state effect (location me) = ?to)))
;;; End
|
The domain provides one way get to work and two ways to travel from home to work. One, walking, can be used only if the weather is sunny.
It's a domain for a dedicated newspaper reader, since it's not possible to construct a plan using the domain unless at least one paper is available.
| The resulting plan |
|---|
(refinement plan-top-level ("Top level of the plan")
(nodes
(node-0 (get-to-work)))
(annotations
(world-state =
(Map
((location me) = home)
((have-paper Scotsman) = true)))))
(refinement expand-node-0 (get-to-work)
(nodes
(node-0-0 (get-dressed))
(node-0-1 (eat-breakfast))
(node-0-2 (read-paper Scotsman))
(node-0-3 (travel home work)))
(orderings
(node-0-0 node-0-3) (node-0-1 node-0-3) (node-0-2 node-0-3))
(constraints
(world-state condition (have-paper Scotsman) = true))
(annotations
(expands = node-0)
(expansion-refinement-name = "get-up-and-go")))
(refinement expand-node-0-3 (travel home work)
(constraints
(world-state condition (location me) = home)
(world-state effect (location me) = work))
(annotations
(expands = node-0-3)
(expansion-refinement-name = "take-bus")))
|
In the resulting plan, the world-state information is the same as in the initial plan, because the plan's meant to begin execution in that state; but the variable ?paper has been replaced by Scotsman (which was the only possibility); the (get-to-work) activity has been refined using the get-up-and-go refinement, expanding it into sub-activities and adding ordering constraints and a word-state constraint; and the (travel home work) sub-activity has been refined using take-bus. The activities (nodes) have been given unique IDs so that they can be referred to from outside their refinement.
The similarities between the output plan and the parts of the domain that were used in constructing it should be clear.