I-X: Technology for Intelligent Agents & Tools Systems Architecture Overview

Work in Intelligent Planning and Activity Management at the University of Edinburgh (See http://www.aiai.ed.ac.uk/project/plan/) has led to a number of significant assets that are re-used on a number of projects. These assets include: Nonlin, O-Plan, <I-N-OVA>, Enterprise Ontology, Enterprise Architecture, Task Manager, O-P³ Process Panels, Common Process Editor, etc. A new generation of the work will drawn on this work, generalise it, and significantly extend the application of the core concepts and assets, leading to new re-usable components, and create opportunities for applications and further research.

This new programme is called I-X and the core components are a shared model representation called <I-N-CA> and a systems integration architecture called I-Arch. A variety of re-usable components and systems will be build on the new architecture and these will be collectively referred to as I-Technology and I-Tools.

I-Arch is pronounced "Eye Arch". "Arch" stands for "architecture". The "I" in I-X, I-Technology and I-Arch reflects the following:

• Intelligent - I-Arch supports the construction of intelligent systems and intelligent agents
• Integration - I-Arch is a systems integration architecture
• Issue-based - I-Arch is an issue-based and issue handling architecture

The I-Technology programme has 5 aspects:

1. Systems Integration - A broad vision of an open architecture for the creation of intelligent systems for the synthesis of a result or "product" which is based on a "two cycle" approach which uses plug-in components to "handle issues" and to "manage and respect the domain model".
2. Representation - a core notion of the representation of a product as a set of nodes making up the components of the product model, along with constraints on the relationship between those nodes and a set of outstanding issues - <I-N-CA> - Issues, Nodes, Critical Constraints and Auxiliary Constraints.
3. Reasoning - the provision of reusable reasoning and model management capabilities.
4. Viewers & User Interfaces - to understand user roles in performing activities and to provide generic modules which present the state of the process they are engaged in, their relationships to others and the status of the artifacts/products they are working with.
5. Applications - work in various application sectors which will seek to create generic approaches (I-Tools) for the various types of Task in which users may engage.

The components of I-Arch are as follows:

• Task and Option Management -- The capability to support user tasks via appropriate use of the processing and information assets and to assist the user in managing options being used within the model.
• Model Management -- coordination of the capabilities/assets to represent, store, retrieve, merge, translate, compare, correct, analyse, synthesise and modify models.
• Issue Handlers -- Functional components (distinguished into those which can add to the model (synthesis) and those which analyse the model (to add information only).
• Constraint Managers -- Components which assist in the maintenance of the consistency of the model.
• Information Assets -- Information storage and retrieval components.
• Viewers -- User interface, visualisation and presentation viewers for the model - sometimes differentiated into technical model views (charts, structure diagrams, etc.) and world model views (simulations, animations, etc.)
• Mediators -- Intermediaries or converters between the features of the model and the interfaces of active components of the framework (such as viewers, processing assets, constraint managers and information assets).

A number of different types of "sockets" are available within the framework to reflect the protocols or interfaces into which the various components can fit. The necessity for specific sockets and the types of components vary across projects to some extent, but the separation into viewers, processing assets, constraint managers and information assets has been found to be useful in a number of AIAI projects. This also puts the I-X work on a convergent path with other Model/Viewer/Controller styles of systems framework.

<I-N-CA> Ontology

I - Issues (Implied Constraints)

- which may add an "include node" constraint
- which will not add an "include node" constraint

N - Node Constraints

- include node constraints
- other node constraints

C - Critical Constraints

E.g., if the artifact is an activity plan:
O - Critical Ordering Constraints
V - Critical Object or Variable Constraints

A - Auxiliary Constraints

E.g., if the artifact is an activity plan:
O' - Non-critical Ordering Constraints
V' - Non-critical Object or Variable Constraints
X - eXtra constraints (such as):
- Authority Constraints
- World State Constraints
- Resource Constraints
- Spatial Constraints
- Miscellaneous Constraints

Addition needed here about "yes, no, maybe (in terms of critical constraints)" responses from constraint managers.

Issues can be categorised as to whether they will, may or will never add a "node". The I constraints which can lead to the inclusion of new nodes are of a different nature in the planning process to those which cannot.

The choice of which constraints are considered critical is itself a decision for an application of I-X and I-Arch. It is not pre-determined for all applications. A temporal activity-based planner would normally have objects/variable constraints (equality and inequality of objects) and some temporal constraints (maybe just the simple before(time-point1, time-point-2) constraint) as the critical constraints. But, in a 3D design or a configuration application object/variable and some other critical constraints (possibly spatial constraints) might be chosen. It depends on the nature of what is communicated between constraint managers in the application of the architecture.

A number of concepts are being used as the basis for exploring task orientated multi-agent and mixed-initiative work involving users and systems. Together these provide for a shared model of what each agent can and is authorised to do and what those agents can act upon. The concepts are:

1. Shared Object/Product Model -- a structured representation of the object being modelled or produced using a common constraint model of the object or product (<I-N-CA>).
2. Shared Planning and Activity Model -- a rich plan and activity representation using a common constraint model of activity (<I-N-OVA>, itself a specialisation of <I-N-CA>).
3. Shared Task Model -- Mixed initiative model of "mutually constraining the space of objects/products" - also using <I-N-OVA>.
4. Shared Space of Options -- explicit option management.
5. Shared Model of Agent Processing -- handlers for issues (functional capabilities) and constraint managers - described using <I-N-OVA>.
6. Shared Understanding of Authority -- management of the authority to do work (to handle issues) and which may take into account options and levels of abstraction of the model of the object or product.

In particular, this work will carry forward the development of a strong systematic ontology to underpin the models of processes and activity - including continuing to engage in and promote its use as a basis for standards. The work will draw on the initial efforts to create an ontology suitable for the conceptual description of all apsects of an organisation - the Enterprise Ontology and on the development of a constraint model of activity <I-N-OVA>. The work will promote the aim that PIF, NIST PSL, OMWG CPR and SPAR all converge on a single core model of activity based on <I-N-CA>.

Development Areas

1. Characterisation of the separate components of a single I-X agent to establish what features each has and how they should differ. Establish whether the a priori view on the separate com pone ts is desirable.
2. Initial Java encoding experiments to establish that the envisaged plug-in framework is feasible and to experiment with different approaches.
3. Consideration of how to describe plug-in components. This is envisaged as being in the <I-N-CA> ontology, reified in Sorted First Order Logic and storable in XML/RDF.
4. The provision of an ontology for issues and issue handler descriptions for some sample applications of I-X: (e.g. I-Plan, I-Config).
   • A very simple initial application of I-X fully worked through (factorial computation).
   • A simple, but realistic application of a mainly man ual use of I-X (user level process managment and collaboration support).
   • A DERA-related sample application, possibly based on Coalition Operations.
   • Other sample applications of I-X (e.g. I-Plan, I-Config).
5. Consideration of how to describe the design, architecture and implementation. Possible use of UML models.

• Java encoding limitations and opportunities
• Delivery of any user interfaces on multiple platforms via suitable web browsers.
• Use of XML/RDF to store intermediate results passed between suitable agents and componen ts and to assist in storage of those components in a form which can be retrieved and used.
• Design to allow for the resulting components to be repackaged and re-used as embeddable components in a wide range of orther systems.

• Presentation (about product/artifact and process)
  • Visible indications of users' workflow state
  • Multiple views tailored to user role, information type, etc.
  • Selection of what information to display.
  • Views (e.g. tables) that facilitate comparison.
  • Summary form with drill-down /expansion to details.
  • TechWorld Viewers
  • Colour-coding of status
  • Colour choice principles
  • Layout principles
• Multi-user cooperation
  • User roles (as distinct from physical users)
  • Mixed-initiative
  • Authority
  • Workflow
  • Issues (explicit representation and tracking of)
• Delivery (of applications, e.g. on Web)
  • Portable
  • Standards (XML/RDF markup)
  • Familiar interfaces (e.g. Browsers)
  • Low bandwidth use (e.g. cellular phones, WAP, PDA)
  • Reusable frameworks and modules
  • Embeddability
• Workflow
  • Workflow of using the system itself (hence meta-workflow in workflow tools)
  • Process Issues
• Openness
  • An architecture / framework
  • Plug-in concept and implementation support
  • Plug-in Issue handlers, Artifact analysers, Constraint managers, TechWorld viewers
• Scenarios
  • Emergency or Unfamiliar Procedure Assistant - Context sensitive Cell Phone or web access to procedural assistance
  • Multi-national Coalition Operations
  • IRC in AKT testbeds
  • e-Science testbed

Motivation for I-X

• Human-friendly representations of plans for human communication and cooperation, as well as man-machine interaction in areas such as mixed initiative planning.
• Plan and activity representation ontologies and their potential to assist in the knowledge acquisition and knowledge management process.
• Plan representations well suited to storage and for use in markup languages such as XML.
• Plan representation languages which are also suitable for use to represent the planning (task setting, planning, scheduling and execution) process.
• Bringing AI plan and agent capability description experience into practical use.
• Relationship to emerging standards (NIST PSL, ISO, WfMC, etc).

Standards Efforts related to Plan Representations

The DARPA sponsored Process Interchange Format (PIF) group, an Object Model Working Group (OMWG) Core Plan Representation effort, the Shared Planning and Activity Representation (SPAR) work and other efforts have led to a high degree of commonality in the models adopted. The National Institute for Standards and Technology (NIST) in the US brought some of these threads of separate work together and created a collaboration which has led to the Process Specification Language (NIST PSL) [See http://www.nist.gov/psl/ for more details of NIST PSL]. For references to this work, some of the history and relationships between earlier work in AI on plan representations and the standards bodies, and the part that \inova played in this see Tate (1998).}. NIST PSL uses the PIF core model at its heart and has a formally specified core semantics. <I-N-OVA> and <I-N-CA> are compatible with the approach taken in the PIF Core and therefore NIST PSL.

[This paragraph is a report provided in a personal communication from Craig Schlenoff who led the NIST PSL program from its inception through to February 2000.] In late 1999, at an International Standards Organization (ISO), Technical Committee (TC) 184, Subcommittee (SC) 4 standards meeting in Lillehammer, Norway, a resolution proposing the Process Specification Language (PSL) work as a Preliminary Work Item (PWI) was approved. The PWI is the first stage of the standardization process, in which countries who are interested in the work come together to further pursue the work. TC184 focuses on industrial automation systems and integration while SC4 specifically focuses on standardization of information which is shared or exchanged in the area of industrial and manufacturing applications.