A KNOWLEDGE PRODUCTION ARCHITECTURE | (ed.) Intelligent Agents for Data Mining and Information Retrieval

A system can be described from the following perspectives: (1) the function and structure of the system; (2) the relation and interaction of the system with its environment; and (3) the dynamics of the system. This section deals with the first two perspectives of a reference architecture used to build knowledge production systems:

The function of our knowledge production architecture is to consolidate knowledge created in an agent-coordinated interaction environment. The structure is hierarchical and is based upon interaction domains that we call knowledge marts , as described in this chapter.
Agent interaction in a mart fulfills the rules of the protocol described in this section, while the interaction between different marts is guided by the multilevel architecture of subsection "Multi-Level Architecture".

Knowledge Marts

Knowledge-producing agents usually operate within the boundaries of a knowledge domain that we call a knowledge mart . Such a mart consists of a distributed group of agents, whose purpose is to generate knowledge objects in a knowledge domain. The basic elements of a mart are:

A set of collaborative agents which can communicate in order to consolidate the knowledge that is being produced.
A multicasting transport support that guarantees the reliable delivery of messages to every member in the mart.
An interaction protocol that governs coordination between agents.
An interaction policy that defines the kind of relationship established between agents, which may be mainly competitive or cooperative.
An ontology to represent domain-level knowledge that is produced by agents affiliated with the mart.

Knowledge Consolidation

Agents in a mart should coordinate their interactions with the aim of consolidating the knowledge that is being generated. Consolidation is the establishment of knowledge as accepted by every agent in the mart in such a way that every agent in the group eventually knows about it. The knowledge body is built through the progressive consolidation of proposals, which then become knowledge.

Interaction between agents is carried out by exchanging proposals in a FIPA-like common language (FIPA, 1999) that is driven by the participants ' goals and needs, therefore shaping a social interaction-level knowledge (Jennings & Campos, 1997). By proposal , we mean each formulation act of an agent that intends to consolidate a given knowledge in its group. Since a proposal exhibits an intentional nature, we will not refer to it as fully-fledged knowledge until it becomes consolidated. An agent may be involved in several simultaneous interaction processes. The protocol described below is used to advance each interaction process by executing it in a separate thread.

Multi-Level Architecture

In our architecture, knowledge-producing agents can operate within the boundaries of a specific domain or knowledge mart, as shown in Figure 1. Nevertheless, interaction among different domains is also supported through a number of proxy agents. In order to facilitate interaction between domains, marts can be structured in a hierarchical way. In this architecture, domains are modeled as knowledge marts, and these are arranged into knowledge warehouses , in a similar way to data warehousing systems. A knowledge warehouse is the place where knowledge consolidated in foreign marts is merged in a structured fashion.

Figure 1: Multilevel Architecture of Marts for Knowledge Production

Two or more marts can interact using representatives in a common warehouse. When knowledge produced in a mart can affect performance in some other domain, a special proxy agent can act as a representative in the foreign mart so that interaction between marts is not tightly coupled .

In this hierarchical structure, when a mart sets up a proxy agent in another higher-level mart, a participative relationship is defined between both marts, since agents in the lower-level mart can have influence in production tasks carried out in the upper one.

Agent Interaction in a Knowledge Mart

The minimum requirement to interact is that agents can build and deliver proposals, which can be accepted or rejected. An example is the contract net protocol (Smith & Davis, 1981). The protocol is more sophisticated when recipients have a chance to build counterproposals that alter certain issues that were not satisfactory in the original proposal. A more elaborate form of interaction allows parties to send justifications or arguments along with the proposals. Such arguments indicate why proposals should be accepted (Sycara, 1990).

Interaction between agents is carried out by exchanging proposals in a common language, or ACL (Agent Communication Language) (Mayfield et al., 1995). Proposal interchange is directed by the goals and needs of participating agents. Although the formalization of agents' language and goals is not our concern, we need to assume a set of conventions:

Agent rationality is modeled in terms of preference relationships , or relevance functions , in order to allow agents to evaluate and compare proposals. Nevertheless, other preference structures can be easily integrated, e.g., linguistic- expressed preferences (Delgado et al., 1998).
Relevant aspects of the interaction can be modeled as issues and values that change as the interaction progresses. This is not despite of more powerful, ontology-based possibilities to represent the same aspects (Gruber, 1991).
Concerning our protocol, the following types of messages can be exchanged between agents:
- propose ( k, n ): Given an interaction process n , an agent sends a propose message to inform the rest of agents about its desire for a piece of knowledge k to be consolidated.
- consolidate ( k, n ): Agents send a consolidate message when they want a previously submitted proposal k to be consolidated in an interaction process n .

Both types of messages can be respectively identified with propose and inform declaratives from FIPA ACL specification (FIPA, 1997). Nevertheless, since FIPA ACL provides them with a well-defined semantics ” especially different in the case of consolidate ” we prefer to use the types of messages recently described.

A proposal reflects the intention of an agent to generate a given knowledge that was previously formulated. The attributes of a proposal are elementary criteria that should be considered when comparing it to another in a mart. Some examples of proposal attributes are:

The submitter's hierarchical level, useful when agents present different decision privileges in the mart about the acceptance of proposals (e.g., lecturer vs. assistant in a faculty staff).
The degree of fulfillment of a set of goals. For instance, before the development of a learning content, a set of educational objectives should be defined. In the case of corporate learning, these goals will be determined by the training needs of the organization.
A time-stamp of the moment when a proposal was first submitted in the mart (this is normally considered in the last case, when the rest of attributes cannot decide).

We define the relevance of a proposal as the set of proposal attributes that are considered in fact during a message interaction. In order to measure the relevance of a proposal, a relevance function can be defined.

The relevance function u(k) of a proposal k in a mart returns a numeric value, dependent on attributes of k , in such a way that, if k _i ‰ k , then u ( k _i ) ‰ u ( k _j ). A way to express the relevance is by means of preference relationships , where a proposal k ₁ is preferred to another k ₂ in a mart, denoted as k ₁ > k ₂ , if u ( k ₁ ) > u ( k ₂ ).

Interaction Protocol

An agent A _i may participate in several interaction processes. Each interaction process is handled separately by initiating a new execution thread of the protocol, as depicted in the following algorithm:

Algorithm: Let A _M ={ A ₁ , , A _n } be a discrete set of agents participating in a knowledge mart M .
Start: When A _i wants a knowledge piece k to be consolidated in M , it sends a propose ( k _i , n ) to every agent in M , initiating a new interaction process n . Then, A _i sets a timeout t before confirming its proposal. During t , messages can arrive from any other agent A _j , with j ‰ i , consisting of new proposals ” maybe the original, though modified ” referring to the same interaction process n .
Rule 1: If A _i does not receive any message referred to n during t , it considers that there is no agent against its proposal. It tries to ratify it by sending a consolidate ( k _i , n ) to every agent in M . At the same time, A _i starts a new timeout t ₁ .

Rule 2: When A _i receives a propose ( k _j , n ) message from other agent A _j , referring to the same interaction process n, A _i evaluates the new proposal k _j . If k _i < k _j , then A _i sets a new timeout t ₁ , waiting for proposal k _j to be ratified. Then, A _i proceeds as follows :

2.1	If A _i does not receive any proposal referred to interaction process n before t ₁ expires , then A _i initiates the protocol again with the same proposal k _i .

2.2	If A _i receives a consolidate ( k _j , n ), with k _j > k _i , for j ‰ i , before t ₁ expires, and referring to the same interaction process n , then A _i gives up the initial proposal and the protocol finishes unsuccessfully.

2.3	If A _i receives a new propose ( k _j , n ), with k _i < k _j , it extends the timeout t ₁ .

The interaction protocol described above uses two message types (i.e., propose and consolidate ), but some variants using additional message types to express different semantics can also be formulated ” e.g., retract, substitute or reject . These types of messages can speed up the development of the protocol, but they are not completely necessary for the success of the consolidation process.