Ba provides a platform for advancing individual and/or collective ..... member wishes to send an email to a colleague, he asks for his PA that knows which.
A Multi-agent Architecture for Knowledge Management Systems Cesar Tacla, Jean-Paul Barthès CNRS UMR 6599 HEUDYASIC Université de Technologie de Compiègne, France { Cesar.Tacla, Barthes }@Utc.fr
Abstract. This paper concerns a multi-agent system architecture for knowledge management (KM) systems in research and development (R&D) projects. R&D teams have no time to organize project information and to articulate the rationale behind the actions that generate the information. Our aim is to provide an architecture, which supports collaborative work and helps to capture and to organize experiences without overloading the team members with extra-work. The article describes the components of the architecture, their interactions, and the principles of functioning.
1 Introduction We are interested in defining a multi-agent architecture for knowledge management (KM) systems in R&D projects. R&D team members have neither time to organize documentation nor to articulate the rationale behind the set of decisions and actions in a project. At the end of the project, the group has a naturally distributed memory as each member played a different role and consequently has a different view of joint experiences. Thus, our overall goal is to develop a multi-agent architecture which supports the collaborative work, documentation organization, and knowledge sharing and preservation without overloading the team members with extra-work. Section 2 introduces the KM ideas guiding some of our architectural decisions, and the requirements for the envisaged class of KM systems. In Section 3, we justify the use of a MA architecture in KM systems. Section 4 introduces our platform for developing multi-agent systems. Section 5 presents the architecture that is supported by the platform, describing its components and their interactions. In Section 6, we present the current development status of the architecture, and finally we offer a conclusion.
2. From KM principles to the system requirements We have observed that data, information, and the resulting knowledge, widely spread throughout the enterprise, "belong" to relatively small groups of persons. In the automobile industry for example, groups are set up for R&D projects to design new types of cars. During the project new knowledge is being created and used by the group in
relation with other specialists in the company. The projects we consider lead to the development of prototypes that will eventually be built in a volume production. The main criterion in such projects is time. While working on the prototype, there is very little time allocated for producing detailed documentation. Information ends up spread in a multitude of documents on various supports. Most lessons learnt on the project are buried in the heads of the project team members. Then, since R&D teams change from a project to the next, a great deal of experience can be lost. Thus, it is important to organize and manage knowledge developed in R&D projects. The question is how to provide technology to help the actors organize and improve their use of knowledge, without adding to their workload or endangering the project timetable. LOCATE
Formalizing Conserving
CRUCIAL KNOWLEDGE
Updating Improving
MAINTAIN
PRESERVER
Identifying Locating Characterizing
Accessing Disseminating Using effectively Combining Creating ENHANCE VALUE
Fig. 1.KM cycle [8]
A classical approach to developing knowledge management systems is to follow a knowledge capitalizing cycle as advocated by many authors. Figure 1 shows such a cycle taken from [8]. The process consists of locating crucial knowledge, formalizing it using some information technology so as to be able to distribute it, and to maintain it. In most R&D projects, there is simply no time to do that. However, since such projects end up producing a great number of documents and require the collaboration of many people, a good way to capture information is to offer them a good system supporting collaborative work. If they like it, they will use it, and if they use it, then part of the information can be organized without requiring too much effort. Before going into the details of the requirements for the architecture, we briefly introduce the concept of Ba [15] that has guided us in some of our decisions concerning the architecture. Ba may be considered as a framework for managing and creating knowledge. Quoting [15], "Ba can be thought of as a shared space for emerging relationships. […]; Ba provides a platform for advancing individual and/or collective knowledge. […]".
2.1 Requirements According to the concept of Ba, a project may be considered as a shared space where group members perform their work through successive transformations and exchanges of knowledge. Whether we transfer (and simplify) the Ba concept to the computer world, such shared space may be seen as a system in which team members are able to execute their day-to-day work in a cooperative way. We have also seen that time is a primordial question in R&D projects (it is also true for nearly every industrial project) what means that team members have no time to do extra work. So, they need to be helped whether we want to encourage the creation and sharing of knowledge. Besides this, as documentation is produced in large scale, it seems interesting to aid the users to organize it. Finally, the knowledge must be preserved for new team members and future teams, and documentation confidentiality is a question that must be addressed. So, the general requirements for the KM system are: 1. It must cover as much of the R&D activity as possible, 2. It must save time by helping the user in the day-to-day activities, 3. It must support users in the knowledge creation and sharing process, 4. It must be reliable, secure and persistent.
3 Reasons for using a multi-agent architecture The basic idea that underlines the envisaged class of KM systems is to consider that knowledge is contained in the information produced, retrieved and exchanged among members of the project and to try to organize the information automatically and locally for each team member. The result is a distributed group memory where each member keeps part of the knowledge of the team. Thus, the first reason to employ multi-agents in KM systems is that, like in a team, a multi-agent system is composed by a group of possibly heterogeneous and autonomous agents that share a common goal and work cooperatively to achieve it. Secondly, most part of current technological solutions for KM systems are based on groupware tools. Such tools satisfy a number of our requirements but we think that they do not support adequately the process of knowledge creation (the main function of a KM system). For example, the way users perform their regular activities is not effectively taken into account by groupware at present time, though this may be an important source of knowledge to be reused. It means these tools are not very well equipped for learning from monitoring the users actions. Indeed, in general groupware does not exhibit an intelligent behavior, for instance, capable of suggesting some action or proposing a service for the user, so groupware has limited pro-activity and autonomy, two present features in multi-agent systems. Other approaches using agents in knowledge management have been developed. The CoMMA [6] project, Corporate Memory Management through Agents, combine emergent technologies (e.g. XML, machine learning) allowing users to exploit an organizational memory. The FRODO project [4] provides an agent-based middleware for distributed organizational memories. The CAIRO environment [16] uses software agents that helps geographically distributed teams to do meetings in virtual rooms,
i.e., it is a tool for supporting cooperative work that is able to manage various kinds of meetings (e.g. lectures, round-tables, informal meetings).
4 Our MAS platform In our laboratory we have been developing agent systems for a long time, in particular in the domain of complex design. Monceyron [14] developed a blackboard design environment, EXPORT, applied to harbor design, and more recently Shen and Barthès developed a generic multi-agent platform, DIDE, for mechanical engineering design [19] following the work of Scalabrin et al. [18] on platforms for cognitive agents. This led to the development of the OMAS platform (Open Multi-Agent System). The main features of our platform are summarized in the following paragraphs.
4.1 Cognitive agents Among the many types of agent models and systems that exist, we chose to work with cognitive or deliberative agents. Such agents contain “an explicitly represented, symbolic model of the world and in which decisions are made via symbolic reasoning” [21]. The main advantage of cognitive agents is the possibility of designing intelligent behaviors by means of a set of skills. Moreover, such agents are autonomous, so they run independently of any particular task. This allows them in particular to display a proactive behavior, which makes them very different from client-server systems. A large number of papers and books have been published about agents and the reader is referred to Jennings and co-workers [11] for a quick review of the domain. In our platform the agents are tightly linked within groups, we call coteries. Each agent inside a coterie receives all messages, allowing it to update and maintain its own internal representations, like a person in a small group hears all conversations within a certain distance. A coterie however can participate in higher-level interactions. Coteries can be linked by means of broker agents, and inside a coterie, there is no control structure, and there is no concept of group or social structure. There can be however an organization structure among people involved in the coterie (i.e. people using the agents). Our platform allows the use of two types of agents: 1. Service agents (SAs) that provide a particular type of service corresponding to specific skills. 2. Personal assistants (PAs), in charge of interfacing humans to the system. Their particular skills are devoted to understanding their master and presenting the information intelligently and in a timely manner. The internal structure of an agent is given on Figure 2. It can be seen that a PA is a SA augmented with a user interface and a model of the user (the gray area). Follo wing, a briefly description of the components: − Net interface implements the communication protocols. − Control module is responsible for the agent behavior.
− Skills contain the set of services of the agent. A particular skill can be expressed as procedures or rules. If the skill is complex, then a plan for executing it can be created, and the derived tasks are spawned and broadcast on the network. − World contains a representation of the other agents (their skills) and of the environment. − Tasks are a representation of what the agent is currently executing. − Ontology deals with agent ontology and domain ontologies. The agent ontology is employed to represent the agent skills, the tasks, and the skills of the other agents (world representation). − Self contains the representation of the agent’s skills, data stored in its memory, and possibly its own goals. − User model contains user preferences and a model of the dialog with the user. − User interface allow for communication as simply as possible for the person (e.g. natural language).
Ontology
Skills
User model
Control Tasks
World
Self
User interface
Network interface
Network
SA = white boxes PA = white boxes + gray boxes
Fig. 2. The internal structure of the personal assistant (PA) and service agents (SA)
4.4 Communication Communication within a coterie occurs asynchronously in broadcast mode (messages can be directed, e.g., point to point, but communication mode is broadcast). This probably will appear surprising to some readers and interpreted as a waste of bandwidth. In practice, since the agents of a coterie share the same local network, each agent sees all the messages at the lowest level. Simply, messages are usually filtered out in a point-to-point communication. Thus, broadcasting implemented at a low level (e.g., by means of a UDP protocol) is essentially free. At a higher level, we must make use of some communication protocols. For processing tasks, we extended the well-known Contract-Net protocol [2]. The resulting version, B-Contract-Net, allows for the agents to function at two levels of priority and to work on contracts even if they were not selected. The B-Contract-Net is quite complex and out of the scope of this paper. Note however, that although there are a number of exchanges during the first phase of Contract-Net type protocols, we do not consider such protocols as negotiation protocols but as a coordination method for task allocation, agreeing with Jennings [11]. In relation to the content language, ontologies play an essential role in that. Do main ontologies are used as primitives of the agent content language, assuming a
KQML-like message structure [5] and a content language resembling SL0, SL1 or KIF [7]. SAs use ontologies to interpret the incoming messages and thus provide the required service. Ontologies are also used by the SAs for building and modifying local representations. The PAs employ the ontologies in the same way and additionally for communicating with the user. An interesting point of our platform is that it does not contain a directory service (as recommended by the FIPA standard) that provides a location where agents register their descriptions (name, locator, and eventually other descriptive attributes as the services offered by the agent). So, a new agent (using the internal structure depicted in Figure 2) for advertising its services to the other agents within a coterie may either broadcast a message or simply answer the calls for bid since they are all broadcasted within a coterie. An agent not presenting the same internal structure as the one provided by our platform wishing to communicate with an agent inside the coterie must send messages to a special SA, the postman agent. This agent translates the received messages and broadcasts it to all elements belonging to the coterie. Inversely, an agent inside the coterie must send messages to the postman agent (broker) to interact with an agent outside the coterie. Hence, the postman agent provides facilities for communicating with other coteries and external platforms (i.e. FIPA compliant platforms).
5. The architecture for the KM systems The shared space for project teams inspired in the notion of Ba may be implemented as a multi-agent organization (cf. section 2) supported by the OMAS platform. Based on the requirements defined in section 2.1, the KM systems we intend to derive from the proposed architecture must be able to: 1. Organize automatically the documentation, aid the users in documentation retrieval, and allow them to set different levels of confidentiality to the documents, 2. Provide means to the users for communicating, i.e., e-mail, chat and forums, 3. Provide means to the users for managing their personal tasks, for example, a mechanism for taking notes about the advancement of the task and for recording the performed actions belonging to the task, 4. Express the lessons they have learnt. With these functionalities we try to meet the requirements for the system. The functions 1 to 3 are closely associated to the first requirement (to cover R&D activ ities). Of course, these three functionalities are also supposed to satisfy the requirement 2 (save time) and 3 (support knowledge creation) but they are mainly focused on helping the user to perform his day-to-day activities. The function 4 is more towards the requirement 3 (to support knowledge creation and sharing). The requirement 4 (to be reliable, secure and persistent) must be pursued in all functions. Other functions could be envisaged like management of the team members profile used for discovering specialists in an organization, or task modeling through the definition of a workflow as well as its execution. For the sake of simplicity we have constrained ourselves to the functions we consider fundamental.
Next, we present the agents forming our architecture and the functions they perform. We briefly describe how the PAs monitors the actions of his master. This is an important part of the architecture that facilitates the task of preserving knowledge. Finally, we present a case to illustrate how the agents act both isolated and collaboratively.
5.1 The agents In our architecture, the PAs play a major role in the KM system. Firstly, they are in charge of all exchanges of information among team members. For example, if a team member wishes to send an email to a colleague, he asks for his PA that knows which SA is capable of effectively sending it. Secondly, the PA is able to organize the documentation of its master always with the help of the SAs. Finally, as R&D members have to deal with knowledge intensive tasks, they are supposed to construct their own work methods, and in this process they should remember their past experiences, and if possible have access to other members’ past experiences. So the PAs must capture and represent the team members’ operations helping them in the process of preserving and creating knowledge (we discuss user monitoring in further details in section 5.2). In relation to the document organization, we have stated that documents are locally organized as a function of the user preferences. In fact, the user preferences are related to three ontologies: the domain ontology, containing the main concepts of the domain of the project; the documentation ontology, holding the concepts concerning the documentation domain (e.g. categories of documents); and the project tasks ontology (e.g. prototype construction). A service agent, the project agent, keeps all of these ontologies. Such agent holds all the values shared by the group, among them the ontologies (not to confuse with a blackboard). The team members can only extend these ontologies (i.e. add a new child concept). In this way, the users can express their preferences, for instance, by refining a document category from the documentation ontology. So, the first thing a new user does when he integrates the project is asking for the ontologies. Resuming the document organization, each PA is supposed to help his/her master to organize his/her documentation. In order to do that, each one of them works jointly with its organizer agent, a service agent able to build representations of the documents allowing for late retrieval. A document is represented by its content and context of creation. The document content is represented by a set of segments and each segment is represented by a vector of relevant terms extracted automatically from the segment body (a segment is a fixed sized block of n phrases). To compute the relevance of each term in the segment, we employ the well-known TF/IDF measure (Term frequency, Inverse Document Frequency). The TF/IDF measure is only computed for the terms related to the domain ontology. The context in which the document was created varies accordingly to the category of the document (from the documentation ontology). For example, the authors, the type of publication (a book chapter, conference proceeding article, journal article), and the associated event (e.g. the conference) are the context for an article. For a user task (i.e. a collection of desktop operations with the associated documents, and a textual description), the
context is given by the project task (coming from the project tasks ontology), the task description, and the involved people. For document retrieval, the PA agents use a textual case based reasoning engine as proposed by Burke [1] in the FAQ Finder System. Burke proposes a similarity measure formed by three components: the term frequency (TF/IDF), the semantic distance (based on the domain ontology), and the coverage of the terms. The context description allows for document retrieval as a whole, and the document content representation through segments gives the PAs the ability to propose portions of text to the user. One of the requirements for the architecture is to be reliable, secure and persistent. Such requirement may be partially satisfied by a groupware tool. Generally, such sort of tool furnishes information access control, and they are proven technology, thus providing a reliable and persistent environment. However, as we want the architecture to be independent of any specific software tool we integrated a service agent called repository agent. It encapsulates the groupware that must be part of the architecture. The referred agent offers services of saving and retrieving documentation but, depending on the tool it encapsulates, it can offer other kinds of service as WEB search, and e-mail management. In relation to the documentation confidentiality, the user is able to assign one of the following levels of permission: personal, project, and public. The repository agent must be able to translate such levels of confidentiality to the levels that the encapsulated tool offers.
S
S
Organizer agent
PA
Personal assistant
Project Coterie (LAN)
Postman Agent
S
GW
repository agent S S
Organizer agent
PA
Project agent
Personal assistant
Fig. 3. The multi-agent architecture for KM systems
Figure 3 shows the agents that compound the architecture for the KM systems. Note that there is one PA for each user in a project as well as its associated organizer agent. For the project, there is one postman agent and one project agent. SAs may be added or excluded at any time as a function of the needs of the team and of a specific user. Thus, there are two levels of service, one dedicated to a specific user (e.g. the organizer agent), and other for the whole project (e.g. repository agent). Before describing the architecture in practice, we briefly present the mechanism the PAs employ for monitoring the users’ operations on the computer desktop. This is important to understand how the architecture provides means for aiding the users to preserve their knowledge.
5.2 User monitoring Whilst a user is working, his PA captures the operations he carries out on the computer desktop. Such monitoring mechanism enables the PAs to exhibit an intelligent behavior. They can, for example, perform autonomous searches in the WEB and make easier the task of preserving knowledge (e.g. the method employed by the user to find information about a certain subject may be considered as a knowledge [12]). The operations the user executes directly in the PA interface can be easily captured. The operations executed in other software tools must be externally monitored. Hence, the PA must be prepared to do both monitoring its own interface and receiving the events the user generate in external tools. So, a PA must be able to deal with events coming from the SAs that encapsulate the external monitors. Probably, the communication between a monitor agent and the monitor itself will use a TCP/IP socket (this mechanism is not yet implemented, so only the events occurring in the PA interface are monitored). Many works have employed a monitoring mechanism. In [13] [10] a PA is used to search the Internet. Whilst the user navigates, an agent proposes new WEB sites analyzing the contents of the sites visited by the user. In CALVIN project [12] sequences of visited sites are also considered but the goal is to automatically store cases containing the resources researchers consult during their decision-making. PAs are also used to improve the interface with complex systems. In [9] a PA has been used to facilitate the interaction between the user and a MAC environment. The agent captures the events generated by the user while interacting with the operating system (for example, opening a directory, opening a text editor) and tries to foresee forthcoming events. 5.3 The architecture in practice In order to highlight some important points of the architecture we present two cases that will illustrate our discussion. The first one presents how the proposed architecture helps a single user to preserve and reuse some of the knowledge he has acquired. The second case presents how the preserved knowledge is used by the other agents, and consequently by their masters. The focus is on the interaction among the agents. 5.3.1 Single user case Fred, a hypothetical user, was in a need of information about 3D modeling concerning a certain CAD tool. So he performed some operations (e.g. keep document, chat conversation with a colleague to obtain some guidelines, etc.) to find it. Such operations were captured and grouped by his PA in a task (3d-beginner-info) created by Fred, as Figure 4 shows. Following, we examine three interactions between Fred and his PA (i.e. saving a document, retrieving a collection of documents, and the PA suggesting pro-actively a past task to Fred), and the consequent interactions among the involved agents. When Fred asks his PA to execute an operation like “keep document”, the PA asks the organizer agent to build a representation of the document (as described in 5.1) that, in its turn, asks the repository agent to save the document. The repository agent
returns the document locator, and then the organizer associates the locator to the document representation. The PA receives an acknowledgement from the organizer agent informing that the document was saved.
Fig. 4. Captured operations of the 3d-beginner-info task Suppose that Fred wants to retrieve a previous saved document (or a collection of documents). So, he asks his PA to find the desired document, and then a dialogue between Fred and the PA is started allowing Fred to refine his query (further details on the dialog can be found in [17]). So, the PA sends the query to the organizer that retrieves a set of documents satisfying it. The PA displays the document collection, Fred chooses one of the documents, and the PA sends a request to the repository agent to recover it. Over time more and more operations are aggregated to the task 3D-Beginner-Info. The PA dynamically builds a task context description based on the relevant terms of the documents handled by Fred. The PA is able to suggest similar past tasks to Fred based on the context of the current task. The PA requests the organizer for search for the most similar past tasks, and also for isolated documents in a similar way as described in the previous paragraph. Fred can save his tasks at any moment. Indeed, he can add a textual description to them. His PA will keep a task in the same way as it does for the documents (with the help of the organizer agent). Thus, the interaction among the agents is similar to the keep document operation except for the object being saved (in this case, a user defined task). 5.3.2 Knowledge sharing case We comment on the precedent case because the sharing of knowledge among users occurs naturally every time a user asks his PA for documents or past tasks. In fact, this feature is enabled by the concept of coterie. Suppose that the Fred’s agent (after asking to the organizer) hasn’t any suggestion. Remember that the same query Fred’s PA sent to its organizers was broadcasted to the others PAs (all messages in a coterie are broadcasted). Thus, another PA, being able to help Fred, can answer the query by sending a similar task (or a document) to Fred. An interesting point is that if the other agent suggests the task being executed by its master, Fred will be aware that his colleague is working on a similar subject, thus they can even work cooperatively. Of course, information confidentiality must be observed, so every time Fred asks his PA to keep an object (a document or a task), he also indicates the desired level of sharing to be given to the object.
5 Current status We have been developing a prototype of a KM system using the presented architecture to be used in a cooperative project between two groups in different countries (France and the US). Such groups will design a new product and they will share documents and exchange information. Upcoming teams can benefit from the documentation and captured tasks, and they can also reuse the project ontology, if the projects are in the same domain. The prototype was first undertaken at the occasion of another R&D project in the domain of automobile design. We have implemented the part of the user monitoring mechanism and we are now working on the interaction protocol with the groupware tool. In parallel, we are implementing the textual CBR engine used by the PAs for retrieving relevant documents and past tasks.
6 Conclusion We described a multi-agent architecture for KM systems, inspired in the concept of Ba [15], that enables team members of an R&D project (although it is not restricted to this kind of project) to share and create knowledge. The multi-agent architecture has some interesting features inherited from the OMAS platform: the notion of coteries, the total sharing of information through message broadcast inside a coterie, and the fact that agents use ontologies as a means to disambiguate messages. The architecture aims to be minimal, and so we offer just the elements we consider essential for a KM system supporting cooperative work. The PAs play an important role because they support the users in interacting with the system, in organizing and retrieving their documentation (with the help of the organizer agent), and in preserving and sharing their knowledge (two essential features for KM systems). The repository agent is also important because it wrappers a groupware tool giving independence to the architecture. In the same way, SAs that encapsulates external monitors (i.e. they allow the PAs to receive user events occurred in other software tools) give independence and modularity to the architecture. The groupware tool is an important piece of the architecture because it offers some services that otherwise would be cumbersome to reimplement (e.g. document storing, e-mail manager, etc.). As the architecture is open, the derived systems can be extended by including progressively more complex agents or agents providing redundant services. Personal assistants are aware of presence of new agents and can make use of them even if their masters are not, so they do not need to adapt themselves to new software tools.
References 1. Burke, R., Hammond, K., Kulyukin, V., Lytinen, S., Tomuro, N., Schoenberg, S.: Question Answering from Frequently-Asked Question Files: Experiences with the FAQ Finder System. AI Magazine, 18(2) (1997) 57-66. 2. Davis, R., Smith, R.G.: Negociation as a Metaphor for Distributed Problem Solving. Artificial Intelligence 20 (1983) 63-100.
3. Dignum, F.: Information Management at a bank using agents: theory and practice. Journal of applied Artificial Intelligence 14 (2000), 677-696. 4. van Elst, L., Abecker, A.: Domain Ontology Agents in Distributed Organizational Memories. IJCAI'2001 Workshop on Knowledge Management and Organizational Memories, August (2001), Seattle, Washington, USA. 5. Finin, T., Fritzon, R., McKay, D., McEntire, R.: KQML – a language and protocol for knowledge and information exchange, Technical Report, University of Maryland, Baltimore (1993). 6. Gandon, F.: Multi-Agent System to Support Exploiting an XML-based Corporate Memory, In Proceedings PAKM'00 Basel, Switzerland, October 30-31, (2000) 10.1-10.12. 7. Geneserth, M., Fikes, R.: Knowledge interchange format, version 3.0, Reference Manual, Tech Report Logic-92-1, Computer Science Department, Stanford University, (1992). 8. Grundstein, M. Barthès, J-P.A.: An Approach to Enterprise Knowledge Capitalization. in Knowledge Management. Enterprise, Network and Learning. Advances in Knowledge Management. J. Schreinemakers, J-P. Barthès (Eds), Ergon Verlag, Germany, 2 (1999), 151159. 9. Hoyle, M. A., Lueg, C.: Open Sesame !: a Look at Personal Assistants, Proceedings of the International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM 97), London (1997) 51-60. 10. Huhns, M. N., Singh, M. P. Readings in Agents. Morgan Kaufman Publishers Inc., 1998. 11.Jennings, N.R., Sycara, K., Wooldridge, M.: A Roadmap of Agent Research and Development. Autonomous Agents and Multi-Agent Systems 1 (1998) 7-18. 12. Leake, D. B., Bauer, T., Maguitman, A., Wilson, D.C.: Capture, Storage and Reuse of Lessons about Information Resources: Supporting Task-Based Information Search. Proceedings of the AAAI-00 Workshop on Intelligent Lessons Learned Systems. AAAI Press, Menlo Park, (2000). 13.Lieberman, H.: Let’s browse: a collaborative browsing agent, Elsevier Science B. V., vol 12 December (1999) 427-431. 14.Monceyron, E., Barthès, J-P. A.: Architecture for ICAD Systems: an Example from Harbor Design. Revue Sciences et Techniques de la Conception 1 (1992) 49-68. 15.Nonaka, I., Konno, N.: The Concept of "Ba": Building a Foundation for Knowledge Creation. Califormia Management Review. 3(40) (1998) 40-54. 16.Peña-Mora, F., Hussein K., Vadhavkar, S., Benjamin, K.: CAIRO: a concurrent engineering meeting environment for virtual design teams. Artificial Intelligence in Engineering, 14 (2000), 203-219. 17. Ramos, M. Structuration et évolution conceptuelles d’un agent assistant personnel dans les domaines techniques. Thèse de doctorat de l’Université de Technologie de Compiègne. (2000). (in French). 18.Scalabrin, E. E., Vandenberghe, L., de Azevedo, H., Barthès, J-P. A.: A Generic Model of Cognitive Agent to Develop Open Systems. In Advances in Artificial Intelligence. Series Lecture Notes in Artificial Intelligence. D.L. Borges, C.A.A. Kaestner (Eds). Springer ( 1996) 61-70. 19.Shen, W., Barthès, J-P. A.: An Experimental Multi-Agent Environment for Engineering Design. International Journal of Cooperative Information Systems, World Scientific Publishing Company, 2&3(5) (1996) 131-151. 20.Shipman, F., McCall, R. Integrating Different Perspectives on Design Rationale: Supporting the Emergence of Design Rationale from Design Communication, Artificial Intelligence in Engineering Design, Analysis, and Manufacturing (AIEDAM), 11(2) (1997) 141-154. 21. Wooldridge, M.: "Conceptualising and Developing Agents", In Proceedings of the UNICOM Seminar on Agent Software, 25-26 April (1995) 40-54,.
