The high-level architecture of a multi-agent system (MAS) for knowledge integration described in this section is an attempt of characterizing a KM system in the spirit of the DIP. We use MAS because, in our view, agents are the most promising technology for realizing distributed systems whose components are to be autonomous and pro-active, and show social abilities. In the present section, we assume some familiarity with MAS; a recent handbook on theory and practice of MAS is [22].
The architecture, called KI-MAS, is described in figure 1. It has four macro-levels:
Knowledge Centers (KC). A KC is a knowledge source which represents knowledge that is produced and used by a professional community. In principle, it could be anything, from databases to human operators. In our case study, each KC is a taxonomy of documents, such as papers, internal reports, mail messages, transparencies, automatically generated by an application running on top of Lotus Notes. A KC is viewed as a context where knowledge is managed (i.e. produced, represented, organized, maintained, validated, updated).
Wrappers. The level of wrappers provides the service of software integration. According to FIPA's specification standards, wrappers are agents that interface non agent-based software with a MAS. Basically, they have two components: on one side, they know ``how to talk'' with the software they wrap; on the other side, they know hot to translate I/O from the software in messages of an agent communication language (such as KQML, or FIPA's ACL). Though wrappers are a very specific type of agent, their role is very important, as they allow to integrate many KC without forcing people to learn how to use a new software they are not familiar with.
Group Assistants. Group Assistants are agents that act on behalf of a KC in the system. As such, they have a complete representation of what is available in the KC on whose behalf they act. If we use MCS as specification framework, it can be a first order theory that formalizes the taxonomy of a KC.
The main role of a GA is to interact with the other GAs in order to learn conceptual links between knowledge in its KC and knowledge in other KCs. This is to be done through a process of meaning negotiation. The aim of the negotiation process is to agree on the classification of knowledge about the same object (or topic) in different KCs. Suppose, for example, that a member of KC1 seeks information about Linux. In KC1, this information is classified as ``Operating Systems''. Suppose that KC2 has information about Linux, but this information is classified as ``Free Software''. The goal of negotiation is to learn that, whenever KC1 needs information about Linux, a request should be sent to KC2 for data about ``Free Software''. This relation between the way KC1 and KC2 classify knowledge about the same topic is recorded by GA1, and used in the future as a defeasible rule of query translation with GA2.
An obvious way of doing what we are proposing from the perspective of the GEP is to define a common ontology agents can refer to. This has been proposed by many authors (see e.g. [13]). However, as we discussed in section 4, we don't believe that this top-down approach is scalable to really complex domains. Therefore we propose a bottom-up approach, where bridge rules (in this case, partial mapping between taxonomies of different KCs) are progressively learned by agents (though it is always possible for designers to pre-compile some rules in some GAs). See [8] for a formalization of federated databases which uses bridge rules.
Finally, each GA observes his KC, in order to detect significant changes in knowledge organization. The idea is that a GA may decide to inform other GAs if a change has happened, so that they may update their mappings.
Knowledge Integrators. Knowledge Integrators (KI) form the highest level in our architecture. We can imagine that, for very complex organizations, there are several KIs, hierarchically organized (see figure), each of which integrates information from the lower level. However, for the sake of simplicity, we will ignore this aspect.
KIs have the role of synthesizing complex mappings between KCs. We said that GAs learn one-to-one mappings with other GAs. When one of such mappings proves to be useful, GAs communicate such a mapping to their KI. Each KI receives information about mappings from many GAs. Its task is to infer new mappings starting from one-to-one mappings which have been negotiated between GAs. A trivial case is a transitive mapping: if GA1 has a mapping between P in its language and Q in GA2's language, and GA2 has a mapping between its Q and GA3's concept R, then a KI should be able to infer the mapping between GA1's P and GA3's R, even if GA1 and GA3 have never directly interacted.
When a GA is seeking information about something, the first thing to do will be to ask its KI whether it knows about mappings others that those the GA already knows. This not only helps saving time and communication exchanges between GAs, but also allows to establish connections that GAs could never find by themselves. This is particularly true in more structured organizations, where we assume that not all GAs know each other, or are allowed to communicate with each other.
