PROPOSAL, 1 June 1997   
<- Go to Index
IDA (Intelligent Decision Advisor)
Adam Maria Gadomski

1. Introduction

This report is a document of the MICA RTD program, task under umbrella of MINDES-GEMINI Program. It is a result of long technical debates in the TISPI Sector of ENEA, and it takes under consideration various written and oral opinions presended by the project participants, as wall as, obtained from the potential external partners of the project: IRST and Universita "La Sapienza"(DIS). The basic literature references are the previous ENEA publications elaborated from last 8 years (focused on the problems of IDSSs), the recent proposal document "IDA: General Functional and Structural Requirements and current publications in the subject matter [ references ] This document can be modified and perfectioned yet.

2. Methodology Motivation

In general, in this type of projects it is possible to attempt to the realization of two alternative kinds of IDSSs. The first is focused on a specific application domain, such as in the previous ENEA's projects:  MUSTER , GEO, Civil Protection,. The second-kind of these systems is a shell, where specific application domains can be inserted by its user as a some class of generalized and specific data, using predefined forms (templates).

The first-kind IDSS is mainly based on the application of domain-focused available technologies, it doesn't need many separated levels of abstraction, its prototypes are usually constructed bottom-up, in parallel to the knowledge and information acquisition from domain experts.

Here, the conceptual design framework is based on a typical human process composed of: recognition of a function necessary for the designed system, its specification, and its implementation performed together with other requested functions, constructed in the same way. In such approach, it is possible to identify DataBases, Rule Bases or Procedure Bases, common for some groups of functions but their structures and main algoritms' architecture are specific to the application case.



The "intelligence"of the system is, a behavioral intelligence. It is based on a connection of various role-dependent mental functions of a domain operator, which is possible to formalize and to manage by various strategies.

End-user point of view: The effort of the developers of the first-kind IDSS is mainly concentrated on the best realization of every function, i.e. by using ever more perfectioned methods. Unfortunatelly, the development of sofisticated methods needs ever more data an more knowledge from the domain experts. Usually, the methods are developed independently on the end-users' requirements and on their possibilities to provide necessary data.

At a consequence, we can observe frequent incomprehention between designers and end-users.. On the one hand, the designers of ambitious first-kind IDSSs are hardly concentrated on perseqution of end-users to obtain more and more data, preferibily just formally specified in abstract terms which they don't known. On the other hand, frequently, the end-users consider designers as low efficient and not trustfull. As the result, we have numerous interesting and promissing advanced prototypes, and quasi no really working applications.

We should stress that one of the basic sources of misunderstandings is the fact that the designers/knowledge-engineers acqust knowledge rather from domain-experts and not from domain-managers.- Here, we should recall that the main objective of our IDSSs is a decision support on the managerial level. Unfortunately, the managers have no time to give technical interviews.

On the contrary to various office sofware systems, IDSSs are destinated to the management of high-risk technological domains. Their end-users need to know exactly the competence domain of the system. In its range, the manager must be sure of the completness and congruence of the IDSS knowledge.

A real usability of the IDSS systems requires the transparence of its functioning and a machanizm of conflict resolution between various functions - these aspects are not yet attempted by the designers of the first-kind IDSS.

The second-kind of IDSS is an attempt to construct a system which could be intelligent independently on the possessed domain knowledge. It should have structural intelligence which is obviously, different than the behavioral one. The behavioral intelligence only exists if is visible, the structural can sometimes be visible.

In order to speak about such approach it is necessary to introduce a new ontology which enable reconceptualize some basic terms currently used in AI, such as knowledge and information. In general, we need to introduce a formal conceptualization framework on high abstraction levels of the system specification. Here, we consider to use the architecture of abstract intelligent agent(AIA). The idea of such model has been proposed first time by Gadomski (1990) where a distingtion between such concepts as: information, preference, and knowledge of an abstract simple agent has given.

The key assumption of this approach is a separation of the concepts: intelligence, knowledge and sapience. They are independent, and all of them are necessary to construct an abstract intelligent agent which could elaborate action-oriented decisions in intelligent (behavioral) manner.

In the contrarry to the first kind IDSS, here, the structure of the decision-making kernel is not divided accordig to its functions/tasks. The same structural element of the system executes many various functions according to the current AIA preferences, knowledge and available information (IPK). In the IPK personoid  architecture, an explicite division on the agent functions does not exists, what is illustrated on the Fig.2. The main "tasks" of a meta-function is a modification of the possibilities of a function located on the low level.

  Fig. 2


Roughly, we can confront the repetitive architecture of such system with domain-independent Data Base Management systems where data structures are substituted by preferences, knowledge and information bases, as well as, they are connected with domain-independent reasoning engines.

End-user point of view: The utility of the second kind IDSS increases proportionally to the quality of the inserted knowledge and preferences, what, from the begining, can be well visible for the end-user.

Knowledge and preference acquisition process will be incremental, easy modificable, and their insertion to the system will be performed with the direct participation of the end-user and domain-experts according to their needs.

The system can use many specific methods, as planning, learning and preference management, starting from a simplest version/configuration. In this way the "professionality" of the intelligent advisor can grown continously and it depends only on the real requests of the end-user, and on the knowledge possesed by domain-experts.

The main advantages and disadvantages of the both kinds of IDSS are presented in the table below.

  • application of existing higher-level software development tools
  • implementation of the requirements in the end-user terminology
  • incremental construction without initial architecture specification
  • possibility to realize and easy to demonstrate detaliated separated end-user functions
  • possible to the realization by one ambitious small computer industry.
  • application of quasi-domain-independent terminology and conceptualization tools
  • strongly reusable-technology for various emergency-domain management
  • new manager role specialization: incremental and easy modyficable
  • transparent for the diagnostics, software safety & reliability analysis
  • minimal domain-dependent knowledge acquisition during development phase
  • flexble for the end-user modifications, such as, role dependent: preference and knowledge
  • robust on unexpected queries in frame of the predefined competence.
  • Disadvantages 
  • strictly domain-dependent in the terminology and supported tasks specification
  • low modular reusability
  • requires detailed role specialization in the phase of system specification, i.e. initial detailed knowledge acquisition
  • difficulty with transparency for the diagnostics and software safety & reliability analysis
  • possible unexpected reactions on not foreseen end-user queries/actions
  • Especially, they are related to the design of the system shell:
  • requires a new repetitive modular architecture of an abstract intelligent agent.
  • application of low-level software development tools
  • strongly research enterprise where the cooperation between various software specialists is very desirable according to knowledge-engineering methodology
  •  the final utility of the system depends on the quality of applied reasoning methods.
  • Constrains
    of the Project management
    and time

    In order to divide tasks between project partners  a detailed knowledge acquisition phase (with the end-user and domain experts) must be finished.
    It mainly depends on the project management 
    decisions related to the number of end-user functions accepted for design, and their complexity.
    In order to divide tasks between project partners  a meta-functional architecture of the system intelligent kernel (sufficiently clear for all partners) is necessary.
    It mainly depends on the decisions related to the accepted compexity of the followig components:
    -complexity and efficency of reasoning engines
    - complexity of the domain-dependent test case.

    Summarizing, in this project we intend to attempt to the design of a prototype of the second type of IDSS.

    Such choice requires a common definition of a meta-functional architecture of the IDA intelligent kernel,
    and the choice of the necessary reasoning engines.

    Of course, in order to satisfy the IDA requirements (the second kind of IDSSs) multi-agent frameworks other than AIA architecture, can also be discussed.

    Up to now, in the next chapters we accept the IPK cognitive architecture and its top-down design methodology as a conceptual framework for the project and the system development.

    3. Initial Assumptions

    0. IDA (Intelligent Decision Advisor) is a proposed name for a selected class of the second type emergency managers IDSS.

    1. IDA must be a demo of an emergency management IDSS, and require a concrete test-case.

    2. The main objective of IDA is to suggest an intervention as a consequence of a new situation in the domain of activity of emergency manager.

    This main IDA activity is an action-oriented decision-making.

    3. IDA architecture is composed of the classical and agent-based functional elements which are shown on the Fig.3. On this figure the suggested responsabilities distribution between the project partners (ENEA, IRST, SAPIENZA) are indicated.

    .  Fig.3


    4. The kernel of the system is a multi-monad (multi-agent structure) module and it produces alternative decisions.

    5. For the distinguishing this IDA kernel system from other numerous agents and intelligent agents ,known from the subject matter literature, and from other possible Abstract Intelligent Agents, this one is called personoid . The IDA kernel which is based on the architecture framework of a personoid is called Multi-agente, Its main architecture is illustrated on the Fig.4.



    Go to next chapter -> 4. Project Tasks ( and functioning of the IDA Kernel)