A range of different outputs can be produced by the O-Plan Web demos. This document provides a brief explanation.
Contents:
O-Plan is given a task, and it produces a plan. The task specifies actions to be carried out or conditions to be achieved. Since conditions are achieved by actions that have the required effects, both aspects of the task result in actions being added to the plan.
The plans that O-Plan produces are hierarchical, partially-ordered networks of actions. They're hierarchical because some actions are broken down (expanded) into subactions. They're partially ordered because actions don't always have to occur in sequence. Sequencing is added only when it's needed. For instance, if I'm going to go to work, I have to eat breakfast and get dressed first; but I could eat breakfast and get dressed in either order, and I might eat breakfast and read the paper at the same time.
Note that it's only the latter case - actions that could be happening at the same time - that can remain unordered. For actions that could happen in either order, a valid plan will have them in one order or the other; but both plans will be possible.
pattern = valuefor instance
{on a b} = true {size a} = 10 {distance_between a b} = 3 {location jeff} = work {breakfast_eaten} = true
If we imagine the actions of a plan taking place in time, then at any given time the state of the world at that time can be described as a list of pattern = value pairs, or p-v-pairs. If p=v is such a pair, we might say p has value v or perhaps that p=v is true. (Don't confuse this with the case where v is true.) The pairs are sometimes called facts.
An action's conditions describe what values certain patterns must have before the action can occur. An action's effects describe changes in pattern values.
Every condition in the plan must have at least one matching effect that (a) occurs at an earlier point in time, and (b) cannot be canceled by any intervening effect. This ensures that the required condition is true. When a condition depends on an effect in this way, the dependency is recorded in a table known as the GOST (for GOal STructure).
O-Plan does not explicitly track the state of the world. Instead, it records effects and when they occur in another table called the TOME (Table Of Multiple Effects). From this, and from information about when actions take place, it's possible to determine at least part of the state of the world at a given time, t. It may not be possible to determine the entire state at t, because it may not be known whether certain effects must happen before t or not.
For instance, suppose I'm traveling to Edinburgh on a train that will arrive between 10 and 11 at night and that we're using effects to record my position. (Forget about whether we could actually know the arrival time that precisely, given all the things that can go wrong.) We can represent this in a plan. The travel-to-Edinburgh action would have an end-point that is listed as being between 10 and 11, and there'd be an effect at that point such as
{location jeff} = EdinburghNow supppse we ask for the state of the world at 10:30. Am I in Edinburgh or not? The answer is that we can't say, because there's nothing in the plan that tells us. In the plan, I could be in Edinburgh by 10:30, but I am not definitely in Edinburgh until 11.
A PostScript graph of the nodes and links in the plan. In order to simplify the graph, dummy nodes that can be removed without increasing the number of links have been removed, as have redundant links. However, all of the necessary order-relationships are preserved.
When possible, both ends of a node are shown as a single block. This happens when links do not enter or leave "between the ends", i.e. when links go only to the begin-half of the node or from the end-half.
Requesting a KP trace will substantially slow the planner.
The format is:
world pattern_1 = value_1 pattern_2 = value_2 ... end_world