Planning Initiative SPAR Objectives

Part of the DARPA/Air Force Research Laboratory (Rome) Planning Initiative (ARPI)

Original Objectives for SPAR | Lists of Requirements | Classification of Requirements

Objectives defined by Tom Garvey, Doug Dyer, Nort Fowler and Rick Metzger

The driving need is to achieve a practical balance (as in one that will actually be applied in DARPA and AFRL sponsored systems development) between coverage, adequate expressiveness and reasonable computational efficiency. ARPI has a long history of wandering around in this space, often simultaneously by several subgroups. The intent is that the common plan representation will actually be useful and used by many, including IFD and ATD builders. The first step is to propose some solid core as version 1, and release it to get banged upon by wildly divergent communities.

There are many facets to the plan representation, of course, and many of these (e.g. uncertainty and temporal reasoning) have themselves not solved the problem by achieving consensus on the right balance in a representation for just their specialty. So we are not intending to resolve all the deep representational issues of the larger, combined space, a mistake we've made before. Rather, the goal is to get something that's practical, but under which we feel there is a reasonable foundation, and not just "ad hocery", as in the past (e.g. IFD-3). The long term goal is to grow this appropriately, as the various specialities resolve their own representational issues, while trying to maintain the practical balance above.

From Tom Garvey:

A core group would have responsibility for defining the representation. They would do this by combining their own viewpoints with those expressed by "experts," representatives of both technical disciplines and users (this second group is not intended to be "implementers", especially not implementers of the common plan representation). The first meeting of the core group would be to flesh out the methodology and define the set of operating requirements.

The result of this meeting would be a set of questions that would guide the presenters at the next meeting. These questions would characterize the desiderata for our representation, that is the set of things we want to do with it and that we want it to be able to support. They would encompass both expressiveness and performance requirements.

The results of the defining meeting would be used to shape the presentations we will be requesting from the experts at the second meeting. In the second meeting the experts would brief the core panel wrt needs that their discipline or interest would impose on the representation as well as representational formalisms that could support their requirements.

The core group will synthesize the collective view, create a strawman representation and publish it for comments. Following a period for comments, a more final version will be defined and implementations started.

We would like a brief overview of the project and progress in the ARPI meeting in San Francisco in November 1997.

From Tom Garvey:

What I am aiming for here is a plan representation that will support -- efficiently -- the needs of the application/system programs while providing an expressive enough representation that our technology-base programs will be able to use it and to plug into future demos with a minimum of heartache.

This is the reason that I want to make sure we cover all the key users and contributors to planning and plan management systems. Without a common, shared plan representation that is both expressive and utile (if that's a word - my spelling checker, presciently, perhaps, tried to change it to 'futile'), I am very pessimistic about ever transitioning our technology to the programs that could benefit from it.

Lists of Requirements

I'd like to ask you all to begin assembling a list of the desiderata for the representation that define what we hope to be able to do with it, what it will have to be able to represent, and what attributes it will need to have. My entries include the following:

1. I'd like a persistent, extensible representation that can be stubbed off to cover incomplete aspects;
2. I'd like to be able to represent directly uncertainty, ignorance, and ambiguity;
3. I'd like the planning horizon to be explicit;
4. I'd like to be able to back-track to the source of each element of the plan, i.e., I want to be able to do rapid and intelligent replanning and want access to the place from whence the original was developed.
5. I assume plan merging will be a common operation and I'd like support for that (whatever that means);
6. I'd like to represent time explicitly;
7. I'd like to represent dependencies in the plan;
8. when planned tasks are scheduled, I'd like the schedule to be incorporated in the plan;
9. I'd like plan knowledge (such as operators, cases, ACTs, ...) to be included in the representation;
10. I'd like a scheme that would allow us to go with the full representation for complex problems and trim it down to essentials for simpler cases;
11. I'd like to support reactive and deliberate planning;
12. I'd like whatever would be required to support workflow management (which may require introspection over the plan).

I think we need to make a global list of this type of requirement that we can discuss, make sensible, prune, and prioritize for implementation.

From Adam Pease:

(speaking as a hypothetical user)...

1. I'd like to store all the things specific to my specialized type of planning but be able (with some loss) to translate to a representation others can understand.
2. I'd like a design I can specialize directly for my special planning needs
3. I'd like a design I can specialize parts of or throw away parts of without affecting the parts I care about.
4. I'd like a design that assumes object orientation but not a particular language.
5. I'd like an implementation I can play with and specialize from.
6. It should be easy and simple to represent easy and simple things. It should be possible to represent complex things.
7. I'd like to be able to represent the information I have at every stage. I should be able to start by representing just the name of a plan. I should be able to name actions without specifying their order but add in ordering later when I have that information.
8. I'd like to be able to record the state of execution of a plan even though there may be uncertainty about the state.
9. It should support human-human, machine-machine and human-machine communication.

I'd like a plan representation to:

1. allow for the specification of sufficiency criteria for determining when a goal (or objective) has been achieved to a sufficient degree that one can consider it done. Some goals don't really need a sufficiency criteria, for example, PUT A ON B has a clear criteria for achievement. However, other goals, such as "stop enemy incursion into southern region" do not necessarily need to be completely achieved. Our plan representation should allow one to specify how completely it is necessary to achieve a goal, or more precisely, it should allow for the specification of completion criteria that specify when the goal can be considered to be achieved.
2. allow for the representation of external actions, such as actions by adversaries or an external environment that are not under the control of the planner. In addition, we need to be able to create contingency plans that take into account these external actions that may hypothetically occur.
3. capture a plan's design. Specifically , I'd like a representation that could capture the plan that was chosen to achieve a goal, possible alternatives that might be feasible, other alternatives that may have been explored and either failed or were found to be infeasible. In all of these cases, I'd also like to have the reasons for selection, rejection and failure recorded. This kind of a representation is critical both to support replanning and to document plans and explain them.
4. support explanation and paraphrasing. In mixed initiative planning situations, human users must be able to understand a plan and easily modify it. Making a planning system understandable is not just a matter of adding on an explanation generator to some arbitrary plan representation. That approach tends not to work because the arbitrary representations fail to capture distinctions that are needed for good explanations. Providing good explanations is a pervasive concern that not only affects the explanation generator but also the underlying planning representation from which the explanations are generated. The goal here is to try to create representations for planning that reduce the gap between the computer representation and the way that human planners talk about the planning they do.

Stuart Moralee of Unilever has kindly provided me with his writeup of a 3 day workshop help at IBM in Nottingham, UK in April 1994. This was a meeting of the UK Enterprise Project partners to discuss the enterprise ontology for the project and to look in particular at existing ontologies and their potential contribution. The Enterprise project partners were Unilever, IBM, Logica, Lloyd's Register and AIAI. More information is available here.

The important part is the tables showing contributing ontologies and the list of ontology elements that the participants of the workshop felt the various contributions were particularily strong in. Take a look at the tables of contributions from the various ontological efforts like KADS, TOVE, ACT, KRSL, O-Plan TF, ORDIT, etc. It also lists required elements for an enterprise ontology as required for the Enterprise project.

• Workshop on Content, Form and Methods for Ontologies- May 1994, IBM, Nottingham, UK.

Classification of Objectives

Requirements for a Rich, Shared Plan Representation

ARPI Home Page | SPAR Home Page

Page maintained by Austin Tate (a.tate@ed.ac.uk), Last updated: Fri Apr 28 14:33:20 2000
Please make contact if you have any comments on these pages or the ARPI Plan Representation Project.