JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

40

Issues in Structuring the Knowledge Base of a Project Memory Management System

Hatem BEN STA
LI3 Laboratoire de lIngnierie Intelligente des Informations; Institut Suprieur dInformatique 2, Rue Abou Rayhane El Birouni, 2080 Tunis Universit de Tunis a El Manar

Abstract: The knowledge preservation of design project is an important issue for high technological industry.
A general framework for managing knowledge pertaining to design projects is proposed. The objective is to allow preserving relevant information to be used later, thanks to a product design project memory. We introduce a generic platform-independent model that fits requirements of project memory management; this platform is based on UML generic models. We describe P2M2, an original implementation over object-relational technology in a multi-tier architecture; model transformation based on Model Driven Architecture (MDA) is developed. Finally, we discuss the benefits of ontology engineering for Project Memory management purposes. Keywords: Project Memory, Object-Relational, Knowledge Management, Ontology

1. Introduction:

In design projects characterized by a high level of technological and organizational complexity, an important question is to know how a company or partners consortium can maintain competencies generated during an engineering project until their next use, and how the technical choices validated or invalidated within a previous projects can be reused. In the framework of high technology products, designers use their experience to make choices. The justification of these choices is sometimes stored in documents which are exploitable with difficulty or at the very worst remains in the implicit domain and is never formalized. These choices depend on the context: economic constraints for example can change during the time; new technologies can appear, as well as new requirements concerning comfort or security. If a team has to design a new product version some time later, it is interesting to retrieve the different considered solutions and the reason why they were rejected. The cost of a particular component was perhaps prohibitive, but it is now acceptable, and so a previously abandoned solution becomes possible. So, the traceability of reasoning process can ensure going faster in the design of future products, by reusing. Furthermore, it is often necessary to know who by, when and why, the decision was made, to determine the responsibilities when a problem occurs. Another problematic is to preserve information about a product configuration. An aircraft for example is often a particular case, and to be able to ensure the airplanes maintenance, a company has sometimes to call actors who have

left the firm, because these persons are the only ones to have the appropriate knowledge. This situation is unacceptable. So, the question is: how to store design choices, their justifications, working hypotheses, context and authors of these choices. The proposed answer is to implement a method of experts knowledge management using a software tool: a product design project memory [1]. This software must be considered as a means serving a learning organization, including human aspects. In this paper only technical aspects are considered.

2. A Model for Project Memory: 2.1. Project Memory:

A project memory can be defined as a memory of both knowledge and information acquired during the realization of projects [2]. [3] distinguishes the memory of the projects characteristics (concerning the context, the organization, the result) from the memory of the design reasoning (relating to the decisions and the resolution of problem). We can find others of project memory in [1]. In the field of the engineering and knowledge management, some traditional methods can be quoted, like REX [4] (individual memory of experiment), MKSM [5] and CommonKADS [6] (memory of activities). Several approaches are proposed more specifically for the design memory. For example, Design Rationale Capture Design [7] based on a representation language (language DRCS) is adapted to concurrent engineering. Other approaches like IBIS [8] or QOC [9] are interested in the decision-making process in design. Other non-technical aspects must be taken into account,

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

41

as [10] shows that it is necessary to develop a new culture to transform an organization by project into a learning organization. [11] Shows the interest to capitalize on the failures and missed opportunities. Many aspects require nevertheless to be improved, in particular the problem of the traceability of the design choices is still of topicality.

2.2. State of the Art of Project Memory:

In what follows we present three proposals for a modeling of the memory of projects which are close to our objectives of taking into account of all dimensions of the project. These proposals are alternative approaches with the methods of definition of already quoted memories of projects. The flexibility of the models and the re-use of the produced memory are the two privileged criteria.

The models do not take into account the concepts of justification of the choices of decision and argumentation of the choices of decision at the time of the stages of design. The processes are limited to the processes of design. The resources are limited to human resources. Yasmina Harani structured its proposal in the form of three levels (meta model, specification and realization) with bonds (of specification and instantiation) between these three levels the model of specification is completely defined; on the other hand the level meta model is formalized little.

2.2.2. Smain Bekhti Proposition :

In its work, Smain Bekhti [13] was based on work of [14]. Its memory of projects is broken up into a resolution part of the problems and decisionmaking called "memory of logic design" as well as part representing the characteristics of the project called "memory of context". The memory of context is the whole of elements characterizing the course and the organization of project of design. The principal characteristics are the deadlines (definition of an estimated calendar of a project), the quality (of the objectives traced in the specifications) and the costs (given according to the awaited quality of the product and the traced times). The memory of the logic design represents the knowledge invested in the resolution of the problems and the decision-makings during the realization of a project. A process of capitalization of knowledge was defined. This is a process which makes it possible to obtain a structured trace of a memory of project containing the context in which the design as well as the logic of resolution of the problems proceeds. Smain Bekhti proposes a model of memory of projects formalized by using the semantic networks. It is a model clear and easy to interpret. Its weakness is that it does not take into account aspects evolution, documentation, organization, justification. It stressed much the logical aspect of design but the part context (times, cost, and quality) was not developed. The models of Smain Bekhti do not benefit from the more recent developments of directed modeling objects in particular the, generalization/specialization and of its technological tools such as the RDBMS and the OODBMS. The constraints of integrity are not clarified.

2.2.1. Yasmina Harani Proposition :

In its work [12] defined using models entities associations: A model of product allowing to describe the various facets of the product to be conceived at various levels of abstraction. This model takes into account a whole of qualitative information (through the entity "Description") and quantitative (through the entity "Parameter") of the product. The entities of the produced model are: Product, Point of view, Variable Behavior, Equation Behavior, Description, Constant, Bond, Parameter and Node. A whole of semantic relations connects these entities between them. Another model process of design of the product allowing to describe the process of design of the product at various levels of detail recalling it why, it how and it by which or what relating to each stage of the design. The entities of the model process of design are: Process of design, Tries, Operator, State, Transition, and Resource. A third model of resources allowing to represent the whole of the speakers during the course of the design. The link between the Produced model and the Process model of design was established starting from certain concepts belonging as well to the one with the other of the two models. Indeed, each of the two models calls upon the concepts of the second model. The integration of these two complementary models makes it possible to obtain a coherent model. The force of the model of Harani is that it presents a strong integration between the three basic concepts: Product/Process/Resource. However the models suggested do not take into account the aspects documentation. The contribution of the directed approaches object would have made it possible to introduce a clear classification on the level of these concepts. Moreover, because of the formalism used (entity association), the models of Yasmina Harani do not benefit from the more recent developments of directed modeling objects in particular the generalization/specialization.

2.2.3. Michel Labrousse Proposition:

In his work, Michel Labrousse [15], was interested much in the aspect of integration of the Product/Process/Resource concepts as being three concepts essential to the description of a system of company. He mainly modeled these three concepts. Various possibilities of representation of the processes were presented, among which UML [16], GRAI [17], and IDEF3 [18]. Examples of models

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

42

were presented such as: model FBS (Function, Behavior and Structure) [19], the model MOKA [20] and the model of Yasmina Harani [12]. A synthesis of these various models was made. On the basis of this synthesis a Product/Process/Resource model was presented called "FBS-PPRE model" (Function/Behavior/StructureProcess/Product/Resou rce/External effect). The model of Michel Labrousse does not make distinction at the base between Product, Process and Resource which are generalized in "Object". The concepts of Product, Process and Resources do not appear whereas through roles that the objects the ones compared to the others play. The objects Organization, Justification of the choices and Documentation are not taken into account.

responsibilities in case of default, the software will store the tasks, the actors, the organization and the date of each action.

2.4. A Generic Data Model:

In the framework of product design project, real objects can often be represented by tree structures.The search of a generic concept leads to represent such models by the use of a pattern (design scheme) Figure 2 adapted from those proposed in [22].
::Core::Entity

isComposedOf
0..* RootElement 1..1 Element 1..1

2.3. General Architecture Information System:

of

the

isComposedOf
0..*

Our approach consists in proposing a generic model allowing the implementation of project memories. In reference to model levels proposed by [21], we suggest a three level architecture (Figure 1).
M2 Generic model represents M1 Project memory represents Real objects

Figure 2: Patterns describing a tree-like structure

A pattern is in a sense a motif duplicable and adaptable according to necessities. This pattern contains a class Root-Element intended to represent the root of the structure, because it was noticed that this one is stable. Indeed, if one represents the WBS of a project for example, the root is at once the name of the project and remains unchanged. On the other hand, for Gamma, leaves have to remain leaves, without possibility of continuing the breakdown. This limit does not correspond to what was noticed in real design cases. The users often have to break down elements that were previously leaves. As a result, the pattern we propose contains a class called Element representing a node of the breakdown. This class contains a reflexive association (a node can consist of nodes). The association between Root-Element and Element as well as the reflexive association represented on Figure 2 are of composition type; a node belongs only to a father node, and the suppression of this father leads to suppress all children nodes. But the pattern can be adapted according to necessities, and one or some of these compositions can become aggregations; in this case, a node can be shared between several fathers, and the lifecycles of a node and its father can be different. We may also notice that such a pattern can be enriched by constraints described with a language such as [23] to specify for example the impossibility to create a circular breakdown structure (if Element_1 consists of Element_2, then Element_2 can not consist of Element_1). These constraints are specified once. The pattern described allows only keeping the last version of the arborescence, administering neither its history nor any other constraint such

M0

Figure 1: The three levels architecture

Level M0 is relative to real world objects, such as product, human or material resources, calculation resources, CAD models, documentation, etc. Level M1 corresponds to the models of the previous real objects, and constitutes a project memory; it structures the pertinent information without redundancies, but indicating where to find this information. Lastly, level M2 is the more abstract one; it describes the model allowing project memories instantiation. This level is generic and ensures the possibility to memorize all projects information. For example, it is possible to add dynamically attributes to a class, to associate it to one or several viewpoints. It also allows linking to the actor who is responsible of its values validity and to elements from which it is issued (documentation, calculation resource, etc.). By instantiation of the model, the softwares developer of a particular project memory for an enterprise has to define the appropriate information to store, depending on its next use. For example, if the concern is tracking the

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

43

as exclusivity between children nodes, etc. These aspects are managed by the means of relations which are defined between entities in the package Core [1].

Figure 3 gives the global view of the information system models structure in packages.

Knowledge Corps::Entity

View Point

Process

Functions

Documentations

Organizations Product

Actors

Figure 3 Package structure of the IS models

2.4.1. Details levels:

The architecture of the information system dedicated to the project memory that we developed articulates around two levels: concepts level and objects level. Concepts Level: It contains two under-levels: Under-level packages: it is the level which offers a general mechanism for the partition of the models and the regrouping of the elements of modeling of the information system. Architecture is made up of a whole of package (cf Figure 26). Each package contains classes, and associations. Our decomposition in packages does not follow functional criteria; but each package is a grouping of elements according to a purely logical criterion with an aim of having a strong coherence between elements of the same package and a weak coupling between packages. The general form of the information system dedicated report of project is expressed by the hierarchy of packages and the network of relations of dependence between packages. Principal package is the Corps package which forms the spinal column structural of the model: it contains the generic elements of the project memory. Under-Level Classes: it is a level of finer detail which contains the static description of the project memory in terms of classes and relations between these classes. Objects Level: it is the level authorities of the storage elements of project and the bonds between them. It makes it possible to clarify the complex structures of the diagrams of classes while being based on real examples.

packages : products, process, organization, documentation, decisions, actors, knowledge, point of view. Each one of these aspects has an interest in the reconstitution of the life of a project. They are dependent, and it is necessary to manage each one of these elements is one of the components necessary to the construction of the project memory. Product Package: decomposition structural of the product. Process Package: organization of the various stages of a process. Functions Package: functional schedule of conditions that the product must satisfy. Documentation Package: to manage the structure, the contents, the justification of the technical choices, to indicate the references to any data carrier (image, text, hypertext link). Organization Package: structure of the team of project, structure of a company. Point of view Package: definition from the various points of view Actors: management of the actors intervening on the project, access authorizations. Knowledge Package: structuring of

various levels of knowledge.

2.4.2. The packages:

The packages of the information system for the project memory of design which we propose are conceived to take into account a great number of aspects of such projects; our system contain

Corps Package: it is intended to manage the common attributes and the relations between all the classes, as well as the sights. It also makes it possible to follow the evolution of any object, forced on an object and the history of the relations between objects. For example, a rotor is component of a turbo pump; the creation of a new version of the rotor will involve that of a new version of the turbo pump. The models make it possible to manage all the versions of the product. It is possible of "tracker" (to leave traces allowing to find the origin of) mainly: representations, choices, decisions and their justifications, adopted solutions and those which were rejected. However, it is to the

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

44

user to decide what it wishes to memorize or not; for example, does he want to or not keep the history of the decomposition of the product? Does he want to file the documents of justification of the decisions which were made at the time of a stage of design of a product or not? Obviously, this whole of packages is not exhaustive. The architecture suggested as well as the generics of Corps packages makes it possible to add other dependent concepts easily to the project memory.

actors are instances of the classes sheets. The

number of sights defined is not evolutionary by actor.

Acteur

Concepteur

Fabricant

Economiste

3. Management of Points of View within the framework of Project memory: 1) Context:

[24] Has defined the point of view as being "a prospect for an interest from which an expert examines the knowledge base". In its definition Ribire [25] based itself on that of Marino but while being interested moreover in two dimensions, namely contextual dimension where the opinion (the focus) of an expert is described, and the dimension of the person from where the angle of sight of an expert is described: The opinion describes the context of the work of the expert. Several experts can have the same opinion. However one characterizes the point of view by personal dimension: the angle of sight; The angle of sight describes the characteristics of an expert or a group of experts. It can describe the name of this expert, his applicability, his level of expertise or competences, his experiment in other fields interesting for the application and his role and place in the organization. This fact the definition of Ribire is: "a point of view is an interface allowing the indexing and the interpretation of the sight composing the elements of knowledge. A point of view is characterized by an opinion and the angle of sight"[25]. In the case of our work, we are interested in construction of a model from point of view which independent of the elements will be modeled (product, process, document, etc), and of his applicability. The process of development of the model will be progressive.

Figure 4 : Diagramme de classes de description de Point de Vue (Version 1). Version 2: Following the insufficiencies raised in the diagram of Figure 5, we will introduce the class View. According to [26] and the multiplicity 0.. * With dimensions one of the class View, it is possible now to allot several sights to an actor.
acceder Acteur * * Vue

Concepteur

Fabricant

Economiste

Figure 5: Diagramme de classes de description de Point de Vue (Version 2). However the number of sights taken into account is limited by the different ones under classes from the class View. Indeed, if an actor can reach at several sights it can reach only the statically definite sights by under classes, and it will not be possible to add new sights dynamically. Version 3: We will present the diagram of version 3 in two stages; this version aims at improving the solution of version 2. Figure 6 illustrates the possibility of allocating a number of sights which became unlimited by actor. A sight is allocated with one or more Actor. An actor can have several sights. A class attribute is added in order to manage the sights dynamically. The dynamic change of the sights does not affect the existing models.
estAlloueeA *

2) Classes Diagram:
Version 1: Our objective is to manage several
points of sights i.e. to propose model from point of view per applicability of the actor. The structure of modeling more adapted for classification is the generalization/specialization what leads us to propose the model of Figure 4 on which the class actor specializes according to various points of view's taken into account. In such a version, it is possible to allocate only one single sight with each actor because the
Vue Acteur

Figure 6 : Diagramme de classes de description de Point de Vue (Version 3-1). In such a version one allocates one or more sights with each Actor. The number of sights is evolutionary. A dynamic management of visible

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

45

information is possible. It is possible to have as well simple or composed attributes. From where the relation of the IsComposedOf. A storage element of project memory can be of the View type. A sight can relate to one or more storage element of project memory. The whole of the attributes of the various models of the project
estComposeDe * concerne Attri but 0..1 * estConstitueDe

memory can be in the Attribut class. It is a solution which gives answers to our goals where the concept of sight in its construction is independent of the elements of project memory and the applicability elements of the project memory of (Figure 7).

Entite *

* estAlloueA Vue * * Acte ur

Figure 7 : Diagramme de classes de description de Point de Vue (Version 3-2).

2) Objects Diagram:
Let us consider a rotor (Figure 8) defined by two attributes: the cumulated price and total mass. These two attributes belong to two points of view the management of the masses and the management of the price defined for two actors. An Act1 element of the Actor type is allocated to him the element GestionMasses element of the View type. This element is consisted of the
concerne M asse T ot aleRot or:At t ribut

element MasseTotalRotor element of the Attribut type. With the Act2 element of the Actor type is allocated the GestionPrix element of the View type. This element is consisted of the element PrixCumulProduit element of the Attribut type. The Rotor element of the ElementProduit type is consisted of the two attributes MasseTotaleRotor and PrixCumulProduit.

Rot or:Element Produit

concerne est Const it ueeDe

PrixCumuleProduit :At t ribut Gest ionM asses:Vue est AlloueeA est AlloueeA Act 2:Act eur Act 1:Act eur est AlloueeA

Gest ionPrix:Vue

Figure 8 : Diagramme dobjets de description de Point de Vue (Version 3). Data filtering with object views 4. P2M2: An Object-Oriented Project associated to database triggers "instead of" - The second tier consists of a business Memory Management System: application server hosting one entity EJB per 4.1. Prototype architecture: object view and one session EJB implementing The models proposed are already implemented the classical faade pattern. This pattern provides by using multi-tier J2EE architecture (Figure 9). a unified interface to a set of interfaces in a - The first tier is the database tier supported by subsystem. Faade defines a higher-level an Oracle database management system in interface that makes the subsystem easier to user version 9iR2 and is in charge of: [22]. The definition of the database type - The third tier is the presentation tier composed hierarchy using the object/relational feature of of JSP and html pages. the server (type inheritance, nested tables, type - The last tier is the client tier. The client uses the references) application trough a simple web browser. Data storage in one object relational The figure 4 illustrates the component mapping table named "entity_tab" for the product aspect of the project memory.

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

46

databaseTier View ProductTreeEJB

applicationServer

PresentationServer JSP listOfEntities

Client

EJB session ProjectMemoryFacadeEJB

View ProductViewEJB EJB entity ProductTreeEjb

JSP productTree

View Entity_View table entity_tab EJB entity ProductViewEjb

JSP addProduct

JSP listOfProducts

type Entity_type

EJB entity EntityView JSP deleteProducts

pageHTML indexProduct.html

0..1

type * Product_Element * -Term2 -Term1 -Child *

WebBrowser Product JSP updateProduct

-parent

Figure 9: General technical architecture of the information system

For the implementation of the project memory, one of the main interesting features of this database management system is to provide the developer with the object relational technology. The object-relational model is based on the extension of the relational model by the essential concepts of the object. The system main part thus remains relational, but all the key concepts of the object are added there in a form particularly designed to facilitate the integration of the two models. In addition to built-in data types, the developer can define new object types that make it possible to model complex structures such as type hierarchy, object references, etc. In general, the object-type model is similar to the class mechanism found in C++ and Java. Like classes, objects make it easier to model complex, real-world business entities and logic, and the reusability of objects makes it possible to develop database applications faster and more efficiently. By natively supporting object types in the database, Oracle enables application developers to directly access the data structures used by their applications. Object abstraction and the encapsulation of object behaviours also make applications easier to understand and maintain [27].

E.g, the statements for the diagram shown on Figure 10 are:

Class1 -id_class1 : integer -attrib1 : String(10) type Class1Type -id_classe1 : integer -attrib1 : Varchar2(10)

Class2 -attrib2 : String(10)

type Class2Type -attrib2 : Varchar2(10)

Figure 10: Type structure for a class hierarchy

Classe1_Tab
Id_class1 attrib1

Classe2_Tab
Id_class1 attrib1 attrib2

Figure 11: Horizontal model: one table per type

Classe1_Tab
Id_class1 attrib1 attrib2

4.2. Model Implementation Guidelines:

The classical principle of the model implementation is the following: 1) For each UML class, define one user defined type ("CREATE TYPE MyType" statement). 2) For sub-classes, sub-types are created using the CREATE TYPE UNDER " statement.

Figure 12: Flattened model: one table for the hierarchy CREATE TYPE Class1Type (Id_class1 INTEGER, Attrib1 VARCHAR2 (10)) NOT FINAL CREATE TYPE Class2Type UNDER Class1Type (Attrib2 VARCHAR2 (10)) 3) define one object-relational table per userdefined type ("CREATE TABLE MyTable OF MyType" statement), except for types

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

47

corresponding to UML sub-classes. In the horizontal model, the developer defines one table per type (Figure 11) the benefit of this model resides in the straightforward access to data. However it becomes difficult to build referential integrity constraints concerning instances of different classes of the hierarchy due to the scattering of the data in the large number of tables. In the flattened model, the substitutability principle in a type hierarchy is used. This principle indicates that one instance of the subclass can be considered as one instance of its super-class, i.e. from set viewpoints all elements of the subclass also belong to the set of elements of the super-class. In practice, only one table of the super-class type can be created for storing data of all the type hierarchy (Figure 12). The statements of the data manipulation language can access directly to the columns corresponding to the attributes of the super-type, but have to include down casting operators (i.e. TREAT) to access to columns corresponding to the attributes of the sub-type. For each association (including aggregation and composition) and according to the multiplicities expressed on association-ends: 1. Define references (REF or FOREIGN KEY) 2. Define composite structure if necessary for managing "1...*" multiplicities.

For each inheritance relation it is possible to use two different implementation models: horizontal or flattened model. This last possibility was chosen for the inheritance implementation because all the project memory components are sub-classes of a unique root class ("Entity") and the management of links between two components of any class is easier this way.

4.3. Implementation:
Several models are implemented in the prototype: product, documentation, and evolution relation and version models. In this prototype it is possible to define (create, update, delete) different product lists (Figure 13 a) and hierarchies (Figure 13b). Also, it is possible to manage documentation, by using nested documentation items whose structure can be modified throughout versions (Figure 14a). P2M2 allows one to reference as many entities as necessary in a version item (Figure 14b), which is a composition of a set of any entity of the project memory. Versions can evolve: their history is being referenced in an evolution item. On Figure 15, one can see how a version or a documentation item can be declared as the evolution of a former entity of the same type.

Figure 13 a List of products b products hierarchy in P2M2

Figure 14: a Documentation tree, b Version content

Figure 15: List of evolutions in P2M2

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

48

5. Ontologies for Project Memory Management: 5.1. Ontologies and the Semantic Web:
Over the past decade, knowledge representation research has focused on ontologies, which are, as [28] defines them, formal specifications of conceptualizations. An Ontology typically consists in a set of formallydefined concepts and properties. By applying inference rules defined by ontology, a software agent can compute inferred knowledge from a given ontology asserted knowledge. Several general inference tasks are referenced by ontology engineering, the main one being the subsumption problem, which consists in finding all the classes a given object belongs to. Ontologies usually rely on a subset of first order predicate logic known as Description Logics [29]. Depending on the constructs an ontology is built upon, a given ontology can be proven decidable, in the sense of subsumption, and therefore ensure tractability of applications using it. SHOIN (D) is one of the most popular Description Logics, since a well-known implementation of it is OWL-DL, the Description Logic compliant subset of the Web Ontology Language (OWL) [30]. The World Wide Web Consortium (W3C) has recently issued a recommendation for OWL as a core technology of the Semantic Web, but only with its DL restriction can one ensure an EXPTIME decidability regarding the subsumption problem.Unlike expert systems that aim at building the most extensive knowledge base or ontology pertaining to a specific domain and to compute it, Semantic Web ontologies tend to focus on knowledge interchange and interoperability. The Semantic Web can be regarded as a httpbased network of XML-serialized ontologies, such that any resource is identified by an URI (Uniform Resource Identifier, of which URL are a subset). On the Semantic Web, a resource can assert a relation involving some instances of a concept defined by another ontology, simply by referencing the URI of that concept. Therefore, using applications that are aware of a limited set of primitives, a machine can compute knowledge formalized in distinct ontologies, and have access to the meaning of a description rather than to plain text strings.

Description Logics) comes from the way classes (or types, concepts...) are defined. When creating a new object type in an Oracle application, one can assert that the new type extends any previously defined type, but there is no other way to create a subtype than to explicitly state what type it extends. Under the Description Logics paradigm, a concept is defined by asserting a set of necessary conditions, under which any instance in the knowledge base will be classified as an instance of the considered concepts, whenever those conditions are met. Thus, a knowledge base (KB) has to be classified, and depending on the complexity of the concepts necessary or necessary and sufficient conditions, a software agent, known as a reasoner, will achieve classification of the KB in a tractable time. Therefore, from a set of asserted concepts and roles definitions, a DL-based KB will compute an inferred ontology, including concept taxonomy. For these reasons, ontology-based modelling can be regarded as much more extensible than UMLbased models, since whenever a new concept has to be defined, there is no need for a complete redesign of the model. Under the Semantic Web, one will also benefit from another kind of flexibility due to ontologybased modelling: since concepts can be formally identified by an URI, there is no need to maintain an exhaustive database of any concept one might have to refer to inside the system. By using external URIs, and thanks to Web Services, one can model projects involving externalized resources. Let's suppose a product is completely designed and the model makes use of external references through the URI mechanism. Whenever someone will need a new functionality for which no form was intended (e.g. to check that all the parts of a product, including subcontracted ones, are free of certain particles), the ability to scale a query up to the semantic web will be a powerful advantage.

Acknowledgements:
This study has been completed within the IS3C group on Design System Engineering and Product Life Cycle and supported by the GDRMACS from the CNRS (http://www.univvalenciennes.fr/GDR-MACS/). The author would thank his colleagues from the Industrial Engineering Department of the Ecole Centrale Paris, the Research team on Industrial Engineering from the Ecole Centrale Lille for their helpful comments during the whole process of this study.

5.2. Benefits of the OWL-DL data-model over Object-Relational technology:

Although Object-Relational data-bases offer a very powerful environment for knowledge management, several insufficiencies remain under this paradigm that an ontology-based approach might help to solve. The main difference between Object-Oriented modelling, and frame-based systems (built upon

Conclusion:
We have designed P2M2 a generic framework suited for project memory management. We

2012 JCSE www.Journalcse.co.uk

JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 15, ISSUE 2, OCTOBER 2012

49

present its platform independent model, and explain its implementation over object-relational technology, in compliance with the model-driven application (MDA) paradigm. We discuss an extension of our work to support ontologies for project memory, and present its benefits. In the near future, we aim at extending P2M2 beyond product centred-aspects of design projects, and to validate our tool in an industrial context.

References:
[1] Ben Sta Hatem Contribution de la modlisation Conceptuelle a lIngnierie du Knowledge Management : Application dans le cadre de la mmoire de Projet, Thse de Doctorat, Ecole Centrale de Lille, Lille, 2002. [2] R. Dieng, O. Corby, A. Giboin and M. Ribire, Methods and Tools for Corporate Knowledge Management, International Journal of Human-Computer Studies, 51:567-598, Academic Press, 1999. [3] N. Matta, O. Corby and M.Ribire, Mthodes de capitalisation de mmoire de projet, INRIA, Rapport de recherche n3819, 1999. [4] P.Malvache and P. Prieur, Mastering Corporate Experience with the REX Method, Management of Industrial and Corporate Memory, ISMICK03, Compigne (France), pp.33-41, 1993. [5] J.L. Ermine, M. Chaillot, P. Bigeon, B. Charenton and D. Malavielle, MKSM a method for knowledge management, Knowledge management: organization, competence and methodology, ISMICK96, Schreimenmakers ed., Rotterdam (Neederlands), pp.288-302, 1996. [6] G. Schreiber, H. Akkermans, A. Anjewierden, R. De Hoog, N. Shadbolt, W. Van de Velde, B. Wielinga, Knowledge engineering and management: The CommonKADS Methodology, The MIT Press ed., ISBN 0262-19300-0, 1999. [7] M. Klein, Capturing Design Rationale in Concurrent Engineering Teams, IEEE, Computer Support for Concurrent Engineering, January, 1993. [8] J.E. Conklin and M.L. Begeman, gIBIS: A Hypertext Tool for exploratory Policy Discussion, ACM Transactions on Office Informations Systems, 6:303-331, 1998. [9] S. Buckingham Shum, Negotiating the construction and reconstruction of organizational memories, Journal of Universal Computer Science, 3(8):899-928, 1997. [10] J.J. Kasvi, M. Vartiainen and M. Hailikari, Managing knowledge and knowledge competences in projects and project organizations, International Journal of Project Management, Pergamon ed., 2003. [11] M. Jarke, Experience-based knowledge management: a cooperative information systems perspective, Control Engineering Practice Vol 10 (2002) 561 569. [12] : HARANI Y., "Une Approche Multi-modles pour la Capitalisation des Connaissances dans le Domaine de la Conception", Thse de l'INPG, spcialit en Gnie Industriel, 19 Novembre 1997. [13] Bekhti S. (2003), DYPKM : Un Processus Dynamique de Dfinition et de Rutilisation de Mmoire de Projets, Thse de lUTT, spcialit Rseaux, Connaissances et organisations, 17 Dcembre 2003.

[14] Matta N. et al. (1999b). Mthodes de capitalisation de mmoire de projet, Rapport de Recherche INRIA N. 3819, Novembre 1999. [15] Labrousse M., (2004), proposition dun Modle Conceptuel unifi pour la Gestion Dynamique des Connaissances dEntreprise , Thse de lEcole Centrale de Nantes, spcialit Gnie Mcanique, 13 Juillet 2004. [16] OMG, (2003) Object Management Group Unified modelling language Specification, www.omg.org/docs/formal/03-03--01.pdf, Version 1.5 formal/03-03-012003, March 2003. [17] Doumeingts, G. (1984), mthode GRAI, mthode de conception des systmes en productique, Thse de doctorat dtat, Universit Bordeaux 1. [18] Mayer, R. J. Menzel, C. P., Painter, M.K., deWitte, P.S., Blinn, T., Perakath, B., Information Integration for Concurrent Engineering (IICE) IDEF3 process description capture method report, http://www.idef.com, September 1995. [19] Hu, X., (2000), a survey on design rationale: representation, capture and retrieval, Proceedings of DETC00, 2000 ASME Design Engineering Technical Conferences, September 10-3, 2000, Balmore, Maryland, DETC2000/DFM-14008. [20] Daimler Chrysler (2000).methodology and tools Oriented to Knowledge-based engineering Applications, MOKA project ESPRIT 25418, deliverable D4.3, final version, 26 juin. [21] OMG-Meta Object Facility Specification v1.4, April 2002. [22] Gamma E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Reading, Addison-Wesley, 1995. [23] Object Constraint Language Specification. OMG Unified Modeling Language specification version 1.5, http://www.OMG.org/uml, 2003. [24] O. Marino, F. Rechenmann, P. Uvietta, Multiple perspectives and classification mechanism in Object-oriented Representation, Proc. 9th ECAI, Stockholm, Sweden, p. 425430, Pitman Publishing, London, August 1990. [25] M. Ribire, R. Dieng-Kuntz. A Viewpoint Model for Cooperative Building of an Ontology, Conceptual Structures : Integration and Interfaces, Proceedings of the 10th International Conference in Conceptual Structures (ICCS'2002), Springer-Verlag, LNCS 2393, editeur : U. Priss, D. Corbett, G. Angelova. p. 220-234, Borovetz, Bulgarie, 15-19 juillet, 2002. [26] Francis G. Moss Modeling Roles A Practical Series of Analysis Patterns JOURNAL OF OBJECT TECHNOLOGY, JOT, 2002 Vol. 1, no. 4, September-October 2002 [27] Oracle Application Developer's Guide - ObjectRelational Features, Release 2 (9.2), Part No. A96594-01, March 2002. [28] T. R. Gruber, A translation approach to portable ontologies, Knowledge Acquisition, 5(2):199-220, 1993. [29] F. Baader, D. Calvanese, D. McGuiness, D. Nardi, The Description Logics Handbook, Theory Implementations and Applications, Cambridge, 2003. [30] D. McGuiness, F. VanHermalen, OWL Web Ontology Language Overview, http://www.w3.org/TR/2004/RECowl-features-20040210/,W3C recommendation, 2004.

2012 JCSE www.Journalcse.co.uk