Workshop on Knowledge Management and Organizational Memory

Rose Dieng-Kuntz (INRIA, France)

Nada Matta (UTT, France)

Knowledge Management and Organizational Memory Knowledge Management (KM) is one of the key progress factors in organizations. It involves explicit and persistent representation of knowledge of (geographically) dispersed groups of people in the organization, so as to improve the activities of the organization. Although KM is an issue in human resource management and enterprise organization beyond any specific technology questions, there are important aspects that can be supported or even enabled by intelligent information systems. Especially AI and related fields provide solutions for important parts of the overall KM problem. Identification and analysis of a company's knowledge-intensive work processes (e.g., product design or strategic planning). Knowledge Engineering and Enterprise Modeling techniques can contribute to this topic. The analysis of information flow and involved knowledge sources allows to identify shortcomings of business processes, and to specify requirements on potential IT support. In an organization, know-how may relate to problem solving expertise in functional disciplines, 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" (OM). It is regarded as the central prerequisite for IT support of Knowledge Management and is the means for knowledge conservation, distribution, and reuse. An OM enables organizational learning and continuous process improvement. Activities underlying knowledge management in an organization can comprise detection of needs, construction, distribution, use and maintenance of the corporate memory. It demands abilities to manage disparate know-how and heterogeneous viewpoints, to make it accessible and suitable for adequate members of the organization. When the organization knowledge is distributed on several experts and documents in different locations all over the world, the Internet or an Intranet inside the organization and World Wide Web (WWW) techniques can be a privileged means for acquisition, modelling, management of this distributed knowledge.

Organizing Committee Jean Paul Barthès, Univesity of Technology of Compiègne (France) Rose Dieng, INRIA (France) Knut Hinkelmann, GmbH (Germany) Ann Macintosh, International Teledemocracy Centre (United Kingdom) Nada Matta, Université de Technologie de Troyes (France) Ulrich Reimer, ACM (Switzerland) Carla Simone, Universita' di Torino (Italy)

Program committee Andreas Abecker, DFKI, Germany Mark Ackerman, University of California, Irvine (USA) (to be confirmed) Jean-Paul Barthès (UTC-Compiègne, France) Jeff Conklin, CogNexus Institute and George Mason University (USA) John Debenham, University of Technology, (Sydney, Australia) John Domingue, Open University, (UK) Jean-Louis Ermine, CEA, (Paris, France) Fabien Gandon, Carnegie Mellon University, USA Knut Hinkelmann, University of Applied Sciences Solothurn Robert Jasper, Intelligent Results (USA) Myriam Lewkowicz, Tech-CICO, UTT (Troyes, France) Ann Macintosh, International Teledemocracy Centre, UK Frank Maurer, Calgary University, Canada Ulrich Reimer, ACM (Switzerland) Myriam Ribière, Motorola (France) David G. Schwartz, Bar-Ilan University (Israel) Carla Simone, University of Torino (Italy) Steffen Staab, University of Karlsruhe, (Germany) Gertjan van Heijst, Oryon, The Netherlands) Manuel Zacklad, Tech-CICO, UTT (Troyes, France)

Table of Content Structured Case Base Organizational Memories to manage Experimental Knowledge S. Bandini, S. Manzoni, P. Meerghetti, C. Simone------------------------------------------------1 Mash Environments for Corporate Memory J.P. Barthès --------------------------------------------------------------------------------------------- 14 Projetc Memory: an approach of modeling and reusing the Context and the Design Rationale S. Bekhti, N. Matta------------------------------------------------------------------------------------- 20 A Framework to construct Hypertext Interfaces for Ontology Engineering G. Falquet,C.L. Mottaz-Jiang ----------------------------------------------------------------------- 26 A Knowledge Management System for Industrial Research Activities : Case study for IT

Research Activities at the EADS Corporate Research Center CH; Frank, M. Gardoni ------------------------------------------------------------------------------ 38 Management and Reuse of Software Design Knowledge Using a CBR Approach P. Gomez, F. C. Pereira, P. Paiva, N. Seco, P. Carreiro, J. L. Ferreira, C. Bento ----- 54 Knowledge Management Using Business Process Modelling and Workflow techniques H.L. Kuo, Y. H. Chen-Burger,D. Robertson ----------------------------------------------------- 63 Locating the Company’s Crucial Knowledge to specify Corporate Memory: A Case Study in

Automative Company I. Saad, M. Grundstein, C. Rosenthal-Sabroux -------------------------------------------------- 75

Structured Case Base Organizational Memoriesto Manage Experiential Knowledge

Stefania Bandini, Sara Manzoni, Paolo Mereghetti, and Carla Simone

Department of Computer Science, Systems and CommunicationUniversity of Milano-Bicocca

Via Bicocca degli Arcimboldi 8 20126 Milan - Italytel +39 02 64487835 fax + 39 02 64487839

e.mail:{bandini, manzoni, mere, simone}@disco.unimib.it

Abstract. The paper proposes a solution to one of the main topics re-lated to the use of Case Based Reasoning (CBR) in the organizationallearning context, that is the problem to define a suitable and effectiverepresentation of cases and Case Based Organizational Memory (CB–OM). The proposed solution focuses on case complexity related to thehuge amount of involved information and to the need of incrementalknowledge representation. Moreover, it allows to deal with another im-portant aspect that must be taken into account: nowadays organizationsare distributed environments. The proposed approach will be exemplifiedwith an ongoing Knowledge Management project that exploits CBR tosupport the CB–OM management of the Business Unit Truck of PirelliTyres.

1 Introduction

Organizational Learning (OL) can be defined as the process of “detection andcorrection of errors” [1, 2]. Supporting the Organizational Learning means to en-able the organization ability to learn faster than its competition. OL is focussedon the way in which knowledge becomes embedded in network of relationships,information technology, business processes, performance management systemsor product and services offering. In this view successful organizations are thosethat can assimilate and transform new ideas into action faster than a competitor.

Within this framework learning means to transform important experiencesinto knowledge, experiences that can belong to the entire organization or a partof it. In the latter case, information sharing inside the organization favors thelearning process of the whole organization. This happens also when the relatedinformation is subjected to different interpretations and a local experience pro-vides knowledge to the organization in different forms.

Besides, the usual phases (i.e. knowledge acquisition, information distribu-tion, and information interpretation), another important concept must be relatedto the Organizational Learning process that is Organizational Memory [3]. Theorganizational memory can be considered as a set of heterogeneous structureswithin an organization that hold knowledge in different forms. For instance,

1

databases and information stores, work processes, procedures and product orservice architecture. The learning process can also be considered as a processto develop the organizational memory [4], and the organizational memory is theplace where the experiences made by the organization reside.

The management of the organizational memory must focus on those com-ponents strictly related to experiences. In particular, it must focus on thoseexperiences that could be considered a key factor for the success of the orga-nization. Experience representation can be facilitated by case based organiza-tional learning, meaning that relevant experiences can be captured in the formof cases for reuse in a corporate experience repository, called Case Based Or-ganizational Memory (CB–OM). Case Based Reasoning (CBR) [5, 6] can be ef-fectively adopted in order to manage the organizational memory [7], and allowsexperiential knowledge to be captured when models cannot or are hard to beformalized. CBR has been applied to Knowledge Management (KM) in manyareas and there is a growing interest in this kind of approach (for instance, tosupport organizational learning in software development [8], project planning [9],and local government regulations [10]). Using the CBR paradigm in KM is stilla challenge from many points of view. In fact the challenge is to characterizecases in the appropriate way to capture the dynamic aspects of innovation, todefine retrieving strategies that fit the needs of skillful actors involved in theinnovation process, and finally to collect cases from the every day activities andthe related technological supports.

The paper proposes a solution to one of the main topics related to the useof CBR in the organizational learning context, that is the problem to define asuitable and effective representation of cases and CB–OM. As it will be betterexplained in the following, the proposed solution focuses on case complexity re-lated to the huge amount of involved information and the need of incrementalknowledge representation. Moreover, it allows to deal with another aspect thatmust be taken into account in the development of an organizational memory:nowadays organizations are distributed environments. Organizational memory,and thus CB–OM, could be distributed both logically (i.e. inside a company)and geographically (i.e. networks of department or companies). The importanceto consider this aspect as central is stated by the huge number of researches andapplications dealing with the adoption of the CBR approach in distributed envi-ronments (e.g. Distributed CBR [11], Collaborative CBR [12, 13] and CooperativeCBR [14]).

The proposed solution to represent and manage cases and Case Bases fororganizational memory will be described in Section 2. Then the approach willbe exemplified with an overview of an ongoing KM project that exploits CBRto support the CB–OM management of the Business Unit Truck of Pirelli Tyres(Section 3).

2

2 Case and Case Base Management

In this section the result of researches focussed on effective case and Case Baserepresentation for organizational memories will be summarized.

2.1 Structured Cases

One of the main aspects to be considered in the representation of cases forCB–OM is related to the heterogeneity of the involved information. A case iscomposed by a set of attributes that are organized in different categories andsub–categories according to their meaning. This organization leads to a treestructure where the children nodes can be viewed as a refinement of the conceptexpressed by the father node [15]. For instance the concept of “geometrical fig-ure” (i.e. father node) can be refined in “triangle”, “rectangle” and “pentagon”(i.e. children nodes).

This case structure is particularly suitable for the knowledge representationtask in the organizational learning context, where the information that buildsup a case in the OM could be located in different places. Hence informationsources can be both logically and geographically distributed. For example, inFigure 1 information concerning different sources (e.g. organization departments)is represented by different colors and it is organized as a different branch of thetree.

A hierarchical structure of cases has already been used and validated inother works [16]. However the peculiarity of this approach to structure cases isrelated to the flexibility of case representation that, when needed, can be easilymodified (e.g. in order to include new acquired information). This is particularlyuseful when facing with OM where long knowledge acquisition campaigns can beneeded (incremental knowledge acquisition) and the acquired knowledge mustbe incrementally represented in the CB–OM. Figure 2 shows two possible waysto update the case structure. A new child node can be added to an existingfather node (Figure 2(b)) or a leaf node can be refined adding new nodes underit (Figure 2(c)).

Another important aspect related to Case Bases with huge amount of infor-mation concerns the level of information details needed to fill each case. Evenif in our proposal each case is structured according to the same tree structure,not all cases have necessarily to contain information at the same level of details(e.g. some attribute values can be unspecified). This can be useful when the casestructure is dynamic, some pieces of information are not available or too difficultto be provided. In the first circumstance, cases created before a case structureupdating, may have no information associated to the new added attributes. Onthe other hand, the value associated to a father node can sometimes be omittedsince the children nodes contain more detailed information (Figure 4(a)). On thecontrary, sometimes information related to children is not available but the oneassociated to the father node can be enough.

Since this case structure allows the Case Base to contain cases described atdifferent level of details, a suitable similarity function has to be studied. The

3

Root node from source1

Sub−tree from source2 Sub−tree from source4

Sub−tree from source3

Fig. 1. An example of tree structure to represent cases in an OM. Information con-cerning different sources (e.g. organization departments) is represented by differentcolors.

easiest way to compute the similarity between two cases with different levelof details, is to use only those attribute values that are present in both cases.Obviously this is not an effective solution because when a case is newer thananother, all the knowledge acquired and represented in the newer case is lost.Similarly it happens when different information is available for the two casesdescription. As shown in Figure 3, if it has been decided that the nodes involvedin the similarity computation are the circled ones, a lot of available knowledgeis not used because only the two black circled attributes have associated valuesin both cases.

A suitable solution that has been investigated and used in [17] proposesto derive the set of required node values. In this proposal, since the childrennodes are refinements of the concept expressed by the father node, the idea isto encapsulate in the father the knowledge available in the children nodes. Thiscould be done associating to each father node a function that derives its valueusing, for example, the values of the children and a set of weights. The effortand difficulty to design this function depends on the concepts expressed by thenode. As a simple example it is possible to think to the concept of “sweetness”

4

(b)

(a)

(c)

New added attributes

Old attributes

Fig. 2. Two possible ways to update the case structure.

of a cake. There are different ingredients in a cake recipe that make it sweet;for instance sugar, saccharine, jam and so on. As shown in Figure 4(b), in thissituation it is possible to derive the value associated to the sweetness simplycalculating the weighted sum of all the ingredients that bring sweets to the cake.In this example it has been assumed that the sugar brings a sweetness equal tothe hundred percent of its weight, the saccharine the eighty percent and the jamthe twenty.

2.2 Structured Case Base

Since in many circumstances a new case is derived by adaptation from othersalready present in the Case Base, a hierarchical structure of the Case Base canbe considered as an appropriate choice that allows to efficiently store them. Theuser of the CBR system can choose to append the new retained case under thecase it derives from or to create a new tree root (see Figure 5).

The main advantage of this approach is to allow to track the sequence ofadaptation phases that had lead to the solution achieved.

A hierarchical Case Base structure also maximize the efficiency of case re-trieval and update. The set of cases contained in the Case Base has to be suffi-ciently wide to guarantee the retrieval and reuse of previously stored and usefulcases, but at the same time the case base organization has to be sufficientlycompact to allow the storage of a large number of cases with a limited memoryoccupancy. In a set of tree structures in fact only differences from the father node

5

Attributes with an associated value

Attributes with a calculated value

Attributes used before completion

New attributes after completion

Case 2

Case 1

Fig. 3. Case similarity computation. The circled nodes represent the ones that has tobe involved in the similarity computation. The values of the grey nodes can be derivedin order to maximize the number of nodes to be involved.

and information about type of adaptation must be stored in order to representson nodes derived from it.

3 Application in a KM Project

The work described in this paper takes its motivations from the P–Truck project,whose main aim is the development of a KM system to support the BusinessUnit Truck of Pirelli Tyres in the design and manufacturing of truck tyres.In this paper we take tyre manufacturing as the reference domain, since weadopted the CBR paradigm to build a computer system supporting the designof rubber compounds in the production of tyres dedicated to car racing andtrucks (P–Race [18] and P–Truck [19], respectively). However, the approach weare going to illustrate could be applied to other manufacturing domains.

6

sweetness

sugar saccharine jam

0.8 0.21.0

40 40 30

sugar saccharine jam

sweetness

(b)

0.8 0.21.0

40 40 30

(a)

78 f(...)

Fig. 4. The value of the ‘sweetness’ node is derived from its children node values andthe set of associated weights.

The design approach of the solution proposed to Pirelli Tyres was deeplyknowledge based. A knowledge acquisition campaign and direct observation ofBusiness Unit working activities have been conducted. The result of this designphase is an integrated KM system in which different knowledge based and servicemodules exploit the Pirelli organizational memory to support the main designand productive activities of the Business Unit Truck of Pirelli Tyres. In particulara knowledge based module, based on a previously introduced model for the designof rubber compounds [20], supports compound designers in the definition ofproduct specification. Moreover, rule based reasoning and CBR are exploited tosupport the design of some tyre production processes for rubber compounds (i.e.mixing of rubber compound ingredients and tyre vulcanization, respectively). Asreported in [19], the CBR paradigm has also been applied to support the tuningof production processes, a fundamental task strictly related to the experience ofpeople involved in manufacturing.

3.1 The KM Context

The life–cycle of a product in manufacturing companies consists of several phasesthat can be divided into two main steps: design and production. The design stepis usually triggered by the need of innovation defined by marketing strategiesoriented to answer requests emerging from the market or from new needs in-duced in it [21]. The goal of the design step is to define product and productionprocess specifications. Product and process specifications define the constraintsthe production process has to respect in order to make products pass the qualitycontrol and be successfully distributed on the market.

In the reality of manufacturing another step has often to be considered in thedesign–production cycle (i.e. production tuning). This need is due to the pos-sibility to encounter unpredictable problems during the production step. Likeany sort of specifications, product and process specifications cannot be exhaus-tive of all the possible details characterizing the instantiations of the production

7

New case added to an existing tree

New case added as a new root node

case_7case_5

case_3

case_7

case_1

case_2case_5

case_6 case_9

case_8

case_4

case_1

case_2case_5

case_6 case_9

case_8

case_4

case_5

case_3

new case

new case

Fig. 5. A case to be retained to the structured Case Base can be added as a child nodeto the one it derives from, or it can originate a new tree and be added as root node.

process. In fact, design is usually a process located where the core design compe-tencies reside, while production is increasingly distributed in different plants totake advantage of local facilities or to make production scheduling more flexibleto the market needs. Each instantiation of the production process happens in adifferent contingent situation where, for instance, raw materials can show evenslightly different properties. Different production context might lead to variableor unexpected results on the final product and to the consequent modificationof the product structure or composition [22].

The tuning of product and process specifications in order to adapt them totake care of structural properties of the local plant, of unanticipated events or nonuniformity in raw materials may be necessary in order to guarantee the necessaryuniformity of production results. Thus, besides standard process design, processtuning has sometimes to be performed during manufacturing. Although thiscritical situations (also referred as, production anomalies) are not too frequent,they are extremely crucial since the time available to solve them and to continuethe production under the new circumstances is very short. Search for a quicksolution justifies to record anomalies connected to problems that have alreadybeen experienced and solved in the past.

8

Fig. 6. The representation of a portion of the tree structured cases of the P–TruckCB–OM.

3.2 The CBR Solution

Knowledge engineering with Pirelli technicians involved in product and processtuning (i.e. people working in the production line, typically experienced work-ers who are however very busy or involved in off–line production activities, likeproduct testing) revealed that the nature of their problem solving activity ismainly episodic, that is based on previous similar situations: they often reasonabout past cases in order to solve the current one. Thus, CBR has been chosenas a suitable approach in order to captures the episodic knowledge characteriz-ing most of the reasoning activity of people involved in production tuning, andto support the dynamical process of experience growth and knowledge creationthrough incremental learning. A dedicated Case Based Organizational Memory(CB-OM) has been designed for the Business Unit Truck of Pirelli Tyres. Inter-ested readers can refer to [19] for more details about the content and structureof the Pirelli CB–OM.

Flexibility of the case structure was an fundamental requirement for thePirelli CB–OM related to the fact that a huge amount of information is usuallyinvolved in the decision making process of people that perform this crucial activ-ity. Knowledge involved in the tuning process is related to products (e.g. in termsof marketing requirements, product specification, composing subassemblies, sub-

9

assembly specifications), production processes (e.g. timing, number and order ofeach production phase), and to production context (e.g. peculiarities of the localproduction plant, set of available machineries and raw materials). The hetero-geneous nature and huge amount of involved knowledge have obliged P–Trucksystem designers to plan an incremental knowledge acquisition campaign thatis being performed with a team of about twenty Pirelli technicians that arededicated to different activities for tyre design and production.

According to this incremental approach to knowledge acquisition, the chosencase representation had to be flexible enough in order to allow an incrementalenrichment of case structure when new information is collected. The approachpresented in Section 2 has been adopted to this aim. The CB–OM that has beendeveloped and integrated into the overall P–Truck system architecture collectsa set of production cases. As shown in Figure 6, each case content has beenorganized into product, production processes, production context, and outcome.Then, each node has been specialized into more details (for instance, the productpart into product use and recipe).

The advantage of this approach to case structuring has been validated withinthe P–Truck project, during the development of a CBR module to support thedesign of the vulcanization phase that characterizes tyre production (vulcaniza-tion, also referred as curing process is a chemical process of treating crude rubberto give it useful properties, such as elasticity, strength, and stability). A CBRmodule has been developed to support Pirelli technicians in the vulcanizationdesign. The tree structure of vulcanization cases has allowed to integrate thisCase Base to the P–Truck CB–OM (i.e. the vulcanization process node has beendetailed according to the structure of vulcanization cases) and thus experien-tial knowledge about curing processes can be shared among P–Truck modulesdevoted to other tasks (e.g. production tuning).

Moreover, as in the most of manufacturing contexts, Pirelli design and pro-duction activities are the result of interactions among multiple and heteroge-neous competence (i.e. functional distributedness) that can sometimes be alsogeographically distributed. Thus, the Pirelli CB–OM has been designed in orderto allow the management of a distributed Case Base: data sources for the CB–OM are located in different places inside the Pirelli information system and theresulting CB–OM can be remotely accessed, retrieved, updated, created, and soon.

3.3 P–Truck Technical Solutions

The P–Truck system has been designed and developed according to a ComponentBased approach. P–Truck modules have been designed in order to satisfy all theidentified user and non–user requirements (i.e. integration of heterogeneous andinteracting components, independent development of components, extendible ar-chitecture, separation between business and presentation logic, portability, inte-gration into the existing information system and Web orientation).

System requirements lead to the choice of the Java 2 Enterprise Edition(J2EE [23]) platform as technological solution to develop the P–Truck system.

10

Currently the J2EE technology supports component–based development (Enter-prise Java Beans, EJB), integration between systems (it complies with CORBAand Remote Method Invocation, it supports XML, and so on), database acces-sibility and web–based user interfaces development. Figure 7 shows an exampleof the web based user interface of a module of the P–Truck system. Moreover,the designed solution allows the integration of several knowledge based mod-ules based on different approaches (e.g. rule based and Case Based Reasoning)into an already existing and used company information system (made of a hugenumber of databases and applications).

Fig. 7. A screenshot of the web based user interface of the P–Truck system. The showninterface allows the access to the knowledge based module to support the design ofrubber compounds (P–Truck Formulation module).

4 Future Work

The proposed approach to structure cases in CB–OM that in this paper hasbeen exemplified within the P–Truck project will be applied to manage OM toother manufacturing contexts. However other activities have to be done beforethe end of the P–Truck project. For instance, suitable security policies have to be

11

studied and integrated into the P–Truck system in order to protect the privacyof involved information.

Moreover, the design and development of a training portal dedicated to newemployees of the Business Unit Truck has been planned. P–Truck knowledgebased modules will be exploited within this portal as simulators of design andtuning activities.

From a software engineering point of view, possible advantages in movingfrom the Component Based to the Agent Oriented approach will be investigated.Moreover, the Peer–to–Peer model will be investigated as a possible solution tomanage the dynamic nature of OM, and if suitable and effective, it will beadopted with the chosen architectural approach.

References

1. Argyris, C.: Double loop learning in organizations. Harvard Business Review 55(1977) 115–125

2. Argyris, C.: Organizational learning and management information systems. Ac-counting, Organizations, and Society 2 (1977) 113–123

3. Huber, G.: Organizational learning: The contributing processes and the literatures.Organization Science 2 (1991) 88–115

4. Walsh, J.P., Ungson, G.R.: Organizational memory. Academy of ManagementReview (1991) 57–91

5. Slade, S.: Case-based reasoning: a research paradigm. AI Magazine 12 (1991)42–55

6. Kolodner, J.: Case-Based Reasoning. Morgan Kaufmann, San Mateo (CA) (1993)

7. Watson, I.: Applying knowledge management: Techniques for building organiza-tional memories. In Craw, S., Preece, A., eds.: Advances in Case-Based Reasoning,Proceedings of the 6th European Conference, ECCBR 2002, Aberdeen, Scotland,UK, September 2002. Volume 2416 of Lecture Notes in Artificial Intelligence.,Berlin, Springer-Verlag (2002) 6–12

8. Althoff, K.D., Birk, A., vonWangenheim, C.G., Tautz, C.: CBR for experimentalsoftware engineering. In Lenz, M., Bartsch-Sporl, B., Burkhard, H.D., Wess, S.,eds.: Case-Based Reasoning Technology. Volume 1400 of Lecture Notes in Com-puter Science., Springer (1998) 235–254

9. Munoz-Avila, H., Gupta, K., Aha, D.W., Nau, D.S.: Knowledge based project plan-ning. In: R. Dieng-Kuntz, N. Matta: Knowledge Management and Organizationalmemories. Kluwer Academic Publisher (2002) ... ISBN 0-7923-7659-5.

10. Watson, I.: A knowledge management initiative by UK local government. In: R.Dieng-Kuntz, N. Matta: Knowledge Management and Organizational memories.Kluwer Academic Publisher (2002) 115–124 ISBN 0-7923-7659-5.

11. Watson, I., Gardingen, D.: A distributed case-based reasoning application for engi-neering sales support. In Dean, T., ed.: Proceedings of the Sixteenth InternationalJoint Conference on Artificial Intelligence, Morgan Kaufmann (1999) 600–605

12. Cunningham, P., Zenobi, G.: Case representation issues for case-based reasoningfrom ensemble research. In Aha, D.W., Watson, I., eds.: Case-Based ReasoningResearch and Development. Volume 2080 of LNAI., Springer-Verlag (2001) 146–157

12

13. Ginty, L.M., Smyth, B.: Collaborative CBR for real-world route planning. In Aha,D.W., Watson, I., eds.: Case-Based Reasoning Research and Development. Volume2080 of LNAI., Springer Verlag (2001) 362–376

14. Plaza, E., Arcos, J.L., Martın, F.: Cooperative case-based reasoning. In Weiss,G., ed.: Distributed Artificial Intelligence meets Machine Learning. Volume 1221of LNAI., Springer-Verlag (1997) 180–201

15. Manzoni, S., Mereghetti, P.: A tree structured case base for the system p–trucktuning. In: UK CBR workshop at ES 2002, Cambridge, 10 december, 2002, Glas-gow, University of Paisley (2002) 17–26

16. Ricci, F., Arslan, B., Mirzadeh, N., Venturini, A.: Itr: a case-based travel advisorysystem. In Craw, S., Preece, A., eds.: Advances in Case-Based Reasoning, Pro-ceedings of the 6th European Conference, ECCBR 2002, Aberdeen, Scotland, UK,September 2002. Volume 2416 of Lecture Notes in Artificial Intelligence., Berlin,Springer-Verlag (2002) ....

17. Bandini, S., Manzoni, S., Mereghetti, P.: Business service components: a knowl-edge based approach. In: Research and Development in Intelligent Systems XIX,Proceedings of the 22th International Conference on Knowledge Based Systemsand Applied Artificial Intelligence, (ES 2002), Cambridge (UK), 10-12 December2002. BCS Conference series, London, Springer-Verlag (2002) 237–250

18. Bandini, S., Manzoni, S.: A support system based on CBR for the design ofrubber compounds in motor racing. In Blanzieri, E., Portinale, L., eds.: Advancesin Case-Based Reasoning, Proceedings of the 5th European Workshop, EWCBR2000, Trento, Italy, September 6-9, 2000. Volume 1898 of Lecture Notes in ArtificialIntelligence., Berlin, Springer-Verlag (2000) 348–357

19. Bandini, S., Manzoni, S., Simone, C.: Tuning production processes through a casebased reasoning approach. In Craw, S., Preece, A., eds.: Advances in Case-BasedReasoning, Proceedings of the 6th European Conference on Case Based Reasoning(ECCBR 2002), Aberdeen, Scotland, September 4-7, 2002. Volume 2416 of LectureNotes in Artificial Intelligence., Berlin, Springer-Verlag (2002) 475–489

20. Bandini, S., Manzoni, S.: CBR adaptation for chemical formulation. In Aha, D.W.,Watson, I., eds.: Case-Based Reasoning Research and Development, Proceedingsof the 4th International Conference on Case-Based Reasoning, ICCBR 2001, Van-couver, BC, Canada, July 30 - August 2, 2001. Volume 2080 of Lecture Notes inArtificial Intelligence., Berlin, Springer-Verlag (2001) 634–647

21. Prahalad, C.K., Hamel, G.: The core competence of the corporation. Strate-gic Learning in Knowledge Economy: Individual, Collective and OrganizationalLearning Process (2000) 3–22

22. Utterback, J.M.: Mastering the Dynamics of Innovation. Harvard Business SchoolPress, Boston (MA) (1996)

23. JavaTM 2 Platform, E.E.J.: http://java.sun.com/j2ee/. (2002)

13

A b st r a c t B a s e d o n o u r p r o j e c t s w i t h l a r g e i n d u s tr i a l p a r t - n e r s , t h e p r o p o s e d w o r k e x am i n e s t h e p r o b l e m o f d e s i g n i n g a t e ch n i c a l e n v i r o n m e n t f o r s u p p o r ti n g ( p ar t o f ) a d i s t r i b u te d o r g a n i z a ti o n a l m e m o r y . W e d e s i g n e d a m u l t i - ag e n t s y s t e m o r g a n iz e d a s a s e t o f c o t e r i e s [ B a r t h è s an d T a cl a , 2 0 0 1 ] , in w h ic h i s u s e r is g i v en a p er s o n a l a s s i s t a n t ag e n t a s s o c i a t ed w i t h a s t af f o f s p e c i al i z e d a g e n t s a n d i n te r a c t in g w i th s h a r e d s e r v i c e ag e n t s . T h e g o a l i s t o s u p p o r t th e k i n d o f ex c h a n g e s t h at o n e c a n e x p e c t t o f i n d i n a b a [ N o n a k a a n d K o n n o , 1 9 9 8 ] . Th e p e r s o n a l a s s i s ta n t i s c a p a b l e o f l e ar n i n g f r o m th e i n f o r m a t io n i t m o n i t o r s , a s w e ll a s f r o m t h e u s e r ’ s b e h a v i o r . I t s r o l e i s t o c a p t u r e en o u g h o f t h e u s e r ’ s k n o w l e d g e s o t h at i t c a n r e p l ac e t h e u s e r ( i ) f o r a n s w e r i n g s i m p l e q u es t i o n s , o r ( i i ) w h e n t h e u s e r i s n o l o n g e r a v ai l a b l e.

1 I n t r o d u c t i o n D u r i n g t h e p a s t y e a r s , d i f f e r e n t a p p r o ac h e s h a v e b ee n p r o p o s e d f o r m an a g i n g k n o w le d g e , s o m e f r o m a t e c h n i - c a l p o i n t o f v ie w , s o m e f r o m a b u s i n e s s p o i n t o f v ie w . A v e r y f i r s t p r o p o s a l d u r i n g t h e 8 0 s w a s t o u s e e x p e r t s y s - t e m s , a l lo w i n g t h e k n o w l e d g e f r o m a s i n g l e e x p e r t o r f r o m a g r o u p o f e x p e r t s t o b e s h ar e d b y o t h e r p e o p le [ H ay e s - R o t h , e t a l . , 1 9 8 3 ] . A s e c o n d a p p r o a c h w a s t o t a ck l e t h e p r o b l e m c en t r a l ly , d e v e l o p i n g a c o r p o r a te s t r u c t u r e f o r o r g a n i zi n g k n o w l e d g e [ W i ig , 1 9 9 3 ] . Mo r e r e ce n t l y , s e v e r a l p r o p o s a l s i n t r o d u c e d a d i s tr i b u t ed a p - p r o a c h u s i n g a g e n t t ec h n o l o g y [ G o u v e i a , 1 9 9 3 ; G a n d o n , e t a l . , 2 0 0 0 ; L i eb o w i t z, 1 9 9 9 ] . Th u s , o n e c a n a p p r ec i a t e t h e e v o l u t i o n th a t t o o k p l ac e f r o m d e v el o p i n g a c o n c e p - t u al m o d el o f an e x p er t ’ s al r e a d y m a t u r e k n o w l e d g e , t o c o n s i d e r in g e m er g i n g k n o w l ed g e d u r i n g co o p e r at i v e w o r k a m o n g m e m b e r s o f a t e am . T h e l a s t a p p r o ac h w a s t r ig g e r e d b y m an y s t u d i e s r e p o r t in g t h at k n o w l e d g e c o u l d n o t b e u s e d w i th o u t an a c t iv e p a r t i c i p at i o n f r o m h u m a n u s er s , a n d t h a t s y s t em s r e ly i n g o n l y o n d o c u m e n t m an - a g em e n t , i f t h ey w e r e o f t e n a s i g n i f i c an t i m p r o v e m en t o v er a p r e v i o u s s i t u at i o n , d i d n o t t a k e a l l in f o r m at i o n in t o a c co u n t ( e . g . , h o w to u s e a d o c u m e n t is r a r el y p a r t o f th e

d o cu m e n t i t s e l f ) . I n s o m e ca s e s , l i k e in R & D p r o j e ct s , k n o w l e d g e i s u s e d a n d c r e a te d i n e v e r y d a y a c ti v i t i es . H o w e v e r , w h e n n e w k n o w l e d g e i s c r e a t e d , i t i s n o t u s u - a l ly f o r m a l i z e d ( i . e . t r a n s l a t e d i n t o d o c u m e n t s ) d u e t o th e l a ck o f ti m e f r o m t h e p r o j ec t m e m b e r s o r b e c au s e o f i n - s u f f i c i e n t b u d g e t ; m o s t o f t h e t im e t h e k n o w le d g e is l o s t. W e a r e s p ec i a l l y i n t e r e s t e d i n s i tu a t i o n s w h e r e k n o w l - e d g e i s p r o d u c ed b y a g r o u p e n c o u n t e r i n g p r o b l e m s f o r c a p i t a l i zi n g i t, w h e th e r f r o m t i m e c o n s i d e r a ti o n s o r b u d g e t r es t r i c ti o n s . T h e m a i n q u e s t io n w e w a n t to a d - d r es s h e r e i s : w h a t k i n d o f t e c h n o l o g i ca l s u p p o r t co u l d i m p r o v e th e s i tu a t i o n a n d co n t r i b u t e t o d e v e lo p p a r t o f t h e o r g a n i z a t i o n a l m em o r y ? O u r a p p r o a c h i s b as e d o n t h e d e v e l o p m en t o f a n e n v i r o n m en t m i x i n g a r t i f i c ia l a g en t s a n d h u m a n s ( m u lt i - a g en t s y s t e m w it h h u m a n s , o r M A S H ) . A M A S H al l o w s m e m b e r s o f a g r o u p t o c o o p e r - a t e u s i n g g r o u p w a r e t o o l s , b u t a t t h e s a m e t i m e tr i e s to c a p t u r e h u m a n k n o w l e d g e o n t h e f ly . T h e g o a l s a r e : ( i ) t o b e a b l e to a n s w e r s i m p l e q u e s t i o n s a d d r e s s e d t o a p a r - t i cu l a r u s e r a u t o m a t ic a l l y , t h u s d e c r e as i n g h e r w o r k l o a d , a n d ( i i ) t o r e p l a c e th e u s er w h e n s h e h a s l e f t t h e o r g a n i - z a ti o n , b y h a v in g r e ta i n e d p a r t o f h e r k n o w l ed g e . Th e k n o w l e d g e w e a r e t r y in g t o c a p t u r e i s r e l a t e d t o t h e e x - c h an g e s am o n g th e m e m b e r s o f t h e g r o u p ( a s e le c t r o n i c d o cu m e n t s ) , b u t a l s o t o t h e p r o b l e m s o l v i n g b e h a v i o r o f a u s er , w h ic h i s m u c h m o r e d if f i c u lt t o r e c o v e r . Th e m a in f e a tu r e o f a M A S H i s in s p i r ed f r o m t h e co n - c e p t o f b a p r o p o s e d b y [ N o n a k a a n d K o n n o , 1 9 9 8 ] . I t l e ad t o th e c o n c e p t o f a n ag e n t c o te r i e a s e x p l ai n e d in S e ct i o n 2 . H u m a n u s e r s ar e i n te g r a t ed i n t o t h e s y s t e m t h an k s t o a p e r s o n a l a s s i s ta n t a g e n t r es e m b l in g t h e d i g i t a l b u tl e r p r o p o s e d b y [ N e g r o p o n te , 1 9 9 7 ] . Th e p e r s o n a l a s s i s t a n t i s g iv e n a s t a f f o f s p ec i a l i ze d a g en t s a s d e - s c r i b e d in S e c ti o n 2 . 1 . H o w t h e s y s t em c a p tu r e s an d o r - g a n i z e s k n o w l e d g e e i th e r f r o m t h e g l o b al e x c h a n g e s o f i n f o r m a t io n o r f r o m a u s e r ’ s b e h av i o r is e x p la i n e d i n S e ct i o n 2 . 2 .

2 M A S H A p p r o a c h O u r o v e r al l a p p r o a c h i s b a s e d o n t h e c o n c e p t o f b a a s d i s c u s s e d b y N o n a k a a n d K o n n o , a n d , a s th e y r ep o r t , o r ig i n a l ly p r o p o s e d b y N i s h i d a a n d t h e n d e v e lo p e d b y S h im i z u . I n a p a p e r [ N o n a k a a n d K o n n o , 1 9 9 8 ] , N o n a k a

M A SH E n v ir o n m e nt s fo r C o r p or a t e KM

J e an - P a u l . A. B a rt h è s C N RS UM R 65 9 9 HE U D I A S Y C

F - 60 2 0 0 U n i v e r s i t é de T e ch n o l o gi e de C o m p i è g n e, F r a nc e b a r t h e s @ ut c . f r

14

a n d K o n n o s t a t e: " B a c an b e th o u g h t o f a s a s h ar e d s p a c e f o r e m e r g i n g r el a t i o n s h i p s . [ … ] B a p r o v i d e s a p l at f o r m f o r a d v a n c i n g in d i v i d u a l a n d / o r co l l e c ti v e k n o w l e d g e . [ … ] W e c o n s i d e r b a t o b e a s h a r e d s p a c e t h a t s e r v e s a s a f o u n d a t i o n f o r k n o w l ed g e c r e a t i o n . [ … ] T h e c o n c e p t o f b a u n i f i e s t h e p h y s i c a l s p a c e, t h e v i r t u al s p a ce , a n d t h e m e n t a l s p a c e s . [ … ] B a i s a l s o c o n c e iv e d a s t h e f r a m e ( m ad e u p o f t h e b o r d er s o f s p a c e a n d t im e ) i n w h i c h k n o w l e d g e i s a ct i v a t ed a s a r e s o u r c e f o r c r e at i o n . [ … ] B a i s t h e p la t f o r m f o r th e ' r es o u r c e c o n c en t r a t io n ' o f t h e o r - g a n i z a t i o n ' s k n o w l e d g e a s s et s a n d t h e in t e l l ec t u a l iz i n g c a p a b i l i ti e s w it h i n th e k n o w l e d g e c r e a ti o n p r o c e s s es . " F r o m o u r w o r k w i t h l a r g e E u r o p ea n c o m p a n i e s w e c o u l d i n d e e d o b s e r v e t h a t d a t a , in f o r m at i o n , a n d t h e r e - s u lt i n g k n o w l e d g e a r e w i d e ly s p r ea d t h r o u g h o u t t h e e n - t e r p r i s e a n d " b e l o n g " t o r el a t i v el y s m al l g r o u p s o f p e r - s o n s . S u ch g r o u p s m a y o r m ay n o t b e p e r m a n e n t. I n th e a u to m o b i le i n d u s t r y f o r e x am p l e , g r o u p s a r e s e t u p f o r R & D p r o j ec t s t o d e s i g n n e w t y p e s o f c a r s . D u r i n g t h e p r o j e c t n e w k n o w l e d g e i s b ei n g c r e a t e d a n d u s e d b y t h e g r o u p i n c o n n e ct i o n w i t h o th e r s p e c i a l is t s i n t h e co m - p a n y . S u ch a g r o u p , if i t to o k t h e t i m e t o r ef l e c t u p o n it s k n o w l e d g e a n d o r g a n i ze i t , c o u l d q u a l i f y a s a b a . Lo c a t - i n g s u c h g r o u p s i n t h e e n t er p r i s e c a n b e d o n e b y u s i n g m e th o d s li k e t h e G A M ET H m e th o d , b a s e d o n t h e c o n c e p t o f a c t i v it y [ G r u n d s t e in , 1 9 9 6 ] . T h e n e x t q u e s ti o n i s h o w t o p r o v i d e t e c h n o l o g y t o h el p t h e a c t o r s o r g an i z e an d i m p r o v e th e i r u s e o f k n o w l ed g e , w i t h o u t a d d i n g t o th e i r w o r k l o a d o r e n d a n g e r in g t h e p r o j ec t t i m e - t a b le . T h eJ a p a n e s e p e r s p ec t i v e i s c e n t e r e d o n t h e r o l e o f p e o p l e , t h e W e s t er n p e r s p e c t iv e i s b a s e d o n t o o l s a n d i n f o r m a t i o n t e ch n o l o g y [ P a p o w s , 1 9 9 8 ] . T h u s , f o l l o w i n g a t ec h n i c al t e n d e n c y , a n d co n s i d er i n g th e d i s t r i b u te d n a tu r e o f k n o w l e d g e w i t h in t h e e n t e r p r i s e , o n e n at u r a l ly t h i n k s o f a g en t s a s a p o s s i b l e p a r a d ig m a p p l i c a b le t o th i s p r o b l e m .C o n s e q u e n t l y , it i s in t e r e s t i n g to r e s ea r c h h o w t h e a g e n tt e ch n o l o g y c o u ld b e ad a p t e d t o s u p p o r t s o m e s o r t o f b a o r g a n i z a ti o n , w h i c h is t h e o b j e c t o f t h e n e x t s e c t io n .

2 . 1 O v e r a l l A r c h i t e c t u r e S i n c e w e c o n s i d e r t h at k n o w l e d g e i s c o n t a i n e d i n t h e i n f o r m a t io n e x ch a n g e d a m o n g t h e m e m b e r s o f a p r o j e ct a n d t o t r y t o o r g a n i ze i t au t o m a ti c a l l y a t t h e l e v el o f ea c h m e m b e r , w e c h o s e t o u s e c o g n i t i v e a g e n ts , a s s o c i a t in g a p e r s o n a l a s s i s ta n t w it h e a ch m e m b e r o f t h e p r o j e c t . T h e a s s i s t a n t i s i n c h a r g e o f al l t r an s f e r s o f i n f o r m a ti o n a m o n g t h e m e m b er s o f t h e g r o u p . Th i s a p p r o a c h p r e s en t s t w o a d v a n t a g e s : ( i ) i t i s e a s y to i m p le m e n t ; a n d ( i i ) t h e i n f o r m a t io n i s f i l t e r e d ( q u a l i f i ed ) a c co r d i n g t o t h e n e e d s o f a p a r ti c u l a r s p e c ia l i s t . T h u s , i n t h i s a p p r o a c h i m p o r ta n t a g en t s a r e p e r s o n a l as s i s t an t s r at h e r th a n s er v i c e a g e n t s . T h e n e t r e s u l t i s a d i s t r i b u t e d k n o w l e d g e s y s t e m i n w h i c h t h e i n f o r m a t i o n h a s b e e n o r g a n i z ed l o c al l y a s a f u n c t i o n o f t h e p ar t i c u la r i n te r e s t s o f a g i v e n s p e c i al i s t . O f c o u r s e , i n o r d e r t o b e e f f i c ie n t , ea c h l o c a l s tr u c t u r e ( p e r s o n a l a g en t ) m u s t “ s ee ” a l l e x c h an g e d in f o r m at i o n , a s m e m b e r s i n a b a h ea r w h at o t h er s h a v e t o s a y . S ee i n g in f o r m at i o n , a n a g e n t m u s t b e a b l e t o o r g a n i z e i t .

A M A S H i n c l u d e s t w o p o p u la t i o n s o f a g e n t s . I t i s o r g a - n i ze d a s a t h r ee - l e v el a r c h i t e c t u r e : ( i ) a l o c al g r o u p o f a g en t s a s s o c i a te d w i th a p ar t i c u la r u s er ( p e r s o n a l a s s i s - t a n t a n d s t a f f a g e n t s ) ; ( i i) a c o t e r i e i n c l u d i n g s ev e r a l u s - e r s a n d th e i r o w n a g en t s p lu s s e r v i c e ag e n t s s h a r e d b y a l l; a n d ( i i i ) a c l u s t e r o f c o t e r i e s .

P e r s o n a l A s s i s t a n t s a n d S t a f f I n o u r s y s t e m a l l a g e n ts a r e c l o n e d f r o m a g e n er i c a g e n t ( r ep r e s e n t e d F ig u r e 1 ) a n d h a v e th e f o ll o w i n g s t r u ct u r e : c o m m u n i c at i o n in t e r f ac e , s k i l l s , m o d e l s o f t h e w o r ld o f i t s e l f , an d o f t h e t as k s . A s e r v ic e a g en t i m p l e m e n ts a s p e - c i f i c s e r v i c e b y u s i n g t h e c o r r e s p o n d i n g s k i ll s . A p e r - s o n a l a s s i s t a n t i s a s e r v i ce a g e n t t h a t i n c l u d e s a u s e r in - t e r f a c e , a n d a u s e r m o d e l . T h e s k i l l s o f a p er s o n a l a s s i s - t a n t a r e e n t i r el y d e v o t e d to i n t er f a c i n g i t s m a s t e r , t h e h u m a n u s er .

skills

self

user model

user

inter-faceworld

ontology

tasks

net

inter-face

control

Personal assistant

Network

F i g u r e 1 - G e n er i c A g e n t

P e r s o n a l a s s i s ta n t s ( P A ) a r e n e e d e d t o a l l o w h u m a n s t o c o m m u n i c at e w i th t h e s y s t e m . A P A w i l l t r a n s la t e a h u - m a n r e q u es t i n to t h e p r o p e r a g e n t p r o t o c o l , an d c o n - v e r s e l y d i s p l a y t h e r e s u l t s a c c o r d i n g to i t s o w n e r 's p r o - f i le . A P A c a n b e m u ch m o r e t h a n t h a t , a c t i n g o n b eh a l f o f i t s o w n e r o n s i m p le m a t te r s . Th u s , w e a d o p t e d t h e p o s it i o n o f [ N e g r o p o n te , 1 9 9 7 ] w h o a d v o ca t e d th a t a p e r s o n a l a s s i s t a n t s h o u ld b e a d i g i - t a l b u t l er , i. e . , k n o w i ts m a s te r , k n o w w h er e t o f i n d s e r v i c e s , a n d s u b c o n tr a c t al l t a s k s . H o w e v e r , b e c a u s e t h en u m b e r a n d d i v er s i t y o f t a s k s i n g e n e r al c a n b e q u it e h i g h , w e a s s o c ia t e w it h e a ch p e r s o n a l as s i s t an t a s e t o f s e r v i c e ag e n t s s p e c i al i z e d i n s u b c o n t r ac t i n g p a r t i cu l a r s e r v i c e s . T h e y f o r m th e t e ch n i c a l s t a f f. T h e p e r s o n a l a s - s i s t a n t an d i t s t e c h n i c a l s t a f f f o r m a s u b p a r t o f a c o t e r i e . A P A a n d i t s s ta f f a r e u s u al l y l o c a t e d p h y s i ca l l y o n t h e u s er ’ s m ac h i n e , a n d s e r v i c e a g e n ts f r o m t h e s t a f f w o r k f o r a s i n g l e u s e r . O t h e r s e r v i c e ag e n t s a r e s h a r e d b y a l l m e m b e r s o f a c o t e r i e .

C o t e r i e s A g en t s a r e o r g an i z e d a s s m al l g r o u p s o r c o te r i e s 1. Th e p r in c i p a l f e a t u r e o f c o t e r ie s i s t h a t th e y s h a r e t h e s a m e

1 A coterie is a small group of persons sharing some commoninterest.

15

l o ca l n e tw o r k ( F i g u r e 2 ) , al l o w i n g c o m m u n i c a ti o n s in t h e b r o a d c a s t m o d e v e r y s i m p l y a n d e co n o m i ca l l y . T h u s a g en t s i n a c o te r i e ar e c l o s e l y r e l a t e d , w h i ch d o e s n o t m e an t h a t t h e y a r e s tr o n g l y c o u p le d . A ll a g e n t s i n a c o t e - r i e i n c l u d i n g P A s a r e f i r s t cl a s s . A l l i n f o r m a ti o n i s s h ar e d , in c l u d in g s o m e i n f o r m a t i o n t h a t m a y ap p e a r t o b e i r r e l e v a n t t o a p a r t ic u l a r a g e n t . T h u s , a g e n ts c a n b e s e en a s b e i n g i m m e r s e d i n a f i e ld o f in f o r m at i o n s i m i l a r t o a r a d i o n e tw o r k . A c o t er i e i s t h e in f o r m at i o n s t r u c t u r e s u p - p o r t i n g th e c o n c e p t o f b a w h e n a p p l i e d to l o c al g r o u p s . W h il e t h e s y s t em w o r k s , e a ch a g e n t d e v el o p s it s o w n r e p r e s e n ta t i o n o f t h e s i t u at i o n , a n d , if l e a r n i n g is a l lo w e d , m a y d e v e lo p a s p e c i f ic k n o w l e d g e b a s e d o n h i s t o r y ( e . g . , t h r o u g h ca s e - b as e d r ea s o n i n g ) . E ac h a g en t i n d e x e s it s k n o w l e d g e l o c a ll y , u s i n g i ts o w n s k i l l s a s a r e f e r en t i a l ,w i th t h e p o s s i b l e h e lp o f o n to l o g i es . A g en t s c an h a v er e d u n d a n t s k i l ls a n d d e v e l o p r e d u n d a n t m o d e l s o f w h a t i s g o in g o n . T h e n u m b e r o f a g en t s i n a c o te r i e is n o t f i x e d o n ce a n d f o r a ll . N e w a g e n ts c a n j o i n th e c o te r i e , p a r t i c i - p a ti n g a g e n t s ca n l e av e o r b e r e m o v e d d y n a m i ca l l y . O f c o u r s e , if w e r e m o v e P A s f r o m t h e s y s t e m , t h i s w i l l d e - f e at o u r p u r p o s e o f b u i l d i n g a k n o w l e d g e r e p o s i t o r y . W e s h o u l d a ls o s t r e s s t h a t , e x c e p t f o r a P A a n d i t s s ta f f , w e u s u a l l y in s t a l l e a c h o f o u r a g e n ts o n it s o w n m a c h in e , m e an i n g th a t a g e n t s r u n i n p a r a l le l . M o r e i n f o r m a t io n a b o u t c o te r i e s i s a v ai l a b l e f r o m [ B a r t h è s an d T a cl a , 2 0 0 1 ] .

GW /DB

A’s staff

PA

ProjectCoterie(LAN)

Project scope

LegendPA: personnal assistantO: organizer agentP: project agentX: transfer agentR: repository agent

OB’s staff

PA

O

P

XR GW /

DB

A’s staff

PA

ProjectCoterie(LAN)

Project scope

LegendPA: personnal assistantO: organizer agentP: project agentX: transfer agentR: repository agent

OB’s staff

PA

O

P

XR

F i g u r e 2 – C o t er i e f o r K M (f r o m [B a rt h è s an d T a cl a 2 0 0 1 ] )

C l u s t e r s o f C o t e r i e s A t a h i g h e r l e v e l c o te r i e s a r e l in k e d to o n e a n o t h er . I n t h e m o d e l d i s c u s s e d b y N o n a k a a n d K o n n o , b a a t a h i g h e r l e v e l p a r t i c i p at e i n a l a r g e r o n e c a l l ed a b a s h o . Th e f i r s t h i g h e r l ev e l i s t h a t o f t h e e n t e r p r i s e , g a t h er i n g th e k n o w l - e d g e d e v el o p e d i n e a ch b a . H o w t h is c o n s o l i d a ti o n p r o c - e s s i s d o n e i s n o t r ea l l y o b v i o u s . I n o u r c a s e , w e d i d n o t a d d r e s s th i s i s s u e , b u t d e s i g n e d o n e o f t h e lo c a l a g en t t o a c t a s a f a c i l it a t o r o r a b r o k e r w h e n n o n l o ca l k n o w l e d g ei s r e q u i r e d f o r s o l v in g a p a r t i c u l a r p r o b l e m . I n t e r c o t e r i e

c o m m u n i c at i o n is d o n e p o i n t- t o - p o i n t a n d n o lo n g e r i n a b r o a d c a s t m a n n er .

2 . 2 C a p t u r i n g K n o w l e d g e A co t e r i e i s a n e n v i r o n m e n t a i m e d a t s u p p o r t in g c o ll a b o - r a ti v e w o r k . A ll a g e n t s i n a c o t er i e , w h e t h e r a r t i f i c i a l o r h u m a n , e x c h a n g e i n f o r m a t i o n i n t h e f o r m o f n u m e r i c al d o cu m e n t s . E a c h a g e n t r e c e iv e s a c o p y o f e a c h d o c u m e n t b e in g e x ch a n g e d . T h u s , e a c h a g e n t c a n p o t e n t ia l l y o r g a - n i ze t h e d o c u m en t s a cc o r d i n g t o it s o w n g o a l s t o s u i t i t s o w n p u r p o s e s . P a r t o f t h e k n o w l e d g e w i ll b e ca p t u r ed f r o m t h e s e t o f e x c h an g e d d o c u m e n t s . O n t h e o t h e r h a n d , a s p e c i f ic u s e r w o r k in g i n t h e e n v i r o n m e n t u n d e r t a k e s a n u m b e r o f t a s k s , i . e ., s e q u e n c e s o f a c ti o n s o r o p e r a t i o n s . S u ch s e q u e n c e s r e f l e ct h i s w a y o f t a c k li n g a n d s o l v i n g p r o b l e m s , a n d ar e a l s o p a r t o f h is e x p er i e n c e a n d co n t a i n k n o w l e d g e. S i n ce a P A i s c lo s e l y a s s o c ia t e d w i t h a h u - m a n u s e r , i t i s w o r t h t r y i n g t o u s e t h e a s s o ci a t i o n t o c ap - t u r e ( i . e. , f o r m a l i z e a n d o r g a n i ze ) t h e u s e r ’ s b e h av i o r , i n o r d e r t o s h a r e h i s a p p r o a c h w i t h o t h e r p e o p l e. T h e n e x t t w o s u b s ec t i o n s d e t a il h o w w e a d d r e s s b o t h p r o b l e m s .

K n o w l e d g e f r o m E x c h a n g e d D o c u m e n t s I n f o r m a t io n e x ch a n g e d a m o n g t h e d i f f e r en t u s er s c o n s i s t s o f e l e c t r o n i c d o c u m e n t s , t ex t u a l , g r a p h i c s , au d i o o r v i d e o . W e w i l l f o c u s h e r e o n t e x tu a l d o c u m e n ts l i k et e ch n i c a l d o c u m e n t s , e - m a i ls , a n n o t a t e d g r a p h i c s , au d i o o r v i d e o . D o c u m e n t s ar e e a s i l y o r g a n i z ed u s i n g l e a r n i n g t e ch n i q u es . A l t h o u g h e a c h M A S H a g e n t c o u l d o r g a n iz e d o cu - m e n t s — a n d i t w il l b e t h e c as e f o r t h e s e r v i c e a g e n t i n c h ar g e o f t h e p r o j e c t d o c u m e n t s — w e o n l y c o n s id e r h er e p e r s o n a l a s s i s ta n t s an d t h ei r s t af f . W e u s e a s i n g le l e a r n - i n g a p p r o a c h b as e d o n a u t o m a t i c cl a s s i f i c a t i o n . T h eo v er a l l ap p r o a ch i s th e f o ll o w i n g . A u s e r k e ep s d o cu - m e n t s i n d i f f e r e n t f il e s ( m a i n t a in e d b y o n e o f t h e s t a f f a g en t s ) . T h u s , w h e n e v e r a n e w d o cu m e n t c o m e s i n , i t i s a n al y z e d a n d c o m p a r e d w i t h t h e a lr e a d y s a v e d d o c u - m e n t s , a n d , i f s u f f i ci e n t l y c l o s e, p r o p o s e d to t h e u s e r . D i s c r i m i n a t i o n i s b a s e d o n a f i l te r i n g a l g o r it h m u s i n g t h e T F /I D F a p p r o a c h t h a t w e e x te n d e d t o t a k e i n t o a c co u n t a n o p e n v o c a b u la r y ( s e e [ E n em b r e c k a n d B a r t h è s , 2 0 0 2 ] f o r d e t a il s ) . Le t u s b r i e f ly i l l u s t r a t es t h e g l o b a l a p p r o a c h f o r e x a m p l e f o r g e t t in g i n f o r m a t io n f r o m t h e W e b . A P A u s es t w o s t a f f a g e n t s : a F il t e r i n g A g e n t ( F A ) a n d a L i - b r ar y A g en t ( L A ) a n d a n u m b e r o f s e r v i ce a g e n t s ( F ig u r e 4 ) . T h e u s e r a s k s f o r i n f o r m a t i o n g i v i n g s o m e c l u e s t o h e r P A . Th e P A s e n d s a r e q u e s t t o t h e F i l t e r in g A g en t . T h e F i l t er i n g A g e n t ac t i v a te s a n u m b e r o f s e r v i c e ag e n t s ,o n e f o r ea c h s ea r c h en g i n e o f i n te r e s t . A t t h e s a m e t i m e t h e F i l t er i n g A g e n t o b t a i n s f r o m t h e L ib r a r y A g e n t v a r i - o u s p r o f il e s c o r r e s p o n d i n g t o t h e u s e r ’ s i n t er e s t s ( o n e p r o f i l e o r v e c to r f o r e a c h d o m a i n o f i n t e r e s t) . T h en , t h eF i lt e r i n g A g e n t c o l l ec t s d o c u m e n ts f r o m t h e s e r v i c ea g en t s ( ty p i c a ll y s e v e r a l h u n d r e d ) . E a ch d o c u m e n t is p r o c e s s e d t o a cq u i r e a v e c to r r e p r e s e n ti n g i t, u s i n g a n o n to l o g y . T h e n a s i m p l e c r o s s - p r o d u c t b e t w e e n t h e v e c - t o r s r e p r e s e n t in g t h e a c q u ir e d d o c u m e n t a n d a v e c t o r r e p -

16

r e s e n t i n g a d o m a i n o f i n t e r e s t i s d o n e , a n d th e n e w d o cu m e n t i s k e p t w h e n t h e r e s u l t i s a b o v e a p r e d e f in e d t h r e s h o l d . R e c o v e r e d d o c u m en t s ( ty p i c a ll y a d o z e n ) a r e p r es e n t e d t o t h e u s e r , a n d i f s h e d e c i d e s t o k e e p th e m , ar e i n s e r t e d i n t o th e f i le s r e p r e s e n ti n g t h e d o m ai n s o f i n t e r e s t ( a n d m a i n t a i n e d b y t h e L i b r a r y A g e n t ) . T h e c o m p u t a ti o n s a r e s t r a ig h t f o r w a r d , e x c e p t f o r a t r i c k y p a r t r e l a te d t o t h e p o s s i b i l it y o f a n o p en v o c ab u l a r y i n t h e o n to l o g i es . T h is a p p r o a c h i s u s ed o n al l d o cu m e n t s c o n t ai n i n g t e x t , w i t h e x ce l l e n t r e s u lt s , a n d p e r m i t s t o o r g a n i z e t h e d o c u m e n t s .I t c a n f u n c t i o n f u l l y a u t o m a t i c a ll y .

F i g u r e 4 – O r g an i z i n g d o c u m e n t s

C a p t u r i n g U s e r ’ s B e h a v i o r S e v e r a l r e s e a r ch g r o u p s h a v e p r o p o s e d to r e c o r d l e s s o n s l e ar n e d , b a s e d o n a u s e r ’ s b e h a v io r , i n p a r t ic u l a r [ I k e d a , e t a l . , 2 0 0 2 ] f o r c o r p o r a t e l e a r n in g , [ A l th o f f , e t a l ., 2 0 0 2 ] f o r b u s i n e s s p r o c e s s es o r [ M a tt a , e t a l . , 2 0 0 2 ] f o r e n g i - n e er i n g d e s i g n . T h e y a l l u s e s o m e m o d e l f o r ac q u i r in g a n d i n d e x i n g i n f o r m a ti o n . O u r a p p r o a c h i s a b o t t o m u p a p p r o a c h a n d a im s a t r e c o r d i n g t h e u s e r ’ s b e h a v i o r a u t o - m a ti c a l l y w h e n ev e r p o s s i b l e, b u i ld i n g a l i b r ar y o f c a s e s .I t c o m p r is e s s ev e r a l s t e p s : c a p t u r i n g an d r e p r e s e n ti n g a n a c ti o n o r o p e r at i o n , a u g m e n t i n g an o p e r a t i o n r e p r e s e n t a - t i o n , c l u s t e r i n g o p e r a t i o n s , i n d ex i n g an d c l as s i f y in g t h er e s u l t s . A l l t h i s i s d o n e lo c a l l y ( p e r s o n a l as s i s t an t a n d i t s s t af f ) a n d r e s u l t s i n t o a d i s t r i b u t ed m e m o r y . C a p t u r i n g o p e r a t i o n s . A c t i o n s o r o p e r a t i o n s a r e m a i n ly r e la t e d to c o m m u n i c a ti o n s ( e . g . s e n d i n g e - m a il s ) , o r d o cu m e n t s ( e . g . s e a r ch i n g f o r d o cu m e n t s ) . T h ey c a n b e a c ti v a t e d f r o m t h e u s e r i n te r f a c e p r o v id e d b y t h e P A . T h eP A b u i l d s a r e p r e s e n ta t i o n f o r e ac h o p er a t i o n a s i ll u s - t r at e d F ig u r e 5 f o r a s a v e - d o c u m en t , c h a t , a n d s e n d - e m a i lo p er a t i o n . N o t e t h a t a n o p er a t i o n h a s al w a y s a n a s s o c i - a t ed d o c u m e n t . A u g m e n t i n g a n o p e r a t io n r e p r e s e n t a t i o n . O n c e t h e P A h a s p a r t ia l l y r e p r e s en t e d an o p e r a t i o n , i t t r a n s f e r s i t to t h e O r g a n i z e r A g e n t t h a t w i l l co m p l e m e n t t h e r e p r e s e n t at i o n b y i d e n t if y i n g t h e r el e v a n t t e r m s o f t h e a s s o c i a t e d d o c u - m e n t . T h e r e l e v a n c e o f a t er m r e s u l t s f r o m a s i m p l em e as u r e b a s e d o n t h e t e r m f r e q u e n c y . A t e r m m u s t b e - l o n g t o th e d o m a i n o n t o l o g y .

C l u s t e r i n g o p e ra t i o n s . O n c e t h e O r g an i z e r A g e n t h a s g a th e r e d a n u m b e r o f o p e r a ti o n s to g e t h er w i t h t h e as s o c i - a t ed d o c u m e n t s , i t c lu s t e r s o p e r at i o n s i n a n a t t e m p t t o c o r r e l a t e t h e m w i t h an i m p li c i t in t e n t io n . I .e . , t h e d o c u - m e n t s a r e c o r r el a t e d b e c a u s e t h e y a r e r e l e v a n t f o r s a t i s - f y in g a g o a l a lt h o u g h t h i s g o a l is n o t e x p l i ci t l y r e p r e - s e n t e d . Cl u s t e r i n g o f o p e r at i o n s h a s a d u a l p u r p o s e: o r - g a n i z e d o c u m e n ts b y th e s i m i l a r i ty o f th e i r r e l e v a n t t e r m s , a n d h e l p t h e u s e r t o m a k e h i s i n t e n t i o n s e x p l i c i t .T h e O r g a n i z e r A g e n t k e e p s th e o p er a t i o n s i n a f r a m e r e p - r e s e n t a t io n . F o r e a c h n e w o p e r a t io n , i t l o o k s f o r a c l u s te r t h at b e s t f i t s t h e o p e r a t i o n , u s in g C O BW E B , an i n c r e - m e n t a l u n s u p e r v i s e d le a r n i n g a l g o r i t h m b y ( F is h e r 1 9 9 0 ) . F i g u r e 5 s h o w s c l u s t er s b u il t a u to m a t i ca l l y b y t h e s y s - t e m , b a s ed o n th e r e le v a n t t e r m s o f t h e t h r e e o p e r at i o n s t h at a u s e r n a m e d F r ed h a s p e r f o r m e d : f i n d i n g a t u to r i a l ,c h at t i n g w i t h S h e i l a , a n d s e n d i n g a n e - m a i l to P e t er . A t t h is s t a g e , e v en i f th e u s er d o e s n o t r e a r r a n g e t h e o p e r a - t i o n s , a t l e a s t t h e s y s t e m h a s o r g a n i z ed t h e d o c u m en t s b y i n d e x i n g t h e m au t o m a ti c a l l y .

Operation 1

Type: SAVE-DOCName: save-doc-1Owner: FredRelevant-terms: form, view, DBDocument: tutorial.html

Fred’s clusters

Type: CHATName: chat-1Owner: FredParticipants: SheilaRelevant-terms: field, computed, formDocument: TipsSheila.txt

Operation 2

Type: SEND-EMAILName: s-email-1Owner: FredParticipants: PeterRelevant-terms: field, computed Document: toPeter.txt

Operation 3

Relevant-terms: form, view, DB

Cluster 1

Relevant-terms: field, computed, form

Cluster 2

Operation 1

Type: SAVE-DOCName: save-doc-1Owner: FredRelevant-terms: form, view, DBDocument: tutorial.html

Fred’s clusters

Type: CHATName: chat-1Owner: FredParticipants: SheilaRelevant-terms: field, computed, formDocument: TipsSheila.txt

Operation 2

Type: CHATName: chat-1Owner: FredParticipants: SheilaRelevant-terms: field, computed, formDocument: TipsSheila.txt

Operation 2

Type: SEND-EMAILName: s-email-1Owner: FredParticipants: PeterRelevant-terms: field, computed Document: toPeter.txt

Operation 3

Type: SEND-EMAILName: s-email-1Owner: FredParticipants: PeterRelevant-terms: field, computed Document: toPeter.txt

Operation 3

Relevant-terms: form, view, DB

Cluster 1

Relevant-terms: field, computed, form

Cluster 2

F i g u r e 5 – C l u st e r i n g o f F re d ’ s o p e r a t io n s ( ta k e n fr o m [ T a cl a a n d B a rt h è s , 2 0 0 3 ] )

C r ea t i n g t a s k s o r l e s s o n s le a r n e d . W h e n a u s e r t h i n k s t h at a c lu s t e r i s w e ll f o r m e d , s h e m a y d e c i d e t o t r a n s f o r m i t i n t o a t a s k o r a le s s o n l e a r n ed ( L L ) . T o d o t h i s s h e ex - t r ac t s a m o d e l f r o m th e R & D t a s k o n t o l o g y a n d f i l l s p a r t

17

o f t h e p r o p o s e d s l o t s , w h i le t h e O r g a n iz e r A g e n t f il l s t h e r e s t f r o m i n f o r m a t i o n f o u n d i n t h e c l u s t e r . I n d e x i n g t h e r es u l t i n g t a s k o r L L. F i n a l l y , t h e O r g a - n i ze r A g en t , u s i n g t h e d o m ai n o n to l o g y , p e r f o r m s a l e x i - c a l a n a l y s i s o f t h e te x t u a l d e s c r i p t i o n s a d d ed m a n u a l l y b y t h e u s e r , a n d ex t r a c ts t e r m s t h a t w i l l i n d e x t h e t as k o r L L . S u ch i n d ex e s i n c o n j u n c t i o n w i t h o t h e r L L s l o t s ( e .g . p r o j e c t ta s k , in v o l v ed p e o p l e ) w il l e n ab l e t ea m m e m b e r s t o r e t r i ev e t h e L L i n f o r m a ti o n . E x p l o i t i n g a n d s h a r i n g t h e L L . O v e r t im e , t ea m m e m - b e r s a c c u m u l a t e e x p e r i e n c e s a n d th e i r o r g a n i ze r a g en t s a r r a n g e th e m a s L L , ta s k s , a n d o p e r a t i o n s . T h e s h a r i n g o f s u ch e l e m e n t s o c c u r s w h e n : ( i ) u s e r m a k e s a r e q u es t t o h i s P A ; ( i i ) a P A m a k e s a r e q u e s t t o o th e r P A s ; ( i i i) a P A p r o - a c t i v e l y s u g g e s t s a p a s t e x p er i e n c e t o t h e u s e r ; ( i v ) a P A “ h e a r s ” o t h er P A s e x c h an g i n g m e s s a g e s .

I m p o r t a n t P o i n t s F i r s t , i n t h e p r o p o s ed s y s te m , i n f o r m a ti o n c an b e g r a d u - a l ly f o r m a l i z e d [ S h ip m a n an d M c ca l l , 1 9 9 7 ] . Th u s , a u s e r c a n w o r k w i t h is o l a t ed o p e r a t i o n s a n d d o c u m e n t s , t as k s , o r L L . T h e c l u s t e r i n g o f o p e r a t i o n s i s i n t e n d e d t o e a s e th e c r ea t i o n o f t a s k s a n d L L . Th e c r ea t i o n o f t a s k s a n d L L s r e d u c e s th e i n f o r m a t io n o v er l o a d a n d i m p r o v e s t h e ac c u - r a cy o f th e r e tu r n e d a n s w e r s , w h en l a t er q u e r y i n g th e s y s t e m . Be s i d e s , i n a m o r e g e n e r al p e r s p e c t i v e , i t i s a t e n t a t i v e t o h el p t e am m e m b e r s t o a r t i cu l a t e p a r t o f t h e ir t a ci t k n o w l e d g e a n d to s t i m u l a t e t h e m f o r s h ar i n g it . S e c o n d , a u s er s h a r e s h i s e x p e r i e n c e s i n a t r a n s p a r e n t w a y . W h i le h e is w o r k i n g , h i s O r g a n i z e r A g e n t i s a b l e t o a n s w e r q u e r i e s c o m i n g f r o m o t h e r a g e n t s t a f f s . I n t h e o t h e r d i r e c t i o n , a P A i s a b l e t o c a p t u r e L L s f r o m o t h e r m e m b e r s o r s e n d s r e q u e s t s f o r i n f o r m a t io n t o t h e m in o r d e r t o m a k e s u g g e s ti o n s to i t s m a s t e r . S u c h a m e ch a - n i s m e m u la t e s w h a t h ap p e n s i n a r e a l t ea m : e ac h t e am m e m b e r p er f o r m s h i s o w n t a s k s a n d w h e n h e m i s s e s s o m e i n f o r m a t i o n ( o r k n o w l ed g e ) to c o m p l e t e th e t a s k , h e c a ll s h i s c o l l ea g u e s f o r h el p .

2 D i s c u s s i o n a n d C o n c l u s i o n A s m e n t i o n e d a t t h e b e g i n n in g o f t h i s p a p e r w e a r e i n t e r - e s te d i n c a p t u r i n g k n o w l e d g e i n tr a n s i en t g r o u p s , e. g . , i n v o l v e d i n R & D p r o j ec t s . K n o w l e d g e i s c r e a t ed w h i le t h e t e a m i s w o r k i n g . S o m e k n o w l e d g e i s e x p l i ci t a n d c o n t a i n e d i n t h e e x c h a n g e d d o c u m en t s , s o m e k n o w l e d g e i s i m p l i ci t a n d r e s u lt s f r o m t h e t e a m m e m b e r s ’ b e h av i o r . W e p r o p o s e d t o d e v e l o p a n en v i r o n m e n t co n t a i n i n g a r t i - f i ci a l a n d h u m an a g e n t s , a M A S H . I n s u ch a n en v i r o n - m e n t e a c h h u m a n u s e r i s g i v e n a p e r s o n al a s s is t a n t w i t h s p ec i a l i ze d s t af f a g en t s . Th e e n v i r o n m en t i s u s e d f o r t w o p u r p o s e s ; ( i ) t o r e co r d a n d o r g an i z e d o c u m e n t s ; a n d ( i i ) t o c a p t u r e , f o r m a l i z e a n d o r g a n i ze u s e r s ’ b e h a v i o r .

R e l a t e d W o r k O r g a n i z i n g d o c u m e n t s i s n o t n e w . I n o u r a p p r o a c h i t i s d o n e i n s e v e r a l p l a c es : c e n t r a l l y b y a s p e c i al i z e d s e r v i ce a g en t f o r t h e w h o l e p r o j e c t, a n d l o c a l ly b y ea c h p er s o n a la s s i s t a n t f o r ea c h u s e r . I n t h e la t t e r c a s e a p r i v at e O r g a -

n i ze r A g en t r e co r d s an d c l as s i f i es a l l e l e c t r o n i c d o c u - m e n t s t h at i t ju d g e s i n t e r es t i n g f o r i ts m a s te r . O r g a n i z in g a n d r e t r ie v i n g d o c u m en t s u s i n g a g e n t s h a s b e en d o n e i n a n u m b e r o f p r o j ec t s i n t h e p a s t , r a n g i n g f r o m s i n g l e a d - v i s i n g a g e n t s [ L i eb e r m a n , 1 9 9 5 ; L i eb e r m a n , e t al . , 1 9 9 9 ; C h en a n d S y ca r a , 1 9 9 8 ] , to q u i te s o p h i s t i c at e d s y s t e m s [ K it a m u r a, e t al . , 2 0 0 1 ; G a n d o n e t a l . , 2 0 0 0 ; B a y a r d o J r . , e t a l . , 1 9 9 7 ] . O u r a p p r o a c h i n t h is d o m ai n i s n o t v er y d i f f e r e n t t o w h a t h a s a l r e ad y b e en p r o p o s e d . Ca p t u r in g i m p l i c i t k n o w l ed g e i s m o r e i n t e r es t i n g . I t i s t h u s w o r th s t r es s i n g t h e d if f e r e n c e s w it h o t h e r p r o p o s a l s . I n t h e i n d i G o p r o j e c t [ A l th o f f e t a l . , 2 0 0 2 ] o n e s t a r t s f r o m i n d iv i d u a l a c t i o n s ( a n n o t a t io n s o r d i s c u s s i o n s ) t o p r o d u c e p r o c e s s d e s c r i p t i o n s , i . e. , s e m i f o r m a l c a s e s r e p - r e s e n t i n g p r o c es s e s . A c t i o n s a r e o r g a n iz e d w it h r e s p e c t t o t h o s e m o d e l s a n d ce n t r a li z e d in t o a n e x p e r i e n c e b a s e . P r o c e s s m o d e l s a r e s u b j e c t t o e v o l u t i o n . T h u s , t h e o r g a - n i za t i o n d e p e n d s e s s en t i a l ly o n a s e t o f p r e d e f i n e d l a b e ls , a n d n o t as i n o u r c a s e o n an a n a ly s i s o f t h e i n f o r m a l c o n t e n t o f t h e d o c u m en t s . [ M a tt a e t a l . , 2 0 0 2 ] p r e s e n t a n a p p r o a c h f o r c o n t i n u o u s c a p t u r e o f d e s ig n k n o w l e d g e. T h ei r a p p r o a c h d e p e n d s o n th e a v ai l a b i li t y o f a l i b r a r y o f p r ed e f i n ed m o d el s l i n k e d t o d e s i g n a c t iv i t i e s . A l l n e t - w o r k t r a f f i c o r i g i n a ti n g a t t h e u s e r ’ s p l a c e i s s e n t t o ak n o w l e d g e e n g i n e e r w h o h a s th e r e s p o n s i b i l i t y o f s t r u c - t u r i n g t h e d o c u m e n t s . T h e r e s u l t i s a s e t o f X M L d o c u - m e n t s , w it h o u t a n y s p e c i f i c g l o b al s t r u c t u r e l i k e p r o c e s s d e s c r i p t io n s i n t h e p r e v i o u s c a s e o r c lu s t e r s i n o u r c a s e. T h e p r o j ec t i n f o r m a t io n i s c e n t r al i z e d a n d t h e r e i s n o e x p l i c i t u s e o f o n to l o g i es o u t s i d e t h e X M L l a b e l s ( ? ) . F i n a l l y , t h e a p p r o a c h f r o m [ I k e d a e t a l . , 2 0 0 2 ] i s m o r e g e n e r a l b u t n e v e r t h e le s s r el a t e d . C o n c r e t e a ct i v i t ie s a r et h e s t a r ti n g p o i n t o f t h e ap p r o a ch . T h ey a r e a g g r e g a t e d i n to a n “i n t e l le c t g en e a l o g y g r a p h ” a n d t h e n r e f i n ed i n t o a m o d e l o f i n t el l e c t . T h e r e s u l t o f p a r s i n g an a c t iv i t y f r o m a u s e r ’ s ac t i o n s i s h o w e v e r n o t c le a r . A n i n t el l e c t g e n e a l o g y g r a p h i s a t i m e s e r i e s o f c o n c r e t e a c t i v it i e s o b s e r v e d i n t h e w o r k p l a c e a n d i s d i f f er e n t f r o m o u r c l u s t e r w h e r e ti m e i s n o t a c r u c ia l c o m p o n e n t. A l l i n - f o r m a t i o n is ce n t r a li z e d . Th u s , an i m p o r t a n t a s p e c t o f o u r a p p r o a c h is t h e b u i l d - i n g u p o f l o c a l k n o w le d g e r e p o s i to r i e s , i n c l u d i n g d o c u - m e n t s f i lt e r e d b y t h e p r o f il e o f a g i v en u s e r , a n d c a s e s d e s c r i b i n g t h e b e h a v io r o f t h e u s e r . T h e c o t er i e o r g a n i z a - t i o n f a v o r s t h e k n o w le d g e ex c h a n g e s , p u t t i n g t h e e m p h a - s i s o n t h e r o l e o f t h e p e r s o n a l as s i s t an t a g en t s . W h e n a u s er i s n o t a v ai l a b l e f o r s o m e r ea s o n , h e r P A c a n an s w e r s o m e s i m p l e r e q u e s t s a u t o m at i c a l ly . W h en t h e u s e r l e av e s t h e o r g an i z a t io n , i t i s n o t n e c es s a r y t o r e m o v e h er P A f r o m th e g l o b a l s y s t e m .

F u t u r e W o r k W e s t r o n g l y b e li e v e th a t m a n a g i n g k n o w l ed g e c an n o t b e d o n e b y an e x t er n a l o r g e n er a l t o o l , b u t n e e d s t h e s u p p o r t o f a n e n v i r o n m en t l i k e a M A S H i n w h i c h u s e r s a r e i n - c l u d e d . W e a l s o b e l i ev e t h at k n o w l e d g e i s b y e s s e n ce d i s t r i b u te d a n d s h o u ld b e o r g a n i ze d a t t h e l ev e l o f a u s er . A l l t h e m e c h a n is m s p r e s e n t ed i n th i s p ap e r h av e b e en i m p l e m e n te d u s in g o u r O M A S p l a t f o r m a n d w e a r e

18

b u il d i n g a w o r k i n g M A S H e n v i r o n m en t t o b e t e s t e d i n C S CW i n D e s i g n ( b y g r o u p s o f F r e n c h a n d U S s tu d e n t s ) . W e t h e n n e e d t o d o m o r e r e s e a r c h o n t h e r o l e o f i n f o r - m a ti o n p er c e i v ed b u t n o t d ir e c t l y a d d r es s e d to a s p e c i f i ca g en t ( i .e . , o v e r h e a r d b y an a g e n t ) . I n t h e lo n g e r t e r m w e w o u l d l i k e t o ad d r e s s t h e p r o b l e m o f c lu s t e r s o f c o t e r i e t o b e d e p l o y e d a t t h e l ev e l o f a d e p a r t m e n t o r a d i v i s i o n .

A c k n o w l e d g m e n t s

T h e w o r k h a s b ee n f i n a n c e d i n p a r t b y th e F r en c h C N R S u n d e r t h e P R O S P E R p r o g r a m an d b y t h e R eg i o n o f P i ca r d i e w i t h th e A A CC p r o je c t . I a m i n d e b t e d t o F a b r i - c i o E n em b r e c k w h o d e s i g n ed t h e n e w c la s s i f ic a t i o n a l g o - r i th m , a n d t o Ce s a r T a cl a w h o i m p l em e n t e d t h e p a r t c o n - c e r n i n g th e u s er ’ s b eh a v i o r .

R e f e r e n c e s [ A l th o f f e t a l . , 2 0 0 2 ] K l au s - D i et e r A l th o f f , U l r i k e

B e ck e r - K o r n s t a e d t , B j ö r n D ec k e r , A n d r e as K l o t z , E d d a L e o p o l d , J ö r g R e ch a n d A n g i V o s s . En h a n c in g E x p e r i e n ce M a n ag e m e n t a n d P r o c e s s L e a r n i n g w it h M o d e r a t e d D i s c o u r s e s : t h e i n d i G o A p p r o a c h . I n P r o - c e ed i n g s o f t h e K n o w le d g e Ma n a g e m e n t a n d O r g a n i - z a ti o n a l M e m o r y W o r k s h o p , EC A I 2 0 0 2 , p a g e s 1 - 1 0 , L y o n , F r an c e , J u l y 2 1 - 2 6 , 2 0 0 2 . E C A I .

[ B a r t h è s an d T a cl a , 2 0 0 1 ] J e an - P a u l A . B a r t h è s a n d C e - s a r A . T a cl a . Ma n a g i n g K n o w l e d g e w i t h Co t e r i es o f N o is y A g en t s . I n P r o c e e d i n g s o f t h e S CS ' 0 1 , M a r s e i l l e, F r an c e , 2 0 0 1 .

[ B a y a r d o J r . e t a l . , 1 9 9 7 ] R . J . B a y a r d o J r . , W . B o h r e r , R. B r ic e , A . . C i ch o c k i , J . F o w l e r , A . . H e la l , V . K a s h y a p , T . K s ie z y k , G . M a r t i n , M. N o d i n e , R a s h i d M ., M . R u s i n k i e w i c z , R. S h ea , C . U n n i k r i s h n a n , A . U n r u h a n d D . W o el k . I n f o S l e u th : A g en t - B a s e d S e m a n t i c I n t e g r a - t i o n o f I n f o r m at i o n in O p e n a n d D y n a m i c E n v i r o n - m e n t s . I n P r o c e e d i n g s o f t h e t h e A C M S I G M O D I n t e r - n a ti o n a l C o n f e r e n c e o n M a n a g e m e n t o f D a t a , p a g e s 1 9 5 - 2 0 6 , 1 9 9 7 . A C M P r e s s .

[ C h e n a n d S y ca r a , 1 9 9 8 ] L Ch e n a n d K S y ca r a . W e b - m a te : A P e r s o n al A g e n t f o r B r o w s in g a n d S e a r ch i n g . I n P r o c e e d i n g s o f t h e 2 n d I n t er n a t i o n a l C o n f e r e n c e o n A u to n o m o u s A g e n t s ( A g e n t s ’ 9 8 ) , p a g e s 1 3 2 - 1 3 9 , M i n - n e ap o l i s , M N , U S A , 1 9 9 8 . A CM P r e s s .

[ E n em b r e c k a n d B a r t h è s , 2 0 0 2 ] F a b r i c i o E n em b r e c k a n d J e an - P a u l B a r t h è s . P e r s o n a l A s s i s ta n t s to I m p r o v e C S CW D . I n P r o c e e d i n g s o f t h e T h e S e v e n t h I n te r n a - t i o n a l C o n f e r e n c e o n C o m p u te r S u p p o r t e d C o o p er a t i v eW o r k i n En g i n e er i n g , p a g e s 3 2 9 - 3 3 5 , R i o d e J a n e ir o , B r as i l , 2 0 0 2 2 0 0 2 . C O P P E / U F RJ .

[ G a n d o n e t a l . , 2 0 0 0 ] F G a n d o n , Ro s e D i en g , O l i v i e r C o r b y a n d A G i b o i n . A Mu l t i - A g e n t S y s t e m t o S u p - p o r t E x p lo i t i n g a n X ML - B a s ed C o r p o r a t e M e m o r y . I n P r o c e e d i n g s o f t h e T h i r d I n t e r n a ti o n a l C o n f e r e n c e o n P r a c t i c a l A s p e ct s o f K n o w l ed g e M a n a g e m en t , p a g e s 1 0 /1 - 1 2 , B a s e l , S w i t z e r la n d , 2 0 0 0 .

[ G o u v e i a , 1 9 9 3 ] F e li z R i b e i r o G o u v e i a . O p e n S y s t e m s a n d C o r p o r a t e K n o w l e d g e . I n P r o c e e d i n g s o f t h e

I S MI C K ' 9 3 , p a g e s 5 3 - 6 3 , C o m p i è g n e, F r a n c e , 1 9 9 3 . E C 2 , P a r is .

[ G r u n d s t e in , 1 9 9 6 ] M i ch e l G r u n d s t e in . C O RP U S - A n A p p r o a c h t o C a p i t a l i ze C o m p a n y K n o w l e d g e . I n P r o - c e ed i n g s o f t h e T h e f o u r th I n t er n a t i o n a l W o r k s h o p : A r ti f i c i a l I n t el l i g e n c e i n E c o n o m i c s a n d M a n a g e m e n t, T e l A v i v , I s r a el , j a n 6 - 1 0 1 9 9 6 .

[ H ay e s - R o t h e t a l . , 1 9 8 3 ] F r ed e r i k H ay e s - R o t h , D o n a l d A . W a te r m a n a n d D o u g l a s B . L e n a t . B u il d i n g E x p e r tS y s t e m s , A d d i s o n - W e s l ey , L o n d o n , 1 9 8 3 .

[ I k e d a e t a l . , 2 0 0 2 ] M i ts u r u I k e d a , Y u s u k e H a y a s h i , H i - r o y u k i T s u m o t o a n d R i ic h i r o M i zo g u c h i. A n I n t el l e c - t u al G e n ea l o g y G r a p h - A f f o r d i n g a F i n e P r o s p e c t o f O r g a n i z a ti o n a l L e a r n in g . I n P r o c e e d i n g s o f t h e K n o w l - e d g e M a n a g e m e n t a n d O r g a n i z a t i o n a l M e m o r y W o r k - s h o p , E C AI 2 0 0 2 , p a g e s 7 1 - 7 7 , L y o n , F r a n c e , J u l y 2 1 - 2 6 , 2 0 0 2 . E C A I .

[ K it a m u r a e t a l . , 2 0 0 1 ] Y a s u s h i k o K it a m u r a, T e r u h i r o Y a m a d a , Ta k a s h i K o k u b o , Y a s u h i r o M a w a r i m i ch i , T a iz o Y am a m o t o a n d To r u I s h i d a . I n te r a c t iv e I n te g r a - t i o n o f I n f o r m at i o n A g e n t s o n t h e W e b . I n P r o c e e d i n g s o f t h e 5 th I n t er n a t i o n a l W o r k s h o p , C I A 2 0 0 1 , M o d e n a , I t al y , S ep t e m b er 2 0 0 1 .

[ L i eb e r m a n , 1 9 9 5 ] H e n r i L i eb e r m a n . L e ti z i a : A n A g en t T h at A s s is t s W eb B r o w s i n g . I n P r o c e e d i n g s o f t h e I n - t e r n a t i o n a l J o in t C o n f e r e n ce o n Ar t i f i ci a l I n t e l l i g e n c e , M o n t r é a l , C a n a d a , 1 9 9 5 .

[ L i eb e r m a n e t a l . , 1 9 9 9 ] H e n r i L i eb e r m a n , N v a n D y ck e a n d A V i v a c q u a . L e t ’ s b r o w s e : a co l l a b o r a t i v e b r o w s - i n g a g e n t, E l s e v i e r S c i e n ce B . V, 1 2 : 4 2 7 - 4 3 1 , d e c1 9 9 9 .

[ L i eb o w i t z, 1 9 9 9 ] J a y L i eb o w i t z. K n o w l e d g e M a n a g e - m e n t H a n d b o o k , CR C P r es s , 1 9 9 9 .

[ M a tt a e t a l . , 2 0 0 2 ] N a d a M a tt a , Be n o i t E y n a r d , Li o n e l R o u c o u l e s a n d M a r c L e m e r c i e r . C o n t i n u o u s c a p it a l i - z a ti o n o f d e s i g n k n o w l e d g e . I n P r o c e e d i n g s o f t h e K n o w l e d g e M a n a g e m e n t a n d O r g a n i z a t i o n a l M e m o r y W o r k s h o p , E C A I 2 0 0 2 , p a g e s 9 9 - 1 0 7 , Ly o n , f r an c e , J u ly 2 1 - 2 6 , 2 0 0 2 . E C A I .

[ N e g r o p o n te , 1 9 9 7 ] N N e g r o p o n te . A g e n t s : F r o m D i r e c tM a n i p u l a ti o n t o D e l e g a t i o n . I n S o ft w a r e A g e n t s J . M . B r ad s h a w , e d . , p a g e s 5 7 - 6 6 , 1 9 9 7 , M I T P r e s s .

[ N o n a k a a n d K o n n o , 1 9 9 8 ] I k u j i r o N o n a k a a n d N o b u r u K o n n o . T h e C o n ce p t o f " B a " : B u i ld i n g a F o u n d a t i o n f o r K n o w le d g e Cr e a t i o n , C a li f o r n ia M a n a g e m e n t R e - v i ew , 4 0 ( 3 ) : 4 0 - 5 4 , 1 9 9 8 .

[ P a p o w s , 1 9 9 8 ] J P a p o w s . E n te r p r i s e . c o m , B r ea l e y P u b - l i s h i n g , L o n d o n , 1 9 9 8 .

[ S h ip m a n an d M c ca l l , 1 9 9 7 ] F . S h ip m a n a n d R . M c Ca l l . I n te g r a t in g D i f f e r e n t P e r s p e c t i v es o n D e s i g n R a t i o n - a l e: S u p p o r t i n g t h e Em e r g e n c e o f D e s i g n R a t i o n a l e f r o m D e s ig n C o m m u n i c at i o n , A r ti f i c i a l I n t el l i g e n c e i n E n g i n e e r in g D e s i g n , An a l y s is , a n d M a n u fa c t u r in g ( A I E D A M ) , 1 1 ( 2 ) : 1 4 1 - 1 5 4 , 1 9 9 7 .

[ W i ig , 1 9 9 3 ] K a r l M . W i ig . K n o w l e d g e M a n a g e m e n t F o u n d a t i o n s : t h i n k i n g a b o u t t h i n ki n g - H o w P eo p l e a n d O r g a n i z a t i o n s C r ea t e , Re p r e s en t a n d U s e Kn o w l - e d g e , S c h e m a P r e s s , A r l i n g t o n , T e x a s , U S A , 1 9 9 3 .

19

Abstract A project memory is a representation of the experience acquired during projects realization [Matta et al., 2000]. It can be gotten through a continuous capitalization of the enterprise activity, notably its design rationale. We present in this paper a representation structure of a project memory (Context and design rationale). Our aim is to demonstrate how a formalization of this structure can give a flexible representation as well as a dynamic knowledge access.

1 Introduction Knowledge management is a process of explicitation, modeling, sharing and appropriation of knowledge [Dieng and al., 1998]. The majority of knowledge management methods aim at defining a corporate memory considered as a strategic asset of the organization. We can classify these methods in two main categories: knowledge capitalization methods and direct extraction methods (Figure 1).

Figure 1 . Two techniques of explicitation of knowledge: capitalization and direct extraction

• The methods of knowledge capitalization use primarily techniques of knowledge engineering. These techniques consist mainly of knowledge extraction (experts interviews or collection from documents) and modelling. We can note for instance methods MASK, REX [Matta et al., 2000], etc.

• The direct extraction aims at extracting knowledge directly from the activity of the organization. We can distinguish several techniques as data mining (extracting knowledge using statistical analysis), text mining (extraction of knowledge based on linguistic analysis of texts [Bourigault and Lépine, 1996], techniques of traceability (e-mail, forum of discussion structuring) and design rationale representation).

We study in this paper, the traceability of the design rationale that aims at defining a project memory [Matta et al., 2000]. We demonstrate how the formalization of the project memory representation could be interesting and useful. This formalization has as goal obtaining a flexible representation structure as well as a dynamic knowledge access.

2 Building a Project memory A project memory is generally defined as a representation of the experience acquired during projects realization [Matta et al., 2000]. This memory must contain elements of the experience coming from the context as well as from the problem solving. these elements have a strong mutual influence so that if the context is omitted, the restitution problem solving is insufficient.

2.1 Project context We mean by project context the whole information which could be used to characterize project situation in each time. The project context must contain notably

PROJECT MEMORY : An approach of modelling and reusing the context and the design rationale

Smain Bekhti, Nada Matta University of technology of Troyes

12, rue Marie Curie, BP. 2060, 10010 Troyes Cedex, France {smain.bekhti, nada.matta}@utt.fr

MASK, REX, …

Traceability

Profession Memory

Knowledge Network

Knowledge Asset

Information Asset

EXPLICITATION

EXPLICITATION

Direct Extraction

Knowledge Engineering

Project Memory

MASK, REX, …

Traceability

Profession Memory

Knowledge Network

Knowledge Asset

Information Asset

EXPLICITATION

EXPLICITATION

Direct Extraction

Knowledge Engineering Knowledge Network

Knowledge Asset

Information Asset

EXPLICITATION

EXPLICITATION

Knowledge Network

Knowledge Asset

Information AssetInformation AssetInformation Asset

EXPLICITATION

EXPLICITATION

EXPLICITATION

EXPLICITATION

Direct ExtractionDirect Extraction

Knowledge Engineering

Project Memory

20

the description of the work environment (means and techniques, referential, instructions and constraints of the project) and the project organization (participants, their roles and tasks organization).

Figure 2 . Mutual influences between elements of the project

Except the system DRCS [Klein, 1993], some approaches (the reader can refer to [Matta et al., 2000] to have more details about these methods) provides techniques to represent design rationale but they omit representing the influence between the context and problem solving in a project. Even DRCS system can only allow representing a part of this context (the tasks organization and the projection of the decisions on the artifact). In the same way, we can observe some efforts in DIPA formalism [Lewkowicz and Zacklad, 1999] to represent the organization of work in a workflow (task/role). However, also other elements have to be identified like constraints, directives, resources and competences, modes of communication, etc. We consider in our approach representing a complete vision of the project context by emphasizing its influence on the problem solving (Figure 2).

2.2 design rationale Representing the design rationale [Buckinham, 1997] in the project memory consists of modeling the process of decision-making through all the elements characterizing it. These elements are essentially (figure 3):

• Problem objects: The global problem discussed during the meetings is composed of sub-problems or elements of problem. The idea is to break up the whole discussion into basic elements. The structure thus permits to represent these elements of discussion with their contents, to bind between them

and to represent the evolution of each of them during the negotiations.

• Arguments: One of the most significant elements of any negotiation is the argumentation. In our approach the argumentation is an essential element of the representative structure because it is the origin and the cause of the evolution of the discussion of the problem and consequently of the decision-making.

• Suggestions: The arguments advanced by the speakers during meetings often lead them to make their own suggestions concerning such or such part of the discussed problem, we envisaged in the model a space for the suggestions of the participants. The suggestions are related to the arguments and the participants who proposed them.

• Participants: The representation of the participants in the structure is important, it permits to bind the arguments and suggestions to their transmitters. Each participant is characterized, primarily, by his competences and his role in the project (see context). It permits to really understand the logic and the reasoning of the participants and the motives of their interventions.

Figure 3 . Problem discussion structured form [Bekhti and Matta,

2001]

2.3 Relational model (context/design rationale)

We studied different models representing the cooperative work and containing the same elements as in a project. We can find this kind of model in CSCW studies and notably in the group awareness

Tâches

Calendrier

Charges de travail

Participant/compétences

Techniques et moyens Directives

Tasks

Calendar

Workloads

Participants/competences

Technicsand means Directives

Context

Communication Relations

Suggestions

ArgumentsProblèmes discutés DécisionSuggestions

ArgumentsDiscussedproblems Decisions

Design rationale

Tâches

Calendrier

Charges de travail

Participant/compétences

Techniques et moyens Directives

Tasks

Calendar

Workloads

Participants/competences

Technicsand means Directives

Context

Communication Relations

Tâches

Calendrier

Charges de travail

Participant/compétences

Techniques et moyens Directives

Tasks

Calendar

Workloads

Participants/competences

Technicsand means Directives

Context

Communication Relations

Suggestions

ArgumentsProblèmes discutés DécisionSuggestions

ArgumentsDiscussedproblems Decisions

Design rationale

Suggestions

ArgumentsProblèmes discutés DécisionSuggestions

ArgumentsDiscussedproblems Decisions

Design rationale

PROBLEM ELEMENT

SuggestionsArguments

SuggestionsArguments

…………….…………….

………….………….

-Sugg2 / participant X-Sugg3 / participant Y-………………

-Arg1/ participant X-Arg3/ participant Z-………..

ArgumentationCriteriaII

-Sugg1 / participant Z-Sugg2 / participant X-Sugg3 / participant Y-………………

-Arg1/ participant X-Arg2/ participant Y-Arg3/ participant Z-……..

Argumentation CriteriaI

SuggestionsArguments

SuggestionsArguments

…………….…………….

………….………….

-Sugg2 / participant X-Sugg3 / participant Y-………………

-Arg1/ participant X-Arg3/ participant Z-………..

ArgumentationCriteriaII

-Sugg1 / participant Z-Sugg2 / participant X-Sugg3 / participant Y-………………

-Arg1/ participant X-Arg2/ participant Y-Arg3/ participant Z-……..

Argumentation CriteriaI

�Maintaining�Modification �Suppression�Creation

Decision

�Maintaining�Modification �Suppression�Creation

Decision

Version x.y

21

representations. We suggest in figure4, a relational model representing different connections existing between the elements of design rationale and those of the project context. The idea is to make a global model representing both the context and the design rationale and showing the existing influences of the elements of each part on the other one.

Figure 4 . Relational model design rationale/context

3. Using the formal representation As we noticed before, our first motivation is to construct a global and flexible model. This model must represent all project memory components and their relations. The formal system is very adapted to model this kind of memories. In fact, we can represent the project memory elements, relations by using the formal logic language. We can thus represent the situations defined in the project memory using terms and formulas.

3.1 Formal logic and the project memory In Figure4 below, we propose a global graphical model representing both context and design rationale in the same time. In order to get the formalization level, we define our appropriate syntax based on the first order logic. We thus define our vocabulary containing variables, constants and relations to represent information in the project memory (figure5).

• Variables: represent the objects composing our domain (project memory) like role, constraint and resource (nodes of the graphic model – figure4).

• Constants: represent the defined values of the domain object.

• Relations (predicates): represent the relations between the domain objects.

• Logical brackets and connectors. To represent the situations set, we consider two steps:

3.2 Conceptual representation This step corresponds to the modeling. It allows representing the information existing in the project memory. In this case we use only variables and connections.

Figure 5 . The relation Participant - Task

Example: to represent the connection "participant affected to task" (figure5) we need:

• A variable symbol par for participants set. • A variable symbol task for tasks set. • the relation Affected_To for “affected to” .

"Participant affected to task" become thus:

Affected_To(part,task).

Problem element

Argument

Suggestion

Decision

Task

Criteria

Participant

MembershipAppartenance

Contrainst

Role

Ressource

Generate

Generate Support/OpposeDiscuss

Bring to

Has as solution

Suppport/Oppose

Evoluate

Belong to

Bring to

Generate

Related to

Related to Voice

Voice

Have

Consider

Affected toBelong to

Consider

HaveBelong toHave

Problem element

Argument

Suggestion

Decision

Task

Criteria

Participant

MembershipAppartenance

Contrainst

Role

Ressource

Generate

Generate Support/OpposeDiscuss

Bring to

Has as solution

Suppport/Oppose

Evoluate

Belong to

Bring to

Generate

Related to

Related to Voice

Voice

Have

Consider

Affected toBelong to

Consider

HaveBelong toHave

Participant (p)

-Part 1-Part 2-Part 3-…-Part n

Tasks (t)

-Task 1-Task 2-Task 3-…-Task m

Affected to

Participant (p)

-Part 1-Part 2-Part 3-…-Part n

Tasks (t)

-Task 1-Task 2-Task 3-…-Task m

Participant (p)

-Part 1-Part 2-Part 3-…-Part n

Participant (p)

-Part 1-Part 2-Part 3-…-Part n

Tasks (t)

-Task 1-Task 2-Task 3-…-Task m

Tasks (t)

-Task 1-Task 2-Task 3-…-Task m

Affected to

22

We, thus, represent the model part in figure6 by the expressions in figure7.

Figure 6 . Project memory model part

We obtain:

Figure 7 . Formal representation of figure6

We represent in the same way the other situations and we, thus, obtain a formal representing of different parts of the model “context / Design rationale”.

3.3 Generated representation A project memory is defined in order to keep track of experience and, thus, provides guidelines to solve problems in an organization. We are, then, interested in the way to reuse knowledge memorized. In fact the interest of make a track of a project is to be able to understand information which it contains and especially the “why” of the decisions. To meet this need we propose many access to the project memory according to different points of view [Bekhti and Matta, 2001] like: problem solving, argumentation criteria, evolution of the problem solving, participants competences and chronological point of view. These

points of view permit to understand the decision-making procedures and their contexts. The formal representation of the memory helps to generate different representations according to the need. In fact, using an inference system, based on the relations between the concepts, we can obtain several views on the memory. This generation gives a dynamic access corresponding to the need of the user. The views can be represented as graphs which show the influence some memory’s elements. These influences can be shown according to the user need in a given situation and not predefined as usually recommended in design rationale approaches. For instance, user can need to get all argumentation criteria characterizing the discussion of a given problem or he want to see the problem according to the participants competences as in Example 1 and 2 respectively:

Have_sol(PROB1,SUGG12);

Related_to(SUGG12, CRIT3).

Discuss(ARG3,PROB1);

Related_to(ARG3,CRIT1).

Discuss(ARG5,PROB1);

Support(ARG5, SUGG10);

Related_to(ARG5,CRIT4).

Related_to(SUGG10,CRIT2). Figure 8 . An example of a generated situation focused

on criteria

Example 1: Figure8 is an example showing three possible ways to get the argumentation criteria regarding the problem PROB1. In fact its shows that the problem element PROB1 has as solution the suggestion SUGG12 which is related to criteria CRIT3. We also notice that argument ARG3, which is related to criteria CRIT1, discuss the problem element PROB1 and finally that the argument ARG5, which is related to the criteria CRIT4 discuss the problem element PROB1, ARG5 is support the suggestion SUGG10 which is related to the criteria CRIT2. From these instances we can generate a graphical representation (figure9) of point of view of argumentation regarding the problem element PROB1.

Problem element

Argument

Suggestion

Criteria

Decision

Evoluate

Dicuss

Related to

Related toBringto

Act on

Support

Problem element

Argument

Suggestion

Criteria

Decision

Evoluate

Dicuss

Related to

Related toBringto

Act on

Support

Have_sol(Prob_elem,sugg); Support(arg, sugg);

related_to (agr, crit); related_to (sugg, crit);

Bring_to(sugg,dec); Act_on (dec, prob_elem);

Evoluate (Prob_elem).

23

Figure 9 . Graphical representation of figure8

Example 2: In figure10 there is an example of two project situations focused on participants’ competences. A graphical representation of the point of view of participants’ competences could be generated as in Figure11.

Discuss(ARG9,PROB2);

Voice(ARG9, PART6);

Have(PART6,COMP3).

Generate(PROB2, TASK6);

Affected_to(PART2,TASK6);

Have(PART2, COMP1).

Figure 10 . An example of a generated situation focused on participants competences

Figure 11 . Graphical representation of figure10

The procedure is similar to generate other point of views representation.

4. Definition of multiple views The design rationale as it is generally defined, represents the space of decision in a project. We propose to describe this space in various points of view while focusing on the negotiation that takes a central place in the design rationale. The majority of these points of view can be generated automatically from

structuring forms. We identified four points of view[Bekhti et al., 2001]: Point of view of problem solving, Point of view of argumentation criteria, Point of view evolution of the problem solving and chronological point of view. We study other points of view that permit to show the links between the participants and the problem solving[Brown, Berker, 2000].

4.1 Point of view of problem solving This point of view is based primarily on the structured forms corresponding to the elements of the problems treated.

Figure 12 . Example of a point of a view on the problem

solving [Bekhti et al., 2001].

4.2 Point of view of argumentation criteria

A view extracted from the criteria of argumentation shows a synthesis of the key elements that influenced the problem solving and from through that the decision-making. This view presents the relations between the criteria, the advanced. This view presents the relations between the criteria, the advanced arguments and the arising problems.

4.3 Point of view evolution of the problem solving

The evolution of the decisions is an important element to memorize in the design rationale. We put the evolution of the problems forward while joining the problem to its solution that can also generate other problems.

Permettre l’autonomie de l’entreprisePermettre l’autonomie de l’entreprise

Version 3.0 Désigner un garant de l’ERPdans l’entreprise/ particip14

Degré d’engagement

Permettre la possibilité d’avoir recours à une sous-traitanceexterne/ particip3La sous-traitancedoit être dans un but d’apprentissage./ particip1

Maîtrise de l’ERP(+) Les entreprises doivent rester maîtres des décisions à prendre pour ymaîtriser le risque après l’évaluation particip11

Contextualisationdes principes selon chaque entreprise/ particip6

Souplesse dans la procédure d’ERP(+) particip6ne contredit pas le principe d’autonomie mais propose d’introduire un principe d’adaptabilité(contexte).

Citer les compétences dont l’entreprise doit disposer pour procéder à une ERP/ particip2

Ressources exigées pour l’ERP

Désigner un garant de l’ERPdans l’entreprise/ particip14

Degré d’engagement

Permettre la possibilité d’avoir recours à une sous-traitanceexterne/ particip3La sous-traitancedoit être dans un but d’apprentissage./ particip1

Maîtrise de l’ERP(+) Les entreprises doivent rester maîtres des décisions à prendre pour ymaîtriser le risque après l’évaluation particip11

Contextualisationdes principes selon chaque entreprise/ particip6

Souplesse dans la procédure d’ERP(+) particip6ne contredit pas le principe d’autonomie mais propose d’introduire un principe d’adaptabilité(contexte).

Citer les compétences dont l’entreprise doit disposer pour procéder à une ERP/ particip2

Ressources exigées pour l’ERP

�Hold keeping�Modification

of «principe d’autonomie»

�Removing�Creationof«principe

d’adaptabilité»

Decision

�Hold keeping�Modification

of «principe d’autonomie»

�Removing�Creationof«principe

d’adaptabilité»

Decision

SuggestionArgument

PR O B 2

C O M P 3

C O M P 2

PA R T 6

A R G 9

PA R T 2

T A SK 6PR O B 2

C O M P 3

C O M P 2

PA R T 6

A R G 9

PA R T 2

T A SK 6

PROB1

CRIT1

CRIT2

CRIT3SUGG12

ARG3

ARG5

SUGG10

CRIT4

PROB1

CRIT1

CRIT2

CRIT3SUGG12

ARG3

ARG5

SUGG10

CRIT4

24

Figure 13 . Example of a view on the evolution of the artefact (principles of assessment of the professional risks).

4.4 Chronological point of view The transcription forms can offer a chronological view on the progress of the negotiation. Indeed, from this chronological representation, we can reach at any phase of the evolution of the problem solving. The representation of the task process in the context as well as the link between these tasks and the forms provide a global view on the progress of the project.

5. Conclusion A project memory reflects an acquired experience it must represent all elements of information related to the project, the context as well as the design rationale. We described in this paper an approach that permit a global representation of these elements. It puts forward the elements and the mutual relations that influence the problem solving in a project and that through views representing the different faces of the project progress. We also presented a formal representation of the memory. This representation emphasizes influence between different elements of the memory. We thus obtain a flexible structure which can be easily augmented corresponding to the specifity of domains. Otherwise, this formal representation can be used as inference system in order to generate dynamically views on the collective problem solving. In fact depending on the needs of the user, he can ask to know about a given element has influence on some decision-making. It thus can rely these elements with its context and learn from the adequate decision making experience. We also showed in this paper how a formal representation can give flexibility not only in knowledge representation but also in knowledge structuring and search.

We develop a tool to support our approach offering, on one hand, a flexible structure of representation and on the other hand an adaptive user interface.

References [Dieng et al., 1998] Diend R, Corby O., Giboin A. and Ribière M. – Methods and Tools for Corporate Knowledge Management, in Proc. of KAW'98, Banff, Canada. 1998. [Brown, Berker, 2000] Brown David C., Berker I., – Modeling Conflicts Between Agents in a Design Context, Computational conflicts, Conflicts Modeling for Distributed Intelligent System, 144-164, Springer 2000. [Bourigault and Lépine, 1996] Bourigault D. et Lépine P. – Utilisation d'un logiciel d'extraction de terminologie (LEXTER) en acquisition des connaissances, Acquistion et Ingénièrie des Connaissances, tendances actuelles, Editions Cépaduès, 1996. [Matta et al., 2000]Matta, N., Ribière, M., Corby, O., Lewkowicz, M., et Zacklad, M. Project Memory in Design, Industrial Knowledge Management - A Micro Level Approach. SPRINGER-VERLAG : RAJKUMAR ROY, 2000. [Bekhti et al., 2001] Bekhti S., Matta N., Andéol B. et Aubertin G. – Mémoire de projet : Processus dynamique de modélisation des connaissance , CITE'2001, p. 329-345. Troyes, 29-30 Novembre 2001. [Buckinham, 1997] Buckingham Shum S. – Representing Hard-to-Formalise, Contextualised, Multidisciplinary, Organisational Knowledge. Proceedings of AAI Spring Symposium on Artificial Intelligence in Knowledge Management, P.9-16, 1997. http://ksi.cpsc.ucalgary.ca/AIKM97/AIKM97Proc.html [Klein, 1993] Klein M. – Capturing Design Rationale in Concurrent Engineering Teams, IEEE, Computer Support for Concurrent Engineering, January 1993. [Lewkowicz, Zacklad, 1999]Lewkowicz M., Zacklad M., MEMO-net, un collecticiel utilisant la méthode de résolution de problème DIPA pour la capitalisation et la gestion des connaissances dans les projets de conception, IC’99, Palaiseau, p.119-128. 14-16 juin 1999.

Préparer l’évaluation des

risques

Principe d’engagement

Principe 1: Il n’existe pas de...

Principe 2: L’évaluation des risques..

Principe definalité

Principe 3: Permettre l’autonomie..

Principe de participation

Principe 4: L’évaluation des risques doit...

Principe 5 : L’ERPest une démarche..

Principe d’action 1 : Organiser l’ERP

Principe d’action 1 : Définir le

cadre de l’ERP

Principe d’action 2 : Les phases de...

Principe d’action 2 : Suivre une démarche

Principe d’adaptabilité

Principe definalité

Principe d’engagement

Principe de d’autonomie

Principe de participation

Structurer l’ERP

Suivre un déroulement a

minima

Principe d’engagement

Principe definalité

Principe d’adaptabilité

Principe de participation

Préparer l’évaluation des

risques

Suivre une démarche

Principe d’engagement

Principe definalité

Principe d’adaptabilité

Principe de participation

Suivre une démarche

Version 1.0

Version 3.0

Version 4.0

Version 2.0

Version 4.1

Principe de d’autonomie

Principe de d’autonomie

Préparer l’évaluation des

risques

Principe d’engagement

Principe 1: Il n’existe pas de...

Principe 2: L’évaluation des risques..

Principe definalité

Principe 3: Permettre l’autonomie..

Principe de participation

Principe 4: L’évaluation des risques doit...

Principe 5 : L’ERPest une démarche..

Principe d’action 1 : Organiser l’ERP

Principe d’action 1 : Définir le

cadre de l’ERP

Principe d’action 2 : Les phases de...

Principe d’action 2 : Suivre une démarche

Principe d’adaptabilité

Principe definalité

Principe d’engagement

Principe de d’autonomie

Principe de participation

Structurer l’ERP

Suivre un déroulement a

minima

Principe d’engagement

Principe definalité

Principe d’adaptabilité

Principe de participation

Préparer l’évaluation des

risques

Suivre une démarche

Principe d’engagement

Principe definalité

Principe d’adaptabilité

Principe de participation

Suivre une démarche

Version 1.0

Version 3.0

Version 4.0

Version 2.0

Version 4.1

Principe de d’autonomie

Principe de d’autonomie

25

A Framework to Specify Hypertext Interfaces for Ontology Engineering

Gilles Falquet, Claire-Lise Mottaz Jiang

Centre Universitaire d'Informatique, Université de Genève Rue du Général-Dufour 24, CH-1211 Genève 4, Switzerland

Gilles.Falquet@cui.unige.ch, Claire-Lise.Mottaz@cui.unige.ch

Abstract

Ontology construction is a complex process involving different types of users and multiple tasks. Moreover, it should take place in an integrated environment including the other elements of the organizational memory, such as databases and document bases. In this paper we show that various hypertext interfaces can be created easily using a declarative approach that was originally developed to enable the publication of databases. We first describe the formal ontology model we use and present the hypertext view technique and its application on databases. Then we show how to apply this technique on formal ontologies and finally propose some design principles for hypertext views on ontologies.

1 Introduction In the past decade, the importance of knowledge management (KM) has been increasingly recognised in organisations. Knowledge management involves collecting and storing knowledge expressed in various forms to facilitate its conservation, access, sharing and reuse. The repository used to integrate all these pieces of knowledge is often called an organizational memory (OM). The OM can contain all kinds of documents, for example catologs, reports, specifications, user manuals, etc. but also formalized knowledge such as an ontology.

1.1 Formal Ontologies A formal ontology is a set of interrelated concepts

together with their definition expressed in a formal language (having a formal syntax and a formal interpretation). During the last decade several formalisms have been proposed to express that kind of knowledge. They range from simple semantic networks (labelled graphs of concepts and relationships) to first order logic. Although first order logic

is highly expressive, its undecidability prevents its acceptance as a universal ontology description language. In the recent years, ontology researchers and engineers have turned to formalisms that are less expressive but decidable, such as frame-based systems and description logics [Brachman et al., 1991; Horrocks et al., 2000].

1.2 Designing Ontologies The construction of the ontology itself involves two process: formalization of the definitions and "consensualization" on these definitions. The formalization of definition consists in transforming a textual (natural language) definition into a formal one. This is not an easy task, especially if the chosen formalism is very expressive or if the person is not an experienced "ontologist". It is often necessary to go through a few intermediate phases: first write a textual definition from the information collected in documents, then write a first formal definition, using only basic constructs of the language, then add more subtle elements.

Consensualization is not a straightforward task either. The ontology should reflect a consensual view of the domain. However, ontology building is usually a collaborative task that includes both domain experts and ontology experts. In addition, in an organisation, there are many different kind of individuals, each having his personal view of the domain according to his background and function. Thus, debates and conflicts on concept definitions are inevitable. Conflicts can occur either on the meaning or on the form of a definition: even people who agree on the meaning of a concept will not necessary use the same words to write its definition. Consensualization consist in trying to reconciliate those different viewpoints in order to get a coherent ontology. To support collaborative work on ontologies, we added IBIS-like components to our concept model.

IBIS [Kuntz and Rittel, 1972] provides a structure to discuss and explore open problems: the discussion begins with a question for which the participants can propose possible solutions. The solutions are then argumented positively or negatively. In the case of ontology building,

26

one of the recurrent question is: "What is the definition of concept X ?" The idea is that participants can express their opinion by creating a definition (possible solution) and linking it to a concept. Then one tries to progress towards consensus, for example by linking each definition to an adequate point of view. In [Falquet and Mottaz Jiang, 2000] we proposed a methodology for analysing and solving definitions conflicts.

1.3 Organizational Memory Structure Defining concepts in a specific domain entails using general concepts, or concepts from another domain, that are considered to be univocally defined. For example, definitions in the wine domain use concepts such as red, white, and region, that do not belong the domain. It is reasonable to assume that terminological work in a specific domain is possible only if there is an agreement on the concepts that are outside the domain. This is why we consider those concepts as atomic. The ontology thus consists of a working ontology, the one that is being built or maintained, and one or several (fixed) auxiliary ontologies (for example a lexical ontology like WordNet)

As we have shown in [Falquet and Mottaz Jiang, 2000 and 2002] the collaborative work on an ontology requires specific data structures to support the building and maintenance processes. For instance, in a multiple-point of view approach, every concept definition must be attached to a point of view. Moreover, conflict detection and resolution implies that users can attach issues, arguments, and endorsements to elements of the ontology. The pure ontology structure together with these process support structures form what we call the multipoint of view ontology.

Since most of the factual information of an organization are contained in databases and document bases, these two storage structures must be considered as part of the organizational memory. In addition, the ontology development process can and must refer to information found in the organization’s databases and/or document bases. Thus we consider that an integrated organizational memory is composed of the parts shown on the following figure. We will see in section 4 that the interface model we propose can generate integrated views of the whole organizational memory.

Ontology

Extended ontology / method support

Database(s)

Document base(s)

Auxiliary Ontologies

Fig. 1. Components of the organizational memory

1.4 The Complexity of the Ontology Interfacing Problem

There are several reasons that make it difficult to build efficient user interfaces for ontologies. Let us consider an ontology that is stored in a database. The schema of such a database can be quite simple, a few tables are sufficient to represent the objects of an ontology (see section 3.2 for an example), so one could be tempted to apply usual database interfacing techniques. This means presenting the database content in tabular form and use forms to input new data. But this approach won't work because the complexity does not lie in the database schema but in the data themselves. Indeed, the data form a complex network of interrelated objects that represent concept definitions and links between concepts. Even with simple knowledge representation models (like semantic networks or frame-based systems), the definition of a concept refers to other concepts. More expressive models, like description logic and first order logic, need more sophisticated representations (e.g. syntax trees). Moreover, there exist implicit relationships between concepts (subsumption, equivalence, degrees of similarity, syntactic symilarity, etc.) that play an important role in ontology design.

Thus the user interface cannot be simply derived from the database schema. It must provide the user with interface objects that are well adapted to the graph and tree nature of this particular kind of data. Again, this is not easy because there is no universal technique for presenting a complex graph on a screen. Thus the interface designer must select the most efficient presentation techniques, and this may depend on the ontology's structure or on the domain's structure.

Another difficulty stems from the semantics of data. The objects stored in an ontology database represent abstract things, namely concepts, that may have complex descriptions. Thus, working on an ontology (defining concepts, linking them, placing them in a hierarchy, etc.) is a hard task, compared to working with a database that represents simple and well known objects (e.g. a library database, a flight reservation system, or a product database). The ontology interface must thus help the user understand the data he or she is working with. For instance, it must provide tools to compare concepts, to view examples, to give explanations, etc.

Finally, as mentioned in 1.3, data that represent the ontology form only a part of the extended ontology. The extended ontology contains data to support the design process (e.g. IBIS support, representation of different point of views, etc.). It is clear that the ontology interface must not only provide access to these data but also support the intended design process. This means that the interface must show an integrated view of the extended ontology. Since the extended ontology has a more complex schema than the ontology alone, it is quite obvious that there is no single "optimal" interface for this database.

27

For all these reasons, it is probably vain to work on the definition of an ontology engineering interface. What we propose here is a general formalism to specify ontology engineering interfaces (independent of the ontology formalism and the design methodology).

2 State of the Art This section starts with a short review of existing

ontology development tools. Then, we briefly present the relationships between hypertexts, knowledge representation and databases. It motivates the use of the hypertext paradigm to build efficient knowledge base interfaces.

2.1 Ontology Development Tools Over the past few years, many ontology and knowledge base development tools have been developed [OntoWeb, 2002; KAON, 2003]. Some of them, like Protégé [Fridman Noy et al., 2000] and OilEd [OntoWeb, 2002] are intended for a single user. Other tools provide different ways to support collaborative work. For instance, WebODE [Gómez-Pérez et al., 1998] and OntoLingua [Farquhar et al., 1996] have mecanisms that enable to manage groups of users and control access to the ontologies. WebOnto [Domingue, 1998] (through Tadzebao) and APECKS [Tennison and Shadbolt, 1998] both have a synchronous dicussion feature. CO4 [Euzenat, 1996] uses a vote protocol to create a consensual knowledge base.

Tools that are intended for multiple users usually feature a web-based interface (hypertextual or graphical, using for example Java Applets). For authoring and querying, the most used paradigm is forms. Each of these tools has a slightly different presentation style, but what is common is that they only display explicit information coming directly from the representation language. They do not use deduced or computed information. Some systems include analysis tools. For example, CODE4 [Skuce and Lethbridge, 1995] provides a "property matrix" to compare properties of two or more concepts. WebGrid [Gaines and Shaw, 1996] can be used to compare the conceptual systems of two experts. In [Ng, 2000], Ng presents the InfoLens, a technique that is aimed at finding patterns within large knowledge bases. Some tools, for instance SemNet [Fairchild et al., 1988] include new visual formalisms to represent knowledge bases, while others, like Ontobroker [Fensel, 2001] use general visualization techniques, such as hyperbolic trees [Lamping et al., 1995].

Even though there exists many tools to develop ontologies, some important needs remain currently neglected:

- In many cases, one has to work directly on formalized

definitions. This supposes that the formalization work has occured before the actual edition of the ontology. Exceptions to this are WebODE and Terminae [Biébow and Szulman, 1999]. WebODE uses intermediary

representations (tables) to "hide" the underlying formalism and thus tries to be more user-friendly towards non-ontologists. Terminae actually supports the formalisation process by following the traditional methodology used by terminologists, with the addition of a few steps.

- Concerning collaboration, many ontology editors are more intended to store the result of the consensualization than to support its process. In systems that do include some support to the process (such as Tadzebao, APECKS or CO4), it is still difficult to have a general view of the various viewpoints.

- The ontology must be tightly integrated with information sources (OM). In fact, when an ontology builder works, he or she must constantly refer to data sources or documents to validate his or her conceptualization. Hence, the engineering environment should provide him or her quick and easy access to reference material. This is in fact not often the case, except in tools such as Terminae.

- A single interface cannot be the best in all situations. It must be possible to customize the tool’s interface according to the specificities of the domain and to the reference data and documents. This customization must be structural (i.e. not limited to changing the appearance of objects on screen) and it must be simple (i.e. not requiring specific programming). Protégé and LinkFactory [OntoWeb, 2002] are in fact extensible, but imply the programming of plugins (Protégé) or Java beans (LinkFactory).

In this paper we propose a framework for specifying

ontology engineering interfaces that take into account the above-mentioned issues. This framework relies on the hypertext view principles and techniques. We will first motivate our approach by presenting the long-standing relationships between hypertexts, knowledge bases, and databases. Then we will present the declarative hypertext view technique and its application on ontologies and organizational memories. The next section will present design principles to build hypertext views for ontology engineering in an organizational memory context.

2.2 Knowledge Representation and Hypertexts Designers and developers of hypertext systems, in particular “pre-Web” systems, have often sought to represent formalized and non formalized knowledge in the same hypertext. In fact, hypertexts have often been considered as a means for sharing knowledge among a community of users (this was also one of the motivations the pushed the Web’s development at CERN). KMS [Ackscyn et al., 1988], AquaNet [Marshall et al., 1991], MacWeb [Nanard and Nanard, 1993] and WebMap [Gaines and Shaw, 1995] are examples of systems where there is an underlying knowledge model to structure the hypertext or to facilitate information retrieval. The importance of the knowledge

28

formalisation aspect has been particularly stressed in MacWeb. The MacWeb model clearly identifies a document level (information), a knowledge level (a semantic network of concepts), an anchoring level that connects (parts of) documents to concepts (characterization), and a task level that produces virtual documents derived from the three other levels.

Since the hypertext paradigm has already been used in knowledge sharing systems, it is not surprising that this kind of database interface is well adapted to presenting knowledge base contents.

2.3 Database Interfaces and Hypertext Publishing of Databases

Databases have long been used to store common data and share them efficiently and reliably among a number of users. Since there exist many tools to develop database applications and interfaces, it seems natural to simply store the ontology in a database and to build ontology engineering tools with database development tools. However, these tools are intended to develop "typical" database applications and are not specifically targeted at knowledge or ontology management applications. In particuliar, they usually provide form-based or table-based views of the data.

A hypertext view is a derived (computed) hypertext that represents the contents of some underlying information source. The idea is to provide the user with an easy to use hypertext interface that enables him or her to navigate within the information source. Thus it replaces database querying or other complex access mechanisms with just hypertext link following. We can define the notion of hypertext view of a database as a set of hypertext nodes and links that - present the contents of the database to the hypertext

user, - replace database querying by hypertext navigation, - enables the authorized user to act on the database in

order to update its content. The hypertext paradigm has already been widely and successfuly used to present database contents on the web and there already exist several tools to build web interfaces for databases (see for instance PHP (www.php.net), ColdFusion (www.macromedia.com) or Oracle Web Server (www.oracle.com) among others). Although these systems provide user-friendly interfaces to databases, developing hypertext interfaces with these systems is still a demanding and error-prone task because - the approach is procedural (programs or scripts must be

written to produce page contents), - the languages are weakly typed and there is no compile-

time type checking.

The declarative specification of hypertext views is a more promising approach because it does not require any procedural programming. In this approach a set of construction rules specifies the hypertext structure and contents. These rules usually take the form of node schemas, which contain a data selection part, a content construction part, and a link construction part. Since the specification language has a high level of abstraction, new hypertext views can be specified by non-programmers. In addition, a declarative view specification is easier to study than a programatic one. Thus the interface designer is enabled to analyze the interface structure, for instance to check its properties.

In the rest of this paper we will show that

- the declarative specification of hypertext views is an efficient approach to rapidly build effective and customizable (extensible) hypertext interfaces to knowledge bases,

- this formalism can be used to describe a design methodology for building interfaces to knowledge bases and to the whole organizational memory.

3 A Hypertext View Approach to Specify Ontology Interfaces

In this section we will show how to create ontology engineering tools with a hypertext view specification system. The first step consists in defining an appropriate data structure to store an ontology in a database (reification). Then one can define node schemas on this database.

3.1 Description Logics and its Representation The approach we propose is applicable to any ontology formalism. However, in order to enable the illustration of this approach with concrete examples, we briefly present the model we used in our experimentation.

We use a formal concept model that belongs to the description logics (DL) family. This model and its semantics correspond to the SQ language of [Horrocks et al., 2000]. The main advantage of this formalism is that it is simple enough to use for non-specialists and that it has a greater expressive power than object or "semantic" models like UML or RDF [Lassila and Swick, 1998]. In fact, it is slightly more powerful than the type of DL on which OWL or DAML+OIL are based because number restrictions and range restrictions can be grouped together.

In this language, a concept is defined using one the following constructs:

- an atomic concept is simply defined by its identifier

(there is no further definition in the ontology) - the union, intersection, or difference of two concepts

29

- a role restriction - exists (min, max) role: range

every instance of the concept is linked to at least min and at most max instances of concept range through role

- all role: range if an instance of this concept is linked through role to another instance, this last instance must belong to concept range

In addition, a subconceptOf constraint can be used to

indicate that this concept's extension is included in another concept's extension.

Example concept WINE is subconceptOf POTABLE-LIQUID ( all MAKER (1,*): WINERY and all GRAPE-SLOT (1,*): WINE-GRAPE and all region (1,*): WINE-REGION )

This definition means that "A wine is a potable liquid, it has at least one maker; all makers having to be wineries and it is made of one or several grapes, all of them being wine-grapes and it is produced in one or more regions and all of these regions must be wine-regions". (The form all MAKER (1, *) : WINERY is an abbreviation for (all MAKER: WINERY) and (exists (1, *) MAKER: WINERY)).

A more detailed description of this concept model can be found in [Falquet and Mottaz Jiang, 2000].

The data structure shown on Figure 2, can represent any concept defined with this model (it forms the meta-ontology level). It forms the purely ontological part of the organizational memory. subconcept

appliesTo argument

rangeRestrictionconcept

atomic intersection union roleRestriction

min max quantifier role

id

Fig. 2. Structure of the ontology in UML-like notation

(the appliesTo association is not strictly necessary, it is a shortcut to directly reach the role restrictions that belong to a concept's definition)

3.2 An Ontology Interface Specification Formalism

In the rest of this paper we will make use of the Lazy hypertext view specification language [Falquet et al., 1998]. The Lazy language was designed to specify and implement hypertext views on relational and object databases. The language has been applied to generate different Web applications, ranging from virtual museums to electronic books or accounting. Since the language is purely declarative, hypertext views can be specified without any programming .

Principles The hypertext specification language is based on the concept of node schema. A node is comprised of - a set of parameters - a content specification (made of element specifications) - link specifications - a selection condition (what database objets to select)

The instantiation of a node consists in interpreting a node schema for a given set of arguments and on the current state of the database. An instance of a node schema is obtained by first selecting the objects (e.g. relation tuples) of the data collection(s) that satisfy the selection expression. Then the content and link specifications are evaluated on each selected object to generate node contents and links to other nodes. Since the purpose of this paper is not to describe the details of the specification language, but to show its principles, we will base our presentation on examples.

Hypertext node schemas on a DL ontology In the following examples, we will suppose that the ontology is stored in a relational database (an implementation of the conceptual schema in Figure 2). This database contains the following tables: table Concept(id, defCategory) table AtomicConcept(id) table RoleRestriction(id, appliesTo, quantifier, min, max, role, rangeRestriction) table SubConcept(sub, sup) -- sub is (the identifier of) a subconcept of sup. table DefinedBySetOperation(id, operation) table Argument (soConcept, argConcept) -- argConcept is an argument of soConcept, which is defined by a set operation

Consider the following node schema node SubConceptsOf[c] "Subconcepts of " , c { sub ,

href RolesOf [sub] ("details") } from SubConcept

selected by super = c

30

This schema is defined on the SubConcept table, it selects

all the (super, sub) tuples of this table that have their super attribute equal to c, i.e. all the relationships between c and one of its subconcepts. Thus, an instance SubConceptsOf [c] of this schema will show the identities (sub) of all the suconcepts of c. The content specifications between { and } are generated for each selected tuple. In addition, a reference link is generated that points to the node instance of the RolesOf schema defined below. Figure 3.1 shows an instance of this schema.1 node RolesOf[c] "Role restrictions on " , c { quantifier, role, min max rangeRestriction

} href SubConceptsOf [c] ("View subconcepts") from RoleRestriction selected by appliesTo = c

This schema is intended to show all the role restrictions that apply to a given concept c (figure 3.2). The href link outside the repeated part is generated only once, to produce a link to the node showing the subconcepts of c. The figure below shows a part of the hypertext view made of three node instances connected through hyperlinks.

1.

2.

1 The instances shown here have been obtaines with the Lazy system. This system compiles node specifications and executes the compiled code when a node instance is requested. A detailed presentation of Lazy can be found in [Falquet et al., 1998 and 2001; Lazy, 2003].

3.

Fig. 3. A node instance SubConceptsOf[POTABLE-LIQUID]

In the Lazy model there are three types of links: reference links (the well known web links), inclusion links (to include the content of another node at this location), and expand in place links (clicking on such a link will open the target node at the link location, i.e. within the source node). These last two types of links are essential to build usable interfaces. For instance, inclusion links make it possible to build complex hierarchical nodes while expand-in-place links enable the user to interactively explore complex structures by opening and closing sub-components. We will see in the next sections examples illustrating the usefulness of these types of links.

If we slightly modify the SubConceptsOf node, by adding an expand-in-place link to the same node schema, we immediately obtain a typical "class browser" view. node Browse[c] { subID ,

href RolesOf [sub] ("details") , expand href Browse [sub] ("sub")

} from SubConcepts selected superID = c

Figure 4.1 shows an instance of Browse after three 'expand' links have been followed (opened).

We can also define a schema that shows the complete definition of a concept by including a node to display its superconcepts and a node (e.g. RolesOf defined above) to display its role restrictions. An example of a node instance is shown in the figure below (figure. 4.2).

31

1.

2.

Fig. 4. Node instances Browse[WINE] (class browser) and Def[WINE] (role restrictions)

Finally, active links can make the hypertext view active. When an active link is followed, it (possibly) sends input field values to the node server and then triggers an action on the underlying databases (insert, delete, update, or procedure call). This enables the user to update the databases by navigating in the active hypertext view.

4 Towards an Interface Design Methodology for Organizational Memories

Every organisational memory is different (according to the activity area of the organisation, the type of documents it contains, etc). Thus is is not possible to propose just one "one size fits all" interface that can be used everywhere. However, for organisational memories that have a formal

ontology backbone (and provided these ontologies are written in the same formalism), one can create a few core reusable interface elements. Those elements can be combined to create various basic interfaces suited to the needs of different users. The interface design process we propose consists of several steps: 1. Build a hypertext view of the ontology (by assembling

basic reusable elements). 2. Extend this view to the ontology engineering structures

that are necessary to support ontology building and maintenance (support for multiple point of views, collaboration, conflict resolution, etc.).

3. Extend the hypertext view to encompass the whole organizational memory.

In this section, we will successively present the parts of

this design process.

4.1 Basic Interface Elements Several authors have stressed the importance of navigation when building a knowledge base. According to Ng [Ng, 2000], at the highest level, there are three different ontology modeling tasks: authoring, exploring and verifying. Navigation plays an essential role in all these tasks: - Obviously, navigation is the easiest way to explore an

ontology. - Before adding any new concept, it is necessary to

navigate through the ontology to find the appropriate location and to verify that it does not already exist. Then, one should gain a good knowledge of the already used vocabulary, so as to avoid introducing unnecessary heterogeneity to facilitate later retrieval.

- While doing verifications such as checking domain coverage or ontology coherence, one must first have a thorough knowledge of what exists in the ontology.

Although the ontology representation is a simple data

structure (e.g the one shown in figure 2), it is not an easy task to design an efficient hypertext view for this structure. However, a method based on refinement and augmentation of an initial hypertext view structure can lead to a suitable interface, as was shown in [Falquet et al., 2001 and 2003].

4.1.1 Initial Structure An initial structure is a basic hypertext interface that enables the user to visualize the whole ontology through navigation. The most obvious way of navigating in an ontology consists in following the semantic links between concepts. These links correspond to - role restrictions (going from a concept to the concept is

a range restriction of a role, e.g going from WINE to WINERY through the MAKER role - and vice versa),

32

- operation arguments (going from a concept to the concept it is made of),

- subconcept constraints (going from a concept to its direct sup- or superconcepts).

Although it is possible to explore the internal organization

of the ontology by following the semantic links, it is easy to get lost and it does not offer a general overview of the ontology (a well known interface design principle, mentioned by Schneiderman [Schneiderman, 1997], is to have both a general overview and local views). Thus, the initial structure should at the very least be added a simple concept browser and a node that displays the complete definition of a concept (as in figure 4).

This initial structure can be specified by just a few node schemas that are very similar to those presented in section 3. The initial structure can be generated automatically. We have indeed implemented an initial structure generator for databases that could also be used for ontologies with only minor adaptations.

4.1.2 Other Navigations Patterns The class browser of the initial structure is generally a very useful tool. Indeed, most of the currently popular ontology development tool includes one. However, there remain some problems. For example, it is not always evident to determine from which top-level concept to begin the search for a more specific concept. This problem in fact occurs at each level of the hierarchy. Moreover, the browser functions well in the case of a taxonomical ontology, but not much so if the ontology has the shape of a network. For these reasons, it is necessary to offer other ways to locate the relevant concept, in particular, different types of navigation, for example, using computed links.

Proximity (affinity) navigation The aim of this type of navigation is to discover similarities between concepts that are not directly connected (they can even lay far apart in the concept DAG). This navigation requires a similarity relation, or a distance, that is computed by comparing concept definitions (for instance, in [Falquet and Mottaz Jiang, 2000] we propose a conceptual distance based on tree comparison). Then links can be created between concepts whose distance to one another is below a given threshold.

The following node schema displays a list of concepts that are considered as similar to c (according to the dist distance). node conceptsNear[c] { display concept information and links to detailed nodes } from Concept selected by dist(c, id) < threshold

Syntactic similarity An important aim of ontology construction is to obtain a regular structure, in the sense that the same thing should be named and represented in the same way. It is for instance crucial to keep the number of role names as small as possible and to avoid synonyms in role names. Thus the ontology designer must be provided with tools that show how similar definitions have been formalized. For example, one could create a node showing the list of role names used in the ontology, with a link to a node giving the list of concepts using a particular role.

4.1.3 Assembling Basic Interface Elements Once the basic interface elements (node schemas) have been created, one can combine them to produce more complex nodes, according to the needs of different types of users. As basic interface elements are Lazy nodes, one can put them together using inclusion links. Below is an example of a complex hypertext node instance. Its node schema has been defined by including other nodes schemas. The node instance shown here includes the following nodes: - a node that shows all the superconcepts of the concept

cupboard, up to the top-level concept of the domain, - a node that displays all the role restrictions, - a node that gives the subconcepts of cupboard, - a node schema that displays all the concepts whose

distance to cupboard is less than 0.5 (in fact this node generates a list of concepts and distances that is passed as parameter to a 3D graph display applet),

- a node with a list of related documents.

Fig. 5. Example of complex view (ontology of the furniture domain)

33

4.1.4 Updating the Ontology The Lazy hypertext view definition language features an active link mechanism that is intended to trigger database actions (insert, delete, update) when a link is followed. In addition, the source anchor of an active links can collect user inputs (through a form mechanism). Thus, the interface designer can provide update mechanisms within the hypertext interface.

For instance, the following node schemas is intended to add a role restriction to concept c. node newRoleRestrictionOn [ c ] active href RolesOf [c] (

set appliesTo = c, set min = textfield(10), set max = textfield(10), …

on "save" do insert RoleRestriction )

The active href link of this schema will display a form to input attribut values (min, max, etc.) and a "save" button. When clicked, this button will first perform the specified insert action, with the given attribute values, then it will jump to the RolesOf[c] node.

Navigation and active links can be combined to produce sophisticated update patterns. For instance, values can be collected along a multi-step navigation path and eventually used by an active link to update the database.

4.2 Extensibility of the Model Ontology engineering, whatever the approach or method, requires additional data structures to be coupled with the pure knowledge representation structure. For instance, in a multi-point of view approach, every definition must be related to a point of view. In a collaborative environment, specific data structure must be set up to represent comments, issues, arguments, decisions, etc. These engineering data must of course appear in the ontology engineering interface. Moreover, they can influence or dictate the design of the user interface.

Example. Adding an annotation functionality to the ontology interface. The annotation data structure is simply a table that holds the annotations texts, authors, and references to the annotated concepts definitions. Annotation(text, author, onConcept)

Then it is sufficient to add a node schema of the following form to view annotations in the interface. node NotesOn[c]

{ show the annotation text and author } from Annotation selected by onConcept = c

Once this node has been defined, it can be referred to or included in other node schemas. Thus the user will be able to view the corresponding annotations when browsing or navigating the ontology. The following node schema shows how to insert new annotations for a given concept c. Its active link sets attribute values (the text value is taken from an input field) and when followed (by clicking "save") it inserts a new tuple into the database. node WriteNoteOn[c] active href ViewConcept[c] ( set onConcept = c, set text = textfield() ,

set author = USER on "save" do insert into Annotation )

The following figure shows a node that displays concepts together with expand-in-place links to their annotations (the annotations on WINE have been opened) and to a WriteNoteOn node (the user is currently writing a note on TEA).

Fig. 6. Viewing and editing annotations

4.3 Seamless Integration of the Ontology in the Organizational Memory

The integration of the ontology in the organizational memory cannot be automated. Indeed, it depends on how documents and data are organized. For example, in order to be able to create a link between the ontology and the database, one has to know the database schema, which is of course different in every organisation. The same is also true for documents: how are they stored ?

34

4.3.1 Accessing Related Data Suppose that a ”wine” ontology is built on top of a database that contains information about wine prices, availability, etc. If this database has a table wine(name, color, maker, region, productionYear, quantity-on-hand, etc.) one can construct a view that shows both ontological information and operational data. This shows that the hypertext view technique can integrate in a single view different levels of abstraction.

In fact, this is a common situation and it shows the necessity to have a sophisticated mechanism to link the ontology and the database. It is clearly insufficient to state the equation “domain concept = database table or database class”. Some concepts do indeed correspond to a database table, but there can also be the case where a concept corresponds to a table attribute. Some concepts even have no correspondance at all in the database. In our situation, the view mechanism precisely plays this role of sophisticated matching between the ontology and data levels.

4.3.2 Accessing Related Documents Documents are often the primary source of information to create and validate an ontology. It is thus important to provide the ontology designer with views of the document base. If the document base is stored in a database, it is straightforward to define hypertext views on the document base and to interconnect the ontology and the document base. The ontology can in turn serve as a meta-navigation tool within the documents.

If the documents are stored outside the database, one can easily create a link between them and their related domain concepts, using the same extension mecanism as for the annotations. It consists in creating a table containing the concept identifier, and some important informations on the document, such as its title and location. For example: relatedDocument(concept, docTitle, docURL)

Then it is sufficient to add a node schema of the following form to view a concept’s related documents in the interface. node relatedDoc[c]

{ docTitle, href docURL } from relatedDocument selected by concept = c

5 Conclusion In this paper, we show that sophisticated user interfaces for collaborative ontology engineering can be specified by defining simple hypertext node schemas. Since the node schema definition language is concise and simple, the interface can easily be extended and maintained by non programmers and non database specialists. Although based on simple constructs, the specification language is nevertheless sufficiently powerful to define views to represent recursive structures (e.g. a definition tree, or a

subconcept hierarchy) or to build complex heterogeneous nodes.

This delarative language is also well adapted to an incremental approach of interface design. Hence, we proposed an interface design methodology that starts with an initial interface on the core ontology and then extends and refines it.

Another important point is the integration capability offered by hypertext view approach. These interfaces can span not only the ontology but also related parts of the information system (data bases, document bases), thus providing integrated environments for the knowledge workers.

Acknowledgements We would like to thank the anonymous referees for their insightful comments that helped us improve this paper.

References [Ackscyn et al., 1988] Ackscyn, R., McCracken, D., Yoder,

E. KMS: a distributed hypermedia system for managing knowledge in organizations, in Communications of the ACM 31, 820-835, July 1988.

[Biébow and Szulman, 1999] Biébow B., Szulman S. TERMINAE: A Linguistic-Based Tool for the Building of a Domain Ontology, EKAW 99 Proceeding, Springer Verlag, 1999.

[Brachman et al., 1991] Brachman, R., McGuinness, D., Patel-Schneider, P., Borgida, A. and Resnick, L. Living with CLASSIC: When and How to Use a KL-ONE-Like Language, in Principles of Semantic Networks. Morgan Kaufman. pp. 401-456. May 1991.

[Domingue, 1998] Domingue, J. Tadzebao and WebOnto: Discussing, Browsing, and Editing Ontologies on the Web., Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW 98), Banff, Canada, 1998.

[Euzenat, 1996] Euzenat J. Corporate memory through cooperative creation of knowledge bases and hyper-documents, Proceedings of the Tenth Knowledge Acquisition Workshop (KAW 96), Banff, Canada, 1996.

[Fairchild et al., 1988] Fairchild, K. M., Poltrock, S. E., Furnas, G. W. SemNet: Three-Dimensional Graphic Representationof Large Knowledge Bases, in Guidon, R. (Ed.), Cognitive Science and its Application for Human-Computer Interaction, Lawrence Erlbaum, Hillsdale, NJ, USA, 1998.

[Falquet et al., 1998] Falquet G., Guyot J., Nerima L. Languages and Tools to Specify Hypertext Views on Databases, WebDB'98, Valencia, Spain, March 1998, selected papers, LNCS 1590.

[Falquet et al., 2001] Falquet G., Guyot J., Nerima L., Park S. Design and Analysis of Virtual Museums, in

35

Proceedings of the Museums and the Web Conference, Seattle, 2001

[Falquet and Mottaz, 1999] Falquet G., Mottaz C.-L. A Model for the Collaborative Design of Multi-Point-of-View Terminological Knowledge Bases, in Proceedings of the Knowledge Management and Organizational Memory workshop of the IJCAI 99 Conference, Stockholm, 1999.

[Falquet and Mottaz, 2002] Falquet G., Mottaz C.-L. A Model for the Collaborative Design of Multi-Point-of-View Terminological Knowledge Bases, in Dieng-Kuntz R., Matta N. (eds) Knowledge Management and Organizational Memories, Kluwer, 2002.

[Falquet and Mottaz Jiang, 2000] Falquet G., Mottaz Jiang C.-L. Conflict Resolution in the Collaborative Design of Terminological Knowledge Bases, EKAW 2000, Juan-les-Pins, LNAI 1937, Springer-Verlag, 2000.

[Falquet and Mottaz Jiang, 2001] Falquet G., Mottaz Jiang C.-L. Navigation hypertexte dans une ontologie multi-points de vue, in Proceedings of the Nimestic01 Conference, Nîmes, 2001.

[Falquet et al., 2003] Falquet, G., Guyot, J., Nerima, L., Park, S. Design and Analysis of Active Hypertext Views on Databases in P. Van Bommel (Ed.) Information Modeling for Internet Applications, Idea Group Publishing, 2003.

[Farquhar et al., 1996] Farquhar A., Fikes R., Rice J. The Ontolingua Server: a Tool for Collaborative Ontology Construction, Proceedings of the Tenth Knowledge Acquisition Workshop (KAW 96), Banff, Canada, 1996.

[Fensel, 2001] Fensel D. Ontologies: a Silver Bullet for Knowledge Management and Electronic Commerce, Springer Verlag, 2001.

[Fernandez et al., 1998] Fernandez, M., Florescu, D., Kang, J., Levy A., Suciu, D. Catching the boat with Strudel: experience with a web-site management system, In Proceedings of SIGMOD'98 Conference, 1998.

[Fridman Noy et al., 2000] Fridman Noy N., Grosso W., Musen M. A. Knowledge-Acquisition Interfaces for Domain Experts: An Empirical Evaluation of Protégé-2000, SMI Technical report SMI-2000-0825, http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-2000-0825.html, 2000.

[Gaines and Shaw, 1995] Gaines B. R., Shaw M. L. G. WebMap: Concept Mapping on the Web, World Wide Web Journal 1 (1) 171-183, 1995.

[Gaines and Shaw, 1996] Gaines B. R., Shaw M. L. G. WebGrid: Knowledge Modeling and Inference through the World Wide Web, Technical Report, Knowledge Science Institute, University of Calgary, Canada, http://repgrid.com/reports/KBS/KMD/index.html, 1996.

[Gómez-Pérez et al., 1998] Gómez-Pérez A., Fernández M., Blázquez M., García-Pinar J. M. Building Ontologies at

the Knowledge Level using the Ontology Design Environment, Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW 98), Banff, Canada, 1998.

[Horrocks et al., 2000] Horrocks I., Sattler U., Tobies S. Practical Reasoning for Very Expressive Description Logics, Logic Journal of the IGPL, Volume 8, Issue 3, 2000.

[KAON, 2003] http://kaon.semanticweb.org/ [Kietz et al., 2000] Kietz J.-U., Maedche A., Volz R. A

Method for Semi-Automatic Ontology Acquisition from a Corporate Intranet. EKAW 2000 workshop on Ontologies and Texts, 2000.

[Kuntz and Rittel, 1972] Kuntz, W., Rittel, H. Issues as elements of information systems. Working Paper No 131, Institute of Urban and Regional Development, University of California at Berkeley, 1972.

[Lamping et al., 1995] Lamping, J., Rao, R. , Pirolli, P. The Hyperbolic Browser: A Focus+Context Technique for Visualizing Large Hierarchies, in Proc. ACM CHI’95 Conf., New York, 1995.

[Lassila and Swick, 1998] Lassila O., Swick R. Resource Description Framework (RDF) Model and Syntax Specification, W3C Working Draft, 08 October 1998.

[Lazy, 2003] Lazy system home page. http://cui.unige.ch/isi/lazy, 2003

[Marshall et al., 1991] Marshall C., Halasz F., Rogers R., Janssen W. Aquanet: A Hypertext Tool to Hold Your Knowledge in Place, in UK Conference on Hypertext, pp.261-275, 1991.

[Nanard and Nanard, 1993] Nanard, J., Nanard, M. Should Anchors be Typed Too ? An Experiment with MacWeb, in Proc. of the HT’93 Conf., 51-62, 1993.

[Ng, 2000] Ng G. K. C. Interactive Visualisation Techniques for Ontology Development, PhD thesis, University of Manchester, UK, 2000.

[OntoEdit, 2002] OntoEdit, retrieved from http://www.ontoprise.de on May 10, 2002.

[OntoWeb, 2002] OntoWeb (Ontology-based information exchange for knowledge management and electronic commerce) A survey on ontology tools, 2002.

[Schneiderman, 1997] Schneiderman B. Designing the User Interface, Addison-Wesley, 1997.

[Skuce and Lethbridge, 1995] Skuce D., Lethbridge T. CODE4: A Unified System for Managing Conceptual Knowledge, International Journal of Human-Computer Studies, 1995.

[Studer et al., 1998] Studer R., Benjamins V., Fensel D. Knowledge engineering: Principles and methods. IEEE Transactions on Data and Knowledge Engineering, 25:161 – 197, 1998.

36

[Swartout et al., 1996] Swartout B., Patil R., Knight K., Russ T. Toward Distributed Use of Large-Scale Ontologies, Proceedings of the Tenth Knowledge Acquisition Workshop (KAW 96), Banff, Canada, 1996.

[Tennison and Shadbolt, 1998] Tennison J., Shadbolt N. R. APECKS: a Tool to Support Living Ontologies, Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW 98), Banff, Canada, 1998.

[Ushold and King, 1995] Ushold M., King M. Towards a Methodology for Building Ontologies, Workshop on Basic Ontological Issues in Knowledge Sharing (in conjunction with IJCAI-95), 1995.

37

Abstract Knowledge management can support industrial research processes. Indeed, these industrial re-search processes are situated between a system of operational units, requiring and using research results, and a system of technological providers and academic laboratories. The knowledge flow between these systems is exposed to industrial constraints like costs, delays, risks, etc. There-fore, the EADS industrial research centre needs to optimise internal and external knowledge flows. In this purpose we propose a knowledge management system. Based on a research proc-ess model, a knowledge typology and a theoreti-cal knowledge management model we propose a system architecture. This system architecture al-lows manipulating information and knowledge more flexible in order to assure a certain dy-namic necessary to produce new research results under strong constraints. It provides innovative functions to give more context to internal and external identified information. It supports knowledge exchange between industrial re-searchers and stimulates knowledge creation processes. Based on new technologies, the sys-tem helps to manage information, in order to in-crease the performance of industrial researchers. This article discusses the introduction and build-ing of functions of a knowledge management system for IT industrial research processes at the EADS Corporate Research Center.

1 Introduction For companies the managing of knowledge constitutes a strategic perspective [Dieng et al., 2000]. If knowledge

and know-how are not under control, they represent an element of weakness. On the other hand, if they are under control, they become a resource and a strategic factor for continues improvement of product and process quality and for the development of new knowledge [Liebowitz, 1999].

An industrial research center stands between an exter-nal information provider system (e.g. technology suppli-ers, academic laboratories, etc), and an industrial opera-tional system, (operational units like the design office, the assembly factories, etc). The industrial operational system represents the most important final user of the industrial research results and thus can be considered as the industrial research customer. An information ex-change process takes place between the operational sys-tem and the external information provider system with the industrial research center in the middle of this process (Figure 1).

Figure 1: Industrial research processes – a macroscopic description

The role of industrial researchers is to experiment, il-lustrate and validate models with new or existing techno-

A Knowledge Management System for Industrial Research Activities: Case Study for IT Research Activities at the EADS Corporate Research Center

Christian Frank EADS Corporate Research Center

12, rue Pasteur, 92152 Suresnes, France christian.frank@eads.net

Mickaël Gardoni

GILCO Laboratory, INPG-ENSGI 46, av. Félix Viallet, 38000 Grenoble, France

gardoni@gilco.inpg.fr

38

logical and methodological solutions, to combine them in order to propose new possible solutions for the require-ments coming from the operational system. The role con-sists of creating new technological and methodological competencies and knowledge and to transfer them into the industrial operational system [Carneiro, 2000].

The fact that the industrial research activity is in the middle between an information supplier and knowledge demand system implies various information and knowl-edge flows. The industrial researcher has to optimize these information and knowledge flows in order to re-spect the constraints from the operational units. These constraints concern costs, delays, quality and risks. The industrial research center has to deliver new knowledge with minimized costs, with minimized delays, with high quality and estimated costs. Therefore there is a need to improve the management of the resources which help to constitute the research results. In the next chapters we will expose knowledge management relevant problems for industrial research activities. We will give concrete examples for knowledge relevant concerns of industrial researchers. We then demonstrate how we faced these problems with new knowledge management functions. We will present a knowledge management framework for industrial research processes and give a description of the technical solution. These results are based on a case study for IT research activities at the EADS Corporate Research Center.

2 Existing theories and related work This work shows the possible application of knowledge management in the field of industrial research. Industrial research plays an important role concerning industrial innovation. Le Masson [Le Masson and Weil, 1999] shows in his work the development of industrial research over the last decades and discusses innovation as a stra-tegic activity for industrial research. He emphasizes the importance of optimizing knowledge creation processes for industrial research. This work, together with Prasard [Prasad, 1996] gives a good overview to understand the functioning of industrial research activities.

In terms of knowledge management we rely on the knowledge management model introduced by Romhardt [Romhardt, 1998]. This model with the different knowl-edge cycle phases (identification, acquisition, develop-ment, distribution, utilisation, preservation, evaluation) seems to propose a knowledge management structure useful to control the industrial research knowledge flow. As knowledge evaluation plays an important role for in-dustrial research processes, this model tries to integrate a knowledge evaluation phase for knowledge management activities. Nonaka [Nonaka and Takeuchi, 1995], [Nonaka and Treece, 2001] with his model tries to ex-plain that transformation of tacit into explicit knowledge and explicit into tacit knowledge. This plays an important role for innovative processes. This is particularly true for industrial research processes where the generation of ideas and the transfer of research results lead to the trans-

formation of tacit into explicit knowledge. This concerns directly our problem environment and can be confirmed with our concrete use case. Le Moigne [Le Moigne, 1998], Liebowitz [Liebowitz, 1999] and Prax [Prax, 2000] give other knowledge management basics useful for our problems.

Knowledge management plays an important role in the literature dealing with innovation processes. Carneiro [Le Masson and Weil, 1999], Ruggle [Ruggles and Little, 1997], and Schulz [Schultz, 2001] present in their work important steps how to introduce knowledge management for innovation processes. As innovation processes are a part of industrial research processes, these steps form a first knowledge management structure for industrial re-search processes. Tiger [Tiger et Weil, 2001] discusses the importance of keeping the dynamic aspect of innova-tion processes by introducing a knowledge management structure. Miller [Miller and Morris, 1999] gives in Fourth Generation R&D the basic aspects how to take into account a knowledge economy for industrial re-search and innovation processes.

3 Problem description: requirement Analysis – A Functional Analysis

Knowledge management relevant problems concerning industrial research processes can concern (some exam-ples coming from interviews with industrial researchers and research managers): • Knowledge acquisition: find external knowledge to in-

tegrate in research projects, get access to new internal knowledge, be always informed about the needs of the operational units, etc.

• Knowledge distribution: reach and contact the right people, exchange new ideas with experts, inform op-erational units about new research results, etc.

• Knowledge preservation: preserve knowledge when people are leaving, update rapidly new arrivals and assure knowledge continuity, formalize and keep feedback concerning the application of research re-sults, etc.

• Knowledge evaluation: use the right and useful knowl-edge to produce new knowledge, know the maturity of internal knowledge compared to external knowledge, etc.

These problems need to be addressed in order to im-prove the efficiency of industrial research processes of a research center and to counter the existing constraints.

In order to quantify the problems and to get concrete problem situations for the existing environment and the problems coming along with the environment we first did a detailed field analysis describing the problem environ-ment. This analysis was supported with a functional analysis we conducted with a group of industrial re-searchers in order to specify the expected functions for a knowledge management system.

39

3.1 Description of problem environment Currently, industrial researchers and research managers work with an existing information technology based en-vironment which does not allow to manage information in an optimal way in terms of having optimal access to crucial knowledge, knowledge combination facilities, etc.. In this paragraph, we will therefore describe the ex-isting IT based environment, the knowledge management relevant problems coming along with that environment and the needs.

3.1.1 Existing IT based environment to manage information Information is available in explicit and non-explicit for-mat. Non-explicit format concerns oral information whereas explicit format concerns written information. Written information is available in all sorts of documents in various formats. We make a first difference between paper format and electronic available format.

Our concern and therefore also our tool proposition will focus on electronic available format since nowadays, the majority of written information is available in elec-tronic format. This sort of information can concern elec-tronic mails, web pages, all sorts of documents in various formats like .ppt, .pdf, .doc, .txt, etc.

Once the industrial researcher identifies or receives in-formation in electronic format, he proceeds to the follow-ing actions: • He classifies the information in a existing folder struc-

ture on a server environment, • He consumes the information and destroys it, • He reuses the information to create new formal docu-

ments (ex. minutes, reports, presentations, etc.), • He gives the information to other people with eventu-

ally some comments in oral or written format. This environment leads to a certain number of knowl-

edge management relevant problems which are described in the following chapter.

3.1.2 Knowledge management relevant problem description for existing IT based environment We structured the knowledge management relevant prob-lems into three groups. Each group concerns different actors. We distinguished between problems concerning the industrial researcher as individual, problems concern-ing groups of industrial researchers or interaction be-tween industrial researchers and problems concerning the industrial research manager. For each of these three groups, we describe the main problems and possible per-formance indicators.

Industrial researcher as individual: the industrial re-search as individual encounters the following problems: • Loosing the overview of collected documents: what is

collected, why are they collected, where are they stored, what are they talking about.

• Loosing the track of which document or document sec-tion was important to take into account for later re-search work and what for. He has too much implicit information about the different documents and docu-ment sections which he cannot remember when he needs to reuse the information.

• The context or the description of the use of documents or document sections stays implicit and risks to be lost after some time.

• The actual storage structure and server structure has limited capacities in order to store and to find docu-ments according to their storage context. This aspect addresses the retrieval problem for stored documents and information in general.

These aspects can have a direct influence on the per-formance of the industrial researcher in order to achieve his research objectives: • He risks to not taking into account important informa-

tion identified at an earlier moment. • He risks to not taking into account or loosing the ar-

gumentation for intermediate information, research results and ideas. This argumentation can be neces-sary to constitute final or later research results. He therefore can loose important information to create new innovative solutions.

• It takes him too much time to re-access and to re-analyze the already identified information or docu-ments in order to known in which context he planed to use them.

• Groups of industrial researchers or interaction between industrial researchers: groups of industrial researchers meet the following problem:

• There are two main ways of storing identified docu-ments in the existing system: documents can be stored according a precise and official research objective (top-dow) or they can be stored in a private structure. The private structure is not linked to a precise objec-tive (bottom-up). There does not exist any transversal or shared structure. Transversal structures would be necessary to share a common contact database for ex-ample, to share documents between researchers with similar research interests, in an expert network, etc.

In terms of performance influence for groups of re-searchers, this problem could mean: there is no shared structure for an information basis for common research interests among different people. This could mean that researchers have limited access to already identified im-portant information. Furthermore, this has a negative in-fluence on information sharing.

Concerning the interaction between industrial re-searchers the following problems occur:

40

• The implicit communication (reactions) on information in form of documents or document sections is lost af-ter a while and not accessible for other people.

• Oral reactions on internal documents or document sec-tions are not transmitted or lost for the author if he is not available during a certain time. The use of elec-tronic mail does not replace a space where it is possi-ble to exchange about document or document sec-tions.

These aspects have the following influence on the per-formance: • There is a very limited preservation for internal devel-

oped and exchanged additional information. This sort of information can be considered as explicit knowl-edge. Therefore, there is a lack of knowledge preser-vation.

• The fact that relevant information in form of oral reac-tions is not transmitted limits the transfer of internal developed additional information. This information could be an opportunity to provoke the creation of new knowledge and to support creativity. Therefore, not giving the possibility to transfer this information could be a handicap for knowledge creation.

Industrial research managers: the industrial research manager encounters the following problems: • He has a limited overview of available information (in

form of documents) collected by industrial researchers for various research objectives or themes. He needs a global overview of available information for the dif-ferent research activities.

• He has the difficulty to see which external information helped to constitute the research results. This problem concerns two aspects: he has the difficulty to see the origin (in terms of reference) of used external infor-mation and has the difficulty to know, how this in-formation is used to get the new research results.

In terms of performance influences, the problems can have the following impacts: • The research manager has a limited view of existing

possibilities and choices in terms of technologies and customer requirements. This can lead to decision without knowing the relevant information and there-fore lead to critical decision in terms of new research objectives.

• He has only a little possibility to know, if information used to achieve research results was sufficient and ex-haustive.

This problem environment gave us a first idea of the potential functions for a knowledge management system. In order to clarify these ideas we conducted a functional analysis.

3.2 Functional Analysis During the functional analysis we tried in several meet-ings to identify potential and desired KM functions, which should be provided by a KM system. The first part of the analysis is to determine the environment interfaces of a potential system. The environment interfaces should represent the environment of an industrial researcher: he is in interaction with external information suppliers, in-ternal information suppliers, information resources con-cerning the customer requirements (operational units), and teams of researchers (Figure 2).

The potential functions of such a system, identified during the work sessions, combine and link the different interfaces (Figure 2). The functions are described below:

Figure 2 : The environment interfaces of a potential knowledge management system for industrial research processes and its poten-tial functions

F1: The system should help to identify external indus-trial problems comparable with the problems of the re-search customers. The objective is to identify external industrial problems, industrial requirements among in-dustrial partners, competitors, etc. similar to the prob-lems and requirements of internal research customers. Certain external problems could be equivalent to the im-plicit customer needs not yet identified.

F2: The system should help to identify external solu-tion proposals (methods and technologies) for the re-search customer requirements. The objective here is to support the identification of technologies and external methods which could support the solution development for customer problems.

F3: The system displays the gap between the research activities conducted by external research organizations and the internal research activities. This function allows the visualization of an evaluation of external research activities compared to internal research activities con-cerning a research subject. It could show in which way external research problems are treated. After such a com-parison, it would be possible to decide whether to inte-grate external research activities and results and to orien-

41

tate the internal research activities. The knowledge man-agement system can thus contribute to an evaluation for knowledge and supports to select between obsolete, basic and new knowledge [Tiger et Weil, 2001].

F4: The system helps to identify external elements (concepts, methods, technologies, tools, and competen-cies) in order to carry out internal research activities.

F5: The system should show in which way the research activities cover the customer requirements. The objective here is to visualize the difference between the customer research requirements and the requirements treated and covered with internal research activities. This difference indicates the need for future research activities and the need to deepen already existing research activities and initiates actions to create new knowledge.

F6: The system should support a sense of sharing among internal researchers working in the same research area. In order to create this sense of sharing between re-searchers, it will be necessary to develop competencies references, to rely similar professions, similar project environments, and perhaps transverse organizations [Ti-ger et Weil, 2001].

F7: The system should help to identify internal ele-ments (concepts, methods, technologies, tools, and com-petencies) that helps to carry out internal research activi-ties.

These potential functions transform the requirements in wishes for a knowledge management system. They are the starting point for process analysis and solution development.

4 Industrial Research Processes – Process Analysis and Knowledge Flow Description

In order to introduce a KM system, it is important to un-derstand the functioning of processes and information flows. In this purpose we analyzed in more detail the or-ganizational structure, the research processes, the infor-mation and knowledge flow and the knowledge structure used by industrial researchers. This analysis conducted us to elaborate different models representing different as-pects of knowledge for industrial research processes. These models will build a basis for our solution proposi-tion, a KM architectural framework for industrial re-search processes.

4.1 The Organizational Structure of the Research Environment

The research activities are embedded in our case in an organizational structure. The most important parts of this organizational structure concern a quality certification, a stable intranet structure with its document organization, a regularly reporting about the project advancements and regular project meetings and reviews.

The quality certification implied to introduce proce-dures describing and defining certain work processes and

defining the production of certain documents. Documents have to be produced at the beginning of a research pro-ject (research programs) after every meeting concerning this project (minutes of meetings), at milestones and at the end of the projects (reports). This guarantees a mini-mum of information distribution and preservation. The quality framework is supported by an intranet which helps to manage the different documents required by the quality procedures. The documents are structured accord-ing to the research project structure. This concerns also external relevant documents important for certain re-search projects. Regularly project reporting and review meetings are another mean to assure the distribution of the information concerning new research project results.

Of course, this structure is very specific to our work environment. The fact of having quality certification for research processes might not be easy to accept for every researcher [Gardoni and Frank, 2001]. The introduction of quality certification implies to respect certain organ-izational rules and predefined processes. This might be seen as a handicap for research activities. Nevertheless, the trend nowadays is to introduce quality certifications for more and more academic and industrial research or-ganizations [Gardoni and Frank, 2001].

This basic framework will play an important role for our further analysis and solution development. It is pos-sible to better analyze already existing knowledge and information flows. On the other hand this framework with its existing and defined information flow and docu-ment creation is an opportunity to build knowledge man-agement solution on existing practices and structures and to take them into account for new solution development.

4.2 The Activity View of Industrial Re-search Processes and the Knowledge Flows

Industrial research processes are characterized by the anticipation of industrial operational unit requirements. This obliges the industrial research units to know and understand the customers’ problem environment. Provid-ers of new external technologies and information consti-tute knowledge resources.

A research process is initiated by a need to improve processes and/or products of the operational system. A research process can also be initiated by the discovery of the importance of new innovative concepts. According to the maturity degree of the researcher’s knowledge, the research process can be decomposed into three phases: investigate, focus, transfer: • The activities concerning the investigation characterize

the identification of new research domains, the obser-vation of new technological possibilities and activities and aims to constitute state-of-the-arts about new technologies and new methods. Therefore, the indus-trial researcher transfers and transforms external in-formation or external knowledge into internal knowl-edge: a knowledge flow from the external environ-

42

ment to the internal environment. The monitoring ac-tivity is very important for this phase of the research process. Before transferring external knowledge into internal knowledge, the researcher evaluates the utility of the external knowledge for his future research ac-tivities(Figure 3).

• The objective of the next phase is to focus on new technologies and methods and to acquire new knowl-edge and competencies. Experimenting and illustrat-ing prototypes by using new technologies and meth-ods help to acquire new knowledge and competencies. The activity allows combining internal and external knowledge with given problems. This combination is characterized by learning processes for researchers, by knowledge exchanges among researchers and initia-tives of innovations (Figure 3).

• Transfer driven research is directly related to the opera-tional units requirements. The objective is to experi-ment illustrators, prototypes and methods with con-crete data coming from the operational units. By pro-posing improvements for the identified problems, the research units transfer their knowledge into the opera-tional units. As in the “focalization” phase, research-ers combine internal and external knowledge to come up with suitable solutions. However, the role of inter-nal knowledge dominates the role of external knowl-edge. Internal knowledge, coming from exploratory research activities and the experimental phase has to be adapted to research customer problems. This trans-fer of knowledge is also accompanied by learning processes for researchers: the feedback of the opera-tional units about implemented research solutions (Figure 3).

Figure 3: Industrial research process – an activity view

Each phase describes activities which have different forms of output. Nevertheless, each output is in fact a product of combined knowledge (in form of a research report, prototype, etc.) around a defined research prob-lem. In order to produce these products, the industrial

researcher needs resources. These resources are external information / knowledge and the needs of the operational units. In order to organize these resources he uses knowl-edge management activities.

4.3 KM Relevant Activities in Industrial Research Processes

The activity and organization analysis as well as the re-quirement analysis allowed identifying and characteriz-ing the different KM relevant activities for industrial re-search activities. These activities concern basic KM ac-tivities as described in various concepts [Barthes et al., 2000]. For structuring, we decided to represent them with the KM model form Romhardt [Romhardt, 1998] (Figure 4). The important part in this model is the distinction between a core process and a control process. The control process implies the evaluation of knowledge. This activ-ity is important for industrial research activities as seen during the functional analysis.

Figure 4: KM relevant activities according KM model from Rom-hardt [Romhardt, 1998]

This representation illustrates that the different KM relevant activities are always connected to each other. This is also true for the industrial research activity envi-ronment. The different activities, or the KM model, emerge for every research process phase: investigate, focus, and transfer. This will constitute an important building block for our later KM architectural framework proposition in section 5.1.

4.4 The Twelve Knowledge Types of Industrial Researchers

Managing knowledge in industrial research processes requires knowing which knowledge is manageable. Be-sides, it is also important to know which knowledge will be necessary to conduct research activities and to come up with research results. These two aspects encouraged us to find a knowledge typology of industrial researchers necessary to develop research results. In order to identify the different knowledge types, we analysed documents and held interviews with researchers. This analysis was based on a systemic analyse: which are the people con-

43

cerned in a project, which decisions are made, what are the different activities, where information are shared.

The typology tries to describe and categorize 12 knowledge types as objects (Figure 5). The knowledge types represent the basic knowledge to conduct research activities and to elaborate new research results.

Figure 5 : The knowledge types describing the necessary knowl-edge of an industrial researcher to conduct and fulfill research activities

• K1 describes the researcher’s knowledge concerning his own research developments and products.

• K2 describes the researcher’s knowledge concerning the process and daily activities to reach research re-sults and products.

• K3 describes the researcher’s knowledge he has about existing external knowledge resources. These re-sources are a part of the external information provider system (e.g. technology suppliers academic and indus-trial laboratories, etc.) and provide the researcher with new information and knowledge, characterized with K4.

• K4 is the concrete information a researcher has to know and to take into account for new research re-sults. We distinguished three main categories in K4: the researcher has knowledge about academic / indus-trial laboratories, technology suppliers, and external user (competitors / partners). For each main category we found sub-categories describing knowledge ob-jects. As an example, the knowledge objects for tech-nology suppliers are orientations, innovative concepts, methods, tools, means, and experimentations. This al-lows us to precise the knowledge of researchers and to identify, where knowledge does exists and where is a lack of knowledge. For the other knowledge types we defined similar categories.

• K5 describes the researcher’s knowledge he needs to access to external information and resources. He knows how and where to get external information for his research activities and objectives. He owns knowl-edge about conferences, articles, presentations, etc. K3, K4 and K5 describe the entire knowledge of an industrial researcher concerning his knowledge about the external information provider system.

• K6 describes the researcher’s knowledge concerning the internal research unit resources.

• These internal resources (people, projects and units) provide him with knowledge or information (K7) which he includes in his research activities and re-sults.

• K8 describes the researcher’s knowledge which enables him to access the internal information and resources. K6, K7 and K8 are the counterpart of K3, K4 and K5 and describe the entire knowledge of an industrial re-searcher concerning his knowledge about the internal industrial research system.

• K9 describes the researcher’s knowledge about opera-tional unit resources.

• These problems and needs are characterized with K10. • With his knowledge K11 the industrial research knows

how and where to access to the operational unit in-formation and research needs.

• K12 describes the researcher’s knowledge concerning the global group context of his research results.

In this typology we can distinguish between process oriented knowledge, important to conduct activities, and content oriented knowledge, important to produce new research results. For our framework proposition, we will mainly use the content oriented knowledge types.

5 The KM Architectural Framework In this chapter we will first present a basic framework proposition. Based on this proposition we will discuss certain aspects in more deeper technical and functional detail.

5.1 Basic Framework Proposition The KM architectural framework we propose is based on three models: the industrial research process model, the KM relevant activity model and the knowledge typology model. This gives us a three layer architectural frame-work. As a basic layer, we will use the industrial research model which helps to categorize the different research activities in three phases: investigate, focus, transfer. The activities in the phases can be supported by KM ac-tivities as described in the KM relevant activity model (Figure 4). In order to support the different KM activities in the different research phases we propose a toolbox for

44

each activity of the KM relevant activity model. This toolbox should enable the execution of the different ac-tivities from the KM relevant activity model.

Each toolbox contains an information input field, a specific toolbox area according to the activity of the knowledge management model and an information output field. The information input and output field are struc-tured according to the knowledge typology model. As the typology model represents the necessary content knowl-edge for research activities this structure assures the availability of critical knowledge. This three-layer archi-tecture allows to coordinate the different knowledge management activities and to integrate a process view, an activity view and a knowledge management view (Figure 6).

Figure 6: Knowledge management architectural framework

For each research process phase we define the different KM relevant activities with their different inputs, outputs and tool functions. As an example we will describe the investigation phase of the research process and illustrate some inputs, outputs and tool functions for the identifica-tion and acquisition activity of the KM relevant activity model. As we have seen during the investigation phase, the industrial researcher looks for new concepts, new information in general and new needs in the operational units. According to the knowledge typology model the industrial researchers take into account the external, in-ternal and operational unit environment. According to the KM relevant activity model, they first undertake identifi-cation activities. This means using intelligent Internet research machines, consulting internal expert indexes (ex. yellow pages), internal information retrievals sys-tems (document management system), etc. As an output of this activity he has a structured list of potential con-tacts with internal and external experts, a list of interest-ing internal and external documents, a list of potential interesting conferences to visit, etc.

After the identification of these information sources the industrial researcher needs to transform the informa-tion into internal knowledge. He needs to add context on documents, his knowledge on these documents and he

needs to organize them in order to reuse important infor-mation. This happens during the acquisition activity of the KM relevant activity model. The output of the identi-fication activity is the input of the acquisition activity. Tools for this activity are a mixture between organiza-tional tools and technical tools: in order to make use of the potential contacts the industrial researcher has to meet people, hold presentations to get feedback, assist to conference and read the collected information, and give context to identified information.

This basic framework proposition gives a global over-view of the proposed possible solutions. In the next chap-ters we will go into deeper detail for some innovative technical solutions which play an important role for the KM architectural framework realization.

5.2 Document Management – Content Management – Knowledge Manage-ment

Some people consider that a better handling of informa-tion content plays an important role for knowledge man-agement technologies [Beckman, 2000]. The central as-sumption is that explicit knowledge is represented in form of electronic text documents. Many workers of a company spend considerable amounts of time writing documents directly related to their work experience, in which they record items like [Jones et al, 2000]: • Raw data gathered by experimentation, hands-on ex-

perience, and / or observation, • Description of a particular event or specific case, • Interpretation of data, • Beliefs, guesses, • Ideas, theories, opinions, • Conclusions, summaries, recommendations, judg-

ments, proposed actions. The assumption considers that such documents are able

to communicate an explicit representation of at least some of the knowledge and expertise of their authors. This is can be considered as a common-sense assump-tion: the author of a business document intends to com-municate specific information to the reader (documents are never random collections of unrelated word). Accord-ing to Feldman [Feldman, 1998] up to 80 % of a com-pany’s explicit knowledge is typically stored in the form of text documents, rather then in formally structured da-tabases. This implies the need to be able to explore the document contents.

Today, some underlying core technology for the con-tent interpretation technologies consist of two main parts: • A functionality based on natural language processing

that can automatically extract the essential informa-tion from a piece of text, and represent this in the from of a “semantic net”. This means the extraction of the most essential themes and concepts. The semantic

45

net is a kind of a basic ontology representation for the content of the text.

• A functionality based on neuro-fuzzy reasoning to compare the semantic nets with other texts to test for any overlap of interest. This is the basis of compli-cated text search.

This means that once the system has created a semantic representation of a text, it is possible to analyze the con-tent of further texts to test for contextual overlap. This allows a sort of contextual comparison between different information content.

The management of information content stored in documents is very important for industrial research proc-esses. Industrial researchers deal with many internal and external information in form of documents in various formats (reports, web-pages, conference proceedings, minutes, e-mails, etc.). In these documents are stored the explicit knowledge the researchers need for their research activities. The explicit knowledge can be considered as the knowledge resource to create new knowledge.

The relevance for managing information content to stimulate knowledge creation is especially important for the first phases “investigate” and “focus” of the industrial research process model. Here the industrial researcher is confronted with a lot of external and internal explicit information he needs for his research activities, he needs to share in order to get other opinions, and he needs to summarize for his research results.

Therefore we propose solution elements which lie on a better management of information content or explicit knowledge. Of course, it is also important to take into account tacit knowledge forms and here especially the possibility to exchange tacit knowledge by exchanging ideas among researchers. Nevertheless, tacit knowledge exchange forms concerns more organizational questions. We focus on possible technical support for knowledge management. Furthermore, the actual organization of industrial research organizations makes it hardly possible to always have a tacit knowledge exchange when needed. Explicit knowledge exchange must be provided because people are not available or do not have the special and technical possibilities to communicate in a tacit manner.

5.3 Solution Elements 1: Aspects to De-scribe the Context of Documents and Document Sections

We have seen in the previous sections that the industrial researcher has problems to structure his documents or important document sections according to certain points of view (what is it talking about, why does he keep it, how and where does he keep it, etc.). This can implicate the loss of important information necessary to obtain new research results or makes it very time-consuming to re-access already identified important information. A document can talk about different interesting aspects for different research objectives. This leads us to the proposition, to give the researcher the possibility to di-

vide the documents in different document sections which concern different interests and manage these sections separately.

With our tool solution, we propose that the industrial researcher, thus the user of the tool, has the possibility to attribute different points of view to documents or docu-ment sections.

The user has the possibility to attribute points of views to documents according to three dimensions: • What and from whom a document is talking about, • For what does the document represents an interest, • A simple meta-data description to describe where the

document comes from and what format is used. For each dimension, we will present the elements nec-

essary to describe the points of views. These elements come from former research process and activity analyses. 5.3.1 What and from whom a document is talk-ing about This dimension will be described with the knowledge typology. This typology allows to precise the content of a document and from whom the document is talking about.

As an example, the following table describes the knowledge typology K4, for academic and industrial laboratories. The table has three columns. The first col-umn describes the information resource and corresponds to the description “from whom a document is talking about”. The second column describes the information type and corresponds to the description “what a document is talking about”. The third column gives a description of the different knowledge types. Each knowledge type is represented by such a table. The user has the possibility to attribute more than one information type for the re-specting information resource to a document or document section.

For the tool specification, the user should be able to choose among the different information resources and their respecting information types (fields in grey). For each information resource, he has the possibility to spec-ify its name. He also should always have access to the description of the information types.

Therefore, this typology helps him to attribute points of views to document or document sections which helps him to clarify and specify the context of documents.

The following list is only a part of the overall knowl-edge type description.

Information res-source

Information type

Description

46

Research direc-tions

Concerns long-terms planning of research activi-ties and the stra-tegic positioning according to technologies but also according to the industrial environment

Innovative concepts

Description of new innovative concepts, what they are for, what they could bene-fit for

Methods

Description of new methods, what they do, what they are for, what they could benefit for

Prototypes

Description of new prototypes, what they do, what they are for, what they could benefit for

Means

Description of the technology and human ca-pacity to elabo-rate new research solutions

Academic / industrial laboratories

Experiments

Description of experiments and experiences with innovative con-cepts, methods, prototypes

5.3.2 For what or who does the document rep-resent an interest This dimension describes the interest, why an informa-tion should be kept or for what it could be used. This has a direct link with the various research objectives of each industrial researcher. The research objectives can be characterized according to the following categories: • The industrial researcher has to conduct official re-

search studies. Each of these research studies is de-scribed with an official research objective. Official re-search studies can be grouped under other official re-search studies.

• The industrial research has personal research interests. These interests can be directly linked to his official re-search studies or are free general interests.

• There exists virtual or real group of industrial research-ers having common research interests. These re-searcher groups can share information and results use-ful to their common research interests. The shared in-terests can be seen as shared research objectives.

• An industrial researcher can identify information which might be interesting for another industrial researcher. Therefore, he should be able to indicate this informa-tion for the research objectives of the other industrial researcher. It is then up to the other researcher to de-cide if he wants to keep this information and under which points of view.

• Different research objectives can be grouped under a research theme. A theme can cover official research objectives, private research interests, and group inter-ests.

Besides this, we propose to use parts of the knowledge typology model in order to describe in more detail for what perspectives a document represents an interest con-cerning a research objective.

At the end, we thus have a two dimensional description concerning the interest for documents and document sec-tions: a research objective oriented description and a knowledge typology oriented description.

5.3.3 A simple meta-data description to de-scribe where the document comes from, what information support is used The meta-data description contains two possibilities: the description of the author (organization) of the document and the description of the information support. What we called the information support of a document includes also a description of the type of the document (minutes, report, web pages, etc.). For the case that the author or-ganization is the EADS CRC, the author can be the same person who introduces the information in the system and attributes it with points of view. This should appear in the system.

The description of the document meta data is only available for documents. It is not available for document sections or annotations.

The following table gives the possible combinations of author (organizations) and information support. Author organization Characterization of informa-

tion support EADS external (suppli-ers, academic / industrial laboratories, EADS ex-ternal user of technolo-gies (competitors / part-ners))

• Scientific articles • Commercial articles • Thesis • Activity reports • Presentations • External minutes

47

• Web pages • Patents • Mail • Others

5.4 Solution Elements 2: Aspects to Make Explicit Implicit Information or Knowledge

As we have seen in the problem description and for the needs, information around documents to clarify their con-tent and use or exchanged information among people concerning a document content risk to be lost. Therefore, we propose a mechanism allowing to make annotations for documents and document sections.

These annotations are comments or formalized or tracked information elements allowing the user to give supplementary information. Annotations have a title, a creation date and indicate the author. It is also possible to make annotations on annotations.

Annotations can be exchanged between the researchers and each researcher has the possibility to react on differ-ent annotations. This creates a possibility to exchange formalized knowledge between researchers concerning concrete research objectives.

However, we do not propose a classification for anno-tations since they are always linked to a document or document section. This means also, that it is not possible to create stand-alone (detached) annotations which might be lost in a system without any concrete context.

5.5 Solution Elements 3: Formalizing In-termediate Research Results

As we have seen for the needs, it is sometimes difficult to constitute and formalize the final research results based on the available mass of information. Therefore, the in-dustrial researcher needs the possibility to formalize from time to time intermediate research results and findings in order simplify him the constitution of his final research results. We propose an electronic form where he can define a first structure for his results by giving titles and sub ti-tles. Under these titles he has the possibility to insert document sections and annotations. These elements are structured according the knowledge typology and the research objectives. This structure gives him the context for his intermediate research results. The mechanism allows to preserve from time to time the important knowledge for research results. The re-search result document is no longer the last result of the available information at a given moment.

6 Solution specification The solution specification is based on UML. We used use case diagrams to represent the functions, class models to give the static point of view and sequence diagrams to represent the dynamic point of view.

6.1 Use case description Among the different actors we identified three categories of users: creator, reader and administrator (admin). The user group “creator” attributes points of view or an-notations to documents or documents sections and has the possibility to select information important for intermedi-ate research results.

The user group “reader” visualizes the documents or document sections according different points of view and can read the different annotations and selected docu-ments.

The user group “admin” has the possibility to create new points of view or to modify existing points of view. For each user group, we identified different use cases.

6.1.1 The use cases for the user category “crea-tor” We identified six use cases for the user group “creator” (Figure 7): • Use case ”creator” one: attribution of points of view to

a document. • Use case ”creator” two: attribution of points of view to

a document section. • Use case ”creator” three: attribution of annotations.

The attribution of annotations is possible for docu-ments, document sections but also for other annota-tions. This means that users can attribute annotations on annotations.

• Use case ”creator” four: select information for inter-mediate research result document. This describes the possibility to select document sections or annotations to take into account for intermediate research result documents. Documents cannot directly be taken into account for intermediate research reports. Either the user has to select one or more interesting document sections form this document, or he has to precise his choice with annotations. The use case implies the creation of intermediate research result documents (use case five).

• Use case ”creator” five: create intermediate research result document. This implies the description of pre-liminary titles for expected research results.

• Use case ”creator” six: create new point of views. The user has a limited possibility to create new point of views. The possibility to create new ones concerns his private research objectives and interests and for groups of researchers with shared interests where he has the right to create new points of view.

48

Attribute points of view to document

Attribute points of view to document section

Attribute annotation

Create new point of view

Creator

Create intermediate research result document

Select information for intermediate research result document

requires

Figure 7: use cases for user category “creator”

6.1.2 The use cases for the user category “reader” For the “reader” user category we identified two use cases (Figure 8): • Use case ”reader” one: list information according se-

lected points of view. This use case describes how the user selects the different points of view to represent the different documents or document sections. The listing of information is therefore a representation of documents or document sections according to chosen viewpoints.

• Use case “reader” two: display selected information. The user has the possibility to represent selected in-formation which are characterized via viewpoints. This information can concern documents, document sections and annotations. For a document section this means for example, once he chooses to represent a document section, the section is immediately dis-played. The user does not need to scroll the document to find the document section.

Reader

Display selected information

List information according selected points of view

requires

Figure 8: use cases for the user category “reader”

6.1.3 The use cases for the user category “admin” We identified two use cases for the user category “admin” (Figure 9): • Use case ”admin” one: define points of view. The ad-

ministrator defines the possible list of points of view and describes their definition or explanation.

• Use case “admin” two: modify points of view. The administrator can modify and delete existing point of view. Nevertheless, he has to verify the consequences of any modification.

Define points of viewAdmin

Modify points of view

Figure 9: use cases for user category “admin”

6.2 Class descriptions The functions of a tool we described correspond to the needs. The use of these functions is described with the different use cases. Based on the expressed needs and the use cases we defined the different classes.

We identified the following classes: • Actors: represent the user categories described in the

previous section, • Document: represents the documents which contain

points of view, • Document_Section: represents the document sections

of a document. • Knowledge_Typology: contains the different informa-

tion resources and the different information types in form of a list,

• Official_Research: contains a list of official research objectives and their description which are linked to a list of official research studies (list needs to be estab-lished),

• Private_Research: contains a list of private research objectives and their description,

• Interest_Group: contains a list of groups of industrial research with similar research interests and their de-scription,

• Theme: contains a list of official research themes, • Document_Meta_Data: contains a list of descriptions

according to the described table,

49

• Annotation: represents an annotation for a document or a document section,

• Intermediate_Report: represents an intermediate report document,

• Intermediate_Report_Section: represents a document section of an intermediate report document where the user indicates annotations and intermediate document sections.

Based on the defined classes and on sequence diagrams we realize the prototype.

7 Technical realization of KM archi-tectural framework

Our technical realization is based on a portal solution. This solution includes document management and shar-ing, collaborative workspaces, shared agendas, shared contact database and a user profile management. On this portal solution we implement the specific modules ac-cording to the requirements and the industrial research environment. In section 3.1.2 we explained the necessity to introduce more context to information and knowledge stored in external but also self-produced documents. For this purpose we propose a module which allows attribut-ing different viewpoints to documents or document sec-tions, and a second module dealing with the representa-tion according to specific viewpoints of documents, document sections or self-produced additional informa-tion to documents (Figure 10).

Figure 10: Technical realisation of KM framework

Once the user of the system identified an interesting document, he has the possibility to add context by choos-ing in a list different viewpoints and attributing them to this document or document sections. This supports the reuse of identified information for future research result production. Context based documents or documents sec-tions are easier to reuse. The user can for example attrib-ute a theme to a document, indicating that the document is relevant for a special research theme. He also has the

possibility to attribute viewpoints according the knowl-edge typology (ex. a document or document section is talking about a new interesting tool, coming from a sup-plier). This means, he structures the information accord-ing to his research objectives and according to certain knowledge types. The next figure shows an example for external identified information (knowledge type K4) (Figure 11).

Figure 11: Giving viewpoints according research objective and knowledge typology

He also has the possibility to attribute annotations (comments) on documents or document sections, accessi-ble for other users.

The selection and description of documents, document sections, points of view and annotations is supported via XML tags. Tags concern the document title, document section title, annotation title, the different points of view, the author and the date when an information is introduced in the system.

This means technically, that the original document is converted in a XML document when the user selects sec-tions, titles, points of view, etc. (Figure 12).

50

Figure 12: Conversion of document into XML document

It is also possible to indicate if the document or docu-ment section might be interesting for users: after reading documents or annotations, the researcher indicates if he wishes to reuse this information for constituting the final research results. If this is the case, the researcher indi-cates for which part (if he has an rough idea of the re-search results) of the research results and in which con-text he counts to reuse the information. XML tags help to constitute the intermediate research result document. We use the tags for the document title an subtitles for the different sections.

The representation module allows representing infor-mation according to specific user profiles. Research man-agers can have a different representation of information than industrial researchers. The representation is done in a specific two-dimensional format, allowing crossing different viewpoints with each other. Once the researcher decides on the points of views he wants to represents, the systems identifies the different tags with these points of views and represents the corresponding information.

8 Technical issues There are some technical issues which cause difficulties for the tool realization. • Document format: documents are available on various

formats. The main formats which will play an impor-tant role for our tool solution are .doc, .txt, .ppt, .pdf, .html/htm/php, .xml, etc. In order to attribute view-points on documents, working on document sections, representing the documents or document sections with attributed viewpoints, it might be easier to work on one single document format. This means, the different document formats have to be transformed in one sin-gle format. This manipulation brings additional con-straints: there might be a duplications (from original documents to new formatted documents) which have to be avoided (requires probably additional data-bases).

• If transformation is necessary, the new format needs to be highly flexible. XML addresses partly this con-straint.

• Editing documents: editing non-final documents might cause problems for their attributed viewpoints and / or annotations. Once the user attributed viewpoints or annotations to documents or selected document sec-tions, the original documents need to stay static and stable. If the user wants to change or re-edit the origi-nal documents, he might get into conflict with the ex-isting viewpoint and annotation attributions. There-fore, it is important to discuss the possibility to re-edit documents with existing attributions, the technical feasibility and the affect on the fact that documents might be transformed from one format into another. One discussion point here might be that annotations are only possible on final documents. Another point might be the introduction of document versioning.

• Document sections: documents are the smallest object for the information system. One document can have several document sections. Each document section can have several attributed viewpoints or annotations. The constraint is not creating separate objects for document sections. This means not extracting docu-ment sections from documents (double storage of documents and document sections). This implies the following questions: how can document sections be identified and represented separately from their documents? How can the document sections be de-scribed separately from their original documents with viewpoints and annotations? How can document sec-tions be displayed if the user wants to have a look on the sections? XML gives a first possibility to answer these question. However, according to the different formats of documents, this approach has limited pos-sibilities and need to be discussed.

These technical issues play an important role for the so-lution realization.

9 Conclusion and perspectives In order to realize a knowledge management solution for industrial research processes we first described the dif-ferent research activities in a research process model and illustrated the knowledge of industrial researchers in a knowledge typology model. With a functional analysis we tried to describe, in a "systematic way", the demanded functions of a potential knowledge management system. Based on these models and the existing organization en-vironment (ex. quality certification) and with an external theoretical knowledge management model we con-structed a knowledge management solution for industrial research processes. For the different research activities

51

we proposed different knowledge management solutions. All these solutions are integrated in a portal.

The knowledge management architecture takes into ac-count most of the requirements. There is a better struc-ture of information and there exists a better overview of the different external and internal environments where the different information come from. The structure of information according to the knowledge typology of the industrial researchers allows manipulating information without manipulating whole documents. This facilitates comparing external information like information coming from technical suppliers with information coming from operational units (function F2 of the functional analysis).

One of the major advantages of our solution is the pos-sibility to add context to information such as documents and even document sections by attributing viewpoints. This makes explicit, why and for what information could be useful and gives a better understanding of complex information. Beyond, the attribution of viewpoints sup-ports significantly the information retrieval process and therefore saves time.

The possibility to make annotations supports the idea creation process for new solutions and is a mean for deci-sion traceability concerning the choice of new solutions. The fact that annotations can be exchanged among differ-ent users, and other annotations can follow initial annota-tions or be linked together, creates a space to exchange new ideas and therefore a strong support for common knowledge creation and common problem understanding avoiding time-consuming misunderstanding.

The indication and rating of information for further re-search activity reuse can be considered as an indication for preservation of important information. The fact that the information is reused gives it a certain importance for research production. The indication of preservation and the evaluation helps to create a reference which shows on which bases the production of new results has been done. Important information is not lost in the mass of informa-tion overflow. Furthermore, indicating information for reuse for research results accelerates the solution produc-tion process.

The representation module supports the reuse by indi-cating the available information according to certain viewpoints. The two dimensional representation allows to have a multi view on available information. This is a de-cision making support for industrial researchers and re-search managers to define new research orientations.

As a perspective we have the intention to build ontolo-gies in order to use the knowledge typology and the de-scription of the different research objectives to favor the exchange of knowledge and the comparison of concepts. Comparison might be useful to identify automatically external information or expert knowledge for existing internal research problems. The construction of ontolo-gies might also help to harmonize the definition of inter-nal concepts and knowledge in order to build a corporate memory.

As a further perspective, we will also start working on knowledge evaluation. A knowledge evaluation process could constitute a basic framework for the functions in-cluded in a knowledge management system for industrial research processes [Sveiby, 2001]. The evaluation proc-ess is important for innovative processes: considering external knowledge as important can lead to new research activities in order to obtain the same knowledge. The knowledge evaluation in specific research context and for given problems can initiate new research projects which can lead to the development of new knowledge. A knowledge evaluation mechanism is part of the basic functions for a knowledge management system for indus-trial research processes and gives a dynamic framework to knowledge management.

References [Barthes et al., 2000] Jean-Paul Barthes, et al., Livret d’introduction au knowledge management. 1 ed. Paris : IIIA Groupe de Travail Méthodologie, 2000. [Beckman, T., 2000] Beckman, T, Meta-Knowledge and Other Knowledge Dimensions. Proceedings from the 3rd AI and Soft Computing Conference. IASTED, 2000. [Carneiro, 2000] A. Carneiro . How does Knowledge Management influence innovation and competivness . Journal of Knowledge Management, No. 2, 2000. [Dieng et al., 2000] Rose Dieng et al . Méthodes et outils pour la gestion des connaissances. DUNOD, N° 2 10 004574 1, 2000. [Feldman, R. 1998]. R. Feldman. Text Mining: Theory and Practice. 4th World Congress on Expert Systems – Application of Advanced Information Technologies. ITESM Mexico City Campus, 1998. [Gardoni and Frank, 2001] Gardoni, M., Frank, C. : Find-ing and Implementing Best Practices For Design Re-search Activities, International Conferemce on Engineer-ing Design, ICED 01 Glasgow, August, 2001. [Jones, R. R. et al., 2000] Jones, R. R., Bremdal, B. A., Spagiari, C., Johansen, F., Engels, R. Knowledge Man-agement through content interpretation, CognIT a. s., Norway, 2000. [Le Masson and Weil, 1999] Pascal Le Masson, Benoît Weil. Nature de l’innovation et pilotage de la recherche industrielle – Le centre de recherche de Sekurit Saint-Gobain, Cahiers de recherche, Ecole des Mines de Paris, Centre de Gestion Scientifique, 1999. [Le Moigne, 1998] Le Moigne, JL., Connaissance ac-tionnable et action intelligent, Grand Atelier MCX au Futuroscope, Poitiers, 1998.

52

[Liebowitz, 1999] J. Liebowitz . Knowledge Management Handbook. CRC Press, Boca Raton, 1999. [Miller and Morris, 1999] Miller, W. L., Morris, L. - Fourth Generation R&D, Managing Knowledge, Tech-nology, and Innovation. John Wiley & Sons, inc., 1999. [Nonaka and Takeuchi, 1995] Nonaka, I., Takeuchi, H. - The Knowledge Creating Company. How Japanese Com-panies Create the Dynamics of Innovation, Oxford Uni-versity Press, 1995. [Nonaka and Takeuchi, 2001] Nonaka, I. and Treece, D. J., Managing Industrial Knowledge: Creation, Transfer and Utilization. Sage Publications, Thousands Oakks, 2001. [Prasad, 1996] Birren Prasard . Concurrent Engineering Fundamentals - Integrated product and process organi-sation. Vol. 1, Prentice Hall, Englewood Cliffs, NJ, 1996. [Prax, 2000] Prax, J.-Y., Le Guide du Knowledge Mana-gement. DUNOD, 2000. [Romhardt, 1998] Romhardt K. Die Organisation aus der Wissensperspective – Möglichkeiten und Grenzen der Intervention. Gabler, Wiesbaden, 1998. [Ruggles and Little, 1997] Ruggles, R. and Little, R. - Knowledge Management and Innovation, 1997. [Schultz, 2001] Schulz, A. - Applied KM in innovation processes. In Professionelles Wissensmanagement – Er-fahrungen und Visionen. Shaker Verlag, 2001. [Sveiby, 2001] Sveiby, K.-E.: Methods for Measuring Intangible Assets, http://www.sveiby.com.au/, 2001. [Tiger et Weil, 2001] Tiger, H., Weil, B. - La capitalisa-tion des savoirs pour l’innovation dans les projet, Com-munication au Colloque : Mobiliser les talents de l’entreprise par la gestion des connaissances, Paris, 2001.

53

Management and Reuse of Software Design Knowledge Using a CBR Approach

Paulo Gomes, Francisco C. Pereira, Paulo Paiva, Nuno Seco, Paulo CarreiroJose L. Ferreira and Carlos Bento

CISUC - Centro de Informatica e Sistemas da Universidade de CoimbraDepartamento de Engenharia Informatica - Polo II

Universidade de Coimbra - Portugalpgomes@dei.uc.pt

Abstract

From the viewpoint of an organization that devel-ops software, knowledge generated during softwaredevelopment is valuable and would be very usefulif it could be stored for later reuse. In this paperwe describe a computational system for softwaredesign knowledge management and reuse. Ourapproach is based on Case-Based Reasoning andWordNet. We explain how knowledge managementis performed in our system, and how some tools thatwe have implemented help the system administra-tor do this. We also describe how the stored knowl-edge is reused. Finally we discuss the advantagesand limitations of our approach.

1 IntroductionGenerally knowledge generated in the software developmentprocess is not stored in a way that it can be reused lateron other projects. If software development companies reuseknowledge associated with the development process, theywill improve in at least two major aspects: development effi-ciency and software quality. Another main advantage of per-forming knowledge management and reuse of software devel-opment knowledge is that it could minimize the loss of valu-able software engineers. Storing, managing and reusing thedevelopment knowledge would enable the company to haveaccess some of the know-how of their development teams.

Software development has several phases[Boehm, 1988],from analysis to integration, passing by testing and design.Among these phases there is one that is the focus of thiswork: the design phase. During the design phase the struc-ture and behavior of the system is specified. Generally de-sign is a complex task an ill-defined task[Tong and Sriram,1992], making it hard to model and to automate. The knowl-edge generated during the design phase, is going to be reusedlater on other projects by the software engineers. We are in-terested in studying the management of design knowledge ina software development company, involving several softwaredesigners.

Most of the software designers decisions are taken usingtheir experience. The more experience a designer has, the bet-ter s/he can perform its job, in principle. Reasoning based onexperience is a basic mechanism for designers, enabling them

to reuse previous design solutions in well known problems oreven in new projects, sometimes generating innovative or cre-ative solutions. In artificial intelligence there is a sub areacalled Case-Based Reasoning (CBR, see[Kolodner, 1993;Aamodt and Plaza, 1994; Maheret al., 1995]) that uses expe-riences, in the form of cases, to perform reasoning. We thinkthat CBR is a good candidate for building a design systemthat can act like an intelligent design assistant.

The observations presented before, lead us to the devel-opment of a computational system that could perform threetasks: storage of software design, management of this knowl-edge, and reuse of it. To achieve these goals, we proposea system based on CBR. The CBR framework is flexibleenough to comply with different knowledge types and rea-soning mechanisms, enabling the software designer to usewhatever design assistant s/he wants to use. The case-baseused in the CBR system is a key point in the system, allow-ing the system to store and reuse design knowledge. We alsointegrated a lexical resource - WordNet[Miller et al., 1990] -which enables several semantic operations like indexing soft-ware objects and computing semantic distances between con-cepts.

The next section describes the CBR methodology describ-ing its main ideas. Section 3 describes the architecture ofour system - REBUILDER. We then detail some key is-sues of REBUILDER: knowledge base (section 4), designknowledge management (section 5) and design knowledgereuse (section 6). Section 7 describes and example of RE-BUILDER’s use, providing more information about the sys-tem. Finally section 8 discusses several important issues con-cerning design knowledge management in REBUILDER.

2 Case-Based ReasoningCase-Based Reasoning can be viewed as a methodology fordeveloping knowledge-based systems[Althoff, 2001] thatmakes use of experience for reasoning about problems. Itsmain idea is to reuse past experiences to solve new situationsor problems.

A caseis a central concept in CBR, and it represents achunk of experience in a format that can be reused by a CBRsystem. Usually a case comprises three main parts: problem,solution, and outcome. The problem is a description of thesituation that the case is representing. This can be, for ex-ample, the symptoms of a patient in a medical situation, or

54

General Knowledge

Previous Cases

Target Case

Retrieved Case

Problem

Target Case

New Case

Learned Case

Tested / Repaired

Case

RETRIEVE

REUSE

REVISE

RETAIN

Figure 1: The CBR cycle.

a software system’s requirements, or any description that cancharacterize the situation being represented. The solution de-scribes what was used to solve the situation described in theproblem. For instance, in the medical domain it can be thetreatments used to heal the patient, or in the software domaina design that complies with the system’s requirements. Theoutcome expresses the result of the application of the solutionto the problem. This means that commonly there are two pos-sible outcomes: success or failure. A success case representsa situation in which the solution worked well, while a failurecase represents a situation where the solution did not work.There can be other parts of cases like the justification that re-lates problem with solution through causal relations[Bentoetal., 1995].

Another important part of the CBR methodology is the caselibrary. This is the place where all the cases are going to bestored and organized. Due to the high number of cases thatthe library can have, most of the CBR systems use index-ing structures that enable fast retrieval of relevant cases frommemory. So, most of the times a case library is more than justthe place to store cases, but it defines how they are stored andhow they can be accessed.

At an abstract level CBR can be described by the reasoningcycle depicted in figure 1[Aamodt and Plaza, 1994]. The rea-soning process starts with the problem description, which isthen transformed into a target case (or query case). The prob-lem is provided by a system user or by another system. Thefirst phase in the CBR cycle is to retrieve from the case librarythe cases that are relevant for the target case. The relevancy ofa case must be defined by the system, but the most commonone is similarity of features. In the end of retrieval, the bestretrieved case1 is returned and passes to the next phase alongwith the target case.

The reuse phase (also designated as adaptation phase)adapts the retrieved case to the target case, yielding a solvedcase (or new case). This process can be performed withseveral inference techniques, and many work has been doneon the subject[Voss, 1996]. The next step for a CBR sys-

1There are system that retrieve more than one case, dependingon the system’s purpose.

UML Editor Knowledge Base Manager

Knowledge Base Administrator Software Designer

Knowledge Base

Case Library

Case Indexes

WordNet

Data Type Taxonomy

CBR Engine

Retrieval

Design Composition

Analogy

Verification Evaluation

Learning

Figure 2: REBUILDER’s Architecture.

tem is to revise the new case returning a tested and repairedcase. This phase usually comprises two parts: verificationand evaluation. While verification checks the new case con-sistency and coherence, the evaluation phase assesses the per-formance characteristics of the new case. Finally, the retainphase learns the solved case by storing it in the case library.This phase is more complex than it seems, because not allcases should be stored. If a new case is equal or very similarto a case already in the library, then it should not be storedbecause it brings nothing new to the system and it degradesthe system’s performance. This last phase closes the CBR cy-cle by feeding the system with new experiences, making thesystem capable of learning.

3 REBUILDERThe approach carried out in REBUILDER uses CBR as themain reasoning framework, enabling the coordination of sev-eral different types of knowledge. This section, first givesan overview on the system’s architecture, and then describesthe knowledge base used. As a CBR system, REBUILDERimplements the reasoning cycle described in section 2, the de-tails of each reasoning step are described later in this section.

Figure 2 shows the architecture of REBUILDER. It com-prises four main modules: the UML2 editor, the knowledgebase manager, the knowledge base (KB), and the CBR en-gine. It also shows the two different user types: software de-signers, and KB administrators. Software designers use RE-BUILDER as a CASE3 tool, and the reuse capabilities of thesystem. A KB administrator as the function of keeping theKB updated and consistent. The UML editor is the interfacebetween REBUILDER and the software designer, while theKB manager is the interface between the KB administratorand the system.

The UML editor is the front-end of REBUILDER andthe environment where the software designer develops de-signs. Apart from the usual editor commands to manipulateUML objects, the editor integrates new commands capable ofreusing design knowledge. These commands are directly re-

2Unified Modelling Language[Rumbaughet al., 1998].3Computer Aided Software Engineering.

55

lated with the CBR engine capabilities and are divided intotwo main categories: KB actions, such as connect to KB anddisconnect from KB; and cognitive actions, such as retrievedesign, adapt design using analogy or design composition,verify design, evaluate design, and actions related with objectclassification.

The KB Manager module is used by the administrator tomanage the KB, keeping it consistent and updated. This mod-ule comprises all the functionalities of the UML editor, andadds case-base management functions. These are used by theKB administrator to update and modify the KB. The list ofavailable functions are: create KB, open KB, close KB, caselibrary manager (which comprises functions to manipulatethe cases in the case library, like adding new cases, remov-ing cases, or changing the status of a case), activate learning(gives the KB administrator an analysis about the contents ofthe case library), and system settings.

The KB comprises four different parts: the case library,which stores the cases of previous software designs; an indexmemory used for efficient case retrieval; a data type taxon-omy, which is an ontology of the data types used by the sys-tem; and WordNet[Miller et al., 1990], which is a generalpurpose ontology. This module is described in more detail inthe next subsection.

The CBR Engine is the reasoning module of REBUILDER.As the name indicates, it uses the CBR paradigm to establisha reasoning framework. This module comprises five differentparts: Retrieval, Design Composition, Analogy, Verification,and Learning. All these modules are detailed in section 6.

4 Knowledge BaseThe KB comprises the WordNet ontology, a case library, thecase indexes and the data type taxonomy. In REBUILDERa case describes a software design, which is represented inUML through the use of class diagrams. Figure 3 shows anexample of a class diagram representing part of an educa-tional system. Nodes are classes, with name, attributes andmethods. Links represent relations between classes. Closed-arrow relations represent generalizations, and no-arrow rela-tions represent participative associations. Conceptually a casein REBUILDER comprises: a name used to identify the casewithin the case library; the main package, which is an ob-ject that comprises all the objects that describe the main classdiagram; and the file name where the case is stored. Casesare stored using XML/XMI (eXtended Mark-up Language),since it is a widely used format for data exchange. UML classdiagram objects considered in REBUILDER are: packages,classes, interfaces and relations. A package is a UML ob-ject used for grouping other UML objects. A class describesan entity in UML and it corresponds to a concept describedby attributes at a structural level, and by methods at a behav-ioral level. Interfaces have only methods, since they describea protocol of communication for a specific class. A relationdescribes a relationship between two UML objects.

WordNet is used in REBUILDER as a common sense on-tology. It uses a differential theory where concept meaningsare represented by symbols that enable a theorist to distin-guish among them. Symbols are words, and concept mean-

School

+ name : String

+ address : String

+ phone : int

+ addDepartment(Dep: SchoolDepartment) : void

SchoolDepartment

+ name : String

+ addTeacher(prof: Teacher) : void

+ removeTeacher(name: String) : int

+ getTeacher(name: String) : Teacher

+ addStudent(name: String) : int

+ removeStudent(name: String) : int

+ getStudent(name: String) : Student

Student

+ name : String

+ studentID : int

Teacher

+ name : String

1..*

1..*

1..*

Figure 3: Example of an UML Class diagram (Case1), thepackage classification isSchool.

ings are called synsets. A synset is a concept represented byone or more words. If more than one word can be used torepresent a synset, then they are called synonyms. The sameword can have more than one different meaning (polysemy).WordNet is built around the concept of synset. Basically itcomprises a list of word synsets, and different semantic rela-tions between synsets. The first part is a list of words, eachone with a list of synsets that the word represents. The secondpart, is a set of semantic relations between synsets, likeis-arelations,part-of relations, and other relations. REBUILDERuses the word synset list and four semantic relations:is-a,part-of, substance-of, andmember-of. Synsets are classifiedin four different types: nouns, verbs, adjectives, and adverbs.REBUILDER uses synsets for categorization of software ob-jects. Each object has a context synset which represents theobject meaning. The object’s context synset can be used forcomputing object similarity (using the WordNet semantic re-lations), or it can be used as a case index, allowing the rapidaccess to objects with the same classification.

As cases can be large, they are stored in files, which makescase access slower then if they were in memory. To solve thisproblem we use case indexes. These provide a way to accessthe relevant case parts for retrieval without having to read allthe case files from disk. Each object in a case is used as anindex. REBUILDER uses the context synset of each objectto index the case in WordNet. This way REBUILDER canretrieve a complete case, using the case root package, or itcan retrieve only a subset of case objects, using the objects’indexes. This allows REBUILDER to provide the user thepossibility to retrieve not only packages, but also classes andinterfaces. To illustrate this approach, suppose that the classdiagram of Figure 3 representsCase1. Figure 4 presents partof the WordNet structure and some of the case indexes associ-ated withCase1. As can be seen, WordNet relations are of thetypes is-a, part-of andmember-of, while the index relationrelates a case object (squared boxes) with a WordNet synset

56

Institution Educational

Institution

School

Staff

Teacher Classroom

Room is - a

is - a is - a

part - of member - of

member - of

[Case1] Class: Teacher

[Case1] Class: School

[Case1]

Package: School

index index index

College is - a

member - of University

is - a

[Case2] Class: University

[Case2] Package:

University

index index

Figure 4: A small example of the WordNet structure and caseindexes.

(rounded boxes). For instanceCase1has one package calledSchool(the one presented in Figure 3), which is indexed bysynsetSchool. It has also a class with the same name andcategorization, indexed by the same synset, making also thisclass available for retrieval.

The data type taxonomy is a hierarchy of data types usedin REBUILDER. Data types are used in the definition of at-tributes and parameters. The data taxonomy is used to com-pute the conceptual distance between two data types.

5 Design Knowledge ManagementREBUILDER stores and manages design knowledge gath-ered from the software designers activity. This knowledgeis stored in a central repository, which is managed by the KBadministrator.

The knowledge that can be managed by the administratorare the design cases, which is performed through the KB man-ager module. The basic responsibilities of the administratoris to setup the system and to decide which cases should bein the case library. Another task the s/he has to perform isto revise new diagrams submitted to the case library by thesoftware designers.

Deciding the contents of the case library is not an easy task,especially if the case-base has a large number of cases. Inthis situation the KB manager provides a set of case-basedmaintenance policies that s/he can use to determine which arethe cases that should be deleted or added to the case library.These policies are:

Frequency Deletion Criteria [Minton, 1990] This criteriaselects cases for deletion based on the usage frequencyof cases.

Subsumption Criteria [Racine and Yang, 1997] The sub-sumption criteria defines that a case is redundant if: isequal to another case, Or is equivalent to another case,Or is subsumed by another case. In REBUILDER a caseis considered subsumed when, there is another case withthe same root package synset, and the package and ob-jects structure is a substructure of the other case.

Footprint Deletion Criteria [Smyth and Keane, 1995] Thiscriteria is based on two definitions:case coverage, or theset of problems that a case can solve; andreachability setof a case is the set of cases that can be used to providesolutions for a problem. Based on these two notions the

case base is divided in three groups (initially in Smyth’swork were four, but one of the subgroups can not be dis-tinguished in our approach). Pivotal cases represent anunique way to answer a specific query. Auxiliary casesare those which are completely subsumed by other casesin the case base. Spanning cases are cases between Piv-otal and Auxiliary cases, which link together areas cov-ered by other cases. When the case library has too manycases the recommended order of deletion is: auxiliary,spanning, and pivotal.

Footprint-Utility Deletion Criteria [Smyth and Keane,1995] This criteria is the same as the Footprint DeletionCriteria, with the exception that when there is a drawthe selection is based on the case usage - less used casesare chosen for deletion.

Coverage Criteria [Smyth and McKenna, 1998] The cover-age criteria involves three factors: case-base size, case-base density, and case-base distribution. A new case isadded to the case library if its inclusion in the case-baseincreases the case-base coverage/case-base number ra-tio.

Case-Addition Criteria [Zhu and Yang, 1999] The case-addition criteria involves the notion of case neighbor-hood, which in REBUILDER is defined as all the casesthat have the same root package synset as the case be-ing considered. This criteria uses the notion of benefitof a case in relation to a case set, which is based on thefrequency function of cases. A new case is added to thecase base if its benefit is positive.

Relative Coverage [Smyth and McKenna, 1999] The goalof this criteria is to maximize coverage while minimiz-ing case-base size. The proposed technique for build-ing case-bases is to use Condensed Nearest Neighbor oncases that have first been arranged in descending orderof their relative coverage contributions.

Relative Performance Metric [Leake and Wilson, 2000]This criteria uses the notion of relative performance todecide if a case should be added to the case base or not.The relative performance of a case is based on the sumof the adaptation cost of the case being considered to allcases in its coverage set. If the relative performance of anew case being considered is higher than an establishedthreshold, then the new case is added to the case library.

Competence-Guided Criteria [McKenna and Smyth,2000] The competence-guided criteria extends previousworks of Smyth, which use the notions of case com-petence based on case coverage and reachability. Thiscriteria uses three ordering functions:

• Reach for Cover (RFC): which uses the size of thereachability set of a case. The RFC evaluation func-tion implements this idea: the usefulness of a caseis an inverse function of its reachability set size.

• Maximal Cover (MCOV): which uses the size ofthe coverage set of a case. Cases with large cover-age sets can classify many target cases and as suchmust make a significant contribution to classifica-tion competence.

57

• Relative Coverage (RC): which is defined in a pre-vious criteria.

When a diagram is submitted by a software designer as acandidate to a new case to be added to the case library, theadministrator has to check some items in the diagram. Firstthe diagram must have synsets associated to the classes, in-terfaces and packages. This is essential for the diagram to betransformed in a case, and to be indexed and reused by thesystem. The diagram consistency and coherence must also bechecked. REBUILDER provides a verification and evaluationmechanism that can help the administrator in two differentways: verification can identify certain syntax and semanticerrors or less common items in the diagram an draw the ad-ministrator’s attention to them; evaluation assesses the designproperties and characteristics presenting them as guidelinesfor the diagram’s evaluation, this is performed using severalobject-oriented metrics[Bar et al., 1999; Rosenberg and Hy-att, 1996]. Finally the administrator can use the case-basedmaintenance policies described before to help him to decideif the submitted diagram should be added to the case libraryor not.

The KB Manager module is used by the administrator tomanage the KB, keeping it consistent and updated. This mod-ule comprises all the functionalities of the UML editor, andit adds case-base management functions to REBUILDER.These are used by the KB administrator to update and modifythe KB. The list of available functions are:

KB Operations Create, open or close a KB.

Case Library Manager Opens the Case Library Manager,which comprises functions to manipulate the cases in thecase library, like adding new cases, removing cases, orchanging the status of a case.

Activate Learning Gives the KB administrator an analysisabout the contents of the case library. REBUILDERuses several case-base maintenance policies to deter-mine which cases should be added or removed from thecase library.

Settings Adds extra configuration settings which are notpresent in the normal UML Editor version used by thesoftware designers. It also enables the KB administratorto configure the reasoning mechanisms.

6 Design Knowledge Reuse

Reuse of UML class diagrams can be done in REBUILDERin three different ways: using retrieval, using analogy or usingdesign composition. The retrieval mechanisms searches theWordNet structure looking for similar cases and then ranksand presents them to the designer. Analogy takes as input aUML class diagram and tries to complete it using analogicalmapping and knowledge transference. Design compositiongenerates a new class diagram through the integration of dif-ferent pieces of cases, using the target diagram for guidancein this process. The next sub sections describe each one ofthese reuse mechanisms.

ObjsFound ← ?PSynset← Get context synset ofQObjPSynsets← {PSynset}ObjsExplored← ?WHILE(#ObsFound < N )AND(PSynsets 6= ?)DO

Synset← Remove first element ofPSynsetsObjsExplored ← ObjsExplored + SynsetSubSynsets ← GetSynset hyponymsSuperSynsets ← GetSynset hypernymsSubSynsets ←SubSynsets−ObjsExplored

−PSynsetsSuperSynsets ←SuperSynsets

−ObjsExplored− PSynsetsPSynsets ←Add SubSynsets to the end

of PSynsetsPSynsets ←Add SuperSynsets to the end

of PSynsetsObjects ← Get all objects indexed bySynsetObjects ← Objects ∩ObjectListObjsFound ← ObjsFound ∪Objects

ENDWHILEObjsFound ← RankObjsFound by similarityRETURN the firstN elements fromObjsFound

Figure 5: The case retrieval algorithm used in REBUILDER.

6.1 Retrieval

Retrieval in REBUILDER comprises two phases: retrieval ofa set of relevant cases from the case library, and assessmentof the similarity between the target problem and the retrievedcases.

The retrieval phase is based on the WordNet structure,which is used as an indexing structure. The retrieval algo-rithm uses the classifications of the target problem object asthe initial search probe in WordNet. This algorithm is flexi-ble enough to retrieve three different types of UML objects:packages, classes and interfaces, depending on the type of ob-ject selected as target problem. For example, if the designerselects a package as the target problem, the retrieval algo-rithm uses the package’s synset as the initial search probe.Then the algorithm checks if there are any packages indexesassociated with the WordNet node of that synset. If there areenough indexes, the algorithm stops and returns them. Other-wise, it explores the synset nodes adjacent to the initial one,searching for package indexes until the number of found in-dexes reaches the number of objects that the user wants to beretrieved. Suppose that theN best objects are to be retrieved,QObj is the query object, andObjectList is the universe ofobjects that can be retrieved (usuallyObjectListcomprisesall the library cases), then the algorithm is described in figure5.

The second step of retrieval is ranking the retrieved objectsby similarity with the target object. Since there are three typesof target objects (packages, classes and interfaces) we havedeveloped a specific similarity metric for each type of objects(for more details on these metrics see[Gomeset al., 2002a]).

Package Similarity Metric This metric is based on four dif-ferent aspects: the similarity between packages’ synsets,

58

similarity between packages’ dependencies4, similaritybetween packages’ class diagrams, and similarity be-tween the sub-packages (a recursive call to this metric).Basically this metric assesses structure similarity and se-mantic similarity of packages and its objects.

Class Similarity Metric The class similarity metric is basedon three items: synset similarity of classes beingcompared, inter-class similarity comprising the assess-ment of relation similarity between classes, and intra-class similarity which evaluates the similarity betweenclasses’ attribute and methods.

Interface Similarity Metric The interface similarity metricis the same as the class similarity, except in the intra-class similarity, which is based only in method similar-ity, since interfaces do not have attributes.

6.2 AnalogyThe analogy mechanism relies in a set of cases given by theretrieval phase. From these cases then best ones are se-lected for generating new diagrams. This number is chosenby the user and represents the number of alternative solu-tions required. Then, for each case, the analogy module triesto map each object in the target diagram to an object in thecase diagram. In this process structural relations are used asconstraints, transforming this process in a structural match-ing algorithm, in which node matching is based on seman-tic similarity of objects’ synsets. This semantic similarity isbased on the WordNet distance between synsets. The resultof this process is a mapping between target and case objects,which is then used for transferring the knowledge from thecase diagram to a new diagram (which is a copy of the tar-get diagram). Knowledge transference is performed in twosteps: first attributes and classes are transferred from caseclasses/interfaces to the new diagram classes/interfaces, andthen new objects and relations are transferred from the casediagram to the new diagram. The final result is a new classdiagram based on the target diagram. For more details on theanalogy process see[Gomeset al., 2002b].

6.3 Design CompositionThe design composition is a different way of generating newdiagrams based on the merging of different case pieces. De-sign composition starts with a set of retrieved cases, whichare then used to generate the new class diagrams. Thereare two different composition strategies: best case composi-tion (BCC) and best complementary set of cases composition(BCSCC).

The main idea of the BCC strategy is based on selectingthe best retrieved case, mapping it to the target diagram, andtransferring the knowledge to a new diagram. If there are un-mapped target objects, then this strategy tries to find match-ing objects in other retrieved cases. This goes on until, all thetarget objects are mapped or no more retrieved cases can beused.

4Dependencies are a type of UML relations that can exist be-tween packages, expressing a package’s dependency on anotherpackage.

Figure 6: The initial diagram used by the designer as targetproblem.

The BCSCC strategy is based on the idea of complemen-tary cases, regarding the target diagram. This strategy startsby mapping every retrieved case to the target diagram, yield-ing a mapping, which is then used for grouping the retrievedcases in sets. These sets are generated based on how well thecases of a set, map the target diagram. The preference is tohave sets, whose cases merged, completely map the target di-agram. Then, each one of these sets can give origin to a newdiagram. As in analogy, only then best sets originate newdiagrams. Sets are ranked by the degree of mapping of thetarget diagram.

7 Example of UseThis section describes an example that illustrates how the sys-tem can be used by a software designer. This example isabout the designer client of REBUILDER, showing how de-sign knowledge is reused.

Suppose that a designer is starting the design of a infor-mation system for a high school. She has already the sys-tem’s analysis done, in the form of use cases5. From these usecases, some initial entities are extracted by the designer anddrawn in the REBUILDER system. Figure 6 shows the ini-tial class diagram, representing one of the system’s modules(scheduling). This module is responsible for handling the in-formation data about teachers, classes and rooms timetables.

One of the tools available to the designer is the retrievalof similar designs from the case library. The designer canretrieve three types of objects: packages (a complete classdiagram, what we call a case), classes or interfaces. Imaginethat she selects the package object and clicks on the retrievalcommand. REBUILDER retrieves the number of diagramsdefined by the designer (in this situation three cases). Figure7 presents part of one of the retrieved cases (the most similarone), notice that in the diagram’s name there is the similarityscore with the target design.

The retrieved designs can help the designer exploring thedesign space, aiding the assessment of the different alterna-tive designs. Or she can go further and use the adaptationmechanisms of REBUILDER to generate new designs. Theadaptation mechanisms are: analogy, design composition and

5It is a UML diagram type used for describing system require-ments.

59

Figure 7: The most similar case from the retrieved ones, thenumber in brackets is the similarity score.

Figure 8: Part of a diagram generated by design composition.

software design patterns. Suppose that the designer selectsdesign composition, figure 8 shows part of a diagram gener-ated by this mechanism. As can be seen, it used the mostsimilar case (case in figure 7) to build this new case, and thencompleted it with the missing objects.

Generated diagrams can have some inconsistencies, whichcan be fixed using the verification module. For example, sup-pose that, in the generated diagram (figure 8) the relation be-tween classTeacherand classTimetableis out of context. Theverification module checks four different knowledge sourcesto assess the relation’s validity: WordNet, design cases andverification cases. In WordNet the system looks for a relationbetween theTeachersynset and theTimetablesynset, if it isfound then the relation is considered valid. Otherwise, thesystem searches the design cases for a similar relation (a rela-tion of the same type between the synsets of classesTeacherandTimetable). If the algorithm fails to find it, the next step is

looking in the verification cases. It searches for a verificationcase describing the validity of a similar relation. A verifica-tion case can have two outcomes: success or fail. This way,if the algorithm finds a similar verification case and the out-come is success, the relation is considered valid, otherwiseis considered invalid. If in the end the relation is consideredinvalid, then the designer is asked for a judgement about therelation and a new verification case is generated and stored inthe case library.

After verification, if the designer considers the diagramcorrect and ready for being stored in the KB, for later reuse,then she can submit the diagram to the KB administrator.This new diagram goes into a list of unconfirmed cases of thecase library. The KB administrator has the task of examiningthese diagrams more carefully, deciding which are going tobe transformed into cases, going to the list of confirmed cases(ready to be reused by REBUILDER), and which are going tothe list of obsolete cases not being used by the system.

8 DiscussionThis paper describes REBUILDER a CASE tool that has theability to manage the design knowledge gathered during soft-ware development. REBUILDER is used as a platform forreuse of that knowledge. If we analyze deeper the implica-tions of software reuse as done in REBUILDER, it can beseen that inexperience designers profit a lot from the reuse ofdesign knowledge, inhibiting the making of mistakes of pre-vious systems. From the point of view of experienced design-ers, the system can help them exploring different alternativedesigns. This exploration can be very useful in innovative orcreative design (see[Gomeset al., 2002c]).

From the company’s viewpoint, REBUILDER can be avery useful tool for minimizing the loss of know-how of soft-ware engineers that leave the company. Part of their experi-ence is kept in the organization in the form of design cases.For the software development process the management andreuse of design knowledge can lower the development timeand increase the software quality.

A limitation of our approach is that the company shouldchange the software development process in order to fully useall the advantages of REBUILDER. The organization shouldshape it’s development process with the goal of developingsoftware through reuse. Of course, that REBUILDER canalso be used in different ways, from just a CASE tool toa complete Knowledge Management tool integrated with aCASE tool. One aspect of this limitation is that the systemshould be managed by a KB administrator. This is a fun-damental piece in the system, and the good functioning ofthe system depends on her/his performance. REBUILDERtries to help the administrator in her/his task automating sev-eral case-base maintenance policies, but the last decision isalways up to the administrator.

There is another important limitation to our approach,which relates to WordNet. From our experience the conceptsdefined in WordNet (the synsets) are sufficient to index casesand objects when the designer is working at a conceptuallevel. Objects represent abstract concepts and do not neces-sarily represent classes to be implemented. A problem arises

60

when the designer goes into the implementation (or detailed)design, where the objects must represent classes and inter-faces to be implemented. To address this problem we haveto WordNet the Java class hierarchy. Several software spe-cific concepts, in this case relating to Java language, whereadded to WordNet hierarchies along withis-a links connect-ing them. These concepts allow the indexing of many soft-ware specific objects, ones that are only defined in the de-tailed design level.

Research works integrating CBR and Knowledge Manage-ment, use CBR to fulfill the technology needs of some ofthe Knowledge Management tasks[Aha and Munoz-Avila,1999]. In our work, CBR is more than that, it provides thebasic framework for all the Knowledge Management process,from the knowledge acquisition (case learning), knowledgemanagement (KB manager) to the reuse of this knowledge(reasoning engine). Despite this, we are aware that the scopeof REBUILDER is limited to the software design task, whichis a specific task compared with the all process of knowledgemanagement in a software development company or organi-zation.

AcknowledgmentsThis work was partially supported by POSI - Programa Op-eracional Sociedade de Informacao of Fundacao Portuguesapara a Ciencia e Tecnologia and European Union FEDER,under contract POSI/33399/SRI/2000, by program PRAXISXXI. REBUILDER homepage is http://rebuilder.dei.uc.pt.We would like to thanks the reviewers of this paper for theirhelpful comments.

References[Aamodt and Plaza, 1994] Agnar Aamodt and Enric Plaza.

Case–based reasoning: Foundational issues, methodolog-ical variations, and system approaches.AI Communica-tions, 7(1):39–59, 1994.

[Aha and Munoz-Avila, 1999] David Aha and HectorMunoz-Avila. Exploring synergies of knowledge manage-ment and case-based reasoning: Papers from the AAAI1999 workshop. InAAAI’99 Workshop, Washington, DC,USA, 1999. Naval Research Laboratory, Navy Center forApplied Research in Artificial Intelligence.

[Althoff, 2001] Klaus-Dieter Althoff. Case-based reasoning.In S. K. Chang, editor,Handbook on Software Engineeringand Knowledge Engineering, volume 1, pages 549–588.World Scientific, 2001.

[Baret al., 1999] Holger Bar, Markus Bauer, Oliver Ciupke,Serge Demeyer, Stephane Ducasse, Michele Lanza, RaduMarinescu, Rob Nebbe, Oscar Nierstrasz, Tamar Rich-ner, Matthias Rieger, Claudio Riva, Anne-Marie Sassen,Benedikt Schulz, Patrick Steyaert, Sander Tichelaar, andJoachim Weisbrod. The famoos object–oriented reengi-neering handbook. Technical report, ForschungszentrumInformatik, Software Composition Group, University ofBerne, 1999.

[Bentoet al., 1995] Carlos Bento, Luıs Macedo, and ErnestoCosta. Reasoning with cases imperfectly described and

explained. In Jean-Paul Haton, Mark Keane, and MichelManago, editors,Proceedings of the 2nd European Work-shop on Advances in Case-Based Reasoning, volume 984of LNAI, pages 45–59, Berlin, November 1995. SpringerVerlag.

[Boehm, 1988] Barry Boehm. A Spiral Model of SoftwareDevelopment and Enhancement. IEEE Press, 1988.

[Gomeset al., 2002a] Paulo Gomes, Francisco C. Pereira,Paulo Paiva, Nuno Seco, Paulo Carreiro, Jose L. Ferreira,and Carlos Bento. Case retrieval of software designs usingwordnet. In F. van Harmelen, editor,European Conferenceon Artificial Intelligence (ECAI’02), Lyon, France, 2002.IOS Press, Amsterdam.

[Gomeset al., 2002b] Paulo Gomes, Francisco C. Pereira,Paulo Paiva, Nuno Seco, Paulo Carreiro, Jose L. Ferreira,and Carlos Bento. Combining case-based reasoning andanalogical reasoning in software design. InProceedingsof the 13th Irish Conference on Artificial Intelligence andCognitive Science (AICS’02), Limerick, Ireland, Septem-ber 2002. Springer-Verlag.

[Gomeset al., 2002c] Paulo Gomes, Francisco C. Pereira,Nuno Seco, Jose L. Ferreira, and Carlos Bento. Supportingcreativity in software design. InAISB’02 Symposium ”AIand Creativity in Arts and Science”., London, UK, 2002.

[Kolodner, 1993] Janet Kolodner. Case-Based Reasoning.Morgan Kaufman, 1993.

[Leake and Wilson, 2000] David Leake and David Wilson.Remembering why to remember: Performance-guidedcase base maintenance. InProceedings of the EuropeanWorkshop on Case-Based Reasoning (EWCBR-00), LNAI,pages 161–172, Berlin, 2000. Springer.

[Maheret al., 1995] Mary Lou Maher, M. Balachandran,and D. Zhang. Case-Based Reasoning in Design.Lawrence Erlbaum Associates, 1995.

[McKenna and Smyth, 2000] Elizabeth McKenna and BarrySmyth. Competence-guided case base editing techniques.In Proceedings of the European Workshop on Case-BasedReasoning (EWCBR-00), LNAI, pages 186–197, Berlin,2000. Springer.

[Miller et al., 1990] George Miller, Richard Beckwith,Christiane Fellbaum, Derek Gross, and Katherine J.Miller. Introduction to wordnet: an on-line lexicaldatabase.International Journal of Lexicography, 3(4):235– 244, 1990.

[Minton, 1990] Steven Minton. Quantitative results concern-ing the utility of explanation-based learning.Artificial In-telligence, 42(2-3):363–391, March 1990.

[Racine and Yang, 1997] Kirsti Racine and Qiang Yang.Maintaining unstructured case bases. In David B. Leakeand Enric Plaza, editors,Proceedings of the 2nd Interna-tional Conference on Case-Based Reasoning (ICCBR-97),volume 1266 ofLNAI, pages 553–564, Berlin, July 1997.Springer.

[Rosenberg and Hyatt, 1996] L. H. Rosenberg and L. E. Hy-att. Developing a successful metrics programme. InESA

61

1996 Product Assurance Symposium and Software Prod-uct Assurance Workshop, pages 213–216, ESTEC, Noord-wijk, The Netherlands, 1996. European Space Agency.

[Rumbaughet al., 1998] J. Rumbaugh, I. Jacobson, andG. Booch. The Unified Modeling Language ReferenceManual. Addison-Wesley, Reading, MA, 1998.

[Smyth and Keane, 1995] Barry Smyth and Mark T. Keane.Remembering to forget: A competence-preserving casedeletion policy for case-based reasoning systems. InChris S. Mellish, editor,Proceedings of the Fourteenth In-ternational Joint Conference on Artificial Intelligence (IJ-CAI 95), pages 377–383, San Mateo, August 1995. Mor-gan Kaufmann.

[Smyth and McKenna, 1998] Barry Smyth and ElizabethMcKenna. Modelling the competence of case-bases. InBarry Smyth and Padraig Cunningham, editors,Proceed-ings of the 4th European Workshop on Advances in Case-Based Reasoning (EWCBR-98), volume 1488 ofLNAI,pages 208–220, Berlin, September 1998. Springer.

[Smyth and McKenna, 1999] Barry Smyth and ElizabethMcKenna. Building compact competent case-bases. InKlaus-Dieter Althoff, Ralph Bergmann, and L. Karl Brant-ing, editors,Proceedings of the 3rd International Confer-ence on Case-Based Reasoning Research and Develop-ment (ICCBR-99), volume 1650 ofLNAI, pages 329–342,Berlin, July 1999. Springer.

[Tong and Sriram, 1992] C. Tong and D. Sriram.ArtificialIntelligence in Engineering Design, volume I. AcademicPress, 1992.

[Voss, 1996] A. Voss. Towards a methodology for case adap-tation. InECAI ’96; 12th European Conference on Artifi-cial Intelligence, pages 147–154, Chichester - New York -Brisbane, August 1996. Wiley.

[Zhu and Yang, 1999] Jun Zhu and Qiang Yang. Remember-ing to add: Competence-preserving case-addition policiesfor case base maintenance. In Dean Thomas, editor,Pro-ceedings of the 16th International Joint Conference on Ar-tificial Intelligence (IJCAI-99-Vol1), pages 234–241, S.F.,July 1999. Morgan Kaufmann Publishers.

62

KnowledgeManagementusing BusinessProcessModeling and WorkflowTechniques

Hsiang-Ling Kuo�, Yun-Heh Chen-Burger

�, DaveRobertson

��

Schoolof Informatics,TheUniversity of Edinburgh,UKemail: s0125762@ed.ac.uk�

AIAI, TheUniversity of Edinburgh,UK email: jessicac@inf.ed.ac.uk�CISA, TheUniversity of Edinburgh,UK email: dr@inf.ed.ac.uk

Abstract

EnterpriseModeling (EM) methodsarerecognisedfor theirvaluein providingamoreorganisedwaytodescribea complex, informal domain. A problemwith EM is that it doesnot alwaysprovide directinput for softwaresystemdevelopment.There is a“gap” betweenEM andsoftwaresystems.Onewayof bridging this gapis to provide a formalisation,herecalled that subsumesa wide variety of coremodeling notationsin asingleusingabusinesspro-cesslanguage.It is possibleto havedifferentviewsof whatis coretosuchalanguagebutourattemptatsuchaview is articulatedin theFundamentalBusi-nessProcessModelingLanguage(FBPML),whichis a merger of IDEF3 andPSL. A workflow lan-guage, the FBPML Workflow Language(FWFL),is constructedandusedto provideadeclarativede-scriptionof a workflow system.FWFL is testedinthe “PC-configuration” domain. We also suggestusinga validationandverification support frame-work to analyseand verify the businessprocessmodel(BPM). Finally, somecomplexity resultsarepresentedfor this typeof modeling.

1 Intr oductionBusinessarebecoming larger andmorediverse, thusoper-ationsare more complex than ever. Although informationtechnology is widely applied in businessoperations,it stilllacks a precisemeansof communicationbetweenbusinessmodel andsoftwaresystemdevelopment. EM methods arewell recognisedfor theirvaluein providing anorganisedwayof describing acomplex, informaldomain,andareoftenusedasa tool for KnowledgeManagement(KM). Therearemanytypesof EM methods suchas businessmodeling methods,processmodeling methods,organisational modelingmethodsandrelatedontology designmethods. However, EM doesnotalwaysprovidedirectinput for softwaresystemdevelopmentwhichleavesagapbetweenenterprisemodelingandsoftwaresystems.

Thispaper triesto bridgethegapbetweenEnterpriseMod-eling (EM) andSoftware Systems. To approachthis,we havecreateda formalisationcalled“FWFL” for all models using

FBPML which providesa declarative descriptionof a work-flow system.A workflow systemmaythenbedesignedandimplementedbasedon “FBPML” and“FWFL”. This wouldplay animportantcommunicationrole in theoperationof anorganisation.

In ordertoverify andanalysetheBPM,athree-level frame-work is alsointroducedasa meansof analysing BPMs andworkflow systems. Finally, the complexity of BPMs andsomecomparisonswith otherrelatedwork arediscussed.

2 Literatu reReviewMany businessprocessmodeling languageshave beenin-ventedfor differentbusinessprocessmodeling needs.In thissection,we will review two typesof processmodelinglan-guageandintroduceathird one– FundamentalBusinessPro-cessModeling Language(FBPML).

2.1 IDEF3 Process Description Capture MethodIDEF3, a processdescription capture method, has two as-pects:capturing processflow andobjectstate. Theprimarygoal of IDEF3 is to provide a well-structured method bywhich a domain expert canexpressknowledgeabouttheop-erationof a particularsystemor organisation[Mayer et al.,1995]. It also capturesthe behavior of an existing or pro-posedsystemby structureddescription. Becauseof its well-structured approach,we canuseIDEF3 asa knowledgeac-quisitiondevice for describingwhata systemdoesor how anorganisationworks.

IDEF3 includes two forms of description: a processflowdescriptionandanobjectstatetransitionnetwork. A processflow description describes “how thingswork” in an organi-sation[Mayeret al., 1995]. It focuseson the processesandtheir temporal, causal,andlogical relations.An object statetransitionnetwork focuseson objects andtheir statechangebehaviors. Thispaperfocusesontheprocessflow descriptionbecauseit is relatedto whatweusein this paper.

An IDEF3 processflow descriptioncapturesa descriptionof processesandtherelationshipsbetweenthem. It providesa graphical andstructural representationthatdomainexpertsandanalystsfrom differentdisciplinescanuseto communi-catewith eachother. This includesknowledge about eventsandobjectsinvolvedin theprocess,andtheconstraining rela-tionswhich determine thebehavior of eachoccurrence(pro-cessandobject).It usesUOB(unitsof behavior), links, junc-

63

tions, referentsandnotesto represent theprocessesandtheirrelationsh� ips (suchastemporal ordering).

2.2 ProcessSpecification LanguagePSLstandsfor ProcessSpecificationLanguage.It is aninter-changelanguagethatallowsapplicationstoexchangediscreteprocessdata[Schlenoff et al., 1997]. It providesa commonlanguagebetweendifferent applicationsandcapturesthenec-essaryprocessinformation from any givenapplication. Thegoalof PSLis to facilitatecommunicationbetweenthoseap-plicationsby usingPSL-basedtranslators. For example,sup-posethereare n different applications, that will communi-catewith eachother. If there is no intermediate languagelike PSL, it requires ������� translators for themto commu-nicate.But with PSLlanguageasastandardizedcommunica-tion medium, thenumberwill reduceto ��� ��� .

PSLprovidesformalspecificationfor semanticsin processmodels due to lacking or inadequate specificationin exist-ing approaches.With PSL, processinformationcanbe ex-changedbetweenavarietyof applications.This formal spec-ification is thePSL “ontology” asit focusesnot only on thetermsof theontology but alsotheirmeanings.

ThePSLontology hasthreenotions:language, modelthe-ory andproof theory. A language is a lexicon (a setof sym-bols) anda grammar (a specificationof how thesesymbolscanbecombined to make well-formed formulas). The lexi-con in PSL is a setof logical symbols (e.g. boolean, quan-tifiers) andnonlogical symbols(i.e. PSL expressions, suchas constants, functions, symbols, andpredicates)[Schlenoffet al., 2000]. In modeltheory, PSL providesa mathemati-cal characterizationof thesemantics,or meaning, of thelan-guage of PSL [Schlenoff et al., 2000]. Proof theoryconsistsof threecomponents: PSLcore, foundational theories, andPSLextensions.

The PSLcore is a setof axiomswritten in the basiclan-guage of PSL. Theseaxioms provide a syntacticrepresen-tation and semanticdescription of the PSL model theory[Schlenoff et al., 2000].

A foundational theoryhassufficient expressive power forgivingprecisedefinitionsof, or axiomatizationsfor, theprim-itiveconcepts of PSL[Schlenoff et al., 2000].

PSLextensionsareexpressionsthatarenot includedin thePSLcore. It providesextra usagefor expressingmorecom-plicatedprocesses.

2.3 Fundamental BusinessProcess ModelingLanguage(FBPML)

FBPML, a visual modeling language, merges IDEF3 andPSL.This language is designedto support bothsoftwareandworkflow systemdevelopment. It offers precisesemanticsandcanexpressbusinessprocessesin logicalsentences.

Therearethreetypesof nodes: Main Node, Junction andAnnotation. Main NodesincludeActivity, Primitive Activ-ity, RoleandTimePoint. Processis themainconcept of pro-cessmodeling languages. In FBPML, asin PSL,anactivityis usedto represent a process.In this document,we will useprocessandactivity interchangeably.

ActivityandPrimitiveActivity: An Activitydescribesatypeof processthatmaybedecomposedinto sub-processes.This

is called “decomposition”. Whenall sub-processesarefin-ished,the high level processis alsofinished. Primitive Ac-tivity is a leaf nodeactivity that may not be further decom-posed. However, theremay be alternative ways of execut-ing a process. Whenonealterative processis not executedand finishedproperly, another alternative processmay col-laborate with thecurrent oneto accomplish thetask.We callthesesub-alternativeprocesses“specialisation”. In FBPML,threemaincomponents of anactivity aretrigger(s), precon-dition(s), andaction(s). An activity alsohasanunique hier-archical position(HP) anda nameto identify it.

TimeandRole: Thedefinitionof Rolein FBPML is useful,an enablermay play a Role that includes a setof activitiesandmayhave responsibilities for theseactivities. TimePointindicatesa particular point in time during theprocessmodel.

Junctions arewidely usedin many processmodelinglan-guages.In FBPML, therearefour differenttypesof junction:Start, Finish, AndandOr. TheStartandFinish junctionsrep-resentthebeginning andendof aBPM. Startis theentryof aBPM. Finish is thepointat whichthemodelstops.

And or Or junctions indicatea one-to-many relationship,andatemporal constraint betweentheactivitiesconnecting tothem[Chen-Burgeretal., 2002]. Bothof thesejunctionshavetwo kinds of interpretation: joint andsplit. They representthedifferent topologiesof a BPM. Figure1 shows thesefourdifferenttypes of topology.

Figure1: And Joint,Or Joint,And Split andOr Split Topol-ogy

And Joint or Or Joint indicatesthat thereis more thanoneprocesspreceding the “And” or “Or” junctionbut thereis only oneprocessfollowing thejunction. 1(a)and(b) showthesekindsof junction. Bothhave threein-comingprocesses(A,B,C) andoneout-going process(D). And Joint indicatesthe processexecution sequence andthe temporal constrainton the process. It meansthat all the processes(A,B,C) onthe left-hand sidemustbe finishedbeforeprocessD canbestarted. If one of the left-hand side processescannot befinished, the entire flow cannot continueto the next stage.Or Joint meansthatwhenat leastoneof the left-hand sideprocessesis finishedthenprocessD canbestarted;it doesnotneedto wait for theotherprocessesto befinished.

And Split or Or Split meansthat only oneprocesswillproceed to the “And” or “OR” junction, but more thanoneprocesswill follow the junction. 1(c) and(d) illustratethis.

64

And Split indicatesthat aslong asthepreceding processisfinished� thenall the following processesbecometemporallyqualifiedandmay alsobe started. It also indicatesthat allthefollowing processesmustbetriggered, but areallowedtobe finishedat somelater time. Or Split meansat leastoneof following processeswill be triggeredandexecuted prop-erly, after thepreceding processis finished.It doesnot haveany constraint abouthow many processeswill be triggered.It maybeone,two or more, dependingon the trigger condi-tionsof thoseprocesses.Theexecutionsequenceof triggeredprocessesmaybeparallelor sequential.

Combination of “ And” and “Or” Junctions: The“OR”and “And” junctions may also be combined to represent amore complicatedBPM. Thereare four different kinds ofcombination. Suppose processA is connectedwith pro-cessesB,C, andD. ProcessE follows processesB,C andDin thesedifferent combination. Thefirst typeof combinationis “And Split” (figure1 (c)) and“And Joint” (figure 1 (a)). ItmeansthatwhenprocessA is finishedthenprocessB,C andD will beandmustbestarted.After all theprocessesB,C andD arefinished1, thenprocessE canstart. It hasthestrictestrestrictionin a BPM. Thecombinationof “Or Split” (figure1 (d)) and“Or Joint” (figure1 (b)) meansthat afterprocessA is finished,at leastoneof theprocessesB, C andD will bestartedandexecuted.ProcessE will notbestartedunlessoneof thetriggeredprocessesis finished.It is a looserconstraintthanan“And Split” and“And Joint” junction.

The combination of “And Split” (figure 1 (c)) and“Or Joint”(figure 1 (b)) meansthat when process A is fin-ished,all the processesB,C andD mustbe startedandexe-cuted.If processB, C or D is finished,thenprocessE canbestarted.It is differentfrom an“And-And” junction in thatthe“Or Split” (figure 1 (d)) and“And Joint” (figure1 (a)) junc-tion indicatesthatat leastoneof theprocessesB,CandD willbe startedandexecuted after processA is finished. ProcessE will not bestartedunless“all of thetriggeredprocesses” 2

arefinished. The triggeredprocessesmaybea combinationof someof them.Becauseof the“Or Split” junction, it doesnot needto trigger all the preceding processes.It thushasmoreflexibility thanthe“And Split” junction.

Annotations include IdeaNoteandNavigationNote. IdeaNoterecordsinformationwhichis relatedto theprocessesbutnot part of the processmodel. Navigation Note records therelationships betweendiagramsin a model [Chen-Burger etal., 2002]. Neitherof themcontributeto theformal semanticsof theprocessmodel. Instead,they areusedto helpuserstounderstandtheprocessesmoreclearlyfrom anintuitivepointof view.

Nodes(MainNodesandJunctions)areconnectedby links.Two typesof links areprovided: theprecedence-linkandthesynchronisation-bar. A precedence-link indicatesa temporalconstraint betweentwo processes.It meansthat activity Bcannot startuntil activity A hasfinished. A synchronisation-bar also places a temporal constraint betweentwo time

1Thereis no restrictionabout the executionsequence of thesethreeprocesses.

2Theseindicatethat the pre-processesof the “And Joint” junc-tion which aretriggered.

ITEM IDEF3 PSL FBPML

Property Processmodelinglanguage

Interchangelanguage be-tween differentmanufacturingapplications

Business mod-eling languageespecially sup-portssoftwareandworkflow systemdevelopment

Notation Rich GraphicNo-tation

OntologyandFor-mal Semantics

Simpler versionNotation butsemantics arepresented

BasicProcessDescription

UOB (Unit of Be-havior)

Activity,Primitive-Activity

Activity,Primitive-Activity

Distinguishtermsbetweenprocess,activity andtask

� � �

Linkbetweenprocesses

PrecedenceLinks withDif ferent typesofConstraints

Ordering Re-lation overActivities(ext)

Precedence-Link,Synchronisation-Bar

Junction AND, OR,XOR AND, OR, XORJunction(core)Junction(ext)

�(not the same

asPSLandIDEF3but is anextensionand refinementofboth)

Time Not in thenotation but maybe expressedinformally

Duration(ext),Temporal Order-ing Relation(ext)

Time point, dura-tion, length

Role� � �

Annotation ReferentandNote�

Idea Note andNavigationNote

Decomposition A processmay bedecomposedintosub-processes

SubActivity(ext) A processmay bedecomposedintosub-processes

Specialisation� � �

ExecutionLogic

� � �

Table1: ComparisonBetweenIDEF3,PSLandFBPML�– Yes�– No/Not applied

core– PSLcoreconceptext – PSLextensionconcept

points. This notationenablesany time points to be madeequivalentandthereforeenablesprocessoperationstobesyn-chronised.

2.4 ComparisonbetweenIDEF3, PSL and FBPML

After briefly reviewing theIDEF3,PSLandFBPML, wewillfocusontheirsimilaritiesanddifferences.Table1 summariesthis brief comparison.

Similarities: IDEF3, PSL andFBPML all focus on pro-cessexpressiontechniquesto provide a standard methodol-ogywhendescribing a process.Thesethreebusinessprocessrepresentationsallow domainexperts to expressknowledgeabout how a systemworks,andcanprovide a common lan-guage betweendifferent applications.

Differ ences: Although IDEF3,PSLandFBPML arecon-ceptuallysimilar, in table1 we lists themajordifferencesbe-tweenthem. IDEF3 provides a graphical way to represent

65

processes,allowing the logic of processesto be more easilyrepresen� ted. Although IDEF3 hasthis advantage;it lacksanunambiguous semanticdescriptionfor its notation. By con-trast,PSLhasa well-definedontology andformal semanticsbut lacksgraphical notations. Userscannot easilydefinepro-cessesin this languagewithoutproper trainingin logical lan-guages.FBPML combinesaspectsof bothIDEF3andPSLtoobtaintheadvantagesof their differentaspects.It providesasimplerandmorepragmatic modeling language suitableforworkflow systemdesign.

3 Devising a logic-basedWorkflow Languagefor FBPML

FBPML is a visualandconceptual language.It capturesanddescribesthebusinessprocessesof anorganisation.Besidesdescribing a model,it alsoallows BPMs to be analysed, re-designedandchecked. Through FBPML, the tasksandop-erationof anorganisationcanbemoreeasilyunderstood.Inordertoprovidethepropertiesdescribedabove,FBPMLhasadeclarative reading (understoodindependentlyof any partic-ularcomputationalprocedure) aswell asanoperational read-ing whencombined with a particularcomputational proce-dure.TheseareexactlytheprinciplesthatFBPML embodies.

While FBPML givespreciseexecution logic for processes,it allowsmultipleversionsof implementationof theworkflowengine. This is becausetheFBPML specifieshow processesshouldbeenactedbut doesnot specifytheworkflow enginethat enactsthoseprocesses. In this section,we have con-structeda workflow language“FWFL” (the FBPML Work-Flow Language) basedon FBPML. In section5, oneversionof theworkflow enginewill beintroducedbasedon“FWFL” .Thedefinitions of FWFL will be introducedin thefollowingsection.

3.1 FBPML WorkFlow Language(FWFL) DesignProcess: The predicatedefinesa process.It hassix param-eters:ProcessId, ProcessName, Pstate, TrigCond, PreCondandAction.������������� �"!#������������$&%(')!#������������*,+&-,� '.!�0/�+�/�� '012� 354&67��89%('.!#� ��6��89%(': �./ 3;��89<ProcessIddefinestheID of aprocess.It mustbeuniqueto allprocessesin the BPM. ProcessNamedescribesthe nameofa process.It does not have any impacton theexecution, butis usedonly for humaninterpretation. It’s purposeis to helpthe userunderstandwhat the processis. Pstaterecordsthestatusof a process.Therearetwo typesof statusin a process– “Triggered” and“Completed”. “Triggered”meansthat theprocessis already triggeredandis temporally qualifiedto beexecuted. “Completed” meansthat the processhasalreadybeenexecutedproperly, i.e. it is already finished. TrigConddefinesthetriggercondition(s)for theprocess.It is composedof a triggeredeventor valuesabout astate,e.g.attributesandtheirvaluesof anentity. PreConddefinesthepre-condition(s)for theprocess.It is composedof attributesandtheir valuesof an entity that a processmanipulates3. A simpleexample

3It also hasa condition – delay time which describesa delaycondition.

will be usedto illustrate this later. A usercan understandwhattheprocesslookslike simplyby reading through its de-scription. Example 1 shows thatprocess“a” needsaneventto triggertheprocess.Thecontent of this triggereventcanbereadsimply through thedescription.

Actions For Processes: In FWFL, eight differ-ent types of action are provided. They are cre-ate entity, get newValue from usr, get uptValue from usr,add attribute, deleteattribute, update attribute, re-fer attribute of entityanddeleteentity.

The actioncreateentity createsa new entity and adds itinto theentitydatabase.To carryoutthisaction– theattributeandits valuefor thatentityareneededatexecution time. Theactionget newValue from usr getsa value from the useratrun time, asa workflow systemmay have interactions withothersystemsaswell aswith the user. This actionprovidesaninterfacethroughwhichaworkflow systemcanobtainnewdatafrom a user. The actionget uptValue from usr is simi-lar to get newValue from usr. The only differenceis that itgetsanupdatedvalueto updateanexistingattribute.Theac-tions add attribute, deleteattribute or update attribute add,deleteor updateattributesin an existing entity. The actionrefer attribute of entityrefersto thevalueof anattributepro-vided by another entity. The actiondeleteentity deletesanexisting entity. Sometimesthe actionsbeingcarriedout byoneprocessmayconflictwith anotherprocess.Theworkflowsystemneedsto dealwith thissituationandprovideappropri-atewarning messages.Example 1:process(a, receiveCustomerReq, Pstate,

[exist(event_occ(EventId,custom_req_for_pc_spec,created,attribute(Attr)))],

[true],[create_entity(attribute(Attr))]).

Instance: A processinstanceis anactualrunning processat execution time. A process(type) mayhave more thanoneinstancedependingonthenumberof events.Thedefinitionofaninstanceis inherited from process,suchasTrigCond, Pre-CondandAction. Theonly differencebetweenaprocessandaninstanceis thatprocess’variablesProcessId, ProcessNameandPstateareusedinsteadof InstanceId, InstanceNameandIstate, but thedefinitionsof theseparametersarethesame.Inaddition, an instancehasa parameter– BeginT/EndT that isdifferentfromprocess.It recordsthestartandendtimeof thatinstance.As weknow, aninstanceis theactualexecutedpro-cess,therefore,its variablesareinstantiatedat run time. Theworkflow systemneeds to recordthis informationandcarryoutsomechecking atexecution time. A predicate–“instance”is therefore:3=89�0/�+&8>��� �"$�89�0/�+&8>����$&%('.$�89�0/�+&8>����*,+&-,� '.$&�0/�+�/���'.1?��3"4&6��89%(')!#����6��89%(': �./ 3;��8@')A7��4�3=8B1DC E89%�12<

Attrib ute: Attributesareusedeverywherein FWFL suchas “TrigCond”, “PreCond”, “Action”, “entity” and“event”.Attributesaredefinedin predicate:+�/F/ ��3;G.HI/�� �"E�8B/ 35/ JK*,+&-,�#L : /F/ � 3=G.HI/���*,+&-,��C : /F/ � 3=G.HI/���MN+�O5HP��<

This meansthat the attribute,AttributeNamebelongs to aparticular entity, EntityName. Its valuewill beassignedatex-ecutiontime. For example, “customer-name/NameV”meanstheentity “customer” hasanattribute“name”. Thevaluehasnotbeenassignedyet.

66

FWFL alsoallowstwo otherdifferent kindsof attributestobeused.Q Thesetwo attributedefinitionsareslightly differentfrom thepreviousone.Thefirst typeis themultiple-valueat-tribute. For example, “ioBoard-capability/(normal-graphics-long)” meansthattheentity“ioBoard” hasanattribute“capa-bility”, and“capability” hasmultiple valueswhich are“nor-mal”, “graphics” and “long”. Thesethree values appearat the sametime in the attribute “capability”. The secondtype is the alternative-value attribute. For example, “box-color/[white,silver,black]” meansthattheentity “box” hasanattribute“color”. Thevaluesof colorareonly oneof “white”,“silver” or “black”.

Attrib ute Domain and Attrib ute Value: Thedomain ofanattribute is definedby+�/F/ %&��-,+&3=8R�"6�O"+K��� ' : /F/ ��3;G.HI/���*,+&-,� '.SN��-,+&3=8B<Theattribute,AttributeName, indicatesthat“AttributeName”is anattributefor instancesin a class,“Class”. Thefield Do-main defines the domainof valuesfor the attribute. For in-stance, TVU�U W>X�YZTV[.�\�5]D^PXP_K`Pa�aIX�^Pb�U�c�]2`Vb(d U&e9b�U�f@b�U�ghb�U�i9jF� meansthatClass“processor”hasanAttributeName“type”, anditsdomain is “t1”,”t2”,”t3” or “t4”. AttributeValueis definedby+�/F/ kK+�O5HP� �"6�O"+K��� ' : /F/ � 3=G.HI/���*,+&-,� '�M�+�O"H���<It means“AttributeName”belongs to class “Class”. Thevalue of this AttributeName is “Value”. For example,TVU�U lVTRm�n?`R��_Knoa(U�X�YZ`(^Pb X�^PW>`I^PpqXRb�lRTRm no`R��eI��� meansthatClass“customer” hasanAttributeName“orderNo’, andits valueis“1”.

Entity: An entityrepresentsaclassin theworld. It definesthepropertiesof anentity.Thepredicateis:��8B/ 35/ J��=E�8P/ 3"/ JK*,+&-,� '�E�8P/ 3"/ JK$&%(')E�8B/ 35/ J�r>/�+�/���'.E�8B/ 35/ J : /F/ � 3;G)HI/���<The EntityNameis the name of the entity. The EntityId istheID of theentity. Thesameentity typewill have thesameentitynamebut differentIDs. Thus,theID is unique. TheEn-tityStaterecords thestateof theentity. Therearetwo typesofthestate:“valid” and“invalid”. Theentity is “valid” whenitis created; it is “invalid” whenit is deletedor after it reachesa particular time point. The EntityAttribute containsthe at-tributesand their values for that entity. At execution time,everyoccurrenceof this entity mustbebound by theseprop-erties.An entityoccurrenceis definedas��8B/ 35/ J �������=E�8P/ 3"/ JK*,+&-,� ')E8P/ 35/ J�$�%('.E�8P/ 3"/ J�r>/�+�/�� '0E�8P/ 3"/ J : /F/ � 3=G.HI/���<which is inherited from theentitydefinition.

Event: An eventdefinesthepropertiesof atriggered event.It is representedas��kK��8P/0�"E�kK��8P/ $&%('0EkK��8P/ 1?J �(� '.EkK��8P/ stO"+&4('�E�kK��8P/ : /F/ ��3;G.HI/�� '01?3=-u��<TheEventIdindicatesthe ID of an event. The EventType isthe type of an event. The EventFlag records the stateof anevent 4. TheEventAttributecontains theattributesandtheirvaluesfor the event. Time records the trigger time for thisevent. The event predicatedefines the properties that areneededin an event. In the sameway, the event datais rep-resentedasanevent occurrence.An event mayhavedifferentoccurrences.We use��kK��8P/ � �����"E�kK��8P/ $&%(')E�kK��8B/ 12J �(� '0E�kK��8B/ stO"+�4I'�E�kK��8P/ : /F/ � 3;G)HI/�� '�1?3"-,��<

4Two flags– “new” and“created”aredefinedin FWFL.

to expressit.Junctionsand Models: Thepredicatev H�89���=w�� %&�0O5$&%('0x9H�89�./ 3=��8B1?J �(� '.!�� ��!�� � ����������� '0!���0/ !�� � ������������<

is usedto representa junction. For example, if we wantto represent a junction Or Split which is connectedwith“b” and“c,d,e,f” for Model “m1”, we canrepresentedis asy n2�#_9� Yze9b�X�^ a�]2m�[0U&b(d { j.bId _Bb�W2b�`Vb |2j �4 Validation and Verification Support

Framework for BusinessProcessModelingIn this research,a three-level framework is providedto anal-yse the BPM. The framework includes“model behavior”,“detailedmodel testing” and“ instantiation of businesssce-nario – casestudy.” This framework is intended to giveusersa more systematicstructure when analysinga BPM. Theframework first addressestheprocessflow control issuesandthenfocusesonthedetailedprocessanalysis.Theanalysisofthis framework mayalsobedividedinto two categories:syn-tactic andsemantic[SadiqandOrlowska,1996]. Theinvaliduseof abusinessprocessmodeling languageresultsin syntac-tic errors. Semanticerrors occurdueto incorrect modelingof businessprocessesor gettinginto erroneoussituationsbe-causeof unanticipatedcombinationsof taskexecution [SadiqandOrlowska, 1996]. Basedon thesetwo typesof error, wedefineour two typesof critiqueassyntacticcritique andse-manticcritique. We verify themandgiveadvicein thethree-level framework.

Figure 2 demonstratesour three-level framework andshows the relationships betweenlevel 1, 2 and3. Level 1considers the overall model behavior to find the appropriatetopology for theBPM andcarriesout thesyntacticcritiques.Level 2 capturesthe topology featuresfrom level 1, carriesout the semanticcritiquesandeliminatesimpossibleexecu-tion sequences. Level 3 executes the BPM using businessscenarios(entity data)in a particular domain and attemptsto validatethemodel. Becausetheexaminedproblem spacefor possibleexecutionpathsis reducedby eachlevel asmoreinformationis presentedby themodel,we presentour three-level approachin a three-layeredoval graph. The detaileddescriptionswill beintroducedin thefollowing sections.

Model Behavior (syntactic critique)

Detailed Model Testing

(semantic critique)

Instantiation of Business Scenario

-- Case Study

Figure2: OverallFramework for BusinessProcessModeling

4.1 Model Behavior LevelSyntactic critiquesarechecked at the modelbehavior level.The typesof syntacticcritiques are shown in tables2 and3. This includestwo parts–syntacticerrors and syntacticwarnings. “Model behavior” is alsoexamined at this level.Themodel behavior indicatesall thepossibleactionsthatthe

64

ErrorTypes Type ofjunction

Errorandexplanation

Junctionlogical error And Joint morethanoneoutgoingnode

Or Joint morethanoneoutgoingnode

And Split only oneoutgoingnode

Or Split only oneoutgoingnode

Start& Link morethanoneoutgoingnode

Table2: SyntacticErrors

WarningTypes Explanation

Connectingwarning Thelink doesnot connectproperly

Redundancy warning More thanoneof thesamenodeconnectedtogether

Table3: SyntacticWarnings

model maycarryout. Thefirst level in this framework gener-atesthiskind of model behavior. At this level, all thepossibletriggeredresultsandtheresultingexecutionsequencesarede-termined. Theusersmayknow all of possiblebehaviorsof theBPM usingthis facility. This facility is usefulin understand-ing thebehavior of a similarly complicatedmodel. Throughthis simplebehavior enumeration,theusermayhavea roughideaabout whatkindsof flow maybeexecuted. Particularly,theusermayknow thestateenumerationandall possibleex-ecutionsequences.Although the BPM that we dealwith iswritten in FBPML, this approachis genericto otherbusinessprocessmodeling languages.

4.2 Detailed Model TestingLevelThemainpurposeof level 2 – detailedmodeltesting– is toprovide semanticcritiquesfor theBPM suchasreachabilityanalysis5, potential deadlocks and irr elevant nodes. As forsyntacticcritiques,it maybedividedinto semanticerrorsandsemanticwarnings. Table4 and5 summariesthesecritiques.

This detailed testing mechanismconsiders the logicalmeaning of the junctions, preconditions and actions of theprocessestogether to verify thesemanticsof a BPM. It alsofiguresout thepossibleexecutionresultsof theBPM.

At this level, notonly thelogicalmeaningof thejunctions,but also the detailedpreconditions and actionsof the pro-cessesareconsidered. Neither level 1 nor level 2 considertrigger conditions, becauseall possibletriggered resultsare

5“Reachability analysis”is usedto describethe constructionofa state-transitionmodelof a systemfrom modelsof individual pro-cesses[YehandYoung,1991]

ErrorTypes Explanation

Unreachabilityerror Thepreconditionof theprocesscannever besatis-fied,andtheprocesswill neverbeexecuted.

Deadlockerror A process(A)waitsfor anotherprocess(B)andpro-cess(B)waitsfor process(A)at thesametime.

Terminationproblem Determining whether a workflow structure canreachaterminatingstate[terHofstedeetal., 1996].

Table4: SemanticErrors

WarningTypes Explanation

Irrelevancewarning A processthatdoesnot useoutputsfrom any otherprocessesand doesnot produceinputs for otherprocessesto use.

Table5: SemanticWarnings

listed at thesetwo levels. The analysisof level 2 is basedon the resultsfrom level 1. Theanalysisof level 1 enumer-atesall possibleresultsof theBPM. Somedetailedcheckingareaddedat level 2 to eliminateall impossibleexecutionse-quenceswhile keeping all possibleones. A termination prob-lemmayalsobedetectedat this level.

4.3 Instantiati on of BusinessScenarioLevel

At level 3, instantiation of businessscenario– casestudy, theentity datais instantiatedto a BPM. At this level, a usersce-nario adapted from AKT project6 in the “PC configuration”domain hasbeenusedto testtheseideas.TheBPM is shownin figure3. It is differentfrom level 1 andlevel 2 in thatlevel1 and2 focuson overall businessprocessmodelsimulation,whereaslevel 3 focuseson a specialcasestudy. At level 3,a workflow systemis executedandmay createinstancesofprocessesat run time which dependon thegiveninput data.Thefinal flow is determineddueto theattributesof this data.At this level, conflictingactionsarealsocheckedandaresig-naledby warningmessages.

A workflow systemdirectly mappedto FWFL is imple-mentedat this level. A BPM describedin FBPML is usedatthis level, andmaybecheckedandrun in this workflow sys-tem.Thedetailedsystemarchitectureandimplementationarediscussedin section5. The three-level framework becomescomplete becausemodel behavior is testedandsomemodelchecking is provided in level 1 and2, anda caseis usedtoanalysetheBPM at level 3.

start autoCreateOrderNumber

b

Or And

determineProcessor

c

determineIoBoard

d

determineDiskController

e

specReqforbox

f

specReqforcase

g

examPCspecification

h

End receiveCustomerReq

a

Figure3: BPM adaptedfrom AKT Project

6Advanced KnowledgeTechnologies (AKT) Projectis an IRC(InterdisclipinedResearchCouncil)project. This projectis usedtodevelopandintegraterelevantAI techniques in thelargerprocessofknowledge management. Variouspublic web sitesareavailableat:http://www.aktors.org/

68

CaseStudyThe caseused in this researchis adapted from the AKTproject [Chen-Burger, 2002a] in the “PC configuration” do-main asshown in figure 3. A BPM andan entity databaseare needed for this workflow engine7. The BPM is com-posedof aProcessSpecification, aJunctionSpecificationandan Entity Specification. Definitionsof processesarestoredin the ProcessSpecification. It is written in FWFL whichprovides direct input to the workflow engine. If a BPM ischanged, the definitions of the processeswritten in FWFLchange correspondingly. Thepurposeof Junction Specifica-tion is to record the logical connections of the BPM. EntitySpecificationstoresthe definitionsof the entitiesandevents(i.e. theeventoccurrencesandentity occurrencesarestoredin theentity database). Becausetheuserneedsto determinehow many stepsthat theflow needsto run, theflow canstopat astepwhich is stipulatedby theuser.

Example 1 in section3.1 illustratesa part of the ProcessSpecification. JunctionSpecification is shown in example 2.Example 2:junc(m1,start,[],[a]).junc(m1,link,[a],[b]).junc(m1,or_split,[b],[c,d,e,f,g]).junc(m1,and_joint,[c,d,e,f,g],[h]).junc(m1,link,[g],[h]).junc(m1,end,[h],[]).

Example 3 illustratesapartof theEntitySpecification.Example 3:event_occ(e1,

custom_req_for_pc_spec,new,attribute([entity-id/’e1’,

customer-name/’John’,customer-doB/’13-06-70’,customer-gender/male,customer-tel/’0131-5563432’,

spec([box-color/white,ioBoard-length/short,ioBoard-capability/(fast-_A-_B)])]),1).

entity_occ(ioBoard,io1,valid,attribute([ioBoard-type/io1,ioBoard-slot/3,ioBoard-length/short,ioBoard-capability/(fast-graphics-short)])).

The BPM in example 3 describesa processflow for “PC-configuration for the customer”as shown in figure 3. Thetriggerconditionsof processc, d, ande are“true” (i.e. theymay be triggered automatically), so they must be triggeredwhentheflow is running. Theusercaneasilyunderstandtheprocessbecausea PCmustconsistof thesethreeparts.Pro-cesses“f” and“g” aredifferent. They aretriggeredonly if thecustomerhasa specialrequirement.TheOr Split junction isusedhere. It indicatesthat not all following processesneedbe triggered. The And Joint is usedin the next junction. Itindicatesthat all the triggered processesmustbe finishedatsometime(i.e. theworkflow mustfind asolutionfor thecus-tomer). The testingresultabouta caseis shown in example4.Example 4:Model: Model1customer: (Mary, John)

SpecialRequirements : John’sspecialrequirementis satis-fied,Mary’s is notsatisfied.

John’s specialrequirementis:sepc([box-color/white,ioBoard-length/short,

ioBoard-capability/(fast-_-_)])

7We constructa BPM here,but FBPML may also be usedtoconstructamanufactory processmodel.

Display

Process Specification

Business ProcessModel

Junction Specification

Entity Specification

FWFL FBPML

ProcessAgenda Execution Queue

Workflow Engine } Entity

Database

Figure4: SystemArchitecture of the FWFL Workflow En-gine

Mary’s specialrequirementis:sepc([case-type/c1,box-color/black])

TheExecution Sequence:a1-i-(e1-John),a1-i-(e2-Mary),b1-i-(e1-John),b1-i-(e2-Mary),f1-i-(e1-John),e1-i-(e1-John),d1-i-(e1-John),c1-i-(e1-John),g1-i-(e2-Mary),e1-i-(e2-Mary),d1-i-(e2-Mary),c1-i-(e2-Mary),h1-i-(e1-John)

TheExecution Result:The process f1-i-e2-Mary cannot be executed.The reason may be the precondition cannot besatisfied or the action has errors!The requirement of customer --Mary cannot be satisfiedThe solution for customer --John is [customer-orderNo/1,box-color/white,

diskController-type/dc1,ioBoard-type/io1,processor-type/p3]

The flow is finishedat step10. We find that John’s specialrequirementsinclude “case”, so processesc, d, e and f aretriggeredandfinished.On theotherhand, Mary’s specialre-quirementsinclude“case”and“box”, soprocessesc, d, e, fandg are triggered. But asMary’s specialrequirement forbox-color/black cannot be found in the entity database,thesolutioncannot beprovidedto Mary. Theflow stopsat step“10” in example 4 becausethetermination“step” definedbytheuseris “10”.

5 FWFL Workflow Engine5.1 SystemAr chitectur eThe systemarchitecture of the FWFL workflow engineisshown in figure 4. A BPM andanentitydatabaseareneededfor thisworkflow engine. TheBPM is composedof aProcessSpecification, a Junction Specification andan Entity Speci-fication8. The definitions of the processesarestoredin theProcessSpecification. It is written in FWFL which providesdirect input to theworkflow engine.If theBPM is changed,thedefinitions of theprocesseswritten in FWFL is changedcorrespondingly. Becauseof thedirectmapping, it doesnotrequire mucheffort to dealwith thesechanges.Thepurposeof theJunction Specification is to recordthe logical connec-tionsof theBPM; it alsofollowstheFWFL.TheEntitySpeci-ficationstoresthedefinitionsof theentitiesandevents. Eventoccurrencesand entity occurrencesare storedin the entitydatabase.

8An entity is a datastoredin theentity database.

69

Theuserneedsto determine how many stepsthattheflowneeds~ to run. Theflow maystopat a stepwhich is stipulatedby theuser. After acceptingtheinput data,theworkflow en-ginestartsrunning the processesbasedon the definitions oftheprocessesandtheBPM. It checksthetriggeredeventsfirstandtriggersall theprocesseswhosetriggerconditionsaresat-isfied.Thelogicalmeaningsof thejunctions directtheflow.

Whenprocessesaretriggered, instancesof thoseprocessesarecreatedandexecuted. In eachtick9, all the possiblein-stancesarerun within thegiven time until they arefinished.Sometimessomeinstancesmaynot beexecutedandfinishedin thecurrent tick; theworkflow enginekeepsthemuntil thenext tick. The enginerechecks all remaining instancesandrunsthemagainin thenext tick. This procedureloopsuntiltheflow reachesthestepdefinedby theuserat thebeginningor until it reachesthe“END” of theBPM. Thetimeandflowstateareupdatedin eachtick, thustheusercanknow thetimepointandflow statein eachstep.

BPM 2002Market MilestoneReport[Group, 2002] clas-sifies workflow processesinto threecategories “process-to-process”, “person-to-process”, and“person-to-person”. TheFWFL workflow engineimplemented in this researchcap-tures formal descriptions of the processesand provides astructured methodto capture the businessprocess. In addi-tion to handling “person-to-person”or “process-to-process”workflow processes,it alsoprovidesinteraction betweentheuser and the workflow system. As well it can deal with“person-to-process”workflow processesbecauseit hassomeexception handling so the usercan choose when he/sheisasked for input datafrom outsidethe workflow system. Inmostsituations,however, theworkflow still worksautomati-cally.

Therearetwo typesof interaction in theFWFL workflowsystemthatdealwith the“person-to-process”workflow pro-cess.First, theworkflow engine asksfor new values(or up-datedvalues)from the user. In this case,the flow may stopandwait for input from the user. Second,the workflow en-ginemayalsodetectconflictingactionswhich happen whendifferentinstancestry to dealwith thesameentitydatasimul-taneously. Warningmessagesareprovide to theuser, andthesystemasksfor adecision.

Figure5 shows the flowchartof the FWFL workflow en-ginewhich is implementedandbasedonthisworkflow meta-interpreter. Table6 showsthesummaryof thepredicatesusedin theworkflow system(meta-interpreter).

5.2 StateTransiti on and Dynamic BehaviorsOnce a workflow is implemented, we need to monitorits progress. We can do this by checking the statusofa workflow [Georgakopoulos et al., 1995]. The FWFLworkflow systemrecords the flow stateusing the predicate|om�X�� a�U�TVU�`R����a(U�TVU�`Vb���� whichindicatestheflow stateattimeT. Figure6 shows an example of the statetransitionof theworkflow system.

In figure6, supposewehaveasimpleBPM:

9A tick indicatesa time point. It is a counterin the workflowsystem(i.e. after all the possibleprocessesareexecutedproperly,thetick increasesby one.)

check_event

WorkFlow Engine �

do_junction_process all_triggered_completed

create_instance

execute_process

update_time �update_step

Entity �

Database

(Reach the end of all process model and ProcessAgenda=[ ] )

or (Step ='usr_defined')

Junction Specification

Step

Process Specification

Yes

END

Entity Database

t = t +1

Step = Step +1

Entity Specification

Business Process Model

No

Figure5: Flowchart of theFWFL Workflow Engine

PredicateName Purpose

executeflow Controlthewholeprocessflow

checkevent Checkthenew event

do junction process Executethejunctionsof theBPM

executeprocess Executetheinstancesof theprocesses

updatetime Updatethetime point

updatestep Updatethestepcounter

flow state Indicatetheflow stateat time T

checkmstate Checkthemodelstate

Table 6: Main Predicatesof the FWFL Workflow Meta-Interpreter

junk(m1,start,[],[a]).junk(m1,link,[a],[b]).junk(m1,end,[b],[]).

andtwo trigger eventsat timepoint t1. Whatwill bethestatetransition?In this case,the initial stateis “flow state([],t0)”.The model stateindicatesthe instancesof the BPM for alltriggerevents. At theinitial time,no trigger event occurs, sono instancesof theBPM arecreated. Theinitial model stateis “[]”. Whentwo events– “customer-John”and“customer-Mary” aretriggered,two instancesof themodelarecreated:

[start/john/[]/[a],link/john/[a]/[b]],[start/mary/[]/[a],link/mary/[a]/[b]] 10

After the instancesof the model arecreated, the flow startsto run. Theinstancesof thefirst processfor eachmodel mayalsobecreatedandexecutedaslong asthepreconditions aresatisfied. In this example, the precondition of processin-stance– “customer-John” is satisfiedbut theprecondition ofprocessinstance– “customer-Mary” is not satisfied.Perhapsthis is becausetherequired input datais not availableimme-diately. Theinstanceof theprocess– “customer-Mary” is leftin theexecution queueandwaitsfor data.Thesekinds of in-stancearerun againat a later time point. Thewholeprocess

10Themodelinstanceof customer-Mary andcustomer-John.

70

Time:t0 �State :s0

Time:t1 �State:s1

Time:t2 �State:s2

END �

New event : john, mary �

No new event �

Step : 0 �ModelState = [ ] flow_state([ ], t0) �

Step : 1 �ModelState = [[link/john/[a]/[b]], [link/mary/[a]/[b]]] �ProcessAgenda=[a-i-e2-mary] flow_state([a-i-e1-john], t1) �

Figure 6: StateTransitionof theFWFL Workflow Engine

flow of “customer-Mary” maystayat this stageuntil this in-stanceis finished.On theotherhand,theinstanceof thefirstprocess– “customer-John”– is executedandfinishedat timepoint t1 (Tick 1). Theinstancesof theBPM changeto

[link/john/[a]/[b]],[lin k/mary/[a]/[b]]

Theflow staterecordstheexecuted result– [[a1-i-(e1-john)],t1], andthe processagenda storesthe remaining instance–[a1-i-(e2-mary)] which maybeexecutedlater. Thedatacre-atedhavebeensavedin theentitydatabase,andthatdatamayalsobe modifiedor removed later. The flow continuesrun-ning,andtheflow statechangesat eachstageuntil it reachestheendof theflow. Therearetwo waysto reachtheendof theprocessflow. First, when“ModelState”is anemptylist andthe“processagenda” is alsoanemptylist, it indicatesthatthewholebusinessprocesshasexecutedcompletely. Second, theflow reachesastepdefinedby theuser. In thiscase,thewholebusinessprocessmayor maynotbefinished.

5.3 Validation and Verification to WorkflowSystem

Errorsandwarnings mayhappenin two situations:First, twoor moreinstancestry to dealwith thesameentity data.Sec-ond, someinstancesmay be left in the execution queuefortoo long. This delaytime duration is defined by theuserus-ing the predicate“delay time duration(Time)”. Table7 andtable8 containdetaileddescriptions of this.

ErrorTypes Description

TypeI Two or more different instancesadd,deleteor updatethe sameentity dataatthesametime.

TypeII Oneor moreinstancesreferto entitydataandotherstry to add,deleteor updateit.

Table7: Error Typesof theFWFL Workflow Engine

WarningType Description

TypeI An instancemay not be executedfor along time.

Table8: WarningTypeof theFWFL Workflow Engine

Whentheworkflow engineencountersthesecases,theflowstops,a messageis displayedandthesystemwaits for a re-

sponsefrom the user. Example 1 shows the messagefor atype I warning. It shows that the instanceof processb-i-id(e1-John,e1-John)is alreadydelayed for morethann- ticks(time). The systemwill show the warning messageto askwhetherthisdelayed instanceof theprocessshouldbekeptordeleted.Theuserthenmakesa decisiontakinginto accountthe impactof the decision. Seriousproblemsmay occur inthis case.Theflow maynotbeableto continue.Example 1:There is a delay in Process=> b-i-id(e1-John,e1-John)Do you want to continue?(y/n)y.Continue.....Keep Process=>b-i-id(e1-John,e1-John)There is a delay in Process=> b-i-id(e1-John,e1-John)Do you want to continue?(y/n)n.delete current process.....

6 Complexity of BusinessProcessModelsThecomplexity of theBPM is discussedin this section.Thecomplexity we calculatehereis thecomplexity of theverifi-cationof the program usingsimulation/world statesteppingtechniques. The result shows that this program will be inpracticeneedto carryout anexhaustive searchto execute ofall thepossiblepermutationenactments of abusinessprocessmodel andfind if thereis any inconsistency. It alsoleadstoa conclusion that“Or split” junctionsmake a processmodelsubstantiallymorecomplicatedas it allows rapid growth ofdifferent dynamic behaviours. In the following paragraphswe will show how we calculatethe complexity of this pro-gram.

6.1 Complexity of a SingleModelIn this section,we will calculatethe complexity of a singlemodel. Definitionof thevariablesusedin thefollowing com-plexity analysisare:� n: The number of branches from an And- or Or-Split

junction.� m: Whentwo models (suchasfigure1 (a)+(d), (a)+(c),(b)+(c), (b)+(d)) are connected, n is the number ofbranchesfrom the first modelandm is the number ofbranchesfrom thesecondmodel.

An “Or-Or” model is usedto illustratehow to compute thecomplexity. Supposean“Or split” junctionhasn branches.Itis possiblethatall n branches,or only n-1branches,arebeingtriggered.In total,thereare �������,��eI����� �,��f>����(���\��edifferent possibletriggeredresults. For eachtriggeredpro-cessset,theexecution sequencemayalsodiffer. Thepossiblepermutationsof theseprocessesshouldbe considered at thesametime.The possibleexecution sequences of the “Or-Or” model aretherefore:� �=��+����o�(� ����3;G�O=�h/ � 354�4K������%t������HIO�/ �+�O5O��(����-uHI/�+�/ 3;��8>�D� �#/��������h/ ��3"4�4K��� ��%2��� � ������������<Thesecondtermin theproductcomesfrom:� �5/����R8BH�-,G0���t����/����h�I3"8B3;������%D�����������������DG0������� �/����R��������89% v H�89�./ 3;��8 � ������-uHI/�+�/ 3;��8�� �o/��������9��� � ����������� ��(��� -uH(/�+&/ 3=��8�� �#/���� ���@����-,+&3=8B3"8B4?�K��� ������������<Basedon the result computed by “Mathematica”. We findthatwhen“n=10”, thevalueof formula 1 is �9��� eI¡t¢ whichis a very big number. The complexity of this kind of BPMis high andhasa factorialrateof growth [Bard,2001]. It is

71

Businessprocessmodeltypes Complexity

“And Split” and“And Joint” model(“And-And” modelinfigure1 (a)+(c))

£ �"8V¤ <“And Split” and“Or Joint” model(“And-Or” modelinfigure1 (a)+(d))

£ �"8,¥�8>¤ <“Or split” and“And Joint” model(“Or-And” modelinfigure1 (b)+(c) ) ¦

£ �"8V¤ <“Or split” and“Or Joint” model(“Or-Or” modelin figure1(b)+(d) ) ¦

£ �"8§¥�8>¤ <

Table9: TheComplexity of Different BPM Types

impossibleto list all thepossibleexecution sequenceswhena BPM becomessocomplex. Table9 lists thecomplexity offour differenttypesof BPM.

As a result,we find the “Or-Or” model is the mostcom-plex modelasit hasthehighestcomplexity. The“And-And”,“And-Or” and “Or-And” are specialcasesof the “Or-Or”model. The“And-And” model caseoccurs whenn processesaretriggeredat thesametime andall thetriggeredprocessesmust be finishedbeforeexecuting the following processofthenext junction. The “And-Or” model caseoccurs whennprocessesaretriggered at the sametime andat leastoneofthe triggeredprocessesis finishedat a later time point. The“Or-And” model is another specialcasewhenall triggeredprocessesmust be finishedbeforeexecuting the followingprocessof the next junction. The following resultsarealsofound:� TheOr split andOr Joint havethegreatestinfluenceon

the complexity. For instance,the complexity of “And-Or” is n timeshigher than“And-And”.� Thecomplexity of thesetypesof BPMsis veryhigh, andit is difficult to carry out all of the possibleexecutionpaths.

6.2 Complexity of Combination ModelsIn this section,we try to combine someof thepreviousmod-els and compute the complexity of them. They are cate-gorisedas:

1. A model finishingwith anAnd Joint junction.2. A model finishingwith anOr Joint junction.

A model finishingwith anAnd Joint junctionis consideredfirst becauseit enables possibleexecution sequencesof oneindependentmodel. In general, thecomplexity of this caseiscomputedas:¨ �"1o���h����-N�KO"��©I3"/ J�����/����@-,��%&��O(�I3"8B3;���I3=8P4#ªt35/���+&8« : 89% x>��3=8P/F¬ v HI8>�./ 3=��8B<Modelsthat finish with an Or Joint have many possibleex-ecutionresults,especiallywhen more than one Or Joint iscombined. Thesemodelsmaybecome very difficult to carryout.

A simpleexample – thecombinationof And-Or andAnd-Andmodels– is usedto describethecomplexity. An assump-tion hasbeenmadeto simplify thisproblem. Wealsoremovetheassumptionto show theextent of thecomplexity. Theas-sumptionis thatall triggeredprocessesmustbefinishedbe-fore thefinal processof eachconnectedmodel(whereasin areal processmodel, an unfinished process may ”propagate”

andexecuteparallelto aprocessin thelattermodel).Basedon this assumption, thecomplexity of this problemis:� 8 ­&®¯ 8V¤�"8@L ­ <)¤o° ��Y±�²�³�²´h�Kµ¶�.|oX�^�Y·nom�T¸f9�\¹º��� Y±�»���&µ 11

As a result, formula 2 only provides the complexity undertheassumption.If we relax theassumption, an“assumptionterm” hasto beadded. Thentheresultis:1?���>������k&3;��HP�D������-uHIO"+¼ 1o�������h��+K�����h3"8\ª#�I3;�������-,�>�����������������+&���h��©����0HI/���%t+K�(/����2/����h�I3"8>+�O���� � �������It will be larger than formula 2. Its complexity remains in��� ��µ½� . Theassumptiondoesnot have a big influenceon thecomplexity.

As ��µ hasa factorial rateof growth which is biggerthanpolynomial rates,[Garey andJohnson, 1979] alsoshows thatanNP-completeproblemneedsmorethanpolynomialtimetosolve (i.e. it needsexponentialtime or greater). Thegrowthrateof ��µ is bigger thanthe growth rateof ´ 8

, so we knowthat thebusinessprocessproblem is at leastanNP-completeproblem. [Chen-Burger, 2002b] indicatesthatworkflow sys-temsmayberequired to handle over 300processesbasedonarealmilitary BPM. Thepossibleexecution sequencesof suchalargemodel maybemorethan ¾9¡Dµ>¿À�D� g���e(¡oÁ

¯, if thereare

many different types of thejunctionin theBPM (i.e. if thereis a totalof 300processesandthereare5 junctions,theneachjunctionwill have approximately60 branches).So thenum-berof possibleresultsmaybeenormousif wedonotconsiderthedetailedsemanticsof theprocesses.

7 Other RelatedWorkIn orderto show thedifferencebetweenFBPML + FWFL andother workflow processlanguages,the applicationof Petrinetsto workflow management[van der Aalst, 1998] is com-paredin this section. The most significant differencebe-tween“FBPML + FWFL” andthisresearchis that“FBPML +FWFL” hasa formal businessprocessmodeling mechanismwhich separatesthe businessandthe implementation logic.Hencetheworkflow systemis more flexibly reactive to a dy-namicenvironment.

A Petri net that modelsa workflow process definition iscalledWorkflow net(WF-net).Comparing theformalmethod(FBPML + FWFL) thatwe provide, andPetri net (WF-net),thefollowing resultshave beenfound (thedetailsof WF-netarenot explained here,we focus only on thecomparisonbe-tweenthem):� Becausea Petri net is a processmodeling technique, it

focuseson workflow processeswhich are designedtohandle cases(called instancesin FWFL). However, itdoesnotfocusonresources,suchaspeople,machinesororganizationunits,which maybe involvedin thework-flow system. The concept of “Role” is ingrained inFBPML+FWFL in orderto representresourcesandusethemin theBPM.� Tasksaremodeled by transitionsin Petri net, whereasin FBPML, activities areusedto describetasks.In Petrinets,casesaremodeledby tokens,whereasin FBPML+ FWFL, instancesareusedto describecases.

11Whenm=0,this formularepresentsthecomplexity of the“And-Or” model.

72

� In Petrinet,eachconditionis modeledby a “place” andit mayrepresent aprecondition or apostcondition of theprocess. In FBPML + FWFL, logical meanings of thejunctionandpreconditions in theattributesof a processreplacetheusageof “place”.� To definea processanda BPM, FBPML + FWFL hasa formal, declarative semantics.A processdescribedinWF-netdoesnothavecleardefinitions of its attributes.� To represent differenttokens (casesor instances),therearetwo waysto represent andlist themin Petrinet(WF-net): 1. Usedifferentcolorsin a high-level Petri net12.2. Useinstancesto describe them.Thelatteris thesamein FBPML + FWFL, but instancesin FBPML+FWFLarenot listed in the BPM. Using FWFL, they areonlydescribedas instanceoccurrencesinside the workflowengine.� High-level Petrinethasa time extensionto describethetemporal behavior of thesystem.In FBPML + FWFL,“Precedence-Link” is usedto indicatea temporal con-straintbetweentwo processes.It is similar to Petrinet.� High-levelPetrinetprovidesahierarchy constructcalled“subnet”whichcanbeusedto structure largeprocesses.In FBPML + FWFL,ahigh-level processcanbedividedinto two different typesof low-level sub-processes(de-composition andalternation) representinga similar no-tion.� Both PetrinetandFBPML+FWFL have a “trigger” no-tion. The trigger condition is clearly definedasan at-tributeof aprocessin FWFL.Theusermayformally de-scribethe trigger condition of this process.Thedeclar-ative descriptionin FWFL makesthe trigger conditioneasyto understand.In Petrinet(WF-net)thetriggerconceptis distinguishedby differentsymbols andfocuseson theenabler (Auto-matic,User, Message,Time)whichtriggers theprocess.It doesnot focuson the dataor world stateconditions.In FBPML + FWFL, trigger conditionsareflexible; theusermaydefineany triggercondition aslong ashe/shefollows thelanguage.� Junctionnotionsusedin Petrinet(WF-net)aremodeledby ordinary transitions.Transitionsaretreatedascon-trol tasks. In FBPML + FWFL, eachjunction hasitsown formal definition. Logical meanings of And SplitandAnd Joint arethesamein FBPML+FWFLandPetrinet (WF-net).However, in Petrinet (WF-net)the“OR-split” is categorised into “implicit OR-split” and “ex-plicit OR-split” (thesameas“OR-join”). Although thismayprovide a cleardefinitionof workflow modeling, itmakesnotationmorecomplex13. FBPML + FWFL doesnot distinguish this caseso that the modeling languageis easyto learnbecauseit is morenatural. Usersdo notneedto rememberspecificmeaningsof notations.

12A Petri net extendedwith color, time and hierarchyis calledhigh-level Petrinet.

13Theauthoralsosaysthat thereis no compellingneedto distin-guishbetweenimplicit andexplicit OR-joins,but thereis for “OR-split”.

� TheWF-netis designedto require thattherearenodan-gling tasksand/or conditions in WF-net. Every task(transition) and condition (place)should contribute tothe processingof cases.The conceptis similar to “ir -relevant nodes” in our three-level framework.� Triggers and workflow attributes are removed whenanalysingworkflow in Petrinet (WF-net). In our three-level framework, we also only consider trigger condi-tions at the level 3 – casestudy. The reason14 is thesameasthatdescribed in [vanderAalst, 1998]. In ourframework, in orderto actuallysimulatepossiblemodelbehaviors,somesemanticsanddetailsof theprocessareconsidered in the analysis.This is different from Petrinet(WF-net)analysisin which all verificationandvali-dationaredoneatagraphical level; although it hasmoreformal definitions for verification thanours.

8 ConclusionsIn this research,we try to bridge thegap betweenEnterpriseModelings (EMs) andSoftware Systemsin orderto providesupport whereEMs areusedasa partof KM initiative. Thisgap exists primarily betweenthe capabilities for gatheringandpresentingknowledge,andthecapabilityfor performingsemantic-basedautomatic manipulation of this knowledge.Formality needsto be introduced to the informal or semi-formal enterprise modeling paradigm to provide precisionandenable automaticsupport. A workflow systemis built tobridge this gap, andallow domainknowledgeto becheckedfor consistency andcorrectnessduring enterprise modeling.Thefollowing conclusions aremade:� FBPML is a merger of two standardisedprocessmodel-

ing languages:IDEF3 andPSL.Thebenefitof mergingthe two languagesis that the former hasgraphic nota-tion but lacksformalprocessconceptualisation,whereasthelatterprovidesformal processtheorywithout any vi-sualisation.Although the two languagesarenot equal,their coreconcepts overlap. Suchcoreconcepts arein-cludedin FBPML, andarecarefully disposedsothattheconsistency of FBPML is maintained.� The graphical notation usedin FBPML is intended tomake it easierfor thoseunfamiliar with predicate logicto describemodels in the language. Although we havenot conducted extensive empirical evaluations of theFBPML graphical language,it is verysimilar in styletoothergraphical processmodelling languagesthat haveachieved widespreaduse. Our aim hereis to conformto currently acceptedmodelling practices.The graphi-cal languagein FBPML, however, translatesautomati-cally to apredicatelogic description thatsupportsbothadeclarative reading (helpful in checkingthelogicalcon-sistency of themodel) andmultipleoperationalreadings(allowing different forms of enactment enginesto exe-cutea processmodel by interpretingthemodeldescrip-tion). As usual,wemakeourenactment enginesgenericfor all forms of FBPML model so that we can freely

14Thereasonis that it is impossibleto modelthebehavior of theenvironment completely.

73

changethedeclarativedescription withoutneeding to al-ter theenactmentengines.� The workflow meta-interpreter is basedon FBPML +FWFL. It acceptsinput specificationsandexecutes theBPM directly. It maybe implemented asa “person-to-process” workflow systemso that somevalidationandexception handlingmaybeconfirmedby theuser. Thismakesit a moreusefultool for theuserdueto this flex-ibility . Mostof thetime,flow is executedautomatically.Thuswe have a flexible way to execute a businesspro-cessflow in adynamic environment.� Our three level-framework provides a thorough testwhich is useful in analysinga BPM. At level 1, aftercarryingoutsyntacticcritiques,theappropriatetopologyfor a complex BPM is mapped out. At level 2, the de-tailsof theprocessareconsidered,andfeaturesfromthistopology areinferred. Becauseof this explicitnessdueto inferenceof themodel,someimpossibleexecution re-sultsareeliminatedafterperformingsemanticcritiques.Problemsizeis therefore reduced. Level 3 corroboratesa BPM written in FBPML + FWFL with respectto aspecialdomain. Thus, thethree-level framework is use-ful for thesefour reasons:

1. A BPM is alwayscomplicated.2. Detailsof processesmustbeconsideredwhenexe-

cutinga process.3. Errors andwarnings alsoneedto becheckedto in-

suretheaccuracy of amodel.4. A casestudyfor testinga BPM is a good way to

simulatepossibleexecution results,and to makea model and workflow system more accurate.Thisdetectssomepossiblemalfunctionsbeforethemodelrunsonlinewhichsavestimeandcost.

This three-level framework is usedto analyseabusinessprocessmodel, andit doesnot have restrictionson thelanguageusedto describea model.� Thecomplexity of aBPM has,at least,afactorialrateofgrowth. The program usedto verify a process modelneedsto carry out an exhaustive searchto execute ofall thepossibleenactmentsof a businessprocessmodel.This will behard. That is why we provide a three-levelframework to analysea BPM in a moreorganisedway.

References[Bard,2001] Jonathan F. Bard. Classificationof integer

programming problems. www.me.utexas.edu/bard/NP-Complete.doc,2001.

[Chen-Burgeret al., 2002] Yun-Heh Chen-Burger, AustinTate,andDaveRobertson. Enterprisemodelling: A declar-ative approachfor fbpml. European Conferenceof Artifi-cial Intelligence, Knowledge ManagementandOrganisa-tional MemoriesWorkshop, 2002.

[Chen-Burger, 2002a] Yun-Heh Chen-Burger.Akt business process model akt project,akt web site (http://www.aktors.org), 2002.

http://www.aiai.ed.ac.uk/project/akt/work/jessicas/pc-config/onto-mode/top-level.html.

[Chen-Burger, 2002b] Yun-Heh Chen-Burger. Sharingandchecking organisationknowledge. Knowledge Manage-mentand Organizational Memories, ISBN 0-7923-7659-5, July 2002. Publisher:Kluwer AcademicPublishers,Boston Hardbound, Editors: Rose Dieng-Kuntz, NadaMatta.

[Garey andJohnson,1979] M. Garey andD. Johnson. Com-puters and Intractability; A Guide to the Theoryof NP-Completeness. W.H. FreemanAndCompany, 1979. ISBN:0716710455.

[Georgakopoulos et al., 1995] Diimitrios Georgakopoulos,Mark Hornick, andAmit Sheth. An overview of work-flow management: From processmodeling to workflowautomation infrastructure. Distributed and ParallelDatabases,3, 119-153, 1995.

[Group, 2002] Delphi Group. Bpm 2002: Market mile-stonereport. Web site: www.delphigroup.com/coverage/bpmwebservices.htm, February2002.

[Mayeret al., 1995] Richard Mayer, Christopher Men-zel, Michael Painter, Paula Witte, Thomas Blinn,and Benjamin Perakath. Information Integrationfor Concurrent Engineering (IICE) IDEF3 Pro-cess Description Capture Method Report. Knowl-edge Based Systems Inc. (KBSI), September1995.http://www.idef.com/overviews/idef3.htm.

[SadiqandOrlowska,1996] WasimSadiqandMaria E. Or-lowska. Modeling and verification of workflow graphs.No. 386, Department of Computer Science,The Univer-sity of Queensland, Qld 4072Australia,November1996.

[Schlenoff et al., 1997] Craig Schlenoff, Amy Knutilla, andStevenRay. Proceedingsof theprocessspecificationlan-guage (psl) roundtable. NISTIR6081, National Instituteof Standards and Technology, Gaithersburg, MD, 1997.http://www.nist.gov/psl/.

[Schlenoff et al., 2000] C. Schlenoff, M. Gruninger, F. Tis-sot, J. Valois, J. Lubell, and J. Lee. The processspecificationlanguage (psl): Overview and version 1.0specification. ISTIR 6459, National Institute of Stan-dards and Technology, Gaithersburg, MD (2000), 2000.http://www.nist.gov/psl/.

[terHofstedeet al., 1996] A.H.M. ter Hofstede, M.E. Or-lowska,andJ.Rajapakse.Verificationproblemsin concep-tualworkflow specifications. International ConferenceonConceptual Modeling/ theEntity RelationshipApproach,1996.

[vanderAalst,1998] W.M.P. vanderAalst. Theapplicationof petrinetsto workflow management.TheJournal of Cir-cuits,SystemsandComputers,8(1):21-66, 1998.

[YehandYoung, 1991] Wei Jen Yeh and Michal Young.Compositional reachability analysisusing process alge-bra. Symposiumon Testing, Analysis,and Verification,1991. SoftwareEngineeringResearchCenter, Departmentof Computer Sciences,PurdueUniversity WestLafayette,IN 47907.

74

Locating The Company’s Crucial knowledge to Specify Corporate Memory :A Case Study in Automotive Company

Inès Saad , Michel Grundstein, Camill e Rosenthal-SabrouxLAMSADE , University - Paris IX,

Place du Maréchal de Lattre de Tassigny, 75775 Paris cedex 16{ saad,sabroux} @lamsade.dauphine.fr

mgrundstein@mgconseil .fr

Abstract

This paper highlights the importance to identify crucialknowledge before choosing engineering methods andtools to capitalize on company’s knowledge. It presentsa preliminary survey on the approach that has beencarried out in PSA Peugeot Citroen, with the final goal tochoose and justify necessary investment to elaboratecorporate memory components.

Keywords: Locating Company’s Crucial Knowledge,Corporate Memory, Knowledge Mapping, ClassificationMulticriteria Method.

1. Introduction

Capitalizing on company’s knowledge isincreasingly being recognized in an industrialenvironment since knowledge is considered asource of competitive advantage [Nonaka andTakeuchi, 1995; Drucker, 1993]. Thus, companiesmust invest in engineering methods and tools inorder to preserve knowledge that grounds theirspecific core competencies. To minimize theseinvestments, they must identify so called “crucialknowledge” that is the most valuable knowledgeto preserve and use. In addition, as pointed out byRose Dieng,"Identification of crucial knowledge inorganization has an influence on the kind ofcorporate memory needed by the enterprise"

[Dieng et al., 1998].

In this paper, after a short description of thecontext and the problem encountered by PSAPeugeot Citroen, we present the essentialcharacteristics of the GAMETH® Framework thathas been used to identified potential crucialknowledge. Then, we describe the actual approachthat has been applied to a specific componentdesign project. Finally, we suggest a discussionfocused on the problem of mapping andquali fying knowledge as a preliminary result ofour research.

Afterwards, we refer to the definition ofcorporate memory proposed by Van Heijst, Vander Spek, and Kruizinga [Van Heijst et al, 1996]“explicit, disembodied, persistent representationof knowledge and information in anorganization.”

2. The context and the problematic

In Automotive companies, capitalizing onknowledge mobili zed in design process, that is,locating, preserving, enhancing value andmaintaining this knowledge is very complex[Saad et al, 2002]. It involves more and moreheavy investment in order to convert unstructuredtacit knowledge into explicit knowledge to beintegrated into corporate memory. As resourcesand budget of companies are limited, companiesmust define accurately knowledge that is to beintegrated in design process’s corporate memory.

75

In the case of this study, our goal is to justify asituations for which capitalizing on knowledge isadvisable and choose methods dedicated to thebuilding of a corporate memory, li ke MKSM/MASK [Ermine, 1996; Matta et al., 2001],CYGMA [Bourne, 1997], Rex [Malvache andPrieur, 1993], CommonKADS (Schreiber et al.,2000), etc. The objective is to transfer the know-how and skill s created and used during the designproject of a component A, toward a line of designprojects in progress of new components alikecomponent A.

Referring to A. Pachulski thesis [Pachulski, 01],we have based our approach on the GAMETH®

Framework to identify crucial knowledge.

3. The GAMETH® Framework in br ief

GAMETH® Framework is aimed to respond to thefirst facet of the Multi faceted Problem-SolvingApproach to capitalizing on company’sknowledge proposed by Michel Grundstein[Barthes and Grundstein, 1996; Grundstein,2000].

3.1 The Multifaceted Problem-Solving Approach

When capitalizing on company’s knowledgeassets, many problems appear. We group theminto a five facets model described as follows (seefigure 1):

Locate, this facet of the problem deals with thelocation of crucial knowledge, that is explicitknowledge and tacit knowledge [Polanyi, 1966],that are necessary for decision-making processesand for the progress of the essential processes thatconstitute the heart of the activities of thecompany.

Preserve, this facet of the problem deals with thepreservation of know-how and skill s. When skill scannot be formalized, “master-to-apprentice”behavior has to be encouraged.Enhance, this facet of the problem deals with theadded-value of know-how and skill s. Here is thelink with innovation processes.

Actualize, this facet of the problem deals with theactualization of know-how and skill s. Here is thelink with business intelli gence processes.

Figure 1. The Multi Facets problem Solving Approach

Manage, this last facet of the problem deals withthe interactions between the various problemsmentioned previously. It is there that themanagement of activities and processes, allowingthe mastery of knowledge in organizations to beinsured, takes place. It is often called KnowledgeManagement in numerous publications. In fact,the expression Knowledge Management covers allthe managerial actions aiming at answering theproblem of capitalization of knowledge in general.It is necessary to align the knowledgemanagement on the strategic orientations of theorganization; to make people sensitive; to form, toencourage, to motivate and to rally people’sinterest; to organize and to pilot activities andspecific processes leading towards more masteryof knowledge; to arouse the implementation offavorable conditions to the cooperative work andto encourage the sharing of knowledge; toelaborate indicators allowing the follow-up andthe coordination of launched actions to be insured,to measure results and to determine the relevanceand the impacts of these actions.

PRESERVE ACTUALIZE

ENHANCEENHANCE

��� ��� � ��������� � � ���

LOCATE

� � � � � � � � � � �� � � � ! " ! # $

% & ' ( ' ) * + ( , - , . /0�1 2 2 3 4 56 7 8 9 :<; 8 9 = >? @ A B @ A C A D A E F

G�H H I J J A E FK�A J J I LMA E N C A E FO P Q R S T U

V�W S T UYX<Z R [\ ] ] \ ^ _ ` a \ b cd e fMg h i h i jd k l m n h i j

oqp p k m h r h i js�p t m n h i j

u n m i t m k t h v h i jw i k h x y h i j

z�{ | } ~ � ~ � ���� � � � ~ � �� � � �<� � � � � � �� � � � � � � � � �

� � � � � � � � �M��� � � � � �� � � �<� � �<�M  ¡ ¢ � � �£�<¤ � ¥ ¦ ¡§ � ¨ ¥ ¡ ¦ © �<�Mª � � � « ¦ ¡ ¥ � �

¬ ¥ ­ ¦ ® ¦ � ¥ � �<�Y¯ ¡ ­ � ° � ¥ ¨ �<�Y±�� � ¦ ² ¥ � �³�´ µ ¶ · ¸ ´<¹Yº » ¼ ¼ » ½ ¾ ¿ À

MANAGEMANAGE

©Michel Grundstein, 2000

76

3.2 The General Descr iption of GAMETH®

Framework

The GAMETH® Framework consists of lookingmore directly at the production processes. TheGAMETH® Framework relies on three postulates,and induces an approach that has three specificcharacteristics and consists of three main stages.A detailed description has been given in[Grundstein et al., 03].

The postulatesThe approach is based on the followingpostulates:

1) Company’s knowledge includes two maincategories of knowledge: explicit knowledge –the specific know-how that characterizes thecompany’s capabili ty to design, produce, selland support its products and services - and theindividual and collective skill s thatcharacterize its capabili ty to act and to evolve.

2) Knowledge is not an object, knowledge existsin the interaction between a person and data.

3) Knowledge is linked to the action.

The characteristicsThe approach is characterized by three maincharacteristics:

1) It is a problem-oriented approach: theproblems are located, the required needs forknowledge that allow their resolution areclarified, the knowledge is characterized andthen, the most adapted solutions to solve theproblems are determined.

2) It is a process-centered approach that connectsknowledge to the action: the analysis is notbased on a strategic analysis of the company’sgoals, but instead on the analysis of theknowledge needed by the value-addedactivities of functional, production, businessand project processes.

3) It is a constructivist approach that allowscollective commitment. The aim of thisapproach is to build from partial knowledge ofthe actors through their activities, therepresentation of the process. Thisrepresentation allows to identify informal

links between the actors that are not describedin the documents.

The main stagesThe approach is aligned on the company’sstrategic orientation, and the deliverable is anAdvisabili ty Analysis Report that notablyincludes:

- A repertory of the crucial explicit knowledge(know-how), associated with a documentpresenting a description and a classification ofthese know-how.

- A repertory of agents, the bearers of crucialtacit knowledge, associated with a documentpresenting a description and a classification ofthese knowledges.

- An index of the agents possessing knowledgeelicitable, associated with a descriptive card oftheir competences, the persons who mightsolicitate them and the events that determinethis solicitation.

- A document defining the tacit elicitableknowledges that should be shared, completedwith a grid establishing the formal andinformal relations between the agents, bearersof these knowledges, and the agents whomight use them.

- Recommendations concerning the acquisitionand the formalization of tacit elicitableknowledges.

In short, the GAMETH® Framework approachconsists of the following steps:

- inventorying the goods and services for whicha knowledge capitalization initiative isenvisaged;

- modeling the units (functions, organs, andcommunication links) that supply these goodsand services;

- delimiti ng the production processes concernedand specifying the phases and steps of theproduction cycles corresponding to theseprocesses;

- analyzing the role of the poles of expertise inthe satisfactory operation of each phase andeach step of the production cycles;

77

- analyzing the risks and determining thecritical activities;

- identifying the constraints and dysfunctionsthat weigh on these activities;

- distinguishing the determining problems;- locating and characterizing the knowledge

necessary to solve these problems;- measuring the value of this knowledge and

determining the crucial knowledge;- drawing up a map of the knowledge to be

capitalized, based on the inventory of theactors;

- cross-checking with the crucial knowledge,for each phase of the production cyclesconcerned.

In this way, the fields of knowledge, theirlocations, their characteristics and their influenceon the operations of the company and its strategicorientations are detailed. At the end of theadvisabili ty analysis, the elements enabling thejustification of a knowledge capitalizationinitiative will have been gathered, making itpossible to decide upon and undertake thefeasibili ty study.

4. A Case Study :Locating Crucial Knowledgein Design Process

4.1 General Synoptic of Knowledge flow in DesignProcess

The design process is complex [Perrin, 1999]. Itproduces one or more output. In this process,there is creation or update of knowledge. Thisknowledge is the result of interaction betweendifferent designing skill s at PSA Peugeot Citroenand some services suppliers dispersedgeographically.

One part of created knowledge remains in theactor’s mind: this is tacit knowledge. We noticethat this tacit knowledge is lost when teams aredislocated, replaced or when actors get retired. Itis called "volatile knowledge".

An other part of created knowledge is preservedwithin Corporate memory. This corporatememory could be enhanced and valued through :innovation, economic intelli gence, validated

knowledge in the product exploitation phase andknowledge related to other projects. Thiscorporate memory should be sustainable andavailable to others project (see figure 2).

In the following section, we present theapproach followed in PSA Peugeot Citroen toidentify potential crucial knowledge.

Figure 2. General Synoptic of Knowledge Flow in Design Process

4.2 An Approach to Identify Potential CrucialKnowledge

We have used the principles proposed byGAMETH® Framework to identify potentialcrucial knowledge. That is, identifying sensitiveprocess, identifying criti cal activities andclarifying the need of knowledge to solveproblems linked with criti cal activities.GAMETH® Framework is oriented by analysis ofprocesses. Indeed, we consider enterprise as asystem of activities and this avoids toconceptualize knowledge separately from action[Tarondeau, 1998].

The approach used at PSA Peugeot Citroencontain three stages (figure 3). First, we identifythe sensitive process with stakeholders : processesthat will be the object of an in-depth analysis.Indeed, it isn’ t conceivable to analyse allprocesses in short period. Our method is based onan heuristic approach to identify sensitiveprocesses. The second stage consists on the onehand, in modelli ng sensitive processes identifiedand on the other hand, in analyzing criti cal

Corporate memory

Other projects

Design Process

Knowledge

Exploitation of product

ProductData

Reuse

Validate

Volatile

Preserve

missing knowledge

Economic intelligence

competition

78

activities associated to each sensitive process.Critical activities take in danger the sensitiveprocess. The third stage consists in identifyingtwo types of knowledge : unwell mastered andmastered knowledge which is essential to theactivity’ f unction. Next, we present ourexperience concerning the application of the threestages in our case study.

Stage 1 : Identifying Sensitive Processes

In this stage, we formalize with stakeholderobjectives rely to the project. These objectives aremodelled with “mission tree” 1. The interest of thisrepresentation is double :

- It allows responsible to have a commonrepresentation of objectives to reach

- It is a way to identify sensitive processes.

Stage 2 : Modeling the Sensitive Process andIdentifying the Critical Activities

In this stage, we model and analyze the sensitiveprocess and then we identify criti cal activitiesassociated to each sensitive process.

- Modeling and anlyzing Sensitive Process

We model the sensitive process to identify andlocate criti cal activities. We represent thesensitive process with “Four Page Model”1. Thismodel is a tool for describing a design process. Itis used at PSA Peugeot Citroen to have a globalvision on design processes [Coustilli ère andColas, 1999]. This model allows actors to positionthemselves within the flow of essential activities.The “Four Page Model” is independent oforganizational structure. It has been establishedaccording to PSA quali ty service requirement. Weuse a backtracking approach to describe activitiessequence and identify actors who contribute to theprocess. The fact that we are limited in one page

1 Mission tree, four page model and flow diagram are represented

in (Saad I., and al., 2002).

is important because we have to make a greateffort to represent the essential activities.

Figure 3. The Approach to Identify Potential Crucial Knowledge

- Analyzing Critical Activities

In this stage, we analyze criti cal activities linkedto sensitive process. We have adapted the modelof Grundstein [Grundstein, 2000]. Indeed, theGrundstein model is based on malfunctionsanalysis. However, in design process the goal is tofind a compromise between different points ofview to resolve a problem.

An activity is a set of elementary effectivetasks (see figure 4). These tasks correspond to thereal work , performed by an individual or a group,oriented by an objective to be intended, thattransforms materials into a product that consumesfinancial and technical resources. Activities useand produce specific knowledge (know-how andskill s). They are subject to constraint. Constraintcan be external to the activities. These are theimposed conditions (example: technicalspecification to be respected). Activities may fallvictim to problem. This leads to differencesbetween the expected results and those actuallyachieved. Problems which cannot be solved byorganisational actions will be analysed byfocusing on knowledge.

� � � � � � � � � � �� �� � � � � � � ��� � � � � � �

��� � � � � � � � � � � � � � � ! " � � �# $ �%" � � " � # � & ��' ( � ) � " "

* � � � # � + ! � � � # $ �) ( � # � ) � � � ) # � & � # � � "

Identifying potential crucial knowledge

, - . / 0 . 1 2 3 465 7 8 1 2 39 : ; <>= ? @ A ?

B C6D E F E G H I H G F E J E F E K LB M N O N P Q R S R S TVU P W X Y N Q>Z

[ \ ] ^ _a`

b c d e f g

h i j k l m

79

Figure 4. Analysis of criti cal activity

In order to characterize some identifiedknowledge, we need to analyse a “SecondaryProcess” specific to the creation of thisknowledge. This secondary process is external toour sensitive process.

We use a Flow Diagram called "actigramme"1 todescribe secondary processes. This “actigramme”allows to represent how different servicescooperate through activities and exchangeinformation all along the time. This “actigramme”help the cognitive engineer to pinpoint informalcommunication between actors. Moreover, thisrepresentation maps the interaction betweenindividuals in terms of how they transfer theirtacit and explicit knowledge in the design process.

Stage 3 : Identifying the Potential CrucialKnowledge

In this stage, we clarify and locate the knowledgeneeded to solve determining problems. Thisanalysis leads to identify two types of knowledge:missing knowledge and poorly masteredknowledge. Moreover, it allows to identifyknowledge, that can be crucial because the ownerof this knowledge is an expert.

When analyzing determining problems westart the explicitation of individual tacitknowledge. As highlighted by Polanyi who makesa distinction in two levels of awarness; focalawareness and subsidiary awareness. We canObserve a difference between knowledge onwhich we focus, and knowledge that supports the

focus : “ When focusing on a whole, we aresubsidiary aware of its part” [Polanyi, 1966;Brohm, 1996].

In the section bellow we suggest a discussionon our prospects. We present (1) A conceptualmodel with the purpose of drawing-up knowledgemaps to get an overview of available and missingknowledge in the organization; these maps will beessential instruments that help making appropriateknowledge management decisions. (2) The basisto elaborate a model for quali fying a set of criteriain order to quali fy knowledge to be capitalized.

5. Prospects : Knowledge Mapping and aModel to Define a Criteria Family

5.1 Knowledge Mapping

Knowledge maps help in discovering the location,value and use of organizational knowledge in thesense of [Tshuchiya, 1993]. Three approachesexist to construct and represent a knowledge map: procedural classification, functionalclassification and conceptual classification[Godbout, 1999]. We refer to the definition ofknowledge mapping given by [Speel et al., 1999]“knowledge mapping is defined as the process,methods and tools for analyzing knowledge areasin order to discover features or meaning and tovisualize these in a comprehensive, transparentform such that the business-relevant features areclearly highlighted” .

The model to construct a knowledge mapwhich is proposed in our study is based onconceptual classification that is focus onknowledge to analyze (see figure 5). We

Constraints

Problems

Knowledgeproduced

Knowledgeused

M ATERIAL PRODUCT

Resources

Updating

Data Data

Constraints

Problems

Knowledgeproduced

Knowledgeproduced

Knowledgeused

Knowledgeused

M ATERIAL PRODUCTM ATERIALM ATERIAL PRODUCTPRODUCT

Resources

Updating

Data Data

©Michel Grundstein, 2000

80

determine the internal characteristics ofknowledge (formal, empirical, experience based,hard to verify, certain/uncertain, cost of itsproduction, complexity, imitabili ty, scarcity,substitutabili ty, highly specialized, quicklychanging) and we identify interaction betweenknowledge and other objects. We have identifiedfive types of objects : document, actor, process,project, objective. That is, answers to thefollowing questions : In what documentsknowledge is formalized? Who use knowledge ?Who create it ? In what process? What are theinfluences of knowledge on the enterpriseobjectives ? In how many processes theknowledge is used ? What is the knowledgedomain needed to create knowledge?

Figure 5. A Model to construct a knowledge Mapping

It is necessary to point out on the map the sourceof the knowledge, that is the name of the owner ofthe knowledge as noted by Davenport in 1998"Knowledge maps typically point to people aswell as to documents and databases? Theemployee with a good knowledge map has accessto knowledge sources that would otherwise bedifficult or impossible to find."(Davenport, 1998).

5.2 A Model to Define a Criteria Family

We have adapted Le Moigne’s systemic approach[Le Moigne, 1977] to construct a family ofcriteria. It is important to note that these authoruses the general system theory to model an objectwhich is characterized by three dimensions:structural, functional and evolution dimension.

We use the model of Le Moigne in spite of ourpostulate: “ the knowledge isn’ t an object” .Indeed, multiple individuals involve in the designprocess have a shared field which improvescommensurabili ty of the interpretativeframeworks of designer members [Tsuchiya,1993]. Thus, articulated individual and collectiveknowledge, which needs to be communicated isshared through dialogue or informationtechnology among actors in design process, but itis considered information for other members ofautomative company.

To construct a family of criteria we haveanalyzed in deep theoretical and empirical workson strategy based theory, knowledgemanagement, knowledge engineering andeconomic theory. The resource based theoryliterature, argues that firm resources are strategictool for competitive advantage if they possesscertain characteristics i.e, if they are valuable,scarce, not easy to imitate, diff icult to substitute[Barney, 1991; Colli s and Montgomery, 1995;Lorino, 1991]. Knowledge has recently heraldedas a strategic tool for competitive advantage[Bontis, 2000; Tarondeau, 2000; Mcevily andChakravarthy, 2002]. Moreover, other researchexist to quali fy knowledge [Boisot, 1998;Grundstein, 1988; Grundstein, 1995; Barthes andGrundstein, 1996; Davenport, 1998; Foray, 2000;Pomian and Roche, 2002]. For example, MichelGrundstein suggests to identify crucial knowledgein two steps : firstly, identifying vulnerableknowledge and, secondly analyzing the influenceof this vulnerable knowledge on the li fe of thecompany, its markets, and its strategy.

In the remainder of this section, we present thefamily of criteria based on theoretical andempirical works. We evaluate the knowledgeneeded to be capitalized and integrated incorporate memory in three steps : first, wemeasure the knowledge role, that is, theknowledge influence on company' s operationalobjective. Second, we analyse the characteristicsof valuable knowledge i.e., we should focus onknowledge which is scarce, not substitutable, notaccessible, hard to transfer, whose production costis very expensive, etc ). In this paper we present

knowledge

Actor

ProcessDocument Project

Iscreatedby (1,n) Isusedby (1,n)

In (1,n)

objective

Is contained in (0,n)

Influences (0,n)

Influences (0,n)

81

two subfamilies of criteria, that is, the knowledgerole and the knowledge characteristic. Theevolution of knowledge is ongoing research.

The Knowledge RolesThe role of the knowledge is measured in regardto company operational objective. We have basedour evaluation on the hypothesis of Lorino “wedon’ t directly measure the degree of contributionof knowledge to the company performance”[Lorino, 1991]. Which means the role ofknowledge is evaluated in two steps :

- First, measuring the frequency of use oradaptation of the knowledge in theprocesses and the degree of importance ofthis use of knowledge.

- Second, measuring the importance of theprocesses to the enterprise operationalobjective.

Figure 6. Role of knowledge

The Knowledge CharacteristicsIn this section, we present the definition of eachcriteria used to characterize knowledge :

- Scarcity represents the number of person(internal or external to the organization)who own the knowledge.

- Transferability is the degree of thetransfer of individual or collectiveknowledge. We have based our analyze onthe definition given by Davenport“knowledge transfer involves two actions :transmission and absorption by thatperson or group” (Davenport, 1998) tomeasure the degree of transferabili ty ofknowledge. So we distinguish two statesfor measuring the knowledgetransferabili ty :

Transmission represents the degree towhich an individual or group of individualcan transmit his knowledge to otherperson. It is diff icult to transmitindividual knowledge because it isfundamentally tacit. “ We know more thanwe can tell ” [Polanyi, 1966]. Knowledgeincorporates so much embedded learningthat its rules may be separate from howindividual acts.

Absorption is the degree to whichindividual can appropriate the knowledgeby either studying technical document ortalking to her predecessor skill edindividual.

- Imitability represents the degree to whichcompetitors can copy knowledge byanalyzing patent, by experiencing product,etc.

- Accessibility represents the time neededto access to the knowledge. Theaccessibili ty notion is relative because ithas to be compared with the length of timethe person actually has to access to theknowledge.

- Complexity represents the degree towhich multiple kind of knowledge domainare needed to create a knowledge in theprocess or to adapt it to another context.

- Validity represents the validation state ofknowledge. We distinguish two types ofvalidation :

o knowledge validated bymacroscopic or microscopeexperiments

o knowledge validated by experts ;for example; thesis, patent...

- Substitutability is the degree to whichknowledge can be replaced by an other

knowledge Project ObjectiveProcessContribute to (0,n) Contributeto (1,n) Contributeto (0,n)

82

knowledge to take the same task with thesame performance.

- Cost and time of knowledge productionrepresents the number of persons and theperiod needed to create the knowledge.

6. Conclusion and further research

This paper addresses an essential issue inknowledge management: Identification of crucialknowledge before choosing the kind of corporatememory to use. Several issues were considered inthis paper. First, we have presented an approachto identify potential crucial knowledge :“GAMETH® Framework” and its characteristics.Second, we have presented a case study in designprocess at PSA Peugeot Citroen to identifypotential crucial knowledge. Finally, we haveopen a discussion on our prospects : knowledgemapping and a model to define a family of criteriawith the purpose of quali fying knowledge to becapitalized.

To evaluate the set of potential crucialknowledge identified, we will base our approachon a multicriteria classification method [Roy andBouyssou, 1995; Mousseau, 2000; Rosenthal-sabroux, 1996]. This method encode stakeholderspreferences according to their several points ofview.

Acknowledgments

We would like to thank Patrick Coustilli ere andChristophe Griard for their valuable contributions.

References

[Barney, 1991] J. BARNEY. Firm Resources and SustainedCompetitive advantage. journal of Management, 17(1) : 99--120, 1991.

[Barthes and Grundstein, 1996] J.P BARTHES, and M.GRUNDSTEIN. An industrial View of the Process ofCapitalizing Knowledge. Advances in KnowledgeManagement, Vol. 1., pages 258--264. Ergon Verlag. InProceedings of the Fourth International ISMICK Symposium,Rotterdam, 1996.

[Boisot, 1998] M. BOISOT. Knowledge assets : SecuringCompetitive advantage in the information economy, Oxford,London, 1998.

[Bontis, 2000] N. BONTIS. Managing Organizational Knowledgeby Diagnosing Intellectual Capital, chapter 17, p. 375-402, in

Knowledge Management, Classic and Contemporary Works byDaryl Morey, Mark Maybury, Bhavani Thuraisingham, TheMIT Press, Cambridge, Massachusetts, 2000.

[Bourne, 1997]. C. Bourne. Catégorisation et formalisation desconnaissances industrielles. Connaissances et savoir-faire enentreprise, Hermes, p179-197, 1997.

[Brohm, 1996] R. BROHM. Bringing Polanyi onto The TheatreStage. In proceedings International Symposium on theManagement of Industrial and Corporate Knowledge , ErasmusUniversity Rotterdam, 1999.

[Colli s and Montgomery, 1995] D. COLLIS and C.AMONTGOMERY. Competing on resources : Strategy in the1990, Harvard Business Review, Pages 127--140, 1995.

[Coustil lière and Colas, 1999] Patrick COUSTILLIERE, P., and D.COLAS , PSA Peugeot Citroën, 1999.

[Davenport and Prusak, 1998] T.H DAVENPORT and L.PRUSAK. Working Knowledge : How organizations managewhat they know ?, Harvard Business School Press, Boston,Massachusettes, 1998.

[Dieng et al., 1998] Rose Dieng, O. Corby, A. Giboin, and M.Ribiere. Methods and Tolls for Corporate KnowledgeManagement. Technical Report (RR-348), INRIA. http://citeseer.nj.nec.com/dieng98methods.html

[Drucker, 1993] P. Drucker. Post- Capitalism Society, Oxford,1993

[Ermine, 1996] Jean Luis Ermine. Les systèmes de connaissances,Hermes, Paris, 1996, deuxième édition 2000

[Foray, 2000] Dominique FORAY . L’économie de laconnaissance, Editions La découverte, 2000.

[Grundstein, 1988] Michel GRUNDSTEIN, B. Bonnières, and S.Para. Les systèmes à base de connaissances, AFNOR gestion,1988.

[Grundstein, 1995] Michel GRUNDSTEIN. La Capitalisation desConnaissances de l' Entreprise, Système de production desconnaissances. Actes du Colloque "L' Entreprise Apprenante etles sciences de la complexité". Université de Provence, Aix-en-Provence, 22-24 mai, 1995.

[Grundstein, 2000] Michel Grundstein. From capitalizing onCompany Knowledge to Knowledge Management, chapter 12,pages 261-287, in Knowledge Management, Classic andContemporary Works by Daryl Morey, Mark Maybury,Bhavani Thuraisingham, The MIT Press, Cambridge,Massachusetts, 2000.

[Grundstein et al., 03] Michel Grundstein, Camill e Rosenthal-Sabroux and Alexandre PACHULSKI. Reinforcing DecisionAid by Capitalizing on Company’s Knowledge. European.Journal of Operational Research : 256-272, january 2003.

[Godbout, 1999] A. Godbout. Cartographie des connaissances, lafondation de l’organisation des connaissances. Article deGodbout Martin Godbout et Associés, 1999.

[Le Moigne, 1977] J.L Le MOIGNE. La théorie du systèmegénéral, Puf, Paris, 1977.

[Lorino, 1991] Phill ipe LORINO. Le contrôle de gestionstratégique, la gestion par les activités, Dunod, Paris, 1991.

83

84

[Malvache and Prieur, 1993] P. Malvache and P. Prieur. MasteringCorporate Experience with the Rex Method, in J.P. Barthes inProceedings of ISMICK’93, Compiègne, 33-41, Octobre 1993.

[Matta et al., 2001] Nada Matta, Jean Luis Ermine, GérardAubertin , and J.TRIVIN, J. Knowledge Capitalization with aknowledge engineering approach : the MASK method. InProceedings of the International Joint Conference on ArtificialIntelli gence IJCAI 2001, Seattle, USA, 4-10 Juin 2001.

[Mcevily and Chakravarthy, 2002] S. McEVILY and B.CHAKRAVARTHY The Persistence of Knowledge-BasedAdvantage : An Empirical Test For Product Performance andTechnical Knowledge, Strategic Management Journal, 23 :pages 285--305, January 2002 .

[Mousseau and Slowinski, 2000] V. MOUSSEAU and R.SLOWINSKI., Inferring an ELECTRE TRI Model fromAssignment Examples. Journal of Global Optimization, 12(2),pages 157-174, 1998

[Nonaka and Takeuchi, 1995] I. Nonaka and H. Takeuchi TheKnowledge Creating Company. How Japanese CompaniesCreate the Dynamics of Innovation, Oxford University Press,New York, 1995.

[Pachulski, 01] Alexandre Pachulski. "Repérage desconnaissances cruciales pour l’entreprise". thèse de doctorat,Université Paris Dauphine, 2000.

[Perrin, 1999] J. Perrin. Pilotage et évaluation des processus deconception, L’Harmattan, Paris, 1999.

[Pomian and Roche, 2002] J. POMIAN et C. ROCHE.Management des connaissances et organisation du travail ,2002.

[Polanyi, 1966] M. Polanyi M. The tacit dimension. Routledge&Kegan Paul Ltd, London, 1966

[Rosenthal-sabroux, 1996] Camill e ROSENTHAL-SABROUX.Contribution méthodologique à la conception de systèmesd’ information coopératifs. HDR, Université Paris-Dauphine,1996.

[Roy and Bouyssou, 1995] Bernard ROY and Denis BOUYSSOU.Aide Multicritères à la décision, Economica ,1985

[Saad et al., 2002] I. SAAD, P. coustilli ere, M. Grundstein, and C.ROSENTHAL-SABROUX. In proceedings of 12th EUROconference Decision Support Systems, Investement DecisionAid Approach, Brussels, April 2002.

[Saad, et al., 2002] Ines Saad, Camill e Rosenthal-Sabroux, MichelGrundstein et Patrick. Coustilliere. Une démarche de repéragede connaissances cruciales conduisant à l' identification descompétences. 1er Colloque du groupe de travail Gestion descompétences et des connaissances en génie industriel , Nantes(France), 12-13 décembre 2002.

[Schreiber et al., 2000] G. Scheiber, A. AKkermans, R.Anjewierden, N. De Hoog, W. Shadbolt, Van De Velde, andB., Wielinga. Knowledge Engineering and management TheCommonKADS Methodology, the MIT Press, Cambridge,Massachusetts, 2000.

[Speel et al., 1999] PH. SPEEL, N. SHADBOLT , W. DE VRIES,PH VAN DAM ,. K. O’HARA. Knowledge Mapping forindustrial purpose. In proceedings conference, Canada,

Octobre 1999.

[Tarondeau, 1998] J.C Tarondeau, J.C. Le management dessavoirs, Puf, Paris, 1998.

[Tshuchiya, 1993] S. TSUCHIYA. Improving Knowledge CreationAbili ty through Organizational Learning,. In ProceedingsInternational Symposium on the Management of Industrialand Corporate Knowledge , UTC, Compiègne, 1993.

[Van Heijst et al., 1996] G. Van Heijst, R. Van Der Speak, and E.,Kruizinga. Organizing Corporate Memories. In B.Gaines,M.Musen eds in proceeding of KAW’96, Banff , Canada, 42-77, Novembre 1996.