I-Face and I-View Notes

I-X Home | Work Area
General | I-View | I-Face | Panels | Communications | Misc | People

General notes

I-View things

A viewer will have: To provide user level, configurable task and process management aids for inter-agent cooperation.

Panel things

Inputs for the Process Monitoring Panel

(communicable and storable via XML formats where appropriate)
  1. a stream of agent messages providing inputs specifically informing the panel of some noteworthy events.
  2. a stream of "issues" which external agents request that the process panel take responsiblity for.
  3. 0..N process specifications/fragments - with related constraints/conditions, and issues for each process.
  4. 0..N process product specifications - including descriptions of process product features.
  5. [possibly 0..N process product status life cycle transitions. See Jessica Chen-Burger thesis and IBM's BSDM].
  6. 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 event stream.
  7. 0..N mappings between agent monitoring "events" notified explicitly or via plug-ins to the panel and:
  8. Others... Process Panel designs beyond the monitoring aspects (e.g. for active process coordination and control) will be given other inputs related to agent capabilities and constraints.

I-Face things

generic I-Face things are:

Task Matrix issues

rows and columns of cells (check out word tables for structure and operation, layout, style)

Graph related issues

draw boxes and lines on a canvas

Product related issues

display a list of products and their properties

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]

Issue list issues

display a list of issues and their properties.
Things happen when you click on issues or their properties (e.g. hyperlink to more detail)

Issues 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:

Some ideas for a sample issue viewer (one of the I-Views) is here.

Issues may be a request to execute a specific process instance - execute(process, parameters).


Communications of process models are done pragmatically within a panel. External/clean communications of process models are always in XML (also storable stuff for the process library!)

let people write their own in/outputters  for their own formats

what about communications about process models?

Things to think about

Process specifications may include constraints/conditions (needed for monitoring aspects) and effects (needed for control aspects later). 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 feqatures, 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 panels only accept responsibility for issues where there is a process that provides a capability to handle that issue. But, they do not guarantee to be able to address the issue when it is processed. They will report the failure or achievement of the issue to the issue provider though.

The status of processes and process products may be tracked by using events, 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.


Planning & Activity Management | I-X
AIAIPage maintained by j.stader@ed.ac.uk, Last updated: 19/1/01