To provide user level, configurable task and process management aids
for inter-agent cooperation. Each user may have their own panel
to reflect their role in a cooperative process.
Inputs for the Process Monitoring Panel
(communicable and storable via XML formats
- Requirement - requirements which external agents request
that the process panel take responsiblity for. The sender may not
know the authority relationship to the reciver, so cannot assume it
will be acepted, and anyway, if accepted the receiver may not be able
to satisfy the requirement. A requirement may be expressed in
<I-N-C-A> form. This can have several elements which can be
stated separately or may be given together.
- "handle issue" requirements
- "perform activity" requirements
- "maintain constraint" requirements
- "note annotation" information
- Report - reports of various kinds:
- "direct reports" - which may be agent messages
providing inputs specifically informing the panel of some noteworthy
- "progress reports" - useful information (before, during (or after)
dealing with the item.
- "completion reports" - indicating success or failure
- "indirect reports" - via monitoring external sources of report
information provided throiugh plug-ins (see below).
- Domain Model - which can include:
- 0..N process specifications/fragments - with related
constraints/conditions, and issues for each process.
- 0..N process product specifications - including descriptions of
process product features.
- [possibly 0..N process product status life cycle transitions.
See Jessica Chen-Burger thesis and IBM's BSDM].
- 0..N mappings from agent monitoring "events" notified
explicitly or via plug-ins to the panel and:
- begin of execution of a process node/activity
- end of execution of a process node/activity
- change in a process product feature
- issue prioritisation rules to influence the controller.
- Monitors - 0..N external event monitoring plug-ins to
acquire externally communicated messages (e.g. as notified to agent
message logging services). The plug-ins provide these events on an
internal channel to be streamed in along with the explicitly notified
- Other - Process Panel designs beyond the monitoring aspects
(e.g. for active process coordination and control) will be given other
inputs related to other agent or process panel capabilities and constraints.
Process Panel Operations
A panel may be started up with a preloaded domain model, with issues it has
been asked to address, with activities it has been asked
to perform, and with constraints it has been asked to maintain.
Process specifications may include constraints/conditions (needed for
monitoring aspects) and effects (needed for control aspects).
These constraints and effects may be specified in terms of process
product features (often the process product status note). Other
constraints such as time, etc, may be provided. Process
specifications may also include "effects" which specify changes which
should be made to product features, etc.
Each process fragment that the panel knows about has an initial node
which is specified as "enabled" or "not enabled". This may be altered
at any time by a "process owner". A process must be enabled for an
instance of it to begin execution. Once execution starts, that
instance will continue until control returns to the initial node. If
the process is not enabled at that stage, processing can be suspended.
[Is this sufficient, or do we need preemptive termination of
process instances for our work?]
The initial node of each process is "orange" (ready to execute) if the
process is enabled, and red (not executable) if not enabled.
Process product features must include:
The process product features can also be extended to those features
specific to given product types... [feature name . feature value]
- Status (to reflect product life cycle)
- Content type
- Content [expressed as a URL?]
Process panels only accept responsibility for issues or activities
where there is a process that provides a capability to handle that
issue or there are known external capabilities for other panels they
can hand it to. But, they do not guarantee to be able to address the
issue or perform the activity when it is processed. If requested, they
will report the failure or achievement of the issue to the issue
Issues and activty requirements may contain information about
the intended performer of an issue, or may leave that to the panel.
Issues are likely to have the following fields:
Activities have the usual full structure allowed within I-X systems.
- Sender Id
- Issue Id
- Issue priority
- Issue verb or function
- Issue contents (perhaps defined by a grammar)
Short display format of contents perhaps deducable from grammar
- Annotations - first line being used for short display form
- 1..N methods by which the issue can be addressed
Some ideas for a sample issue viewer (one of the I-Views) is
Issues may be a requirement to execute a specific process instance -
The status of processes and process products may be tracked by using
direc reports, agent activity logs and partial information which can be
interpreted as indicating where we must be in one or more
processes being executed, and what status process products must
have at any stage. This can be done even where significant
information is missing.
Issues that are addressed by I-P2 panels should have a priority.
This could be as simple as low, medium and high, or could be very complex
with separate features and criteria.
It would be good to allow a panel user to
change the priority from the 3 levels available.
The intention is that our generic approach to process and task
management will allow the priorities of individual issues and
activities to be stated when an issue or activity is first defined, or
modified from agents outside the panel afterwards. We will also potentially
allow the controller of I-P2 to be influenced by a prioritisation
rules that themselves will be stated in terms shared with other agents
and systems (communicated through a shared ontology of such
Page maintained by email@example.com,
Last updated: Sat Mar 8 16:32:03 2008