Artificial Intelligence Applications Institute
The University of Edinburgh, 80 South Bridge, Edinburgh EH1 1HN, UK
Tel: +44 131 650 2732 Fax: +44 131 650 6513 Email: email@example.com
Two papers describe the approach:
In Tate (1996), the <I-N-OVA> model is used to characterise the plan representation used within O-Plan and is related to the plan refinement planning method used in O-Plan. The <I-N-OVA> work is related to emerging formal analyses of plans and planning. This synergy of practical and formal approaches can stretch the formal methods to cover realistic plan representations as needed for real problem solving, and can improve the analysis that is possible for production planning systems.
<I-N-OVA> is intended to act as a bridge to improve dialogue between a number of communities working on formal planning theories, practical planning systems and systems engineering process management methodologies. It is intended to support new work on automatic manipulation of plans, human communication about plans, principled and reliable acquisition of plan information, and formal reasoning about plans.
A plan is represented as a set of constraints which together limit the behaviour that is desired when the plan is executed. The set of constraints are of three principal types with a number of sub-types reflecting practical experience in a number of planning systems.
Plan Constraints I - Issues (Implied Constraints) N - Node Constraints (Activity Constraints) OVA - Detailed Constraints O - Ordering Constraints V - Variable Constraints A - Auxiliary Constraints - Authority Constraints - Condition Constraints - Resource Constraints - Spatial Constraints - Miscellaneous ConstraintsThe node constraints (these are often of the form ``include activity'') in the <I-N-OVA> model set the space within which a plan may be further constrained. The I (issues) and OVA constraints restrict the plans within that space which are valid. Ordering (temporal) and variable constraints are distinguished from all other auxiliary constraints since these act as cross-constraints, usually being involved in describing the others -- such as in a resource constraint which will often refer to plan objects/variables and to time points or ranges.
Workflow ordering and priorities can be applied to impose specific styles of authority to plan within the system. One extreme of user driven plan expansion followed by system ``filling-in'' of details, or the opposite extreme of fully automatic system driven planning (with perhaps occasional appeals to an user to take predefined decisions) are possible. In more practical use, we envisage a mixed initiative form of interaction in which users and systems proceed by mutually constraining the plan using their own areas of strength.