mechanical device. Each group works separately, one in the US and the other in France. This paper examines the international collaborative design education ...
An Ontology-Based Multi-Agent Environment to Improve Collaborative Design Fabrício ENEMBRECK†, Indira THOUVENIN‡, Marie-Hélène ABEL†, Jean-Paul BARTHÈS† Université de Technologie de Compiègne CNRS UMR 6599 HEUDIASYC† CNRS UMR 6066 ROBERVAL‡ BP 20529, 60205 Cedex Compiègne , France
Abstract. The paper presents a knowledge-based approach for collaborative design using a task ontology and a multi-agent architecture. In an educational project, students from two different countries must collaborate to design an electro-mechanical device. Collaboration is a fragile question in pedagogical environments because students very often develop activities in an isolated way and there is no real exchange of knowledge. We offer a tool for improving the early stages of collaboration through a system that provides communication support for design or project management tasks. Agents use knowledge to guide users during the collaborative process. Our multi-agent system works in a passive way. Students are free to accept the suggestions/directions of the system or not. A personal assistant captures and shares personal knowledge (experiences) while cognitive autonomous agents use ontologies to guide the interactions among the students. Keywords: Knowledge Management, Ontology-based Project Management, Collaborative Design, Pedagogical Design Environment.
1. Introduction Distributed collaborative design implies the ability for collaborating designers to work across geographic and time zones. For some years, a few experiments of national and international collaborative work have been conducted at the University of Technology of Compiègne (UTC) in France. Among the experiences: ·
the Taxia project [14]: a hundred students from twelve engineering schools in France were assigned the prototype development of an industrial vehicle.
·
the CADAU project [11] [12]: two groups of students collaborate to design an electromechanical device. Each group works separately, one in the US and the other in France.
This paper examines the international collaborative design education experiment (CADAU project). The experiment simulates a distributed and collaborative computer aided design (CAD) project where students from UTC in France and Iowa State University (ISU) in the United States work together over the Internet on the design of a common product. Based on this experiment, a research project entitled “Agent-Aided Cooperative Design” (AACC) [7] [18] has emerged at UTC to propose a more efficient collaborative design environment. We detected collaboration problems during the educational experiment, and we tried to understand the reasons for success or failure in distributed and collaborative design.
Groupware or collaborative tools allows to capture design intent, and to quickly answer the user needs. But such tools cannot provide sufficient support for design [2]. Another approach is to consider developing an ontology-based multi-agent environment in order to recover and organize knowledge developed during the design projects [4] [15]. In Section 2 we detail the context of the CADAU project and the collaboration problems that were detected. In Section 3, we present the tasks ontology built from tutors’ observations. The ontology is proposed to help students during collaboration. In Section 4 we detail our multiagent architecture. Finally, we indicate how we imagine evaluating our system. Before concluding we discuss some related work. 2. An Educational Multi-Cultural Mechanical Design Project 2.1. Context Students from different countries work together on a unified design project introduced with the offered CAD courses: ·
to learn the theory and application of CAD tools
·
to acquire an international collaborative design experience with students in Mechanical Engineering from another country having a different language and a different culture.
To achieve the second goal, a design project is proposed to groups composed of students from both countries. The groups have to design a product that satisfies predefined design specifications. Taking into account the limited time for the students to work on their project, three months at eight hours per week, the project doesn’t include tolerance analysis nor optimization of the design process. The course includes lectures and computer laboratory sessions. The first computer lab session is devoted to the presentation of the design specifications. The specifications are defined by the supervisors. The product is selected to be an innovative answer to everyday life needs, such as a remotely controlled vacuum cleaner or a shopping cart with an automatic stair climber, etc. Pro/Engineer is the CAD tool chosen by both course instructors. The collaborative work space was Basic Support for Cooperative Work (BSCW) then Pro Collaborate which are the most common tools in this field. The documentation on CAD design for the students is available from different sources including web sites on CAD solutions [1]. No books or reports are provided concerning the project, but the students are provided Internet access. 2.2. Collaboration Problems A major problem is how to support and improve the exchange of organizational information during collaboration. Studies about collaborative design show that organizational information represents most part of the information transmitted among designers [13]. Organizational information regards initial handshake about members, competences, initial ideas about the project, and tasks distribution that are summed up in the first two points (“planning elaboration and task repartition,” “planning control and tasks verification”) in Table 1. We focused on such points because very often team members do not know when, how, why, and who collaborates. Therefore, design management tools need to take into account an interaction protocol allowing people to exchange useful information in opportune moments. Furthermore, domain-specific tasks like “design an electrical engine” cannot be represented easily, or requires extensive customization. Table 1 presents the most important problems detected.
Planning elaboration and task assignment Planning control and tasks verification Product study (state of the art) Functional specification Language for collaboration Decision making and validation File annotation Information diffusion by the lab. tutor Exchange capitalization Deliverables management Table 1. Most important points in the AACC project. During collaboration students are lead to accomplish different tasks. Consequently it is important for them to agree about tasks, and how tasks must be done (definitions, deadlines or precedence). For students it is not easy to define such tasks. We propose a predefined set of adapted tasks that they will be able to select, complete and organize for their work. Such tasks are based on the tutor’s observations. Knowledge representation is an important point in collaborative design. Knowledge can be used for representing information about designers, activities, artifacts, projects and domains at different levels of complexity. Such information is the basis for a successful interaction and consequently can improve the quality of the design and minimize the designers’ efforts. In our approach we represent proposed tasks using ontologies. Ontologies provide a well-structured representation of knowledge, facilitating inference and organization. Next sections describe our approach. 3. Tasks Ontology We notices that the tasks accomplished during the collaborative process do not appear explicitly. Choices are not clearly argued, or the discussion seems to be lost. As it is difficult to establish an ontology [8] under such conditions, we separated the ontology related to modeling, and the one related to collaborative design leaving out the modeling part. An ontology may be defined as a concept hierarchy, links between concepts and inference rules. Among the links between tasks we find subsumption links (“is -a”), composition links (“part of”), p recedence links (“precedes”) and methods links (“has -methods”). Our work is focused on the ontology dedicated to the training project: we are not doing an absolute ontology. The students need help mainly for collaborative tasks and some for modeling. In the paper, we present part of the ontology we have built. All the concepts have been defined from documents such as mails, reports, or discussions with the teachers. But the work is generic and can be used for other kinds of collaborations. 3.1. Ontology Related to a Modeling Tool In the project, students used, Pro Engineer (PTC), a popular CAD tool in both universities. This way, they adopted the corresponding domain ontology. This tool is well known and often used in the CAD community. Some tasks like “extrusio n” cannot be done if another task, like a “sketch” (2D drawing), is a prerequisite. Modeling tasks is clear, and is managed by the user, with the CAD tool directly. Of course the related ontology doesn’t represent the vocabulary and complexity of mechanica l design. Nevertheless, we do not consider that it is useful to list all the terms used by Pro Eng: the CAD tool cannot be modified, and the modeling intent cannot be clearly seen by external applications (e.g., a personal assistant), even with a task ontology for modeling. In addition, there
are a lot of CAD tools using modeling and assembly ontology, and each tool is a strong guide for the user. 3.2. Ontology Related to Mechanical Design before the Modeling Stage After the project development analysis, we have collected implicit and explicit tasks. Explicit tasks were detected from indications in mails like “we would like to build the vacuum cleaner with 12 volts continuous power battery to have a wireless system” or “it is probably easier to work with the International Measurement System (meter second kilogram)”. Concerning implicit tasks, we have imagined them for when a team proposes a solution where no problem is stated. For example, when a team writes “we have received your options and we both prefer the second one because ...” it is necessary to come back to the possible options referring to the answer. We have defined and organized such tasks using an ontology [8]. This tasks ontology contains sub-ontologies. For example, among the collected tasks, some are related to consulting between the teammates(Figure 1). Other tasks require some personal work as looking for ideas, or solutions or analysis. Figure 1 shows part of the tasks sub-ontology where students have to consult among themselves. The use of a task ontology allows the agent to clear up affected tasks and to position them among the whole design process. Consulting task
... for designing an object
... designing a product
...
...designing vacuum cleaner
...for producing a ...for producing report the product functional specifications ...designing a piece
...
...designing a wheel
...of a solution
...of technical constraints to respect
...for producing a ...for making a choice the functional requirement expression
...of a project leader ...of a working method
...of a communication protocol
...of a language
...for the norm choice ...for the measurement system choice
...for the voltage choice
Figure 1. Fragment of the consulting tasks of the term hierarchy This ontology will be completed and enhanced by new educational projects with other countries. 3.3. Description and Links between Tasks First we present the observed main tasks, and then we describe links between the tasks.
3.3.1. Main Tasks We observed eight tasks for which students need help. These tasks are sub ontologies roots: ·
a study task consists of studying, analyzing an object;
·
a presentation task consists of presenting information;
·
a handling task consists of apprehending an object;
·
a consulting task consists of consulting each other for a precise goal;
·
a drafting task consists of presenting written results;
·
an evaluation task consists of evaluating an object;
·
a research task consists of doing a research action;
·
an understanding task consists of giving oneself the means to understand.
3.3.2. Linking Tasks Here we specify the links used in the ontology and their definitions. a) Subsumption Links A subsumption link (“is -a”) allows to refine tasks. For example Figure 2, we see that a voltage choice is a norm choice task, which is a technical-constraint-choice-to-respect task, which is a choice task, which is a consulting task. b) Composition Links A composition link (“part of”) allows defining a task as a composit ion of different subtasks. The consulting task for choosing the working method, for example, is composed of the languagechoice task and the communication-protocol task as described Figure 2.
Consulting task to choose the working method Language choice
Communication protocole choice
Figure 2. Composition link c) Precedence Links A precedence link defines the tasks that have to be executed first. For example, it is necessary to choose a project leader (Figure 4) before adopting a working method. Consulting task to define the functional requirement expression
precedes
Faisability study task
Figure 3. Precedence link
As we can see Figure 4, the feasibility study task is not a consulting task. The precedence links can operate between tasks from different sub-ontologies. d) Has-Method Links A has-method link allows the association of automatic procedures on the tasks, named methods. Such methods are optionally chosen by users and tell how the task should be tackled, since a task can be achieved in different ways. Methods are useful because very often users do not know the preconditions, resources and constraints implied by the task. Such methods are also used for controlling the task development. 3.4. Ontology and Multi-Agent System In the next section, we present a project management system based on a multi-agent architecture. The aim of this system is to improve the organization of collaborative projects and to support users in specialized tasks using the knowledge represented by way of ontologies as partially described previously. In such a system, project knowledge is organizational and domain related. Organizational knowledge is made of high level representations of collaboration tasks and must be represented explicitly. Domain-related knowledge is represented as tasks requiring technical information. 4. Multi-Agent System Architecture for the AACC Project In this section, we present a multi-agent system including personal assistants [10] specially built for improving collaboration between groups of design students. We introduce a knowledgebased approach where agents share information and push students to communicate. Users exploit the structure of each task filling it with current activities accomplished during the task development. The information is saved in users’ profi les and the system can later retrieve it when a user has a similar task to do. At a second level, knowledge is used to improve the collaborative process. Tasks ontology is similarly used for structuring the project design tasks. However, we focus in this paper onto collaborative tasks and not on domain specific tasks. The overall architecture is shown Figure 4. A designer is interfaced to the system via his Personal Assistant. The Personal Assistant in turn uses a set of Service Agents providing services like sending messages or finding a document. A special service agent, named Profile Agent, is responsible for managing the users’ profiles and feeding information back to the Personal Assistant. The agents are implemented using the OMAS (Open Multi-Agent System) platform [3]. The tutor controls students by giving directions and controls the general structure of the project using the Tutor Agent. Then, students are free to follow or to modify this structure. In addition, a standard groupware tool provides a repository for project documents. Schedule and Resolution agents are used for project management, controlling deadlines, document requirements or helping users to accomplish the tasks. Local communication occurs between designers and theirs personal assistants and among the personal assistants and the service agents.
Collaborative Tool
Tutor Agent
Personal Assistant
Internet
. . .
. . .
Web Server
Schedule Agent
Personal Data
Local Network
Resolution Agent
Service Agent - Task Ontology - Domain Ontology - Current Design Tasks
Group A
Group B
Project Database
Figure 4. System Architecture. In the following we first present the agent system, then the main functionalities and more precisely the knowledge -based project management. The principal agents are: ·
Personal Agent;
·
Tutor Agent;
·
Schedule and Resolution Agent.
4.1. Role of the Personal Assistant As mentioned previously, the role of the Personal Assistant is to identify the user’s needs, to execute her commands, to provide feedback from other users, to acquire information on the fly, but also to provide a global view of the project state. Such requirements are detailed in the following paragraphs. 4.2. Role of the Tutor Agent The role of the tutor agent is to provide a generic project structure. The tutor can create new projects, groups, and users. The information is stored on the Project Database. The system proposes a set of tasks corresponding to the entries “planning elaboration and task repar tition” and “planning control and tasks verification” of Table 1. Using the schedule interface of the personal assistant, the tutor can analyze the functioning of the project, send messages to the users and modify the project state by creating/removing or updating tasks. 4.3. Role of the Schedule and Resolution Agents Methods are controlled with the autonomous agents Schedule and Resolution. Schedule Agent uses control methods for controlling temporal constraints related to the development of the tasks. Its behavior is trivial. Resolution Agent controls the resolution methods attached to the tasks. It
implements a method database. The agent executes actions and sends messages according to the methods selected by the user. 4.4. Main Functionalities of the Collaborative Environment 4.4.1. Capturing Personal Knowledge User’s actions are composed of tasks that are saved into the user’s profile as XML documents. Currently, the following tasks are available: send-message, chat dialog, keep document, find document, user task and domain task. The Personal Assistant pushes propositions based on such tasks. While the user works, the Personal Assistant receives similar tasks representations observed on different profiles from the Profile Agent. Then, the user can assign the tasks to his current work. The Profile Agent uses information retrieval techniques1 for searching similar tasks. We believe that the mechanism allows people to represent and to exchange personal experiences, providing some help, letting them reuse previous work and bringing awareness [16]. A more detailed discussion about the last characteristic can be found in [7]. 4.4.2. Knowledge-Based Project Management in the AACC Project Our multi-agent system can effectively manage design projects. The goal of the system is to keep students aware of tasks dates, tasks requirements and to provide additional information. Members of a design project can use an interface for manipulating tasks as shown Figure 5. Designers and the tutor can modify the state of any task of the project. “Complete functional specification construction”
“Tasks repartition”
Day line
“Feasibility study” “Functional specification study”
Tasks
“Product study” “Design tool study” “Bibliographic Study” “Selection of the Project Manager” “Language selection” “Skills presentation”
“People presentation” Time line
“Project Start Up”
Time
Figure 5. Planning of the proposed tasks. Tasks can have subtasks. Subtasks are edited like common tasks. Figure 6 illustrates the edition of the task “Démarrage du projet” (Project Start Up) and the subtask “Choix du chef de projet” (Selection of the Project Manager). Beyond the subtasks and methods, this interface presents the task definition and final report. The definition of predefined tasks (members of the ontology) includes the goals, inputs, expected results and the current state of the task (initially 1
The details regarding such techniques are out of the context of this paper.
empty). The final report option informs if the task must have a final report and provides an interface for uploading or downloading the corresponding file. Project Start Up
Project members
Select. Project Manager
Task participants
Beginning date
End date
Final report
Subtasks Skills presentation Select. Project Manager Language selection People presentation Add
Remove “part -of” link
Remove subtask
Figure 6. Edition of the task “Project Start Up” and the subtask “Selection of the Project Manager” The Schedule and Resolution agents use the information captured through the interfaces presented Figure 7.
Control methods
Resolution methods
Advertise task creation
Random selection
Advertise task beginning
Revolving selection
Advertise task end
Wait for a volunteer
Advertise final report transmission
Daily
Weekly Periodic task call
Monthly Select someone for leading the project for a month. At the end of the month, you must select another chef.
Indicate end of task
Figure 7. Information about control and resolution methods about the task “Select the project manager”. On Figure 7 (b) the method “Choisir en tournant” (Revolving Selection) is selected for the task “Selection of the project manager ” and a small description of the method is shown. In this case, the system will send a message to the members before the end of the month asking users to selecti another project leader. Two other methods are available for this task (“Random Selection” and “Wait for a volunteer”). In fact, each method defines a particular set of actions of the Resolution Agent. Such actions tell when and who must receive messages, specify the content of the messages and procedures to do when the method is selected. The Resolution Agent analyzes task structures like that presented on Table 2. Task
Field definition
“Choix du chef du projet” “Se lection of the Task name Project Manager” :start (12 04 2003)
Start Date
:end (20 04 2003)
End Date
:comments "Objectifs: …"
Comments, goals, inputs, expected results
:participants ("Paul" "Pierre")
List of participants
:politics :DAY
Remember Cycle (:day, :week or :month)
:methods (“Choisir en tournant” “Choisir Name of all methods available for the task un chef de façon aléatoire” “Attendre un volontaire”) :subtasks nil
List of subtasks
:parent-tasks (“Démarrage du Projet”)
List containing the name of the parent task
:final-report ("Paul "upqqghxormrsqhfkrmny" "animal.data")
et
Pierre" Structure containing information about the “paul" final report. This structure presents the follow elements: (« author of the document» « identifier of the document » « name of the sender » « original name of the file » )
:resolution-method “Choisir en tournant”
Name of the selected method.
:need-report “yes”
Whether the task needs a final report or not. Possible values are "yes" or "no".
:finalized “no” Table 2.
Whetherthe end date has expired. Possible values are "yes" or "no". Representation of the task “Choix du chef d u projet” (Selection of the Project Manager).
Currently, project tasks are directly represented in LISP structures inside the agents but they can be easily transformed into XML representations for interoperability.
…
…
Domain Ontology Methods Database
Lisp Code
Resolution Agent
Project Activities
Task Ontology Project Database
Figure 8. Functioning of the Resolution Agent. Figure 8 presents the internal structures of the Project Database. During the development of the project, designers can create instances of the tasks represented on the Tasks ontology. Such instances are shown on the Project Activities frame Figure 8. They represent the current state of the project. The instances and corresponding task models are represented on dark circles. The Resolution Agent observes the current state of the project. When new events occur (new methods are selected), it looks for the corresponding methods and executes the correct Lisp code. In fact, methods can trigger two sorts of actions: active and passive. Active actions have aneffect on the project state. They are generally used for creation of new tasks. For instance, consider the task “Functional Specification.” This task has three different methods according to three different names (AFNOR – French Association of Normalization, DGA – Délégation Générale pour l’Armement in Fran ce and DoD – Department of Defense of EUA). Each name establishes different tasks and subtasks necessary for the construction of a correct functional specification. The hierarchies are represented on the Tasks ontology. When the user selects the AFNOR method, the Resolution Agent adds the correct set of tasks to the project. Passive actions just add the name of the current task and method to the internal functioning cycle of the agent. In fact, the Resolution Agent verifies daily all active methods. Each method contains information about dates, receivers and the contents of specific messages regarding the
corresponding task. For instance, consider the task “Skills Presentation.” If this task is currently active and a given user did not present itself yet, he will probably receive the message containing the follow information: “You must send a message to your colleagues telling your preferences, motivations and skills. You can also send in attach your résumé.” 5. Related Work Very often, work on knowledge intensive design takes into account complex specifications of products, resources and process and neglects the collaborative aspects. For us, collaboration is the main question because students do not like to collaborate. Thus, we need a system to entice students to cooperate. While in [9] a multi-agent system is given specialized agents for design activities like task decomposition, design flow, our approach is more focused onto the collaborative process of design. In other works, some systems try to automatically organize the design process saving designers time [5]. Our problem is exactly the opposite. According the tutor, the system must simply give a general idea about the design process and the students are free to follow it or to take another approach. Cheng et al. [6] developed a Natural Language based system, capable of answering queries of designers about the design process. Design tasks are modeled using a standard ontology (ifcXML – Industry Foundation Classes) defining data of architectural and construction applications. In that work, the system does not interfere with the design process and simply provides information about the current state of the project. Indeed, the system cannot answer complex questions and has a limited usefulness. 6. Conclusions Our work has been developed inside a pedagogical environment where students of mechanic engineering of different countries should collaborate for the development of an electro-mechanic device. The main problem in such an environment is the limited communication and exchange of information and knowledge between students. In this paper we introduced a new framework based on multi-agent systems and knowledge to improve collaboration in design. We focused on the importance of the knowledgebased representation of collaborative tasks. Such a representation induces a communication protocol between designers and has been developed to push designers to better communicate. Since in collaborative design, designers are spread in different places, multi-agent systems provide a good way for integrating the distributed environment. They facilitate the exchange of information and support distributed problem solving. We argue that knowledge can be represented at two levels: personal and project. Personal knowledge is captured with personal assistants capable of formalizing user experiences and exchanging such experiences with other users. Project knowledge requires a predefined model of the design process. We developed a task ontology to formalize collaborative design tasks. We focused in this paper on how cognitive autonomous agents can improve collaboration between designers using such structures. We expect in the near future to have users experiment with the system. However, the current prototype cannot be currently released because the Personal Assistant Agent interface is not good enough. We need a better interface for testing the system (probably in - Spring of 2004). During the course period we will evaluate the results from the collaboration among users while they use the system or not. Some criteria of evaluation for collaboration processes among designers are discussed in [13]. However, to us, the most important criterion is the acceptation of the tool by the students.
References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]
[12] [13] [14] [15] [16] [17]
[18]
About BSCW, URL:http//bscw.gmd.de/about.html Barthès, J-PA., Do we have the technology for supporting knowledge intensive CAD in large design projects?, Proceedings Knowledge Intensive CAD-1, T. Tomiyama, M. Mäntylä, S. Finger Eds., ESPOO, Finland, 1995. ISBN 951-22-2760-6 Barthès, J-P. A., OMAS v 1.0 Technical Reference, Memo UTC/GI/DI/N 151, Université de Technologie de Compiègne, Département de Génie Informatique, Jannuary, 2002. Barthès, J-PA., Managing Knowledge with Coteries of Noisy Agents, Proceedings SCS'01, Marseille, France, 2001. Berry, P.M., Drabble, B. SWIM: An AI-based System for Workflow Enabled Reactive Control. In Proc. of the IJCAI Workshop on Workflow and Process Management held as part of the IJCAI99, 1999. Cheng, J., Kumar, B., Law, K. L., A question answering system for project management applications, Advanced Engineering Informatics, Elsevier, v. 16, pp. 277-289, 2002. Enembreck, F., Barthès, J-P, Improving CSCW with Personnel Assistant Agents, Journal of Integrated Design & Process Science, (B. Kramer, J.P. Tsai, eds.), IOS Press, vol 7, n. 2, pp. 3-19, 2003, ISSN: 1092-0617. Grüber T.R., A translation approach to portable ontology specifications, Knowledge Acquisition 5, p 199-220,1993 Liu, H., Tang, M., Frazer, J. H., A Knowledge Based Collaborative Design Environment, In: Agents in Design, Key Centre of Design Computing and Cognition, University of Sydney, Australia, J. S. Gero and F. M. Brazier (eds.), 2002. ISBN 1 864 87 1202. Negroponte, N., Agents: From Direct Manipulation to Delegation. In Bradshaw, J.M. (ed.) Software Agents. MIT Press, 1997. pp. 57-66. ISBN 0-262-52234-9 Qamhiya, A., Ramond B., CAD Across Universities- An international Collaborative mechanical Engineering Education Experiment, Proceedings Fourth International Workshop on Computer Supported Collaborative Work in Design, J.-P. A. Barthès, Z. Lin, M. Ramos Eds., Compiègne, France, 1999. Qamihiyah A. Z., Ramond B., International Collaboration in mechanical ComputerAided Design Education, ASEE, 2000. Reddy, J. M., Chan, B., Finger, S., Patterns in design discourse: A case study, Proceedings Knowledge Intensive CAD-1, T. Tomiyama, M. Mäntylä, S. Finger Eds., ESPOO, Finland, 1995. ISBN 951-22-2760-6 Ramond, B., Collaborative Design in Education: the Taxia Project, IDMME’98, pp 1261-1268, Compiègne, 27-29 May 1998. Shen, W., Norrie, D. H.; Barthès, J-P., Multi-Agent Systems for Concurrent Intelligent Design and Manufacturing, Taylor & Francis, UK, 2001. ISBN 0-7484-0882-7 Schlichter J, Koch M, Bürger M., Workspace Awareness for Distributed Teams, Proceedings Coordination Technology for Collaborative Applications – Organizations, W. Conen, G. Neumann (eds.), 1997. Tacla C.A., Barthès J-P. A., Multi-agent Architecture for Knowledge Acquisition, AAAI Spring Symposium, March 24-26, Stanford University - Technical Report SS-03-01, L. van Elst, V. Dignum, A. Abecker (eds), AAAI Press, Menlo Park, ISBN 1-57735-178-9 SS-03-01, p. 159-166, 2003. Thouvenin, I., Abel, M-H., Ramond, B., Qamhiyah, A., Environment improvements for a better cooperation in multi-culture collaborative mechanical design, Journal of Integrated Design & Process Science, (B. Kramer, J.P. Tsai, eds.), IOS Press, vol 7, n. 2, pp. 131142, 2003, ISSN: 1092-0617.
