This report is a document of the MICA RTD program, task 18.104.22.168.F.realized 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.
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.
Summarizing, in this project we intend to attempt to the design of a prototype of the second type of IDSS.
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.
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.
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
. The IDA kernel which is based on the architecture framework of a personoid
is called Multi-agente, Its main architecture is illustrated on
Go to next chapter -> 4. Project Tasks ( and functioning of the IDA Kernel)