Knowledge Management Using MODEL-ECS

 

Dickson Lukose

Distributed Artificial Intelligence Centre (DAIC)
Department of Mathematics, Statistics, and Computing Science
The University of New England, Armidale, 2351, N.S.W., AUSTRALIA
 
Email: lukose@peirce.une.edu.au
Tel.: +61 (0)67 73 2302 Fax.: +61 (0)67 73 3312

 

Abstract

Knowledge is the fundamental resource that allows us to function intelligently. Similarly, organisations (i.e., enterprises) typically use different types of knowledge to enhance their performance. Task ontology modelling is the key to corporate knowledge management via modelling shareable and reusable knowledge bases. The mapping between the domain specific task ontology, and the domain independent task ontology, is crucial for realising shareable and reusable knowledge bases. This paper suggests an approach to achieving this objective, by proposing a three phase knowledge engineering approach. Task ontology is modelled using MODEL-ECS (i.e., graphically based executable conceptual modelling language). Conceptualisation of the organisation and its knowledge base is crucial to formalising the mapping functions necessary to realise corporate memory modelling. This paper describes one such approach.


Contents

Abstract
Introduction
Task Ontology Modelling
Architecture of the Knowledge Engineering Environment
Phase One
Phase Two
Phase Three
MODEL-ECS
Primitive Conceptual Structures
Conceptual Graphs
Actors
Executable Conceptual Structures
Actor Graphs
Problem Maps
Complex Modelling Constructs
Future Work
Acknowledgements
References


Introduction

Knowledge (i.e., insight, understanding, and practical know-how) that we all possess is the fundamental resource that allows us to function intelligently. For an organisation (enterprise) to function effectively, it too uses various types of knowledge. Typically, an organisation works with three classes of knowledge: tacit knowledge; rule-based knowledge; and background knowledge (Choo, 1996). Many Artificial Intelligence (AI) based technologies have been used by organisations to model/build, manage and utilise knowledge bases. In particular, expert systems are widely used to manage and utilise rule-based knowledge in many aspects of the day-to-day activities of an organisation. In recent years, much effort has been directed towards tacit knowledge modelling and management, as summarised in Lukose (1996a). New developments in modelling corporate memory reported in Gaines et al., (1996), Mahe et al., (1996), Euzenat (1996), Decker et al., (1996) and Simon (1996) demonstrate the efforts put in by researchers around the world in their attempt to get a firm grip on modelling tacit knowledge at large.

To support tacit knowledge acquisition and management, it is cruical to be able to model a general task ontology (i.e., core knowledge base), a doman specific task ontology, and to be able to map between these two ontologies, as outlined in the finding of Ikeda et al. (1996) in developing their Conceptual Level Programming Environment (CLEPE); Aoki et al., (1996) in developing a Legal Ontology Development Environment (LODE); and Kishimoto et al., (1996) in developing their Interpretive Environment for Distributed Diagnostic Expert Systems (DECIDE). In all of the above knowledge engineering environments, the authors have emphasised the need for a general domain independent tasks ontology, and pointed out the necessity for constructing the domain dependent tasks ontology to obtain a shareable and reusable knowledge bases (i.e., manageable knowledge base).

Typically, the knowledge management process consist of four main related activities. They are acquire, develop, retain, and share. To enable the above knowledge management process to take place in large organisations, manageable knowledge bases need to be constructed. To achieve this objective, it is necessary to have a sound knowledge engineering environment that will enable the knowledge engineer to develop domain independent task ontology, enable the domain experts to build domain specific task ontology, enable the knowledge engineer in collaboration with the domain experts to map the domain specific task ontology to the domain independent task ontology, and finally, to enable the domain experts to build Problem Solving Methods (PSMs) (Schreiber, et al., 1993) using the domain specific task ontology that they have defined earlier.

In this paper, the author attempts to conceptualise a typical organisation, the management of knowledge within this organisation, and proposes an architecture of a knowledge engineering environment based on a graphical based executable conceptual modelling language called MODEL-ECS(Lukose, 1996b) that is suitable for modelling the tacit knowledge of a typical organisation.

The outline of this paper is as follows: In the next section, the author conceptualise an organisation (i.e., enterprise) and its knowledge base (domain independent task ontology and domain specific task ontology), associates different views with each of these domain specific task ontologies, and proposes how mapping of terms/concepts/phrases from the domain specific task ontology to the domain independent task ontology can take place. Following this, the author describes the architecture of the proposed knowledge engineering environment, which can facilitate knowledge management across the enterprise by enabling the construction of shareable and reusable knowledge bases. A brief description of all the conceptual abstraction used in MODEL-ECS is outlined next, and finally, the author summarises this paper and outline future research directions.

 

Task Ontology Modelling

In this section, the author will describe how mapping between domain specific ontology and the domain independent ontology can take place within a knowledge base of an organisation. To be able to conceptualise this mapping process, we will use the following symbols to describe the organisation (enterprise), the various departments within the organisation, the domain independent and domain specific ontologies, and the different views on these ontologies.

In a nutshell, our conceptualisation of an organisation and its knowledge base is as follows: an organisation S consist of n different departments (g1,..,gn). This organisation maintains only one domain independent task ontology Y. Each of the departments maintain one domain specific task ontology (i.e., G1,....,Gn, corresponding to each of the departments g1,.., gn, respectively). The domain experts/users within each of these departments may have m different views on their domain specific task ontology (V1,...,Vm ), where m can range from 1 to °.

So, based on a specific view Vk, the knowledge engineer in collaboration with the domain expert/user will map each of the terms/concepts/phrase from the domain specific task ontology Gi to the domain independent task ontology Y. The simplest approach to realise this mapping is to firstly identify the view that is currently being considered by the domain expert/user, then in collaboration with the domain expert/user, the knowledge engineer records the mapping between a particular term/concept/phrase tp from the domain specific task ontology to the abstraction ay in the domain independent task ontology.

A limitation of the above conceptualisation is that: each department within an organisation is only able to maintain one domain specific task ontology. It is certainly possible that there may be occasions when a department may want to maintain more than one domain specific task ontology.

The proposed approach to task ontology modelling is purely manual. That is, the knowledge engineer performs the mapping in collaboration with the domain expert/user. One of our principle future research directions is to firstly implement a semi-automated mapping mechanism, then eventually a fully automated mapping mechanism. Work towards achieving these objectives is currently being carried out. The next section describes the knowledge engineering environment that can facilitate the knowledge management process within an organisation.

 

Architecture of the Knowledge Engineering Environment

Lukose (1996b) demonstrated the expressibility of MODEL-ECS, and the complex modelling constructs that one can build using MODEL-ECS. This modelling language is formed using the Conceptual Graphs, and the Executable Conceptual Graphs, which may not necessarily be highly palatable to domain experts who are not familiar with this representational formalism. This is indeed one of the major short falls for Conceptual Graphs, for it to be accepted at large for developing knowledge base systems. One certainly could not expect the domain experts to learn conceptual graphs theory, executable conceptual structures theory, canonical formation rules for graph manipulation, and state-spaced reasoning paradigm, before they can begin to model their domain specific activities (i.e., modelling PSMs).

To overcome this limitation, the author proposes a three-phase knowledge management activity. Phase One involves the construction of task ontology by the domain experts in collaboration with the knowledge engineer. Phase Two involves the mapping of the task ontology to the formal core ontology. This phase is carried out by the knowledge engineer in collaboration with the domain expert. Finally, Phase Three involves the domain experts modelling PSMs, using the domain-specific task ontology that they constructed in Phase One. This three phase development of knowledge based systems is necessary to enable ease of use (i.e., modelling using domain specific concepts, and terms), and to reuse the core knowledge base (i.e., defined using domain independent language) by other sections of an enterprise.

A knowledge engineering environment that is based on MODEL-ECS that can effectively perform knowledge management in an organisation by maintaining shareable and reusable knowledge bases is made up of the following three tools:

The three phases involved in building a sharable and reusable knowledge base are outlined in Figures 1, 2, and 3, respectively. Each of the phases are described below:

Phase One

In Phase One, as depicted in Figure 1, the knowledge engineer (along with the domain expert/user) will utilise the Ontology Manager to build the domain independent and the domain specific ontologies, respectively. One must keep in mind that the process of building these ontologies is supported by a canonical knowledge base that is based on Conceptual Graphs (Sowa, 1984), Actors, and Executable Conceptual Structures (i.e., Actor Graphs and Problem Maps) (Lukose, 1993, 1995). A tool like Conceptual Graph Knowledge Engineering Environment (CGKEE) (Munday, et al., 1996) or Deakin ToolSet (Lukose, 1991) can be used to build the supporting canonical knowledge base.

Phase Two

In Phase Two, as depicted in Figure 2, the knowledge engineer in collaboration with the domain expert/user utilises the Ontology Mapping Tool to map the domain specific ontology to the domain independent ontology. This mapping is necessary to enable the domain experts to use the sound, and well formed, domain independent ontology (i.e., with libraries of primitive and simple problem maps (i.e., generic PSMs)) to build domain specific PSMs. These mappings are then stored in the Mapping Database. Without these mappings, the domain experts are forced to use the domain independent ontology to form the PSMs (that are specific to their domain).

Phase Three

In Phase Three, as shown in Figure 3, the domain expert/user utilises the PSM Modelling Tool, and the Mapping Data, as well as the domain specific task ontology to model domain specific PSMs. The Mapping Data is used by the PSM Modelling Tool to link the domain specific and domain independent ontology. This link is maintained automatically. The domain expert/user does not have to be involved themself in maintaining the mapping between these two ontologies.

As stated earlier, the stage of being able to build both the domain independent and domain specific ontology (i.e., Phase One) is supported by a canonical knowledge base that is made up of Conceptual Graphs, Actors, and Executable Conceptual Structures (i.e., Actor Graphs and Problem Maps). In addition, complex modelling constructs (i.e., conditional construct, while loop, repeat loop, and case construct) form the building blocks for constructing complex Problem Maps (i.e., domain independent and domain specific ontologies).

Interested readers are referred to Lukose (1996a) for a detailed description on the use of Primitive and Executable Conceptual Structures, and the Complex Modelling Constructs in task ontology modelling. The following section briefly describes each of these abstractions.

Figure 1: Phase One of Task Ontology Modelling

 

Figure 2: Phase Two of Task Ontology Modelling

 

Figure 3: Phase Three of Task Ontology Modelling

 

MODEL-ECS

MODEL_ECS is composed of two forms of abstractions, and a set of complex modelling constructs. The two forms of abstractions are: Primitive Conceptual Structures; and Executable Conceptual Structures. There are two types of Primitive Conceptual Structures. They are: Conceptual Graphs and Actors. There are also two types of Executable Conceptual Structures. They are Actor Graphs, and Problem Maps. The following subsubsections will elaborate each of these abstractions and describe the complex modelling constructs.

 

Primitive Conceptual Structures

Conceptual Graphs. Conceptual graphs are finite, connected, bipartite graphs. They are bipartite because there are two different kinds of nodes (i.e., concepts and conceptual relations), and every arc links a node of one kind to a node of the other kind (Sowa, 1984, pp. 72). In diagrams (i.e., display form), a concept is drawn as a box, a conceptual relation as a circle, and an arc as an arrow that links a box to a circle. A generalisation hierarchy is defined over all the conceptual graphs.

Actors. There two types of actors (objects). They are the class (type) actor and the instance actor. Class actors are defined as abstractions. An actor hierarchy is defined over all the class actors. It responds to an incoming message by executing a method corresponding to the message.

 

Executable Conceptual Structures

Actor Graphs. Actor Graphs are the most primitive Executable Conceptual Structures. Actor Graphs use conceptual graphs to represent the declarative knowledge associated with an inference step, and an actor to represent the procedural knowledge (Lukose, 1993). An actor graph hierarchy is defined over all the actor graphs.

Problem Maps. The Problem Map is an Executable Conceptual Structure which can be used to represent task knowledge in a KADS model (Wielinga, et al., 1992). A Problem Map is formed by specifying a partial temporal ordering of the Actor Graphs (Cross and Lukose, 1994) which represent the primitive inference steps. A problem map hierarchy is defined over all the problem maps.

 

Complex Modelling Constructs

The main ingredients for building complex modelling constructs are: actor graph, problem map, conceptual relations (to enable expression of temporal relationships), and special purpose actor graphs (for expressing condition and iteration). The conceptual modelling constructs are listed in Table 1.

Conceptual Constructs

Descriptions

(FBS)

conceptual relation to indicate sequence

(SWS)

conceptual relation to indicate concurrence

[PM: { }]

problem map for implementing disjunction

[TRUE_TEST]

actor graph to indicate positive test

[FALSE_TEST]

actor graph to indicate negative test

Table 1: Conceptual Constructs

 

Assuming that f and j denote predicates (i.e., conceptual graphs) and a and b denote problem maps, the above conceptual constructs can be used to construct simple problem maps shown in Table 2.

Syntactic Representation

Semantics

[PM: a ] -> (FBS) -> [PM: b ]

do a followed by b

[PM: { [PM: a ], [PM: b ] }]

do either a or b, non-deterministically

[TRUE_TEST: f ]

proceed if f is true

[FALSE_TEST: f ]

proceed if f is false

Table 2: Syntax and Semantics of Modelling Constructs

 

Using the simple modelling constructs outlined in Table 2, we are able to build more complex modelling constructs as shown below. Again, assume that f and j are predicates (i.e., conceptual graphs), while a and b are problem maps.

 

Sequential Construct: a; b; .......

[PM: a] -> (FBS) -> [PM: b ] -> (FBS) -> ........

 

Conditional Construct: if f the a else b

[PM: { [KS: [TRUE_TEST: f ] ] -> (FBS) -> [PM: a ],

[KS: [FALSE_TEST: f ] ] -> (FBS) -> [PM: b ]

}

]

 

While Construct: while f do a

[PM: { [KS: [TRUE_TEST: f ] ] -> (FBS) -> [PM: a ] -> (FBS) -> [PM:*],

[KS: [FALSE_TEST: f ] ]

}

]

 

Repeat Construct: repeat a until f

[PM: a ] -> (FBS) -> [PM: { [KS: [FALSE_TEST: f ] ] -> (FBS) -> [PM: a ],

[KS: [TRUE_TEST: f ] ]

}

]

 

Case Construct: case f : a, j : b

[PM: { [KS: [TRUE_TEST: f ] ] -> (FBS) -> [PM: a ],

[KS: [TRUE_TEST: j ] ] -> (FBS) -> [PM: b ]

}

]

 

Using all the various types of abstractions outlined in this section, one is able to construct a task ontology (in the form of a problem map hierarchy). An example of such a problem map hierarchy is depicted in Figure 4.

Figure 4: A Simple Task Ontology (in the form of a Prooblem Map Hierarchy)

 

Future Work

In this paper, the author identified the generic knowledge management processes that are becoming quite common practice within intelligent organisations. The author then described a conceptualisation of an organisation (i.e., enterprise) and its knowledge base, and outlined how the mapping between the domain specific task ontology and the domain independent task ontology can take place, based on a particular view of the domain expert/user. Finally, the author described the architecture of the proposed knowledge engineering environment, which can facilitate knowledge management across the enterprise by enabling the construction of shareable and reusable knowledge bases (i.e., task ontology modelling). The domain independent task ontology is built using MODEL-ECS. Task ontology modelling is the key to knowledge management in an organisation. The mapping between domain specific task ontology and domain independent task ontology is crucial for realising shareable and reusable knowledge bases. This paper proposed an approach to achieving this objective.

There are limitations associated with the conceptualisation of an organisation, as outlined in Section 2. But, these limitations may be overcome by a more elaborate (detailed) conceptualisation process. Overcoming the limitations associated with the practical implementation of the mapping techniques is much more urgent. The current proposal to manually carry out the mapping functions is workable (and is currently practiced elsewhere (Ikeda et al., 1996; Aoki et al., 1996; and Kishimoto et al., 1996) quite successfully), but a semi-automated or a fully automated mapping process is required. Overcoming these limitations constitutes the future direction of this research.

 

Acknowledgements

We would like to take this opportunity to thank all the members of the Distributed Artificial Intelligence Centre (DAIC) at The University of New England for all their contributions in developing the modelling constructs described in this paper.

 

References

Aoki, C., Kurematsu, M., and Yamaguchi, T. 1996. LODE: A legal Ontology Development Environment, in Proceedings of The Pacific Knowledge Acquisition Workshop (PKAW'96), Coogee, Sydney, Australia.

Choo, C.W. 1996. The Intelligent Organisation: Mobilizing organizational Knowldge through Information Partnership.(preprints)(http://www.fis.utoronto.ca/people/faculty/choo/FIS/ResPub/IMIOart.html).

Cross, T. and Lukose, D. 1994. The representation of non-linear hierarchical executable plans, in Proceedings of the 1st Australian Workshop on Conceptual Structures, Armidale, N.S.W., Australia.

Decker, S., Erdmann, M., and Studer, R. 1996. A Unifying View on Business process Modelling and Knowledge Engineering, in Proceedings of the 10th Workshop on Knowledge Acquisition for Knowledge Based Systems (KAW'96), Banff, Alberta, Canada.

Euzenat, J. 1996. Corporate memory through cooperative creation of knowledge bases and hyper-documents, in Proceedings of the 10th Workshop on Knowledge Acquisition for Knowledge Based Systems (KAW'96), Banff, Alberta, Canada.

Gaines, B.R., Norrie, D. H., Lapsley, A.Z., Shaw, M.L.G. 1996. Knowledge Management for Distributed Enterprise, in Proceedings of the 10th Workshop on Knowledge Acquisition for Knowledge Based Systems (KAW'96), Banff, Alberta, Canada.

Ikeda M., Seta, K., Kakusho, O., and Mizoguchi, R. 1996. An Environment for Building Conceptual Model of Problem Solving, in Proceedings of The Pacific Knowledge Acquisition Workshop (PKAW'96), Coogee, Sydney, Australia.

Kishimoto, D., and Yamaguchi, T. 1996. DECIDE: An Interoperative Environment for Distributed Diagnostic Expert Systems, in Proceedings of The Pacific Knowledge Acquisition Workshop (PKAW'96), Coogee, Sydney, Australia.

Lukose, D. 1991. Conceptual Graph Tutorial, Technical Report, Department of Computing and Mathematics, School of Sciences, Deakin University, Geelong, Australia, 3217.

Lukose, D. 1993. Executable Conceptual Structures, in G.W. Mineau, B. Moulin and J.F. Sowa (Eds.), Conceptual Graphs for Knowledge Representation, Lecture Notes in Artificial Intelligence (699), Springer-Verlag, Berlin, Germany.

Lukose, D. 1995. Using Executable Conceptual Structures for Modelling Expertise, in Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop, Banff Conference Centre, Banff, Alberta, Canada.

Lukose, D. 1996a. Task Ontology Modelling, Technical Report, Department of Mathematics, Statistics, and Computing Science, University of New England, Armidale, N.S.W., Australia.

Lukose, D. 1996b. MODEL-ECS: Executable Conceptual Modelling Language, in Proceedings of the 10th Workshop on Knowledge Acquisition for Knowledge Based Systems (KAW'96), Banff, Alberta, Canada.

Mahe, S., Riue, C., and Beauchene, D. 1996. An original Model to organize Know-How in a benchmarking Context, in Proceedings of the 10th Workshop on Knowledge Acquisition for Knowledge Based Systems (KAW'96), Banff, Alberta, Canada.

Munday, C., Cross, J., Daengdej, J., and Lukose, D. 1996. CGKEE: Conceptual Graph Knowledge Engineering Environment User and System Manual, Research Report No. 96-118, Department of Mathematics, Statistics, and Computing Science, University of New England, Armidale, 2351, N.S.W., Australia.

Schreiber, G., Wielinga, B., and Breuker, J. 1993. KADS: A Principled Approach to Knowledge-Based System Development, Academic Press, London, UK.

Simon, G. 1996. Knowledge Acquisition and modeling for corporate memory: lessons learnt from experience, in Proceedings of the 10th Workshop on Knowledge Acquisition for Knowledge Based Systems (KAW'96), Banff, Alberta, Canada.

Sowa, J.F. 1984. Conceptual Structures: Information Processing in Mind and Machine, Addison Wesley, Reading, Mass., USA.

Wielinga, B., Schreiber, A.T., and Breuker, J.A. 1992. KADS: A Modelling Approach to Knowledge Engineering, in The KADS Approach to Knowledge Engineering Special Issue, Knowledge Acquisition, 4(1), Academic Press, London, UK.