By Davy Monticolo, Vincent Hilaire, Abder Koukam et Samuel Gomes, UTBM.
2007
This paper presents a knowledge management experiment realized in an industrial company. Our research concerns the
development of a project memory to capitalize Information and Knowledge created, shared and reused in a product
design project. The project memory is based upon a domain ontology called OntoDesign which enables to easily exploit
it. This is implemented with the Semantic Web technologies in order to provide a framework for the annotation and the
reuse of knowledge. This article describes the design rationale of OntoDesign.
1. Introduction
In today’s challenging global market, companies have to innovate in order to improve competitiveness and business performance. They must bring innovative products to market more effectively and more quickly to maximize customer interest and sales. The pressures to reduce time, improve product quality, and lower costs have not gone away; they are being reaffirmed and folded into programs that focus on delivering the “right” product. Product leadership companies must continue to enter new markets with innovative products.
This requires leveraging and reusing the product-related intellectual capital created by partners working together. Business innovation must occur in several dimensions: project organization, product definition, production engineering, ergonomics design, environmental impacts, etc.
This knowledge is based on experiences of human resources, and project experiences in terms of project management issues, design technical issues and lessons learned. The coherent integration of this dispersed know-how in a corporation, aimed at enhancing its access and reuse, is called « corporate memory » or « organizational memory ». It is regarded as the central prerequisite for IT support of Knowledge Management and is the mean for knowledge capitalization, distribution, and reuse. We work on the design of a project memory model that we have called ‘MemoDesign’.
This model is issue from a work with project team in order to store the crucial knowledge created, used and shared in a project. Indeed a project memory is simply an organizational memory for a specific project team; it has a more limited scope than organizational memory since it is composed by the knowledge emanating only during engineering projects. Indeed the project memory is a memory of knowledge and information acquired and produced during the realization of the projects. Thus, project memories constitute a basis for knowledge capitalization and reuse.
Our approach aims to analyze and model the professional process used by project team in order to identify emanating Knowledge. In collaboration with project teams, we have defined the types of knowledge to capitalize and which represent the structure of our project memory.
Then we have explained and described each concept and relation of the project memory to build the associated ontology (Called OntoDesign).
This industrial experiment allows us to propose a domain ontology building process. In section 1 we present the need of capitalizing Knowledge in the company. The second part explains our approach to build a project memory and its associated domain ontology. The last section describes the implementation of the ontology in using Semantic Web languages.
2. Project Memories in Mechanical Design
2.1 Industrial context
Our works are deployed in a company of four hundred employees in the domain activity of window rolling shutters. The research and development department is constituted by fifty technicians. The method department, laboratory department and the design and engineering department work together through a project organization in a concurrent engineering concept.
One of the problems we have tackled is to enable professional actors to reuse their collaborative professional experience from past projects. The direction of the company has decided to develop a knowledge engineering approach in building project memories to solve this problem.
Our experience shows us project memories are difficult to write from interviews since this approach needs numerous time and human resources for every project. Moreover this work has to be realized by a knowledge engineer to analyze each activity and define knowledge to capitalize. Nevertheless, during projects, engineers don’t have time to answer interviews and the design activities monitoring by knowledge engineers is difficult to realize.
Consequently we have decided to conceive and develop tools to assist engineers in building project memories. This requires understanding the design collaborative activities with the view to define emanating knowledge which has to conceptualize in a domain ontology in order to be interpreted by knowledge engineering tools.
2.2. Why to build Project Memories
The company has a intellectual capital created by project teams when they develop new product [5]. Indeed in a model of concurrent engineering, projects use different professional specialities to design and develop products. Each professional actor with his specialities brings several competences to jointly solve some tasks. Those competences use knowledge to realise activities. Knowledge engineering approaches model this type of knowledge to implement methods and classification technique to make this knowledge accessible in a form defined according to the context.
In an engineering context, it’s difficult for professional actors to have an overview of a project or to remember the collaborative work of past projects. Only teams which have the practice to work together and enough experience, can define the fundamental knowledge to store.
We have chosen to store this knowledge in the form of a project memory. The project memory contains knowledge acquired and produced during the realization of the projects. In an organisation of project and in a concurrent engineering context, project memories seem to be a good solution to capitalize knowledge.
Indeed Project memories detain knowledge relative to the description of events (tasks, problems, success…) encountered all along the project. Moreover it contains Knowledge associated to the results of the collaborative design activities.
3. Engineering the ontology OntoDesign
Our approach to build the domain ontology is based on five steps (figure 1) :
1. A modeling of the domain in order to identify emanating knowledge,
2. Knowledge validation by the professional actors,
3. Creation of a knowledge typology and taxonomy,
4. Analysis of existing ontologies and a conceptualization of terms,
5. Specification of the concepts and their relations
3.1. Professional activities modeling to identify emanating Knowledge
Our cartography of knowledge is based on its identification from an organizational approach to model the professional processes implemented in projects. Our modeling is built with the concepts of Roles,
Interactions, Organization Competence and Knowledge. An organization models the professional process containing several under organizations modeling themselves the phases and activities of the process. Inside, roles are generic behaviors. These behaviors can interact mutually according to interaction pattern. Such a pattern which groups generic behaviors and theirs interactions constitutes an organization. Indeed professional actors instantiate an organization (roles and interactions) when they exhibit behaviors defined by the organization’s roles and when they interact following the organization interactions.
Inside the professional process, the actors use and share their knowledge to carry out in a collaborative way the activities of engineering and thus develop their learning resulting from the knowledge capitalization process. From the experiments and observations carried out in the company, we defined, for each organization (activity of the professional process) several roles interpreted by professional actors. We allocate to these roles the competences they used to achieve the activities.
Competences are the capacities for an individual to implement its knowledge and to develop its know-how. Competences are also developed during the achievement of professional activities, in which knowledge sharing takes place. Each competence is aggregated with a set of knowledge.
In the activity (i.e. organization) ‘to write the schedule of conditions’ we observe three roles (Figure 2).
The role ‘Technical commercial assistant’ uses one of its competences; we read it like the capability to ‘To formalize the requirement of the customer’. This competence requires three elements of Knowledge which are used to satisfy the organization. In the RIOCK diagram the type of knowledge is read like Knowledge on, for example the role project leader possesses the Knowledge on ‘means of industrialization of the company’. In addition RIOCK presents the result of the collaboration among these three roles; here this is the schedule of condition
3.2. Defining knowledge to capitalize by the professional actors
The modeling of the professional process with RIOCK allows us to obtain a precise identification of knowledge used, shared and created. With this modeling we have wrote a series of knowledge which we have submitted to the professional actors. Afterwards they have validated knowledge to capitalize in the project memory. We can draw up a list of knowledge identified like necessary to capitalize.
3.3. Creating the Knowledge Typology and Taxonomy
In order to present a Knowledge classification we have realized a classification of Knowledge. We have identified six groups of Knowledge (table 1). Each group represents a type of Knowledge.
In order to structure the Knowledge, we have created taxonomy. This is a classification of information entities in the form of a hierarchy, according to the presumed relationships of the real-world entities that they represent. Furthermore the classification is based on the similarities of the information entities called concepts. This taxonomy represents the structure of the project memory MemoDesign (figure3).
Name of the knowledge type | Knowledge |
Context of the projet (ProjectContext) | Knowledge presenting the origin of the project Knowledge describing the organization of the project |
Evolution of the project (ProjectEvolution) | Knowledge related to the history of the evolution of the project |
Professional processes set up in the project (ProjectProcess) | Knowledge presenting the activities carried out, the interventions of the professional actors and the information handled for each activity |
Glossary of the projet (ProjectGlossary) | Knowledge defining the vocabulary used during the project |
Expertise in the project (ProjectExpertise) | Knowledge related to the professional rules used to develop the product |
Exprience developed in project (ProjectExperience) | Knowledge describing the errors, failures and difficulties in the project |
3.4. Analyzing existing ontologies and conceptualizing the terms of the taxonomy
Our first work, after the identification of knowledge to capitalize, was to analyze and study existing ontologies which we could re-use. Among ontologies modeling companies we can mention “Enterprise”, “TOVE” and “O’ COMMA”. The first two ontologies are reusable at the informal level. Indeed some concepts presented guided us in the conceptualization, in particular for the activity part (“activity”) of Enterprise and the part product (“part”) of ontology TOVE.
The ontology O’ COMMA is reusable since it is developed using RDF diagram, technology of the semantic Web. This ontology is complete for presenting a memory for a company but its concepts do not cover the particular terms used in product design projects. Thus we have conceptualized the project memory MemoDesign and define attributes and relations between these concepts in using the study of the three ontologies presented above
3.5. Specification of the concepts, their attributes and relations
This step of the ontology engineering process is based on the methodology proposed by Gandon [4] i.e. the use of two tables to specify concepts and their relations:
• The table of concepts (see Table 2) giving: unique name of potential concepts (Term), their concept ID (ConceptID), their inheritance links (ParentID), and
a natural language definition of the notion behind the concepts to try to capture their intension (Natural Language Definition).
• The table of relations (Table 3) giving: unique name of potential relations (Relation), the concepts they link (Domain and Range), and a natural language definition of the notion behind the relation to try to capture their intension (Natural Language Definition).
Nowadays the ontology OntoDesign has 104 concepts and 32 relations. It grows as we reuse knowledge since we need to specify new relations.
Table 2 : Extract from the original concept table
Concept | ConceptID | ParentID | Natural Language Definition |
Product professional actor |
Product Professional actor |
ProductEvolution Project organization |
Result of the project Human who takes part of a project |
Table 3 : Extract from the original relations table
Relation | RelationID | Domain | Range | Natural Language Definition |
Give detail constraint function Literale rule |
Give detail constraint function Literale Rule |
Functional analysis Literale Rule |
Constraint Function Design Rule |
Specification of a Constraint function A literale rule is a design rule |
3.6. Implementation of OntoDesign with the Web Semantic Technologies
We have specified the project memory concepts and their relationships in the ontology OntoDesign with Protégé 2000 in order to visualize, validate and build our ontology in the OWL language in conformity with the W3C recommendations. OntoDesign provides an integrated conceptual model for sharing information related to a mechanical design project.
An OWL property (figure 4) is a binary relation to relate an OWL Class (Concept in OntoDesign) to another one, or to RDF literals and XML Schema datatypes. For example, the “infoInput” property relates the Document class to the Activity class. Described by these formal, explicit and rich semantics, the domain concept of Activity, its properties and relationships with other concepts can be queried, reasoned or mapped to support the Knowledge sharing across the mechanical design projects.
4. Conclusion
In this article, we have presented our approach for classification of Knowledge and for building a project memory and its associated domain ontology. The first step of this methodology is based on the use of the RIOCK formalism which helps Knowledge identification. This Knowledge has to be validated by professional actors. With the list of validated knowledge we can create a typology and a taxonomy. This work allows us to build the structure of a project memory called MemoDesign. The project memory is a model presenting the organization of knowledge and information created, used and divided during a project, for their reuse by professional actors.
The following step of our classification of Knowledge is to analyze existing domain ontologies in order to reuse some concepts. This step helps the conceptualization of the MemoDesign terms. The last step of our work is about the specification of concepts, attributes and their relation in order to build the ontology called OntoDesign. This ontology favors the formalization and the distribution of Knowledge through tools aided professional actors like the Multi Agent System KATRAS .
The next step will be to develop a knowledge engineering module based on KATRAS and OntoDesign. This system will monitor the action of the professional actors inside a eGroupware and capitalizes, annotates, and broadcasts Knowledge in using the semantic web technologies and our domain ontology.
References
1. Atifi H., Matta N., Pragamtic Analysis of Intercations for Project Memory. juin 2002, Coop’2000 Workshop Proceedings: Project Memory. SAINT RAPHAEL. 1-5
2. Castelfranchi C. (2004); Engineering Social Order, Fifth International Workshop Engineering Societies in the Agents World, Toulouse, France
3. Fox, M.S., and Huang, J., (2005), « Knowledge Provenance in Enterrprise Information », International Journal of Production Research, Vol. 43, No. 20, pp. 4471-4492.
4. Gandon F., Ontology Engineering : A Survey and a Return on Experience, INRIA Report n°4396, 2002
5. Grundstein M. From capitalizing on Company Knowledge to Knowledge Management, D. Morey,
M. Maybury, B.Thuraisingham, knowledge Management, Classic and Contempory Works, MIT Press, Cambridge, Massachussetts, p. 261-287, 2000
6. Hilaire V., Koukam A., Gruer P. & Müller J-P (2000); Formal Specifi-cation and Prototyping of Multi-Agent Systems. Engineering Socie-ties in the Agents’ World, in Lecture Notes in Artificial Intelligence. n°1972, Springer Verlag.
7. Klein M. – Capturing Design Rationale in Concurrent Engineering Teams, IEEE, Computer Support for Concurrent Engineering, January 1993.
8. Matta N., Ribiere M., Corby O., Lewkowicz M., Zaclad M.. Project Memory in Design, Industrial Knowledge Management – A Micro Level Approach, Rajkumar Roy (Eds), Springer-Verlag, 2000
9. Monticolo D., Gomes S., Hilaire V., Serrafero P. (2007); ‘Knowledge capitalization process linked to the design process’, International Join Conference on Artificial Intelligence (IJCAI). Workshop on Knowledge Management and Organisational Memories, Hyderabad-India, p13
10. Monticolo D., Hilaire V., A. Koukam, S. Gomes, ‘An e-Groupware based on Multi Agents Systems for Knowledge Management’, IEEE International Conference on Digital Ecosystems and Technologies (DEST), Cairns-Australia, February 2007, 6p
11. http://protege.stanford.edu
12. Uschold M., King M., Moralee S. and Zorgios Y. (1998), » The Enterprise Ontology « , The Knowledge Engineering Review, Vol. 13, Special Issue on Putting Ontologies to Use (eds. Mike Uschold and Austin Tate). Also available from AIAI as AIAI-TR-195
http://www.aiai.ed.ac.uk/project/enterprise/