This document was written when it was proposed that ISX's ACPT tool should act as the systems integration Framework for IFD-5, as it had done for IFD-4. The concepts here will work equally well in other systems integration frameworks in which explicit ACP process management is undertaken in some sort of system controller module or agent.
ACPT contains an agenda in its Control Panel which is used to help the user maintain a perspective on the planning process and to get support for carrying out that process. Items on the agenda have a regular but easily extendible format which allows for ACPT to know when their triggering applicability conditions are met. A user can manually pick one (or more in later potential extensions) triggered items off the agenda and have ACPT pass these with appropriate parameters to a tool or user interface/editor which is registered as being a capability which can handle that agenda item. System tools or the user may (if registered to do so) post additional items to the agenda to allow the planning process to be continued with the same or other tools or users involved.
The MIP Framework is intended to support a very simple implementation of the concepts of ACP Process Workflow Support. But it is designed so that extension along a number of dimensions of sophistication is possible, depending on the technology demonstration options which present themselves within ARPI.
The MIP Framework will link into and draw on work being conducted by three clusters within ARPI: Collaborative Planning Cluster (for the ACP Tool Capability Models); Modelling Cluster (for the ACP Process Model and ACP Process Verbs); and the Plan Ontology Cluster (for the ACP Plans and ACP Process Products terminology).
Example Process Product Features for ACP
The terminology used for the military action related ACP Plans themselves is confined to the contents of Process Products. This the subject of the ACP Plans Model being developed by the ARPI Plan Ontology Construction Group (POCG Cluster) [Hoebel, Valente, Q396].
Although the planning process involves activities and their coordination, these are described in terms of the activities which take place in the planning process itself (such as plan, change, review) rather than containing activities that relate to military effects (such as destroy, seek-out). The planning process activities can be described using a set of "process verbs" indicating the actions performed at that level. A separate paper has been produced on the ISAT project giving an initial list of process verbs for the ACP Process [Drabble and Lydiard, Q296].
A description of the ACP Process Products and their Features has been created on work under WP2 of the ISAT Subcontract at AIAI [Drabble, Lydiard, Tate, Q396].
A common underlying model of activity may be used for both the planning process and the ACP plans themselves. In particular, the process products are modelled as resources which are created, modified and used within the process. Authority relationships and other conditions are also able to be modelled and may be used in an extension of the basic mechanism if that is wanted eventually. This is the subject of the POCG KRSL-Plans ontology [Tate, Q295], the Process Interchange Format [PIF Group, Q296], the wider-scope Enterprise Ontology [Uschold, Q395] and the more recent OMWG and JTF ATD Core Plan Representation [Pease, Carrico, Q496.
Finally, all terminology used in each model will be available and defined in the ACP Domain Lexicon being built on the ACP Sensus Ontology [Swartout, Q396].
source agent always known
destination agent may or may not be specified
verb ACP Process Verb
noun phrase(s) Process Products
[ qualifier(s) ] Features of Process Products
[ trigger(s) ] Features of Process Products,
[ inter-agenda item ordering ]
[ inter-agent authorities ]
where [ ] indicates the component is optionalThe source and destination agents are agents (people or systems) which can play a certain role within the ACP Process.
Triggers are often on features of the planning products which flow in the ACP Process (such as the availability of a specific document at a given level of release or given level of refinement of its contents).
Triggers may also relate to ordering constraints between agenda entries. I.e., some later agenda entries may only be performed once earlier agenda entries have been handled. It is possible to avoid the need for inter-agenda ordering triggers if the process products' features are designed such they support all process step ordering requirements. A number of commercial workflow systems make the assumption that document or process product flow itself is sufficient as a basis for triggers.
One way to fill triggers is via "inter-agent authorities". In a well regulated environment, the process products themselves contain all necessary inter-agent authority information, and thus this extension is not needed.
This can be very simple at first, just containing a set of process verbs which an agent can handle, perhaps augmented by some simple constraints on the noun phrase(s) and qualifier(s) that can be handled.
However, more sophisticated extensions are possible for a greater level of intelligent workflow and mixed initiative support in future.
These could include:
ACPT Tool/Agent Registry - used to describe a planning tool, user editor, or ACPT component which can be used to address the issues on the agenda. It is registered in terms of:
Including the specification of the destination agent which a tool/agent is allowed to post agenda entries for will allow control over the workflow process. For example, some tools may post entries for other systems, but only "trusted" tools or levels of agent may post directly for the user as a destination (so we do not get "delegation upwards").
"??" will be allowed if no identified destination agent is known. This would indicate that ACPT should find a suitable destination agent, perhaps with the user selecting amongst any options available.
The initial selection would be loaded as a set of agenda items in the required form, and with suitable triggers, into the agenda during the initialization of the agenda/workflow support system.
Triggering mechanism: to be able to monitor a set of agreed features of process products (as attributes of objects representing those products), and to use these to indicate when agenda items waiting for those triggers are satisfied. The user interface may "grey out" non-triggered agenda items or present these in some suitable way.
Planning Tool Registry: a mechanism to register planning tools or user editors by recording the agenda items which they can process, and perhaps other information in extensions to the basic mechanism.
Agenda Entry Registry:t may be advantageous to have an explicit way to register the legal agenda entries in the form of a grammar. This would allow more active workflow management and inter-tool checks.
Common Tool/Agent Call Interface: a way to allow a planning tool or a user editor or interface to be called by passing it one (or more in extended variants) agenda entry and relevant parameters (mostly in terms of process products such as documents in the ACPT Plan Server).
The Mixed Initiative Planning and Agenda Framework presented provides the underpinning to support all these models. It can be used very simply, or is capable of expansion to a rich "Intelligent Workflow Planning and Execution Support" framework. Expressed needs in the JFACC programme and in the DARPA Collective Action Tools Community to allow for reasoning about time schedules and resource levels in the planning staff could be supported. Delegated authority to people performing given planning roles and systems or tools which can carry out given roles is possible.
O-Plan, acting as an ACP workflow planner, would be called on the indicated agenda entries and would be handed the current workflow "plan" (the current set of agenda entries) and "state" (the present values of the features of the process products in the ACPT "plan features server") via the ACPT controller. It would return additions to the agenda, normally in terms of a replacement set of agenda entries for the one(s) it was passed. This basic demonstration could open the possibility of reasoning about planning resources and time scales in the planning process itself.
It could be advantageous to be able to return "compound agenda entries" (inter-agenda item orderings) at the ACPT workflow level (these are just partially ordered workflow activities to O-Plan). But this will depend on this being a feature known to the workflow core of ACPT.
It may be possible to include O-Plan in IFD-5 or working alongside it as a demonstration in this role.
O-Plan could be included within IFD-6 in this role. [O-Plan project deliverable A-0 - the ACP domain demonstration story board - proposed ACP planning capabilities which may be suitable for an IFD-6 demonstration].