How to Capture Knowledge from Project Environment?

. From the beginning, knowledge is a preoccupation of human preoc-cupation. A lot of questions are still discussed: what is knowledge? How knowledge is built? How is it represented in mind? How can it be kept? How can it be learned? Our challenge is to capture design project knowledge related to work episodes, to extract and to represent the deep knowledge which belongs to the type of projects and design activities. In this paper, we present an approach that helps to capture knowledge from daily design project environment and to aggregate this knowledge as classifications.


Introduction
From the beginning, knowledge is a human preoccupation. A lot of questions are still discussed: what is knowledge? How knowledge is built? How is it represented in mind? How can it be kept? How can it be learned? … The notion of Knowledge is defined from the antiquity. Platon, for instance, defined the thought as the intellectual model of objects. Heraclite went towards the definition of the logos as a triangle in which distinguished thought, from expression, from reality. Saussure defined the base of the semiotic as: a representation of knowledge involved in an activity, which is related to a specific symbol [10]. Currently these representations are more and more used to enhance learning from expertise and past experience. So, human who recog-nizes concepts in the reference makes sense. Based on this theory, knowledge engineering approaches provide techniques that help to represent expertise as references and to promote learning from these references, i.e. knowledge representation using semantic networks. For instance, currently, knowledge-sharing (semantic web studies) techniques use ontology as a guide to share a common sense of a concept in a domain [6]. These techniques are commonly used to represent knowledge in a given domain for a given profession. In our work, we study knowledge produced from a cooperative activity as design projects, in which several actors with different skills and backgrounds work together to reach a given goal. Our challenge is to capture this type of knowledge related to work episodes and to extract and represent the deep knowledge, which belongs to the type of projects and design activities. This paper presents an approach for capturing knowledge from daily design project environment and aggregating this knowledge as classifications.

Capturing knowledge from design projects
Design projects are currently done in cooperative way. Expert interviews, and Textmining are not adequate to capture the collaborative dimensions of knowledge, which it is produced by interactions between actors. Knowledge can be extracted directly from daily work environment. So, techniques and tools as proposed on CSCW [9] are used to support cooperative activities. Information and data will be captured directly from communication, coordination and decision-making support techniques. However, knowledge extracted from daily activity is mainly related to episodic memory. Routines and heuristics rules can then be defined to build semantic memory. By keeping track of knowledge during the realization of each project, the memory is defined as projects cases. These projects will be indexed not only by keywords and the projects' type but also by the main criteria underlined their execution.
This indexation must be linked to a typology of projects and problems. Aggregation and classifications of rules help to extract problem solving strategies related to project's typologies and problems (Erreur ! Source du renvoi introuvable.).

Representing design knowledge as Project memory
Design project knowledge can be represented as a project memory, which can be described as "the history of a project and the experience gained during the realization of a project" [7]. It must consider mainly: • The project organization: participants, competences, sub-teams, tasks, etc.
• The reference frames used in the project various stages: rules, methods, laws… • The realization of the project: solutions evaluation and incidents management.

•
The decision making process: negotiation, argumentation and decision-making.
Often, there are interdependent relations among the various elements of a project memory. Links between these elements emphasize the design rationale in a project.
Project memory architecture

Traceability of information from design projects
Keeping track of information from design projects mainly consists to extract knowledge from several sources: o E-mails, wikis to obtain interactions relayed to coordination.
• Environment: o Meetings to capture negotiation and cooperation.
o Actor work-environment to be aware of activities. In our work, techniques are developed for traceability of decision meetings and e-mails.

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 and DIPA link decision-making to other elements of the projects like tasks, results and constraints [7]. To represent cooperative activity, links between elements from the project context and problem solving are needed. Context is important to enhance learning in an organization. The designer needs to match the context of his problem to past ones in order to understand them and solves 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 [2] approach recommends keeping track of design rationale from the project context and decision meetings. Structuring information cannot be done directly during the meetings. Also, the meetings animator cannot represent different views of discussions afterward as recommended in several design rationale techniques. Traceability of decision-making has to be done on two steps taking notes during the meetings and structuring notes to define report. The 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 annotate them by criteria. In order to obtain this type of results and integrate traceability during an activity, a tool « Memory Meeting » [7] is defined to support collaborative decision-making traceability (Fig. 2). Results are then linked to other project parts using designers' tools like Product Life cycle management tools.
Example of structured report of decision-making meeting. Information are structured as Fig. 2.
design rationale methods adding links to actors organization, skills, …

Keeping track from communication
Several approaches study and analyze e-mails as a specific discourse [8], for instance, tagging work. Other works use natural language processing in order to identify messages concerning tasks and commitments. Pragmatics analysis of e-mails uses some of these methods like ngrams analysis. However techniques studying e-mails, often do not consider the context of discussions, which is important to identify speaker's intention. In this work, e-mails are extracted from professional projects. So, pragmatics analysis and topic parsing are mixed. The results are linked to project context (skills and roles of messages senders and receivers, project phases, and deliverables, etc.) in order to keep track of speakers' intentions. As pragmatics analysis shows [1], there is not only one grid to analyze different types of speech intentions. A grid of request act is built for our study to help the identification problem solving in interactions [8].
Firstly, messages related to project relevant topics are identified. Then, the volume of messages related to each subject and phases are calculated.
In each message thread (message and answers), are represented: • Information about organization: authors, to whom, in Copy • Information about phases: Date and hour of messages and answers • Information about product: topic and joined files • Information about message intention: main speech act. The role and skill of messages' senders and receivers help to analyze the role of the message in problem solving and the nature of the content (solution answering a prob-lem, proposition discussions, coordination messages, etc.). In the same way, linking messages to phases helps to identify the main problems in each one. To begin with, the speech act analysis on problem solving is focus on identifying request and solution. So, speech acts that help to localize a request in a message are identified [8].
Request act grid is identified for this aim. In this grid, there is two request types: direct and indirect. A "Direct" request may use an imperative or a performative form like obligations and want or need statements. An "Indirect" request may use query questions about ability, willingness, and capacity, or may use statements about the willingness (desire) [11].
Then, we study the organization of related messages thread in order to identify the solution proposed (if it exists) to the request (Fig. 3).

Knowledge discovery by classification
Low-level data in project memory should be mapped into other forms that might be more compact, more abstract, or more useful [4]. In this section, a classification method to extract knowledge from design project memory will be proposed. In order to generate rules that represent interrelations between concepts or sub-networks, machine-learning techniques are considered. An evaluation of major machine learning techniques (statistical methods, decision tree, rule based method and neural network) is carried out in search for the appropriate algorithm [5]. Our intention is to classify project memory into rule-based knowledge, which leads us to choose a rule-based algorithm ITRULE. It can induce an optimal set of rules from a set of examples [4]. 1. Problem-solving view: at a specific project phase, we can classify decision-making process for one particular 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.
2. Cooperation view: this classification view allows verifying whether there are parallel tasks that involve cooperative design concerning whole project team. This rule will reveal the influence of concurrent design on project result. i.e. Fig. 4 3. Management view: this classification view will focus on project organization influence on different project memory modules.

Conclusion and perspective
In this paper, we presented our work on traceability and structuring of daily knowledge especially from design projects. Two techniques that help to capture knowledge from decision-making and from communication were described. More techniques in order to capture knowledge from designer's environment (linking to other work on user profiling) are under development. Captured knowledge needs to be classified in order to identify routines. Our classifications rules hypothesis needs to be tested in a large number of examples in order to identify ontology of design projects rules.