Learning from Daily Knowledge: How to Keep Track and to Represent Design Projects Knowledge

Daily knowledge consists mainly of know-how produced in daily work by human. Related to Richard [16], daily knowledge is considered as episodic memory, which contribute to build the epistemic knowledge. Daily knowledge is dependent to the context in which it is produced (activity, environments, tools, etc.). Representing this type of knowledge leads to represent also its context and especially, the organization and the environment in which it is produced.

Based on this postulate, the generation of a sense as it is represented in semiotic triangle (Fig. 1) cannot be done without the recognition of the context, which led to produce the reference. This postulate is more and more verified when we believe that knowledge is produced by the interaction of an actor with his environment (Fig. 2). So the challenge is how to capture the context of the production of knowledge and how to represent it in order to enhance the generation of sense when learning from this knowledge [6]. “The learning content is context specific, and it implies discovery of what is to be done when and how according to the specific organizations routines” [8].

Semiotic triangle [9]

Full size image

Enhancing daily knowledge

Full size image

So the main challenge is how to manage daily knowledge? How to keep track of it by considering all the element of the environment that contribute to its production: interaction, organization, roles, tasks, constraints, rules, means, methods, goals, product, artefact, etc. Currently, in organizations collaborative activities become more and more present. Dealing with the complexity, actors have to solve problems in collaborative way, by interacting with other actors. So, we believe that observing daily knowledge production leads to analyse collaborative activities. In this paper, we study knowledge produced in collaborative activities, what we call “collaborative knowledge”.

We deal with knowledge as interaction between an actor and his environment. Some approaches in Knowledge Management study how to represent individual knowledge while others help to enhance collaborative knowledge. Before detailing our study on management collaborative knowledge from daily work, let-us discussing the difference (Table 1) between individual and collaborative knowledge [13].

2.1 Difference on the Nature of Captured Knowledge

In fact knowledge capitalized with knowledge engineering approaches is related to experience. This experience is built along activities of an expert in which a lot of experiments are analyzed and structured by the expert; Knowledge engineering approaches are based on the cognitive psychology theory which enunciate that human develop a mental schema, routines when repeating activities. In knowledge engineering, approaches tend to make explicit this mental schema by showing heuristic rules in different forms: the “what” manipulated, the “why” of a behavior and the “how” of activities. Strategies and routines are so represented at what we call conceptual level [17]. Allen Newell [14], call this level by knowledge level, in which behavior laws and rational actions must be represented. Observation of individual activity is not sufficient; Knowledge engineering approaches developed several techniques to interact continuously with the expert in order to make explicit strategies and routines.

Whereas knowledge observed in collaborative activity is related to one experiment i.e. a project. Actors in a company move continuously and collaborate in different projects. Each of them, build his own individual knowledge in his field. So, knowledge observed in collaborative activity is related to episodic memory [16]. We know that semantic memory is build by repeating activities and aggregating information and data. So, observations of several activities are needed to capture and structure knowledge in collaborative work. Table 1 explains knowledge development in individual vs collaborative activities.

2.2 Difference on the Dimension to be Considered

The profession memory contains knowledge from a field. Collaborative knowledge belongs to several fields. In fact, in daily work, several teams (of several companies) and in several disciplines collaborate to carry out an activity. So there is a collaborative and organizational dimension to consider in a collaborative knowledge. Profession knowledge is generally about problem solving in a domain [4], whereas collaborative knowledge is about organization, negotiation and cooperative decision making in a project. So, to study the representation of collaborative activity, representations like task to do, strategies followed, concepts manipulated are not sufficient. We need other theories from cooperative, and organizations sciences to define a representation structure of this knowledge. In fact, we must represent knowledge about:

• the organization of the activity: actors, skills, roles;

• the process of the activity: tasks, resources;

• the collaborative problem solving: propositions, argumentation, conflicts, negotiation;

• the context: directives, rules, techniques, constraints.

2.3 Difference on Capturing of Knowledge

The realization of a project in a company implies several actors from sometimes, different groups and companies. For example, in concurrent engineering [18], several teams from several companies and in several disciplines collaborate to carry out a project. The several teams are regarded as Co-partners who share the decision-making during the realization of the project. This type of organization is in general dissolved at the end of the project. In this type of organization, the knowledge produced during the project realization has a collaborative dimension, which is in general volatile. The documents produced in a collaborative activity are not sufficient to keep track of this knowledge, which even the head of project cannot explain. This dynamic characteristic of knowledge is due to the cooperative problem solving where various ideas are confronted to build a solution. So extraction knowledge by interviewing experts or from documents as suggested in knowledge engineering approaches is not sufficient to show different aspects of the projects and specially negotiation [1] Traceability and continuous knowledge capturing are needed to extract knowledge from collaborative activities.

As we noted above, the challenge to manage daily knowledge is to deal with:

• How to capture information and interaction from daily activities without perturbing actors?

• How to structure information captured in order to make explicit the deep knowledge and behavior laws?

• How to implement learning techniques from knowledge in daily work?

Keeping track of knowledge cannot be reduced to traceability of information or behavior. Information captured needs structuring and classification in order to emphasize “What”, “How” and “Why” of a reasoning. Several steps can be definied for this aim (Fig. 3):

Capturing knowledge

Full size image

1. 1.

   Traceability of information: Several techniques can be used to keep track of information from the daily work: user profiling, information sharing, decision-making traceability, communication capturing, actions tracking, etc.

2. 2.

   Tagging captured information: Knowledge stakeholders are the adequate person that able firstly to structure information they produce. So, they can be invited to tag information by showing the usability of them. It is a first step of knowledge representation.

3. 3.

   Linking information to work environment and activity: This information must be linked to the context and the environment of work. We need to understand the context of the production of knowledge in order to represent it.

4. 4.

   Classifications: classifications algorithms can be then used in order to identify the occurrence of the elements and produce concepts. The definition of semantic memory [16] will be simulated by this approach, in which routines are represented based on concepts links.

3.1 Traceability of information

Keeping track of information from cooperative activity consists mainly to extract knowledge from several knowledge sources (Fig. 4):

Cooperative activity environment

Full size image

1. 1.

   Tools:

   1. a.

      Project management tools to kept project organizations (tasks, actors, skills, roles, etc.) and project context (budget, delay, planning, etc.)

   2. b.

      Workflow and documents to capture versioning of results and phases.

   3. c.

      E-mails, wikis to obtain discussions and interactions between actors related to coordination and problem solving.

2. 2.

   Environment:

   1. a.

      Meetings to capture decision making negotiation and cooperation organizations.

   2. b.

      Actor work-environment to be aware of activities.

An example of traceability from decision making in design projects is presented in the following sections.

3.2 Keeping Track of Decision Meetings

Several approaches in CSCW are developed in order to represent design rationale. We can note mainly IBIS and QOC, in which design rationale, named also as the space of design is represented as issues, options and arguments [3] Other approaches as DRCS [10] and DIPA (link decision-making to other elements of the projects like tasks, results and constraints [11]. To represent cooperative activity, we need to link elements from the project context and problem solving. Context is important to enhance learning in an organization. Designer needs to match the context of his problem to past ones in order to understand past related problem solving and use it to solve his problem. Design rationale approaches links decision-making to some aspects of the projects context but it-missed links to project organizations as roles and skills of actors, etc. DYPKM [1] approach recommends keeping track of design rationale from the project context and decision meetings. Traceability of decision-making has to be done on two steps taking notes during the meetings and structuring notes to define report. Secretary in a meeting has to take notes of discussions in order to keep track of links between these discussions, questions and participants. When writing report, he/she has to distinguish suggestions from arguments and to annotate them by criteria. In order to obtain this type of results and to integrate traceability during an activity, we define a tool «Memory Meeting»  [13] that supports collaborative decision-making traceability. Results are then linked to other project parts using designers’ tools like Product Life cycle management tools.

3.3 Memory Meetings

The principle of our work is to structure a meeting result on questions, suggestions, arguments and criteria. Links to participants who enunciate suggestions and arguments must be also recorded. Based on first tests of DYPKM [1] on real applications, we identify that secretary cannot take notes and structure them as the same time. So, we propose on our approach:

• First, secretary can take notes during the meeting, showing questions, discussions, participants and decisions

• Second, when he/she writes the meeting report, he/she should identify suggestions, arguments from discussions and define criteria.

In order to integrate collaborative decision-making traceability in the project activity, we use mobile equipment, like smartphone and organizer as support of our tool. Nowadays, a lot of people have a smartphone, so, we develop an application on an IPhone^{Footnote 1} that help to record and take notes during the meeting (Fig. 5). This application builds links between questions, discussions and participants. Questions can be extracted from the schedule of the meetings, in the same way, participants can be added from the meeting organization.

Prepare meeting using Memory Meetings

Full size image

This information can be directly obtained from project management tool through an XML file. Secretary also can directly put information about meetings in the Memory Meeting application (Fig. 5).

3.3.1 Memory Meetings Record

During the meeting, secretary, selects the question to be discussed, selects participant who speaks and records and takes notes at the same time (Fig. 6).

Discussions record linked to participant and question.

Full size image

So, notes and record are linked directly to the selected question and participant. He/she can select easily another participant, or another question. Results of the meetings can be directly extracted as XML file and/or used later to define the meeting report.

3.3.2 Memory Meetings Report

Secretary uses Memory Meetings application to define a report. Our aim on traceability is to keep track not only link between question, discussions and participants but also to structure discussions in order to identify suggestions, arguments. The QOC [3], approach shows that identifying criteria is important. They put on the main characteristics of discussions. We show in (Fig. 8) how criteria are important to index the evolution of the design. Criteria linked to decision-making show why actions and results are done. To enhance learning, we need to emphasis not only how actions has been done and with which concepts, but also why these actions has been done in a given way. Actions can be done in several ways depending of techniques but the goal of problem solving task shows strategy behind actions. It is the related to heuristics rules and behaviour laws [14].

In order to guide the identification of discussions characteristics in design, we define a set of criteria based on an analysis of design problems [12]. Criteria can concern the product and the project organization problem (Fig. 7).

Design project problems (Matta et al., 2000)

Full size image

So secretary can directly annotate discussions by criteria using Memory Meetings application (Fig. 8). Criteria can be also modified related to project type. We guess that small interface of Smartphone is not easy to use for this activity. So, Memory Meetings is available on tablet.

Identifying arguments, Suggestions and annotating them by criteria using Memory meetings application.

Full size image

The result of this work is on two aspects: a XML file, which will be integrated in project management tool, and a MsWord Report (Fig. 9).

Example of Meetings Report generated by MMReport. Each question is summarized. Discussions are characterized by its type (Proposition, Argument, Decision, etc.) and by its main characteristics (Function, Behaviour, communication, etc.).

Full size image

In cooperative activity, several aspects must be linked (Fig. 10):

Linking concepts in cooperative activity

Full size image

• The organization: different participants, their competences, their organization in sub-teams, the tasks which are assigned to each participant, the planning of work, etc.

• The reference frames: rules, methods, laws, directives, tools, etc.

• The results: several steps and versions of results.

• The decision making process: the negotiation strategy, which guides the making of the decisions as well as the results of the decisions.

For instance, linking decision-making criteria and evolution of the result shows how the artefact is evolved and the reason of such evolution (Fig. 11). This example are extracted from a project that aims at proposing a number of principles that can guide companies to evaluate risk in their activities [1].

Linking criteria to product evolution

Full size image

Question will be linked to task, decision to result or task. Meetings participant has specific skill and are assigned given roles. So, if we follow links between decision, criteria and skill, we can obtain how participants’ skills are influenced decision-making. For instance, in the example of risk principles definition (Fig. 12), we note the consulting participants make more attention to the validity and comprehension of principles. Participants from ergonomics put on the motivation in the application of principles. For medical actors, they will be a control of the application of principles.

Links between question, participants’ skills and decision-making characteristics.

Full size image

As we noted above, knowledge extracted must be integrated in work environment: tools and techniques used by organizations actors. We study how to integrate decision making traces in product Life cycle tools.

5.1 PLM

A product Life cycle Management (PLM) is defined as “a strategic business approach that applies a consistent set of business solutions in support of the collaborative creation, management, dissemination, and use of product definition information across the extended enterprise from concept to end of life - integrating people, processes, business systems, and information». «PLM holds the promise of seamlessly integrating and making available all of the information produced throughout all phases of a product’s life cycle to everyone in an organization, along with key suppliers and customers.»  [19]. So, a PLM platform allows managing the product data along its life cycle process: specification, design and manufacturing (Fig. 13) and requires efficient traceability functionalities, often based on the definition of standards.

PLM functions

Full size image

Despite of these definitions, major PLM platforms focus more on data management rather than on Knowledge Management. These platforms are indeed centralized within an electronic vault that enables data sharing through authentication functionalities. These functionalities accelerate cooperative design but hardly provide solutions for project memory. We propose to integrate project data traceability using “Windchill 10”, a PLM tool developed by PTC (www.ptc.com). Firstly, we analyze how Windchill handles project management before identifying how it allows keeping track of project knowledge. Based on existing analyses [2], this analyse illustrates the functionalities of PLM.

5.2 Windchill and Project Management

There are a number of tools defined as a support of project management. We can note mainly MOSS (produced by Microsoft) and Quickplace (produced by IBM). In these tools a number of functionalities are provided. Table 2 shows the main functions of these tools which are important to handle project management.

We compare Windchill functions with MOSS in order to analyze if this PLM allows handling a project management and consequently finding information about projects (organization and results). Even if PLM is not defined to manage projects but to handle the production process, it provides also functions that can support project management. Table 3 shows a comparison of Windchill functions and MOSS.

This comparison shows first that some project information can be extracted from Windchill, especially links between the task management, agendas, wiki and documents. There are still functions to develop in order to handle organizations (competences of participants) and decision making. Both Windchill and MOSS allow developing of web services. So, extension of Windchill functionalities can be proposed for enhancing its standard functionalities.

5.3 The Organizations of Elements in Windchill

There are a number of functions that support design project in Windchill. This organization links project to team, to documents and to process planning (Fig. 14).

The organization of a project in Windchill

Full size image

We can distinguish that some concepts needed in project memory are already represented in Windchill:

• The project team: members (their organization and contact), their role.

• The project process: planning, tasks, resources, milestones.

• Results: deliverables and documents representing the different parts of the product and in different views (geometric, functions, etc.).

There are also links between these classes:

• Task, members, roles and deliverables.

• Deliverables and intermediate documents.

There is also a traceability of evolution of the project:

• The changes of objects: versioning, forums, workflow, and meetings reports.

• The evolution of the product during process: concept, architecture, prototype, series.

In fact, the product development is represented as a decomposition of objects. Each object is described by its parts (components), description documents (specifications, propositions, etc.) and dynamic documents (CAD, etc.). Each part is considered as an object and be described by parts, documents and dynamic documents.

For each problem related to a part, a problem report (if needed) is defined by the designer. A Modification workflow is then generated corresponding to the problem report (Fig. 15). This workflow is decomposed by decision-making and modification phases [13]. The impact of the problem is calculated and related project members are asked to decide about the modifications and considering its impact. Decision making can be done by meeting and/or using a vote system. When the decision is made, modifications can be performed to the part.

The description of the product in Windchill

Full size image

5.4 Project Memory Within Windchill

To handle a project memory, we need to type the evolution of the project. We propose in our work to use decision making process and especially criteria of negotiation in order to annotate the evolution of a project. As a first step we propose to use the product evolution and modification workflow in order to keep a structured track of this evolution. So, we change the modification report in order to emphasize the characteristic of asked modification in decision report. Summary of general problems in product design can guide the definition of this decision characteristic (Fig. 16).

Example of integration of Project Memory in Windchill

Full size image

Using report generated by our application “MMReport”, each change can be annotated by its characteristics. Then, we can obtain what is relevant in this evolution (Fig. 16). In fact, a problem is discussed in a meeting. So, we can extract from “MMReport” XML file, information related to the discussions and the decision of the questions, and especially the main characteristics of decision. They are integrated as modification report in Windchill. So we obtain a link between the characteristics of the modification (criteria) the members who vote this modification and the result of this modification. Relations between questions and problems can be identified, by using links to product parts in windchill, when preparation a meeting using “MMRecord”. We developed extended applications of “MMRecord” and “MMReport” for this aim.

This characteristics annotation provides a first structure of the product evolution. Based on that and using links between project elements, we can extract several views about the design of the product. For example, the reason of a result based on the project organization: members’ profile and roles and tasks, why such result for this requirement, etc.

We are working at changing the modification workflow and defining a research engine emphasizing the reason of the product.

As we can note, our proposition is mainly on the product evolution, but the project knowledge concerns also the organization of a project and not only the results. In Windchill, there is no representation of the evolution of tasks. In fact, tasks are represented in a planning and linked to members and objects. But the evolution of the planning is not enhanced in Windchill. In order to respect our project memory structure we plan some changing in the PLM in order to handle as same the evolution of the project as the product. In the same way, we have to keep a structured track of this evolution. So, as we proposed a structuring of the product using characteristics, criteria will be also used to characterize decisions on tasks and project members.

We also integrate MMreprot results in Agilefant tool. Agilefant as support tool of the SCRUM method provides techniques to manage tasks and resources (actors/time). Workflow is organized as stories distributed among time and actors. In each story, actors can answers a description of their work. So, we include the related peace of MMReport result in the description of the story.

6.1 Classification

Classification can be defined as the process in which ideas and objects are recognized, differentiated, and understood [5] while knowledge classification is the process in which knowledge is recognized and reasoned. Classification algorithms are used in biology, documentation, etc. They help to recognize an object with characteristics, related to a predefined hierarchy. We focus on knowledge classification in design project memory in order to not only represent the knowledge structure, but also classify knowledge to reuse it.

6.2 CKD “Collaborative Knowledge Discovery” Approach

The nature of knowledge plays a quite important role in knowledge classification. On one hand, according to cognitive science, memory is where information is stored and knowledge is generated. There are two types of memory: short-term memory and long-term memory. Information is registered in short-term memory with a limited duration, it can be gathered in order to maximize the capacity of memorization. For each time a concept is rehearsed while it is in short-term memory, it is reinforced in long-term memory, as a result, contextual information can be encoded into more abstract and more organized concept networks in long-term memory [16] and knowledge reside in the concepts as well as associations in between. Therefore, knowledge can be considered as useful conceptual networks that reside in long-term memory in human mind. On the other hand, knowledge engineering, as an application of logic and ontology, attempts to represent knowledge of human mind by building computable models of some domain for some purpose. The famous semiotic triangle has shown three dimensions of knowledge: “sense”, “reference” and “sign”. Sign stands for the object that human refers to, and sense is the concept or idea associated with sign and object [15]. For the same object, people with different background can give different signs; concept alters according to different context. To represent the meaning triangle, approaches based on semantic network, ontology, logic etc. has been developed.

We propose the CKD “Collaborative Knowledge Discovery” approach [7] based on classification of relation networks between negotiation, coordination and results.

The principle of classification approach is to identify similar graphs of cooperative activities as routines with a weight factor that indicates their importance. The weight factor is defined as percentage of recurrence of a routine among past similar project events. Therefore, the result of classification will be a set of relations between cooperative activity concepts. This result routine can be considered as a knowledge rule for actors to learn from to improve future project performance. We propose then three classification algorithms:

• Problem solving: at a specific project phase, we can classify decision-making process for one similar issue. Solutions that are repetitive will be classified as essential solutions, the solutions that are distinctive will be considered as explorative attempt with its precondition as an explanation.

• Cooperation diagnoses: an important subject that we try to study is cooperation. This classification view allows us to verify whether there are parallel tasks that imply cooperative design or regular meetings concerning whole project team. Projects that are not undertaken concurrently can lead to unsatisfactory results, e.g. solution duplication or excess of project constraint.

• Management diagnoses: this classification view will focus on project organization influence on different project memory modules. For example, we can classify project realization with an organizational dimension to examine how project organization arrangement can influence project realization. This classification will be further demonstrated in the next section.

The three aspects proposed above are the most interesting and practical classification views that we find so far, however we do not exclude the possibility that more useful classification views exist.

In the following we present an example of using Memory Meetings and classifications in software design projects.

Tabspec consists of two software design projects, undertaken by two different groups of Master students of University of Technology in Troyes in the year 2012 and 2013. The group members consist of students majoring in computer science and students majoring in mechanical design. The project 2012 involves eight students, among whom four major in computer science and 4 in mechanical design, and for project 2013, 5 students participated, 3 of them major in computer science and 2 major in mechanical design. There was no predefined organization for each group.

The goal of this project is to design a tablet application, which aids a mechanical technician in product maintenance. This application needs to provide pertinent knowledge concerning a certain problem of product, and enable the technician to order necessary parts to repair or replace the product; more importantly, the technician should be able to update information concerning product maintenance (e.g. report a design default, order a new product etc.) in company’s PLM and ERP system through this application. Budget limit and time delay are specified for the project, and three major tasks are requested:

• Analyze existing technologies

• Define the function specifications of the application

• Realize a prototype of the application

7.1 Information Traceability of the Tabspec Projects

Students are required to use the tool «Memory Meeting» to register work meetings. We collected the registration of their work meetings and their report. They have to follow a specific discussion forum that allows us to know about the organization and the coordination of their work. The conceptual design of the tablet application focuses on the specification of functions. The information of meeting recording is fit into the decision-making model on the “issue” function definition of the tablet application. An example of decision-making process on the issue function definition in the project 2012 and 2013 can be shown (Tables 4 and 5):

Students have several skills: computer sciences, industrial engineering and mechanical engineering. They decide to work in subgroups (Fig. 17)

Coordination of Groups in 2012 and 2013.

Full size image

These traces are a representation of examples of software design problem solving. We need to identify recurrent decision-making situation in order to identify routines and collaborative problem solving strategies related to project types and problems. We know that strategies can be developed when human, repeating an action several times, can identify a routine which can be applied to similar situations. We propose in this work to classify collaborative decision-making traces in order to identify routines and problem solving characteristics that help for learning.

7.2 Classification of Tabspec Projects

A problem-solving rule on the issue “function definition” can be extracted by comparing the decision-making process on this issue of both projects. We classify repetitive solutions as essential solutions for the issue function definition, and distinctive solutions as explorative cases with a precondition (Fig. 18). One solution was distinguished: Connection the Tablet to Data Bases. Different explored solutions are identified: Automatic or manual object recognition, One or several Data Bases. For each explored solution, we store arguments in order to justify these propositions. That helps to understand reasons of and the inconvenient of propositions.

Classification of problem solving in the software design project

Full size image

Cooperation rules on this project can be extracted by classifying project planning, which is represented by the sub-network decision-making process and project-realization. If there are tasks concern module integration and regular meetings on project specification of whole project team, then this project is undertaken concurrently. If no meetings are held with the whole group or no integration task is assigned to more than one sub-group, then this project is considered failed at concurrent design. We can see (Fig. 19) from the project information 2012, four meetings were held inside each sub-group and only one final meeting involved the entire project group, but the issue of the final meeting was “collecting each group’s work”, which means no integration issue was dealt with. Apparently in the project 2012, design activities were not organized concurrently, which leads to the result “database duplication” and “expensive project cost”. Linear project planning leads to bad communication between different sub-group designers, which result in poor integration design (Fig. 19).

Comparison of organization and project result

Full size image

To sum up, the challenge to manage daily knowledge is to deal with:

• How to capture information and interaction from daily activities without perturbing actors?

• How to structure information captured in order to make explicit the deep knowledge and behavior laws?

• How to implement learning techniques from knowledge in daily work?

We deal with daily knowledge produced in cooperative activities. We believe that main activities are realized in collaboration with actors in an organization. We observe then interaction between actors and between actors and their environment as a source of knowledge production in the organization.

So, we discuss in this paper how to keep track and structure this type of knowledge, by considering its several dimensions: coordination, cooperative decision making and communications. Traceability of cooperative decision making approach is presented. Decision-making is defined as a space of alternatives in which human need to select a solution of a problem. In cooperative activity, decision is the result of negotiation and discussions for the evaluation of several choices. So, argumentation and negotiation techniques must be represented in order to give the traces of a decision. Our aim is mainly to promote learning from past projects. So, decision traces must be structured. We propose to use cooperative activity problems and conflict types as criteria in order to emphasize the main characteristics of cooperative decision-making.

Otherwise, traceability will be integrated in the environment of actors. So, we develop applications respecting the work of meetings secretary in order to keep track of decision-making meetings without adding any efforts for actors. Using tablets and smartphones gives interactive and fun for taking notes and writing reports. Several secretaries ask to use these applications in other type of meetings like direction and organization management meetings. Structured traces must be also linked to other tools that support cooperative activity. We show how these traces can be linked in project management tools and how they reflect knowledge in project memory. Knowledge so represented define only cases of projects; we need classifications approach in order to identify strategies and plans used in collaborative activity. CKD approach shows how classification algorithm can be used in order to classify occurrences in project traces. We test our approach in several design projects done by students. An example, is illustrated in this paper. We aim at testing it in a real design projects.

Other dimensions of cooperative activity must be considered as knowledge sources. We work on extracting knowledge from interactions and especially e-mails in order to extract coordination ans negotiation discussions.

Finally, it will be interesting to extend our work for individual traceability and actor profiling in order to discover if it is possible to extract knowledge directly from actor’s work environment without dealing with interactions aspects.