WO1999066420A1

WO1999066420A1 - Generic knowledge management system

Info

Publication number: WO1999066420A1
Application number: PCT/AU1999/000501
Authority: WO
Inventors: Paul Guignard
Original assignee: Savant Systems International P; Paul Guignard
Priority date: 1998-06-18
Filing date: 1999-06-18
Publication date: 1999-12-23
Also published as: EP1095342A1; EP1095342A4; CA2334944A1; AUPP416498A0

Abstract

A computerized generic knowledge management system, comprising a multidimensional global space defined by attributes which are dimensions in the global space. Each attribute defines a feature of the external world or the internal state of the system, or actions that can be taken to modify them. There is a source space, within the global space, made up of selected attributes to define a context in which to state problems. There is a destination space, within the global space, made up of selected attributes to define a context in which to provide answers to problems stated in the source space. Mapping occurs between the source space, representing stated problems, and the destination space, representing answers expressing and embodying knowledge supplied by experts appropriate to the respective problems stated in the part of the source space.

Description

Generic Knowledge Management System

Technical Field

This invention concerns a computer technology for the design of knowledge systems, for the acquisition, modelling, storage and access of knowledge for these systems, and for the maintenance of that knowledge. This technology will be referred to as Generic Knowledge Management System (GKMS).

Background Art

Knowledge-based systems (KBSs) are a class of programs in which the knowledge about a range of problems and their solutions is stored separately from the code that is used to manipulate that knowledge to produce solutions. KBS design is different from traditional software where the knowledge about a problem and its solution is integrated into the code that processes that knowledge. Because of the separation between knowledge and its processing, KBSs, in principle, should be easier to develop and maintain and safer to use than traditional programs. However it is not the case in practice and the penetration of KBSs in industry is very small compared to spreadsheets, databases and word processors

Summary of the Invention

In a first aspect the invention is a computerised generic knowledge management system, comprising: a multi-dimensional global space within computer memory defined by attributes, where each attribute defines a feature of the external world or the internal state of the system, or actions that can be taken to modify them, and each attribute is a dimension of the global space; a source space, within the global space, made up of selected ones of the attributes to define a context, in which to state problems; a destination space, within the global space, made of selected ones of the attributes to define a context in which to provide answers to problems stated in the source space; mappings between defined parts of the source space which each represent one or more stated problems, to defined parts of the destination space which each represent one or more answers expressing and embodying knowledge supplied by experts appropriate to the respective problems stated in the part of the source space.

The system may enjoy a number of advantages. For instance, The system is able to inform a user when the answer to a problem falls outside its knowledge, that is the problem stated is outside a defined part of the source space. In this case the system is able to ask a domain expert (that is an expert in that domain of knowledge) to increase its knowledge by providing the answer and defining an appropriate part of the source and destination space and an appropriate mapping. The experts are also able to maintain the system's knowledge by correcting existing defined parts. In this way the system is able to get more knowledgeable as it is being used.

Knowledge acquisition may be incremental and interactive. In addition the knowledge is certified, that is verified and validated, by the expert at acquisition time. Since the system knows the limits of its knowledge it is able to restrict the use of its knowledge to situation it recognises, that is to problems that fall within the regions in the source space. These regions have been approved by domain experts.

Such systems can form natural extensions of human beings for the management of their knowledge. It is possible for humans to use the system to store knowledge, retrieve it, modify it, extend it and share it with other experts and with users who are not experts. Domain experts can use such systems as repositories of their knowledge and as tools for the development and codification of new knowledge acquired as they gain experience in their domain of expertise.

The defined parts of the source and destination spaces may be points or regions. The destination space may also be part of the source space. The two spaces can overlap.

The mapping process can be explanations or actions. Explanation mappings are not calculated, they are stated. Explanation mappings are associated with code which enable the outcome to be displayed on a screen or printer. Action mappings may associate a sitLiation in the source space to actions expressed in the destination space. In this case the destination space is made of instructions to be carried out by agents. Alternatively, action mappings may be specified by a function or module that can be calculated, using the values of the source attributes that define the situation as parameters. The result of these mappings are attributes which can take values.

Source and destination space editing sub-systems may enable authorised users to define and modify the destination and source spaces or contexts.

A mapping editing sub-system may enable experts to define mappings which embody knowledge. This sub-module may present the expert with the source context which allows the selection of attributes which belong to a region and the specification, for each attribute, of the range of values which mark the borders of the region in each dimension, each attribute is a dimension. The region specifies the conditions which determine whether a mapping can fire. The process is similar for the destination space. The two regions are then linked and identified as a mapping.

The defined parts of the source context determine when a mapping can fire. This process is 'location independent'; that is, it is independent from where the mapping is located in a system. Location independence is seen as a major advantage in that it frees developers from the issue of location.

Processing behaviour depends only on the conditions for a mapping to take place, expressed as a defined part in the source space. There is however an additional load put upon the system that now has to find which mapping applies next, a requirement that is taken care of in normal programming by the location of the code.

A composite system may comprise a collection of systems in which the source contexts of the systems are united, the destination contexts of the systems are united and the mappings of the systems are united to form the composite.

A composite system made of systems with overlapping contexts is referred to a knowledge base. Composite systems can be concatenated or grouped to build larger knowledge bases.

A query definition sub-system may enable a user to define a query in the source space, or a process to perform the role of a user. In effect, the user defines a situation for the knowledge processing module to act on. Each object or attrib ite in the source space can take three values in an inquiry: 'specified', 'don't know' and 'unspecified'. The query definition can be non-interactive, in which case the system presents the user with the complete source space. The user then specifies a situation and the system looks for regions compatible with the query. If there are compatible regions, then their outcomes are presented to the user. If there isn't any compatible region, the user is informed.

Alternatively the query definition may be interactive, in which case the system presents the user with one or a few questions at a time for the user to answer. Once it is done, the system processes the answers and determines the next best questions to ask. The best questions are those that lead to the mappings, that is regions, compatible with the query with as few questions as possible. When the system has identified a compatible region, then it presents its outcome to the user. If the system cannot find a compatible region, it informs the user.

A hybrid query definition is also possible where the system presents the user with several questions grouped logically, that is addressing a single issue. Once the user has answered these questions, the system presents the next group of questions, or single question, as the case may be.

Knowledge processing may be used to identify whether there are regions that are compatible with the inquiry. Knowledge processing starts with a list of candidate regions or mappings, initially all the regions in the knowledge base, and on the basis of the objects specified in the inquiry, that is the vahies of the dimensions in the source space, determines: the regions that are ruled out by the inquiry; the regions that are compatible with the inquiry; and the regions that are undetermined, that is. the regions for which one cannot say whether they are compatible or ruled out because some questions have not yet been asked.

The process may stop when: there are no more candidate regions or mappings; there are no more undetermined regions or mappings; or there are no more objects whose values have not been determined. In non-interactive processing the system takes as input the query defined by the user and looks for regions in the source space that are compatible with the query. A region is compatible with the query if the region contains (as defined) the query. This means that the value of each object in the region contains the value of the object in the query In interactive processing the system calculates the discriminating power (as defined) of each object, or dimension, in the source space the value of which has not yet been specified. Once the discriminating power of each object is calculated, the system asks the questions with the highest discriminating power. If several objects have the same discriminating power, then the system either presents all the related questions or selects one of them only for presentation to the user. Once the user has supplied the answer(s) related to the object(s) with the highest discriminating power, the system uses the answer(s) to remove from the list of candidate all the knowledge items that are ruled out by the answer. The process described above is then repeated. Interactive processing can be either forward chaining or backward chaining.

In another aspect the invention is a data acquisition method for a computerised generic knowledge management system, comprising the steps of: inspecting a problem that either has no answer or an answer which is deemed to be inadequate, that is a problem for which there is no defined part of the source space; specifying attributes, and if appropriate, explanations relevant to the problem; defining the solution to the problem; generalising the source context to generalise the inquiiy to a larger part of the source space; and saving the knowledge item generated. The solution may be defined after the source context has been generalised.

An inquiiy may be accompanied by a message from the user who filed the inquiry. The message may describe the inquiry more specifically or in more details. The context, of either the so irce or destination may be reduced or enlarged. New attributes can be added.

Knowledge items or mappings need to be ordered according to their fit with the enquiries. This applies to definite outcomes only or to definites and candidates outcomes. The fit is determined by three factors: 1. Weight of each source attribute, weights may not all be equal. 2. For definite and candidate knowledge items: proportion of attributes in the inquiry which are satisfied by the region attributes; that is attributes belonging to the region of the knowledge item.

3. For definite and candidate knowledge items: proportion of the attributes in the source context which belong to the region of a candidate knowledge item.

Domain experts need to manage the knowledge base from the point of view of knowledge comprehensiveness, consistency, quality, etc. The tools available to assist them are to: Detect overlapping knowledge items, in their source and/or destination to ensure they are compatible.

Identify knowledge items with a specified combination of source and destination attributes or values

Edit existing knowledge items. Inspect history of knowledge items in the system:

- list of knowledge items (active and deactivated)

- when created, by whom.

Brief Description of the Drawings Examples of the invention will now be described with reference to the accompanying drawings, in which:

Figure 1 is a diagram showing knowledge in the cognitive model.

Figure 2 is a cognitive model reasoning flow chart.

Figure 3 illustrates the mapping from source space to destination space.

Figure 4 is a block diagram illustrating the composite GKMS module design.

Figure 5 is a block diagram showing the network of GKMS knowledge bases. Figure 6 is a flowchart showing knowledge processing.

Figure 7 is a diagram of the elementary GKMS model architecture.

Figure 8 illustrates the definite and candidate knowledge items.

Figure 9 illustrates the definite and candidate knowledge items.

Figure 10 illustrates the architecture for a computer system based on the cognitive model. Figure 11 is a block diagram of the architecture for a user only system based on the cognitive model.

Best Modes of the Invention The Cognitive Model

The invention is based on a cognitive model in which expertise is applied locally and then an attempt is made to generalise. That is, a domain expert first determines the attributes necessary to define an explicit global context for a class of problems and solutions. The domain expert then specifies problem and solution contexts within the global context using the attributes. The domain expert then defines a specific problem within the problem context using the attributes. The domain expert next provides a specific answer to the specific problem. Finally the domain expert expands the specific problem into a region of the problem context where the same specific answer, taking account of its context, is deemed by the expert to hold.

Once a region of a problem and an answer have been produced by a domain expert, this knowledge can be used by non-experts to find the answer to problems that fall within the region. A useable system requires the definition of several, sometimes many, regions and associated answers. These regions are typically defined when a problem is encountered for which there is no existing answer in the system, that is. the problem does not fall within an existing region. Alternatively, the domain expert can decide to define regions in the problem space based on hypothetical problems.

A knowledge item consists of a region of a problem and its associated answer, both defined in their respective contexts, and it may be expressed as a mapping. The model assumes that knowledge has no global validity, but that knowledge is inseparable from its context. This is represented in Figure 1 where the global context is a space with attributes along the axes. In Figure 1 there are six regions in a 2-Dimensional problem plane. The precise problems that triggered the definition of the regions are shown as • in the plane, and six corresponding answers are shown as • on the "answers" axis. Notable features are: 1. The regions can be of different shapes and sizes, as judged appropriate by the domain expert.

2. The precise problem does not need to be in the centre of the region. Again this is judged by the domain expert. 3. Some regions can be defined without being prompted by a precise problem. In this case there is no • in the region (region r4 in Figure 1).

4. Separate regions can have the same answer. This could mean that the domain expert took a conservative approach at the time of the region definition and certified the answer only in a small region. Later, when defining another region, perhaps prompted by a different precise problem, the expert gave the same answer but again felt confident only with respect to a small local region.

5. Regions can overlap. In this case a strategy must be developed to select the appropriate answer among the several that may be possible. Although the answer space is represented as a single axis in Figure 1, it usually is multidimensional, with each outcome being a partition of the total solution space.

Knowledge Acquisition The process followed by a system based on the model for knowledge acquisition is illustrated in Figure 2. The process steps are:

1. The system invites a user to define a specific problem.

2. The system checks whether the problem falls within a region defined in the problem context.

3. If it does, the system gets the answer corresponding to that region and gives it as answer to the new problem.

4. If the problem does not fit inside a defined region, then the system informs the user that no answer can be given at this stage. 5. The system then refers the problem to a domain expert who: a) specifies the answer to the problem, and b) defines a region or mapping for that answer.

6. The system then links the region with the answer and adds both to its knowledge base. This new knowledge now becomes available for all subsequent users of the system. With respect to point 5 above, the domain expert vouches for the region and its answer. In effect this verifies the answer is the appropriate one for the problem, and validates the answer is relevant in the context.

Knowledge Representation Features

Knowledge is local in that each knowledge item is a problem region and its answer in a global context which determines the types and ranges of problems that can be addressed. It is the role of domain experts to use their experience and judgment to define the global context. Because of the local property of knowledge in the model, it is possible to define a global context with a different number of attributes, or dimensions, for different knowledge items, and for the problem regions and the answers.

Knowledge Acquisition Features With reference to Figure 2, the key features are:

1. Knowledge acquisition is incremental, usually prompted by an enquiry about a specific problem.

2. A system is useable even when little knowledge is included in it. As the system is used, more knowledge is entered and the usefulness grows. 3. Only useful knowledge, that is knowledge relevant to specific problems, is acquired. (Since domain experts can define regions and outcomes without being prompted by enquiries, it is possible to include non- useful knowledge in the system, that is knowledge that will not be of use in dealing with practical problems. This is however unlikely to happen to any significant extent in practice.)

4. Knowledge is verified at acquisition time. That is, the domain expert vouches for the applicability and relevance of the knowledge to all situations and problems that fall within the region. This is because the definition of most of the knowledge items stored in the system is triggered by specific problems. The expert can be either very conservative and define a small region or more confident and define a larger region. When regions and outcomes are defined without being prompted by a specific problem, then the regions defined may have little relevance to the intended domain of applications for the system and one cannot claim that these knowledge items are validated. 5. The knowledge items have independent validity. An item can be removed without affecting the validity of the other items of the system. The rest of the system is still useable. A knowledge item can be removed and replaced by another. In a similar way, a region or its outcome can be modified without affecting the validity and the operations of the rest of the system. The system is therefore robust. In contrast traditional rule-based systems are not rob ist in that they can be drastically affected by any changes in the rule base. ■ 6. The knowledge items may be independent of each other. However, where new knowledge items are defined from new enquiries that do not fall within existing regions they may be dependent. The definition and storage of new knowledge items is in part determined by the knowledge already existing in the system.

The Reasoning Process consists of:

1. Knowledge acquisition support

When a new region and answer is being defined by a domain expert, it can happen that this region overlaps with previously defined regions.

Support is required to let the domain expert know that these overlapping regions exist and to assist them in viewing them. The domain expert then can opt to: a. modify the new region or its outcome, or both, appropriately. b. modify one or several already defined regions or their outcomes, or both, provided the domain expert has the authorisation to do so. It is not necessary to remove all overlaps between regions. A case contained by several regions may have several possible or complementary- answers, one from each region containing it. It is also possible that two regions have the same outcome. In this situation, the answer is the same whatever region one selects. Knowledge acquisition support is not mandatory. It is possible, for example, to simply give as answer to an enquiry at run time the outcome of the most recent region containing the enquiry. 2. Solution Search Processing, consisting of: a. Finding the regions that contain the enquiry. This can be done in two ways:

- A non-interactive search: Selecting the region or regions most relevant to the enquiry

Retrieving the outcome or outcomes corresponding to these regions.

Presenting these outcome in the appropriate way to the user. - An interactive search: defining the enquiry as completely as possible finding the regions that contain it.

Interactive searching then involves asking the user only these questions about the problem that enable the system to arrive at a solution as quickly as possible. Each question elicits some features about the enquiiy and directs the search towards the most relevant part of the problem space.

Some features of an enquiry may not be asked as they apply to regions in a part of the problem space that has already been found as being irrelevant to the enquiiy. Interactive searching can be achieved, for example, by measuring the "regions discriminating power" of each feature in the problem space and by asking, at each step in the inferencing process, only about these features that have the highest discriminating power.

The Elementary GKMS Module

The elementary GKMS module is the basic building block for all GKMS implementations. It comprises a source context or space, a destination context or space, and a mapping that can be action or explanation (that is, at least one knowledge item).

The source space is made of attributes or objects that enable the expert user to define situations. The source space typically contains attributes that define the external world. However it can also contain attributes that define the internal state of the system. When it is the case, mappings can be used to take actions based on the state of the system, that is, mappings can be used to control the behaviour of the system.

The destination space is made of attributes that describe actions, events, statements about the external world. It specifies the actions that can be taken to modify the external world or the internal state of the system.

The destination space can also be part of the source space. The two spaces can overlap.

The mappings express and embody the knowledge supplied by experts to provide answers, expressed in the destination space, appropriate to the sit iations described in the source space. A mapping is a relationship between part of a source space onto part of a destination space, typically from a situation or group of situations in the source space onto an outcome in the destination space. In Figure 3, all the situations in the source space which are part of the region are linked to the same outcome. Both spaces are multi-dimensional.

The curved arrow, with its attendant source and destination spaces, its region from the source space to its outcome in the destination space represent the mapping. It specifies a region in the problem space and a way to produce an outcome when the conditions of the problem place it within the region. The mapping process can be explanations or actions. The source and destination spaces define the context for the mapping..

Explanation Mapping

Explanation mappings are defined by their source and their destination. They are not calculated, they are stated. Explanation mappings are associated with code which enable the outcome to be displayed on a screen or printer.

Action Mapping

Action mappings come in two types: - Type 1 mappings associate a situation in the source space to actions expressed in the destination space. The destination space, instead of being explanations as in explanation mappings is made of instructions to be carried out by the some agents.

- Type 2 mappings are specified by a function or module that can be calculated, using the values of the source attributes that define the situation as parameters. The result of type 2 mappings are attrib ites which can take values. Programming can be viewed as the calculation of action mappings, one after another.

Action mapping examples:

• A workflow module in which the action to be taken by the system, outcome, are predicated by a situation described in the source space (type 1).

• An equation with variables and constants that are part of the source and destination spaces (type 2). • A procedure or function (algorithm) (type 2). The regions in the source space can be small or large. Regions can overlap and have SLib-regions. The outcome can be a point or a region in the destination space. The mapping process described above is a generic process that covers all that can be expressed using logical and mathematical expressions.

Time can be an attribute, or object, both in the source and destination spaces.

The elementary GKMS module supports the following functions: A source and destination spaces editing sub-module A explanation mapping editing sub-module An action mapping editing sub-module A knowledge base A query definition sub-module A processing sub-mod ile A svstem behaviour sub-module

The GKMS module has two types of users:

The expert or experts who are responsible for defining the source and destination spaces, and for entering and managing the mappings, or knowledge, in the module. They are accountable for the accuracy and currency of the mappings, or knowledge.

The non-experts, or users, who defines enquiries interactively with the system, with a view of getting knowledge, such as advice and recommendations, from the system. These are the results of actions carried out by the system.

Source And Destination Context Editing Sub-Module

This sub-module enables authorised users to define and modify the destination and source spaces or contexts. These spaces are constructed out of attributes or objects. Contexts are defined as a hierarchy of attributes which are categorised in groups of folders. This is similar to the file system on a personal computer, with enables users to organise their files or documents in folders and subfolders. Context editing enables experts to define attributes or objects used to describe the conditions for a mapping to take place (source context) and the range of possible outcomes of mappings (destination context). It also enables the experts to organise these attributes in folders and subfolders. The source and destination contexts represent the domain in which mappings (or knowledge) are expressed. As such experts need to include in the source and destination contexts all the relevant attributes which define the domain of applicability of the mappings. Table 1 shows these objects with their properties and types. The dimensions of the source and destination spaces are equal to the number of objects or attributes in these spaces. Table 1: Context objects and their properties

Description Properties

Can act Object number as a folder Title and/or attribute Object type (folder or attribute)

As folder: Has members (objects) container for Some or none of its objects specified other objects, M iltimedia explanation (each attribute can be identifies a explained by the expert) class Date created

As Author attribute: Status: active or deactivated (a deactivated attribute is specifies part of one that is no longer part of the current context and cannot a condition, an be used) explanation or Mappings it belongs to an action When attached to a mapping:

- complete source and destination contexts available when mapping was defined

- importance level in determining whether the mapping can fire

- confidence level that the attribute belongs to the outcome

Attribute type (explanation or action)

Explanation: list, logical, numeric, text, constant and their allowed values or ranges of values

Relationships between values: any, all, not • Action: software, its inputs and outputs

Table 2: Context object definition

The implementation of this sub-mod ile can be done easily using modern software development tools.

Mapping Editing

Mapping editing enables experts to define mappings which embody knowledge. Mapping definition takes place in the source and destination contexts. Experts define a region in the source space, and attach it to an outcome in the destination space, the outcome can also be a region. This sub-module presents the expert with the source context which allows the selection of attributes which belong to a region and the specification, for each attribute, of the range of values which mark the borders of the region in each dimension, each attribute is a dimension. The region specifies the conditions which determine whether a mapping can fire. The process is similar for the destination space. The two regions are then linked and identified as a mapping. Each item is an object in the GKMS module.

The two contexts, source and destination, are explicit and, jointly, form the domain of discourse or expertise for the mapping. Mappings represent knowledge with respect to their explicit domain of discourse. This point is very important as any form of knowledge is context dependent; that is, it is associated to an explicit domain of discourse. When a mapping is dissociated from its domain of discourse (by expressing only its region and outcome without specifying the complete so irce and destination contexts for example) then it ceases to represent precise and reliably useful knowledge. As source and destination contexts can vary, a module can contain mappings each defined with respect to a different domain of discourse.

The elementary GKMS module enables experts to define knowledge in the form of explanation or action mappings, which is explicitly context dependent.

The region in the source context determines when a mapping can fire. This process is 'location independent'; that is, it is independent from where the mapping is located in a system. This can be contrasted to usual programs where the knowledge about the processing is located in the code itself and the operations depend on the location of the code in the program. Location independence is seen as a major advantage in that it frees developers from the issLie of location. Processing behaviour depends only on the conditions for a mapping to take place, expressed as a region in the source space. There is however an additional load put upon the system that now has to find which mapping applies next, a requirement that is taken care of in normal programming by the location of the code.

Explanation Mapping Editing

This sub-module enables experts to define and edit mappings, or knowledge items, of the explanation type. Table 3: Object range specification for source and destination attributes in ex lanation ma in s

The specification 'does not matter' can be either explicit or implicit. In the first case, the expert has to specify the range (even 'does not matter') for each object in the region in the source space. In the second case, the objects are assumed to have the default value 'does not matter' unless a range or value is specified.

When an object in the destination space is attached to a region, that is the object becomes part of the outcome of an inference process, then it automatically becomes a member of the so irce space, preferably into a folder labelled 'inferred objects'. An 'inferred object' can also be identified with an icon or a colovir and be located anywhere in the source space list. When an inferred object is attached to a region in the source space, then the source and destination spaces are said to be overlapping. When an inferred object is attached to a region, the region is then labelled as 'inferred region' (an inferred region has at least one inferred object). Objects and regions that are not inferred are also described as primary objects and regions.

Figure 1 illustrates explanation items in the source-destination context. The • in all regions except r4 indicate that an enquiry was presented for which there was no answer. The system then presented the enquiry to an expert who attached it to an outcome. The expert defined a region around the enquiry so that all future enquiries falling inside the region produce the same OLitcome. This last step add usefulness to the knowledge stored in the System as the item becomes applicable to a range of situations rather than to one situation only. The explanation mapping is specified by the properties listed in Table 4.

Table 4: Explanation mapping definition

Properties (fields) Explanation Title

Action Mapping Editing

This sub-module enables experts to define and edit mappings, or knowledge items, of the action type.

Table 5: Object range specification for source and destination attributes in action ma in s

Numeric variable Specify compatible range, or

Specify complement of compatible range

Specify 'does not matter'

Date/time variable Specify compatible date or range of dates Specify complement of compatible date or range of dates

Specify 'does not matter'

Text variable Specify exact or partial compatible match, or Specify complement of exact or partial compatible match 1

Specify 'does not matter'

Action object Specify compatible states (specify input and/or otitput states or ranges)

Specify complement of compatible states

Specify 'does not matter'

Automated activation of object or user controlled activation

The action mapping is specified by its properties as listed in Table 4. In an action mapping, the expert specifies the objects, typically numeric and logical, that are the input to the mapping and then defines the mapping. The output is computed, not specified in a static way as for explanation mappings. The mapping is defined as follows:

• The expert selects the source space objects that go into the mapping computation.

• The expert selects or defines an operation or computation. All the system needs to support initially are the elementary mathematical and logical operations. Do Loops (Do While, Do Until, etc) may also be included as part of the 'primitive' operations. However, if one deals with low level programming, the primitive set may include the operations that are carried out on the registers in a microprocessor.

• The outcome is the result of the computation. It automatically becomes part of the destination space and part of the source space (preferably into a folder labelled as 'calculated outcomes'). The last point ensures that action mappings can be chained to produce arbitrary complex calculations. It means that the source and destination spaces overlap.

There is a similarity between the software objects mentioned earlier and the action mappings described here. An action mapping is defined in the

GKMS environment whereas a software object has been defined elsewhere; it could be part of a library of procedures for example.

If an action object is part of the destination space, then the region in the source space specifies the conditions when the software object becomes part of the outcome. At access or run time an action object as part of the outcome can mean:

• Modify the object and put it in the state specified in the outcome.

• Activate the object automatically (atttomated activation, using the input state the object is in) . • Give user option to activate the object (user controlled activation, using the input state the object is in).

The Composite GKMS Module

A composite GKMS module is a collection of elementary GKMS modules. It comprises the same elements as the elementary GKMS module.

These elements in the composite module are expressed as the union of the corresponding elements in the elementary module.

Table 6: Elements in the com osite GKMS module

It is frequent that the elementary modules which comprise the composite GKMS module have the same source and destination contexts.

Figure 4 illustrates the GKMS model with the source space comprising subsets of the destination space and internal state of the system. The input into the source space comprises elements of the external world, of the destination space and of the internal state. It is also possible to have the output included which becomes a subset of the destination space component of the input. A composite GKMS module made of elementary modules with overlapping contexts is referred to a knowledge base.

A "composite GKMS" is likely to have knowledge items that have different source and destination contexts. Here we explain how the relevant information is presented to users so that they can make their own evaluation as to the validity of the context used in the knowledge item (and which affects the validity of the advice).

For users to assess the validity (if they wish) of the advice offered by the GKMS, they need to be able to see the source and destination contexts. The source context tells users whether the person who entered the advice considered enough issues for defining the applicability of the knowledge. For example, advice about diet may use a context that does not consider the daily physical activity of the person accessing the advice. An elite sports person may decide, on inspecting the source context, that the provider of the advice did not consider all the relevant issues and discard the advice. Conversely, the sports person may decide to accept the advice, even if unexpected, if he/she can see that it the advisor did consider level of physical activity as relevant.

The destination context specifies the range of possible solutions that an advisor considers applicable to the range of problems it is dealing with.

For example, an advisor may reject a range of foods (say, poultry) for animal rights reasons. A user may decide to reject the advice because, by inspecting the destination context, it can see that this advisor had a particular view about food that was affected by issues unrelated to diet (i.e. animal rights). Conversely, another user may choose to take this advice because the destination context rules out poultry food.

At the implementation level, each advice, when viewed, offers the option (via a button) to inspect the source and destination contexts associated with the knowledge item.

Concatenation Of Knowledge Bases

Composite GKMS modules can be concatenated or grouped to build larger knowledge bases. When composite modules have overlapping contexts they are described as overlapping knowledge bases. When they have non- overlapping contexts they are described as disjointed or independent knowledge bases. When independent knowledge bases need to be concatenated, then relationships between the knowledge bases need to be made explicit. For example part of the destination context of one composite module can become part of the source space of another module. Another possibility is that both the source and destination of the two composite modules overlap.

In some situations the contexts of the knowledge bases are disjoint. In this case, the link between the two knowledge bases is done by defining another module or knowledge base which links and explains some elements of the contexts of the independent knowledge bases. For example, see Figure 5, the destination space of one module becomes the source space, or part of the source space, of another GKMS module. Module 0 is a source GKMS to the destination modules 1 and 3 and module 2 is a source GKMS to module 0. The networking of GKMS modules gives flexibility for knowledge management and accountability. For example, module 0 could deal with the hardware aspects of a microprocessor device, module 1 with the low level software, module 2 with application software. Each module can have different domain experts who are responsible for the quality and currency of the knowledge for their module only.

Knowledge certification in networked modules can be either local or global. Local certification is when each GKMS module is certified independently of the other modules. A change to the destination space of a source module, say GKMS 0 in Figure 5, does not affect the certification of the destination module GKMS 1 and 3 in Figure 5. Global certification requires all destination modules to be re-certified when a change takes place in the destination space of a source GKMS.

At the implementation level, the expert is presented with a diagram (graphics) similar to that in Figure 5, without the connecting arrows. The expert then can add the connecting arrows to define the links between the GKMS modules. By clicking on a module, the expert is taken to the module itself and has access to all the functionality of the elementaiy GKMS module.

For processing, the structure above is collapsed onto a single two layer structure, a single source space and a single destination space.

Query Definition Sub-Module This sub-module enables a user to define a query in the source space, or a process to perform the role of a user. In effect, the user defines a situation for the knowledge processing module to act on. Each object in the source space can take three values in an enquiry: i) specified, ii) 'don't know' and iii) 'unspecified'. The query definition can be one of two modes:

Non-interactive enquiry

The GKMS presents the user with the complete source space. The user then specifies a situation and the GKMS looks for regions compatible with the query. If there are compatible regions, then their outcomes are presented to the user. If there isn't any compatible region, the user is informed. In this case, the query can be transmitted to an interactive enquiiy.

Interactive enquiry

The GKMS presents the user with one or a few questions at a time for the user to answer. Once it is done, the GKMS processes the answers and determines the next best question(s) to ask. The best questions are those that lead to the mappings, that is regions, compatible with the query with as few questions as possible. When the system has identified a compatible region, then it presents its outcome to the user. If the system cannot find a compatible region, it informs the user.

Hybrid enquiry

The GKMS presents the tiser with several questions grouped logically, that is addressing a single issue. Once the user has answered these questions, the system presents the next group of questions, or single question, as the case may be.

Knowledge Processing

Knowledge processing is the process tised by GKMS to identify whether there are regions that are compatible with the enquiiy. Knowledge processing starts with a list of candidate regions or mappings, initially all the regions in the knowledge base, and on the basis of the objects specified in the enquiry, that is the values of the dimensions in the source space, determines: a) the regions that are ruled out by the enquiry; b) the regions that are compatible with the enquiry; c) the regions that are undetermined, that is, the regions for which one cannot say whether they are compatible or ruled out because some questions have not yet been asked.

The process is described with reference to Figure 6. The processing stops when: a) there are no more candidate regions or mappings b) there are no more undetermined regions or mappings, or c) there are no more objects whose values have not been determined. Processing can stop with several outcomes: a) There is at least one or more regions compatible with the enquiry b) There is no region compatible with the enquiry.

In the second case, the user is informed and the query is stored and presented to an expert who then defines a mapping, action or explanation, with a region and an outcome, with the region containing the enquiry.

Location Independence

The process described above is 'location independent'. The knowledge that drives the processing resides in the mappings. This can be contrasted to usual programs where the knowledge about the processing is located in the code itself and the operations depend on the location of the code in the program. Location independence is seen as a major advantage in that it frees developers from the issue of location. Processing behaviour depends only on the conditions for a mapping to take place, expressed as a region in the source space. There is however an additional load put upon the system that now has to find which mapping applies next, a requirement that is taken care of in normal programming by the location of the code.

Location independence is seen as particularly advantageous in 'inference chaining'.

Non-Interactive Processing

The GKMS takes as input the query defined by the user and looks for regions in the source space that are compatible with the query. A region is compatible with the query if the region "contains" the query. This means that the value of each object in the region contains the value of the object in the query. See Table 7 below for the meaning of "contain". This applies whether the 'does not matter' is explicit or implicit in the regions, but the system must check all objects in the source space and the dimension, number of space dimensions required to specify the region, of each region is equal to the dimension of the source space. This can be a significant computing overhead when many dimensions have values 'do not matter' in the specification of the region.

It is possible to store regions with less memory space if the dimensions that do not matter are not included explicitly in the regions. Only the dimensions with specified values are explicitly identified. At processing, unspecified dimensions of regions are taken to have the value 'does not matter'. Alternatively, and it is equivalent, the system can check that all dimensions specified in the regions are contained by the objects specified in the query. In this case a region contains a query if the query contains the compacted form of the region. This is computationally advantageous. Table 7: Meanin of "contain"

Practically, users only define the values of the objects that are deemed relevant to the enquiry. Some objects may be left unspecified but this could mean that: i) the user does not know the value of these objects in the problem/situation at hand or ii) the user erroneously considers these objects as being irrelevant to the enquiry. Two processing approaches can be taken: a) 'don't knows' are treated as equal to 'unspecified' and vice versa. In this case GKMS considers all the objects or dimensions in the source space for processing. The system is able to determine which regions are compatible with the enquiiy. All the other regions are deemed incompatible with the enquiry. b) 'don't knows' are different from 'unspecified'. In this case the GKMS only considers the objects whose values have been specified for processing. On the basis of this limited number of dimensions, the system (GKMS) determines which regions are compatible, which are ruled out and which are still candidates: ruled out regions are those that are not compatible with the enquiry on the basis of the specified objects in the enquiry. compatible regions are those that are compatible with the enquiry on the basis of the specified objects in the enquiry and for which all the unspecified objects or dimensions have values (in the region) equal to 'does not matter'. candidate regions are those that are compatible with the enquiry on the basis of the specified objects in the enquiry and for which some of the unspecified objects or dimensions have values (in the region) that are not

'does not matter'.

When some candidate regions still exist, the system moves to an interactive processing mode to determine whether some of these candidate regions may be compatible with a more precise enquiry, as will now be described.

Interactive Processing

The system calculates the 'discriminating power' of each object, or dimension, in the source space the value of which has not yet been specified. The discriminating power can be calculated in 2 ways: a) Calctilate the number of regions, or mappings, for which the value of the object does matter. The discriminating power is the number divided by the number of regions in the candidate list. This assumes that the number of regions for each of the legal values of the object is approximately the same. b) Calculate the number of regions, or mappings, for which the value of the object does matter, for each possible value of the object; the range of values for each object is divided in segments. The discriminating power is the average number of regions per segment, multiplied by the number of segments and divided by the number of regions in the candidate list. This number is weighted with (in the first instance, divided by) its variance (the lower the variance the higher the discriminating power).

Table 8: Segment identification in the calculation of the discriminating power

Once the discriminating power of each object is calculated, the system asks the question with the highest discriminating power. If several objects have the same discriminating power, then the system either presents all the related questions or selects one of them only for presentation to the user. Once the user has supplied the answer related to the object with the highest discriminating power, the system uses the answer to remove from the list of candidate all the knowledge items that are ruled out by the answer. The process described above is then repeated, that is, the discriminating power of each non-specified object or dimensions in the remaining candidates is then calculated, etc. This is carried out until there are no more candidate regions, no more undetermined regions or no more dimensions for which the values have not been ascertained.

Forward And Backward Chaining

Interactive processing can be either forward chaining or backward chaining. Forward chaining processing selects, via the interactive question/answer session, the next best question that will identify the region, if any, that contains the query.

Backward chaining processing selects, via the interactive question/answer session, the next best question that will identify the region, if any, that is compatible with the desired outcome. With backward chaining, users can define a desired outcome by selecting from the objects in the destination space and then find out whether their situation applies. The desired outcome may require the situation to be described by more than one region. In backward chaining the system calculates the discriminating power of source dimensions as follows: a) Calculate the number of knowledge items for which the value of the objects in the desired outcome do matter. The discriminating power is the number divided by the total number of outcomes. This assumes that the number of outcomes for each of the legal values of the object is approximately the same. b) Calculate the number of knowledge items for each possible value of the objects in the desired outcome; each object value can be divided in segments. The discriminating power is the average number of regions per segment weighted with (in the first instance, divided by) its variance (the lower the variance the higher the discriminating power).

Non-interactive processing can also be backward. In this case users define a desired otitcome and the systems informs them of the regions, if any, that are compatible with the stated outcome. The system does that by finding which existing outcomes in the knowledge base contain the target outcome and then selects the ones with the number of stated dimensions nearest to the number of stated dimensions in the target outcome. If no region is compatible, the system can calculate which dimensions of the outcome would need to be changed for the modified outcome to be compatible with a region, by the system finding which outcomes in the knowledge base has the nearest number of compatible dimensions, either too many or too few, with the desired outcome. The system then presents these outcomes.

Hybrid Processing

Hybrid processing takes place when a user starts by defining an enquiry in a non-interactive way, using a subset of all the dimensions in the source space, either the system presents only a subset or the user makes use of only a subset. The system then selects the knowledge items compatible with the enquiry and, if there are more than one, guides the user to the most appropriate knowledge item, if any. using interactive processing.

Sub-Regions

It can happen that the system identifies one or several regions that are compatible with the enquiry. The system may also detect that there are still regions that are candidates with the enquiry, that is, knowledge items that have not been eliminated on the basis of the information supplied by the user, either by specification of an enquiry in a non-interactive way or by answering the questions asked by the system so far. In this case, the system moves into a non-interactive processing mode to determine which is the best next question to ask in order to identify the most appropriate knowledge item. This situation happens when not all dimensions have been specified, and also when a region has sub-regions. While the region is compatible with the enquiry defined so far, a more precise answer may be given if the problem situation can be determined to, in fact, belong to one of the sub- regions. The system identifies sub-regions by checking whether a region contains another (see Table 4 for the meaning of 'contain').

Inference Chaining

Inference chaining uses inferred objects, inferred objects are a members of the destination space, attached to primaiy regions r(i) in the source space, which are themselves part of inferred regions, say r(j), in the source space. When the value of an inferred object is 'true' or valid, then the inferred region r(j) it is part of in the source space can become part of an answer to an enquiry if the other required conditions are satisfied. The outcome attached to inferred region r(j) is then the (or a possible) answer to the enquiry. This chaining effect can be repeated as many times as an expert wishes.

Inference chaining applies to explanation and action mappings.

As explained above, the property of 'location independence' of GKMS processing is a major advantage for software developers in that it frees them from the need to consider not only the code but also its location to determine its impact on the behaviour of the system.

Collapsing Regions

Inference chaining is based on objects whose value is the outcome of an inference. A question arises regarding their discriminating power. The discriminating power of inferred objects does not need to be calculated. Only the discriminating power of non-inferred objects is calculated. An outcome attached to a region which has inferred objects is selected when its 'collapsed equivalent' region is compatible with the enquiry. The 'collapsed equivalent' region is the region obtained in the source space when all the inferred objects are replaced by the objects in the region to which they, the inferred objects, belong. By collapsing the regions, one can also determine whether the inference chaining is consistent. That is, whether some objects in the inferred regions are required to take two different values for the chain to be inferable to the end. That is whether a primary region requires a certain value to an inferred object to be activated which in is a member of another region that requires the same object to take a different, incompatible value for the inference chain to continue.

Alternative Knowledge Processing

Knowledge processing can be carried out in a few steps:

1. Identify the ruled-out regions (that is, identify the compatible and undetermined regions).

2. Discriminate between compatible and undetermined regions.

3. Order compatible regions according to their specificity to the questions asked and answered so far. 4. Order the undetermined regions according to their relevance to the enquiry defined so far.

5. Select and order the questions that should be asked next.

1. Identify the compatible and undetermined regions (that is, the regions which are not ruled-out). This is done in three steps, for each knowledge item in the candidate list: Step 1: Identify the regions (or knowledge items) which can be compatible or undetermined regions. This is done by identifying the regions in which at least one object (question) is present in the source region of the knowledge item with the correct value (that is, with the value given in the answer being part of the region).

Criterion 1: objectl-valuel | object2-value2 | ... | objectN-valueN

This reads as: For a region

(knowledge item) to be compatible or undetermined, one needs:

objectl with value 1 in enquiry is present in candidate region, or object2 with value2 in enquiry is present in candidate region, or

objectN with valueN in enquiry is present in candidate region

For all the objects specified as part of the enquiry (in our example: N)

The result of step 1 is a collection of knowledge items (collection!) .

Step 2: Identify the regions (or knowledge items) in the candidate list that can be ruled-out. This is done by identifying the regions in which one object (question) is present in the source region of the knowledge item but with the wrong value (that is, the value given in the answer to the question in not part of the region).

Criterion 2: (objectl &not objectl-valuel) | (object2 &not object2-value2) | ...

... I (objectN &not objectN- valueN)

This read as: For a region (knowledge item) to be ruled-out, one needs:

objectl is present in the candidate region but with the wrong value, or object2 is present in the candidate region but with the wrong value, or

objectN is present in the candidate region but with the wrong value

For all the objects specified as part of the enquiry (in our example: N)

The result of step 2 is a collection of knowledge items (collection2).

Step 3: The collection of knowledge items that need to be kept as compatible and undetermined is given by:

Criterion 3: ( Criterion 1 ) & not ( Criterion 2 )

collection = knowledge items present in collectionl but not present in collection2

Implementation :

In the Lotus Notes/Domino environment, the above can be implemented using the FTSearch procedure. Discriminate between compatible and undetermined regions (or knowledge items)

Compatible and undetermined regions are discriminated by determining the score of each region (or knowledge item) present in the collection returned by 1 above.

The score of a region is given by the number of questions or defined objects in the enquiry that are present in the region under consideration. From that the compatible and undetermined regions can be identified by comparing the score with the number of defined objects in the knowledge item regions.

Compatible regions: Score = number of defined objects in the knowledge item region

Candidate regions: Score < number of defined objects in the knowledge item region

The score of each region is calculated as follows:

Score = objectl-valuel + object2-value2 + ... + objectN-valueN

The " + " between the objectX-valueX groups is the operator "accrue". It adds the number of time a group is present in the region. In some cases the adding step is weighted with each group having a different weight.

Note that it would be possible to replace stepl in section 1 above by:

1. calculating the score of each knowledge item as shown in this section 2. keeping only the knowledge items with Score > 0.

The best method depends on the way the computation is carried out and what tools are available in the computing environment. Can all the knowledge items be processed in one step (this can be quite efficient), or does one need to take each knowledge item in the knowledge base one after the other (this can be quite slow).

Implementation:

In the Lotus Notes/Domino environment, the above can be implemented using the FTSearch procedure.

3. Order compatible regions according to their specificity

The specificity of a compatible knowledge item (or region) with respect to an enquiry is defined as the number of objects in the region divided by the number of attributes in the enquiry.

Specificity = ( n objects in region ) / ( n objects in enquiry )

4. Order the undetermined regions according to their relevance

Undetermined knowledge items (or regions) can be calculated in two ways.

a. The higher the proportion of objects in the region already accounted for by the questions answered, the higher the relevance of the region.

Relevance = ( n objects in regions accounted for ) / ( n objects in region )

b. The fewer the number of questions left to answer to establish whether a region is compatible or ruled-out, the higher the relevance.

Relevance = ( n objects in region ) - ( n objects in enquiry that are present in region ) In some cases this would not work well. For example, a region could have the same relevance as another but with a larger number of objects in its region. One could argue that it is proportionally closer to being fully answered than the first one.

5. Order the supplementary questions

When there are undetermined knowledge items (or regions) then their status (either compatible or ruled-out) can be determined by asking further questions. These questions can be ordered according to the number of time in which the objects they relate to (a question relate to an object and is asked so that a value can be given to this object for an enquiry) appear in the regions that belong to the undetermined list. Note that it is not necessary to consider the objects (questions) that have already been answered.

6. Multi-choice selection lists in enquiries

Sections 1 and 2 above deal with questions which allow users to define (usually select) a single value or range. There are situations where users may wish to define or select more than one value. This section deals with the changes that are required to knowledge processing to deal with such situations.

Section 1, step 1 : does not need to be modified

Section 1, step 2: needs to be modified

Section 3: does not need to be modified

Section 4: does not need to be modified Section 5: does not need to be modified

Modification to Section 1 , step 2:

At present step 2 identifies the regions (or knowledge items) in the candidate list that can be ruled-out. This is done by identifying the regions in which one object (question) is present in the source region of the knowledge item but with the wrong value (that is, the value given in the answer to the question in not part of the region). To take account of the multiple values, this needs to be changed to: identify the regions in which one object (question) is present in the source region of the knowledge item but with not even one of the values selected is part of the region.

(objectl &not ( objectl-value 1,1 | objectl- value 1,2 | ... | objectl- valuel,M ))

(object2 &not ( object2-value2,l | object2-value2,2 | ... | objects - value2,M ))

(objectN &not ( objectN- valueN,l object_N-valueN,2 objectN-valueN,M ))

This read as: For a region (knowledge item) to be ruled-out, one needs:

objectl is present in the candidate region and not one of the values selected in the enquiry is present in the candidate region, or object2 is present in the candidate region and not one of the values selected in the enquiry is present in the candidate region, or ... objectN is present in the candidate region and not one of the values selected in the enquiry is present in the candidate region For all the objects specified as part of the enquiry (in our example: N) There are also other ways to implement knowledge processing.

Access To All The Knowledge

The knowledge base is made of knowledge items, each comprising a set of objects that are used to define their regions in the source context. The issue is to ensure that at least one question is asked about each knowledge item, so that the GKMS, using the answer given by the user, can determine whether the region (that is, the knowledge item) is ruled-out, undetermined or compatible. (If the region has a single object, then one question suffices to determine whether the knowledge item is ruled-out or compatible. If the region has more than one object, then, on the basis of one question, the GKMS can only determine whether the knowledge item is ruled-out or is undetermined. However, by asking further questions, the final status of the knowledge item can be ascertained.) Procedure for questions selection:

The best first question to ask (that is, the objects in the source context to select as first question) can be determined by calculating the number of knowledge items each object in the source context belongs to, and to order these objects in descending order. The object that appears in the largest number of regions is the best question to ask. Asking this question accounts for all the knowledge items the object corresponding to the question belongs to. The second best question to ask can be determined as follows: take the set of knowledge items not accounted for by the first question and cany out the process described in the previous paragraph.

The next best questions can be determined by repeating this process, until all the knowledge items in the database have been accounted for. It may happen that there are too many independent questions to account for the knowledge base (that is, to reach all the knowledge items in the knowledge base). In this case one can define a new object in the source context that can become a member of a number of (perhaps all) knowledge items (that is, it belongs to their regions), with the knowledge items being grouped according to the values that this object can take. This one object now accounts for a large number of knowledge items. For example, in a knowledge base for trouble-shooting a car, there may be many unrelated questions about the electrical aspects of the car. In this case, one can introduce a new question (object) that enables one to determine which part of the electrical system is functioning or not (before going into the details of why it is not functioning). By making this new object a member of the regions dealing with electrical issues, one effectively reaches a large number of previously independent knowledge items by asking one question. (That is, one question accounts for a large number of knowledge items that could only be reached previously by asking many questions.)

Questions presentation: The first few best questions are presented on the first screen. If there too many questions to fit on one screen, then the next best questions can be asked on the second or third screens, in addition to any supplementary questions raised by the answers to the questions asked so far.

System Behaviour

The system behaviour is specified by considering the state the system is in and in taking actions based on this state. The state of the system can be included as part of the source space and the outcomes that manipulate the state of the system can be part of the destination space. Alternatively, the system behaviour can be specified using a separate module that has as source space a subset of the source space mentioned above and as destination space a subset of the destination space mentioned above.

The system behaviour module enables the expert to define the behaviour of the system it is attached to. It offers an alternative way to implement interactive processing, where the system decides which questions to ask next, in which the expert specifies what the system should do under defined conditions. The system behaviour module is optional.

The system behaviour module is in an elementaiy GKMS module which consists of the same source space as that of the system it is attached to and a different destination space. The state of the system is described as in the elementary GKMS module, using regions attached to outcomes of specified behaviours, the destination space. The destination space specifies behaviour options for the system and has the same attributes or objects as the source space but with different possible values for actions specification, and some other actions as well. Table 9 shows the destination space of a behaviour module. Table 9: S stem behaviour destination s ace

Date/time variable Display variable as enquiry Hide variable

Text variable Display variable as enquiry Hide variable

Software object Display variable as enquiry

Hide variable

Specify state (specify input and/or output states or ranges)

Other Save enquiry

Activate processing (re: search for advice)

Hide all variables displayed after variable x (variables in the display can also be identified with a number)

Display another object which is not part of the problem space (text, image, video, etc) as advice of supplementary information Abort process

Knowledge Review

Experts need to be able to find out conveniently what knowledge items mention some objects. To find that out the expert defines a query which specifies objects and their values, in the source and destination spaces and instructs the system to retrieve all knowledge items that are contained by the enquiry; the unspecified objects are assumed to have the value 'does not matter'. The expert can then review, update and deactivate these knowledge items.

Overlapping Knowledge Items

As shown in Figure 1, knowledge items can overlap and when this occurs experts need to know. Overlap can be in the source space or in the destination space. Overlap happens when a region contains part of another region. Sub-region is a special case of overlapping regions in which one region contains the whole of another region. The meaning of 'overlap' is explained in Table 10 (see Table 7 - meaning of 'contain' - for comparison). Table 10: Meaning of 'overlap'

Space attribute Meaning of 'overlap (in A overlap with B)

Overlap can be checked at any time by the user but can also be checked automatically whenever a new knowledge is defined or an existing knowledge item is modified, that is, whenever the knowledge base is modified.

Knowledge Certification

With reference to Figure 1, knowledge items are certified with respect to explicit source and destination contexts. When the context is modified, knowledge items can still be used as long as their context is made explicit to the users. Alternatively, the knowledge items may need to be re-certified by experts. The expert may need to modify some knowledge items before re- certification.

The GKMS Module Architecture

The architecture is shown in Figure 7 which lists all the elements mentioned.

Practical Implementation Issues In the section below the emphasis is on solutions which support the

GKMS model and which are both computationally effective as well as user friendly. In all cases, the implementation is designed to enable non-computer specialists to build and use knowledge systems.

Context Editing

Context editing needs to be done in two situations:

1. To define an initial domain of discourse before any knowledge items have been defined

2. To modify, usually extend, a domain of discourse to enable it to deal with an extended range of situations and problems.

Initial Context Editing

Users are presented with a blank context, or a context with one or two objects in it as examples. Users can then:

• Define an object or attribute • Edit an existing attribute

• Delete an existing attribute

Modification Of An Existing Context

An existing context can be edited as explained explained above. A second way of editing the context is in response to new queries which require its modification, usually extension. This second way is treated below as it is part of knowledge acquisition in a variable context.

Knowledge Acquisition Knowledge acquisition is also referred to as mappings definition.

Acquisition In A Fixed Context

The context has been defined by domain experts to their satisfaction. That is, the domain of discourse has been set and the task is now to enter knowledge in the form of mappings.

Acquisition Not Prompted By Enquiries

In this situation the experts use their experience to decide, without external prompts, what mappings are needed. They then define these mappings by defining regions in the source context and outcomes in the destination context. The mapping definition process is to define a situation or problem in the source context and then to specify the outcome corresponding to the problem. An alternative way is to define a solution which is known to be useful or relevant to the domain of discourse and then to specify the regions which determine when this outcome is applicable. In practice the two approaches can often be merged.

Knowledge acquisition is a variant of the process described below. The process is as follows:

1. Define a region in the source context

2. Define an outcome in the destination context 3. Save knowledge item (specify a title and a summaiy)

Steps 1 and 2 can be interchanged. At any stage in the process it is possible to go from any step to any other step.

Acquisition Prompted By Enquiries In this situation, an enquiry, typically by a user who is not a domain expert, either has no solution or a solution which is deemed to be inadequate. A enquiry which has no solution is an enquiry for which there is no compatible region in the GKMS. This enquiry is then routed to a domain expert which uses it as a prompt for adding new knowledge, in the form of new mappings, to the system. This process is illustrated in Figure 2, Part 2.

The process in Figure 2 can be guided by the GKMS as follows:

1. GKMS presents a list of unanswered queries to a domain expert

• The unanswered enquiries are presented as a view, with date, and reason for being unanswered . • The expert selects an enquiry and opens it.

2. The domain expert inspect the enquiry

• The enquiry is presented in the source context form (SConl)

• The instruction on Sconl is: "please inspect the enquiry and when ready press "next" to answer it". Sconl cannot be edited. 3. The domain expert answers the query

• GKMS presents the destination context (Dconl). Depending on the size of the display screen the two forms Sconl and Dconl can be shown simultaneously. Dconl is editable.

• The instruction on Dconl is: "please enter the solution to the enquiry by specifying the relevant attributes and providing explanations for your answers. • The expert defines the solution to the enquiry.

• The expert can proceed by pressing "next" or can go back to the enquiry (Sconl) by pressing "back". The only other option available to the expert is to abort the mapping definition process (by pressing the "cancel" button). • Pressing "next" takes the expert to the generalisation process (see below)

4. Return to source context to generalise the enquiry to a region if possible

• GKMS presents Scon2. Scon2 is identical to Sconl except that it can be edited.

• The instruction on Scon2 is: "Generalise the enquiiy if possible by defining a region "around" the enquiry for which the answer specified on the previous screen applies".

• The expert can: a) go back to the Dconl to inspect or edit the solution just defined, b) press "next" to continue, or c) press "cancel" to abort the mapping process. • Pressing "next" allows the knowledge item (or mapping) to be saved.

5. Save knowledge item

• GKMS presents the mapping form (Mform) which enables the expert to enter the title for the mapping and a summary. Only the title is mandatory. When finished the option is to press "next" or "back" or "cancel". • With "back" the expert can go back to the previous display. "Cancel" aborts the knowledge mapping process.

• With "next" GKMS displays: "this knowledge item will be added to the knowledge base and will be used to answer future enquiries. OK, back or cancel". • "OK" save the mapping, "back" goes back to the previous screen, "cancel" aborts the knowledge definition process.

When an enquiry has been answered in the way described above, it is taken off the list of unanswered queries and the view (see point 1 above) is updated. At any time during steps described above, the expert can return to either the source context with the problem in it (no editing allowed), the editable source context with the region in it (to modify the region), or to the destination context to modify the solution proposed.

The process described above can be varied by exchanging steps 3 and 4, as shown below:

1. GKMS presents a list of unanswered queries to a domain expert 2. The domain expert inspects the enquiry

3. The domain expert generalises the enquiry to a region if possible

4. The domain expert answers the query

5. Save knowledge item In a practical implementation the forms can all be presented to the expert, with only the ones that are intended to be edited in the editing mode. The advantage of this is that the expert can always have a synoptic view of the knowledge item being defined.

Acquisition In A Variable Context

The section below recognises that mappings may have different source and destination contexts. The acquisition process for variable contexts builds on the acquisition process in a fixed context described above. The extra or modified steps are shown below in italic. 1. GKMS presents a list of unanswered queries to a domain expert

• The unanswered enquiries are presented as a view, with date, and reason for being unanswered .

• The expert selects an enquiry and opens it. 2. The domain expert inspect the enquiry • The enquiry is presented in the source context form (SConl)

• The instruction on Sconl is: "please inspect the enquiry and when ready press "next" to answer it". Sconl cannot be edited.

• The instruction on Sconl is: "please inspect the enquiry and when ready press "next" to answer it". Sconl cannot be edited. • The enquiry may be accompanied by a message from the user who filed the enquiry. The message may describe the enquiry more specifically or in more details (see "unanswered or poorly answered enquiries").

• Based on this message or on professional judgement, the expert may decide to extend (or reduce) the source context. This is described in point 4b. below. • It is also possible to allow source context editing at this stage in the process:

Sconl has an additional button "edit context" pressing "edit context" allows Sconl to be edited (the enquiry cannot be modified, the attributes in the enquiry cannot be deselected -the deselect option is added to Sconl, new attributes can be added. - see point 4b below for details.

Sconl, when shown at this stage in the process, has the message: "please modify context as appropriate without changing the enquiry. Press "next" when ready to answer it". when finished editing the context the user can press "next" to move to the destination context to answer the enquiry.

3. The domain expert answers the query

• GKMS presents the destination context (Dconl). Depending on the size of the display screen the two forms Sconl and Dconl can be shown simultaneously. Dconl is editable. • The instruction on Dconl is: "please enter the solution to the enquiry by specifying the relevant attributes and providing explanations for your answers.

• The expert defines the solution to the enquiiy.

• The expert can proceed by pressing "next" or can go back to the enquiry (Sconl) by pressing "back". The only other option available to the expert is to abort the mapping definition process (by pressing the "cancel" button). 3b. Specify appropriate destination context

This involves either reducing the context or enlarging the context. Reducing the destination context corresponds to considering fewer options for the outcome than there is present in Dconl . Enlarging the context corresponds to adding new outcome options to Dconl.

Dconl has one additional button labelled "add new attribute". Reducing the context

• By default all the attributes in Dconl are part of the mapping's context. • The expert can deselect some of these attributes by "unchecMng" it (each attribute can have a check box for selection purposes for example). Enlarging the context

• Pressing the "add new attribute" button opens the context editing module (see section above). * The destination context the expert can add to is the Dconl.

• Pressing "next" takes the expert to the generalisation process (see below) 4. Return to source context to generalise the enquiiy to a region if possible

• GKMS presents Scon2. Scon2 is identical to Sconl except that it can be edited. • The instruction on Scon2 is: "Generalise the enquiiy if possible by defining a region "around" the enquiry for which the answer specified on the previous screen applies".

4b. Specify appropriate source context Reducing the source context Scon2 corresponds to considering fewer attributes for defining the enquiry and accepting fewer attribute which are not specified in the enquiiy (that is, which do not play a role in the definition of the enquiry) .Enlarging Scon2 corresponds to adding new attributes for enquiry definition and for specifying which of these attributes do not play a role in the enquiry.

Scon2 has one additional button labelled "add new attribute". Reducing the context

• By default all the attributes in Scon2 are part of the mapping's context.

• The expert can deselect some of these attributes by "unchecking" it (each attribute can have a check box for selection purposes for example).

Enlarging the context

• Pressing the "add new attribute" button opens the context editing module (see section above).

• The destination context the expert can add to is Scon2. 4c. Review the region

• The process is the same as in point 4. Above.

5. Save knowledge item

• With "next" GKMS displays: "this knowledge item will be added to the knowledge base and will be used to answer future enquiries. OK, back or cancel". • "OK" save the mapping, "back" goes back to the previous screen, "cancel" aborts the knowledge definition process. • Each knowledge item is saved with its source and destination context. At any time during steps described above, the expert can return to either the source context with the problem in it (no editing allowed), the editable source context with the region in it, to modify the region, or to the destination context to modify the solution proposed. In a practical implementation the forms can all be presented to the expert, with only the ones that are intended to be edited in the editing mode.

Knowledge Access Interactive and non-interactive knowledge access have already been described. Here we consider the action which activates a knowledge search in an GKMS and the process used to presenting the outcomes of the knowledge items or mappings which are compatible with the enquiiy.

Triggering Mechanisms

The access process can be triggered by a user who defines an enquiry or by a system enquiry, that is, an enquiry specified by values produced by another package or process in a computer system.

Access Mechanisms

In a similar way to the triggering mechanisms, access can be by presentation to a user on a screen, for explanation mappings, or by running some processes or modules, for action mappings. The way the final results are produced and presented to users is under the control of the processes or modules in the outcomes.

Ranking Of Mappings And Their Outcomes

Knowledge items or mappings need to be ordered according to their fit with the enquiries. This applies to definite outcomes only or to definites and candidates outcomes; that is to definite and candidate mappings. Rejected mappings are not considered here. The fit is determined by three factors:

1. Weight of each source attribute, weights may not all be equal.

2. For definite and candidate knowledge items: proportion of attributes in the enquiry which are satisfied by the region attributes; that is attributes belonging to the region of the knowledge item. 3. For definite and candidate knowledge items: proportion of the attributes in the source context which belong to the region of a candidate knowledge item.

Weight Of Source Attributes a(i) attribute i w(i) weight of attribute i nw(i) normalised weight of attribute i Sum w(i) over all attributes = Sw(i) nw(i) = w(i) / Sw(i) normalisation is not strictly necessary.

Proportion Of Enquiry Attributes Satisfied By Region Attributes

This specifies how general or specific a knowledge item is in addressing an enquiry. A high proportion l/p_l indicates a general knowledge item applicable to many enquiries. A low proportion indicates a well targetted answer. In practice is easier to use the inverse pi of the proportion l/p_l (pi < = 1). A value of pi close to one indicates specific and precise knowledge and is highly desirable: a lower value is less desirable. This measure does not consider whether a knowledge item is a candidate or a definite, which is addressed below. l/p_l = Na(i,q) / ( Na(i,r,q)) ; l/p_l > = 1 Na(i,q) = number of attributes i in enquiry q

Na(i,r,q) = number of attributes in the region r of a knowledge item which belong to the enquiry q

With attribute weights:

1/pl = Nw(i.q) / ( Nw(i,r,q)) ; 1/pl > = 1

Figure 8 illustrates the situations for pi < = 1; attributes in the region that "do not matter" are not specified. A simple implementation of this ranking is the number of attributes in the region. Knowledge items which are found to be compatible with the enquiry and which have larger numbers of attributes are more specific than knowledge items with few attributes in their regions.

Proportion Of A Mapping's Source Attributes Which Satisfy The Enquiry This measure applies to candidate mappings. It determines how close candidate mappings are to becoming either rejected mappings or definite mappings. For definite mappings this proportion is 1. The inverse of the desired proportion p2 is first calculated. p2 < = 1. l/p_2 = Na(i,r) / ( Na(i,r,q)) ; l/p_2 > = 1

Na(i,s) = number of attributes i in the region r of a knowledge item Na(i,r,q) = number of attributes in the region r of a knowledge item which belong to the enquiry q With attribute weights: l/p2 = Nw(i,r) / ( Nw(i,r,q)) ; l/p2 > = 1 p2 = 1 for definite knowledge items p2 < 1 for candidate knowledge items

Figure 9 illustrates the situation for p2 < = 1, and attributes that "do not matter" have not been specified.

Overall Ranking

The relevance of a knowledge item, which determines its order or ranking among the knowledge items compatible with an enquiiy, candidate of definite knowledge items, is calculated as: For definite knowledge items: R = pi

For candidate knowledge items: R = pi * p2

A relevance ranking can also include the probability or reliability level p3 that the outcome of a knowledge item solves the situations that can be described in its region. In this case we have: For definite knowledge items: R = pi * p3

For candidate knowledge items: R = pi * p2 ^* p3

Related Issues

Fuzzy logic principles can also be included in GKMS. For example, a query can cover several overlapping regions of several knowledge items.

Similarly, outcomes can overlap. The impact on relevance can be calculated taking into account the overlaps and the weights of the attributes and similar considerations above.

Unanswered Or Poorly Answered Enquiries An unanswered enquiry has no compatible mappings and therefore no outcomes. A poorly answered enquiry can be detected in several ways, which can be specified by users or domain experts:

• The definite knowledge items (and therefore outcomes) have a poor relevance ranking.

• There are candidates knowledge items but no definite knowledge items.

• The user deems the outcome as unsatisfactory and sends feedback to the GKMS administrator.

Once detected, GKMS deals with unanswered or poorly answered enquiries by referring them to an expert who can then add new knowledge in the GKMS to: a) answer this specific enquiry, and b) answer any future enquiry which falls within the region of the newly created knowledge item.

Knowledge Management For Domain Experts Domain experts need tools to enable them to manage the knowledge items or mappings which have been entered into a GKMS. This becomes necessary as soon as more than a few mappings have been entered.

Domain experts need to manage the knowledge base from the point of view of knowledge comprehensiveness, consistency, quality, etc. The tools available to assist them are:

• Detect overlapping knowledge items, in their source and/or destination

• Identify knowledge items with a specified combination of source and destination attributes or values

• Edit existing knowledge items • Inspect history of knowledge items in the system

- list of knowledge items (active and deactivated)

- when created, by whom

Overlapping Knowledge Items Given a certain knowledge item, this tool detects which other knowledge items or mappings in the GKMS overlap with it. The overlap can be in the regions of the mappings or in their outcomes. This tool enables the domain expert to check that overlapping knowledge items are compatible. With overlapping regions, an enquiry in the overlapping part or the regions will produce more than one outcome (one outcome per overlapping region). These outcomes need to be compatible (that is, not contradictory) for the system to provide meaningful results.

With overlapping outcomes, the domain expert can determine which conditions (i.e. regions) produce these outcomes and determine whether these different conditions are not mutually exclusive or contradictory for example.

If overlapping knowledge items are found to be incompatible in some of the ways described above, then the domain experts need to edit one or several of them.

Overlap Detection In Fixed Common Contexts

Here we consider all knowledge items or mappings to have the same source and destination contexts. Note that we assume that the regions are defined by attributes which have specified values. The attributes which do not matter are not included in the region definitions.

Region overlap detection

The process for region overlap detection is as follows:

1. The expert selects which knowledge item to use as reference for detecting overlaps. 2. When the expert click the button "detect overlap", the GKMS:

Takes the region of the reference knowledge item.

Transforms this region into an enquiry (that is, GKMS displays it in the enquiry specification environment).

Activates the search for knowledge item (the same search as when searching for outcomes compatible with an enquiry; it searches for knowledge items with regions which are compatible with the enquiry). The reference knowledge item is not included in the list of knowledge items searched.

3. The GKMS search engine retrieves and presents the knowledge items with outcomes which are definite or candidates. This is different from a normal search in which the system only presents the outcomes).

4. The expert can then inspect and edit these knowledge items. Outcome overlap detection

The process for outcome overlap detection is as follows: 1. The expert selects which knowledge item to use as reference for detecting overlaps. 2. When the expert click the button "detect overlap", the GKMS:

Takes the outcome of the reference knowledge item.

Transforms this outcome (or region in the destination space) into an enquiry (that is, GKMS displays it in the enquiry specification environment). - Activates the search for knowledge item (the same search as when searching for outcomes compatible with an enquiry; it searches for knowledge items with outcomes (not regions in the source space as in a normal search) which are compatible with the enquiry). The reference knowledge item is not included in the list of knowledge items searched. 3. The GKMS search engine retrieves and presents the knowledge items which are definite or candidates. This is different from a normal search in which the system only presents the outcomes).

4. The expert can then inspect and edit these knowledge items.

In practice, experts often search for knowledge items which overlap in their sources and destinations.

Overlap Detection In Variable Contexts

Here we consider all knowledge items or mappings which can have different source and destination contexts.

Search For Knowledge Items With Specific Characteristics

Experts can search the knowledge base of the GKMS for knowledge items which meet specified characteristics. The process is as follows:

1. The GKMS presents the expert with the source and destination contexts. 2. The expert defines an query in these contexts by specifying values for attributes in one or both of the contexts.

3. Pressing "detect overlap" activates the search for overlapping items. The search algorithm combines the two searches described above, that is the GKMS searches for both region and outcome overlaps. 4. The GKMS presents the knowledge items retrieved.

5. The expert can then inspect and edit these knowledge items.

Edit Existing Knowledge Items

The knowledge editing process is described above.

Inspect History Of Knowledge Items The expert can inspect the list of knowledge items or mappings in the GKMS with the author status, date defined, and date deactivated (if appropriate) for each item.

Effluent Disposal Advisory System Example

In the section we consider as example an application related to the discharge of effluents in a river system.

The domain experts first decide the type of application, such as a system for the discharge of effluents in a river. Once the type of applications is decided, the domain experts must specify the problem space and the solution space.

Problem space specification consists of the identification of all the key factors (or attributes) that enter into the definition of an enquiry related to the application field. In our example, some key factors could be: amount and concentration of a restricted substance in the effluent to be discharged and frequency of discharge.

Solution space specification consists of the identification of the components that could be used to define an outcome. In our example, it could include discharge. One can expect that some new factors will have to be added to the problem space and new components to the solution space. Alterations to either the problem or the solution space may need to be done.

An example of a rule might be: IF ((effluent type is organic substance or pesticide or weedicide) OR (effluent type is pesticide)

OR (effluent type is weedicide)) AND ((restricted substance is arsenic)

OR (restricted substance is copper)) AND (0.01 < = concentration < = 0.1) THEN(Carry out the following changes:

(Neutralise chemical with process y And Install concentration monitoring equipment) Only then discharge allowed)) Inspection of Figures 10 and 11 show that a significant part of the system relates to the database management. It is therefore natural to use a database management system as part of the development and implementation tools. The tools used were Microsoft Access and Microsoft Visual Basic. Other tools such as Lotus Notes or Internet technology can be used.

A number of other applications for the technology can be envisaged. For instance: Intelligent (web) Site Advisor (ISA) or Intelligent Resource Advisor (IRA); Intelligent Website Designer or Intelligent Resource Knowledge Designer (IRKD); Product and Service Advisor (PSA); and Intelligent Product and Service Knowledge Designer (PSKD). It should be appreciated that the technology is amenable to network applications.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A computerised generic knowledge management system, comprising: a multi-dimensional global space within computer memory defined by attributes, where each attribute defines a feature of the external world or the internal state of the system, or actions that can be taken to modify them, and each attribute is a dimension of the global space; a source space, within the global space, made up of selected ones of the attributes to define a context, in which to state problems; a destination space, within the global space, made of selected ones of the attributes to define a context in which to provide answers to problems stated in the source space; mappings between defined parts of the source space which each represent one or more stated problems, to defined parts of the destination space which each represent one or more answers expressing and embodying knowledge supplied by experts appropriate to the respective problems stated in the part of the source space.

2. A system according to claim 1, where the defined parts of the source and destination spaces are points or regions.

3. A system according to claim 1 or 2, where the destination space is also part of the source space.

4. A system according to claim 1 where the two spaces overlap.

5. A system according to claim 1, where the mapping process are explanations or actions.

6. A system according to claim 5, where txplanation mappings are not calculated, they are stated.

7. A system according to claim 6, where explanation mappings are associated with code which enable the outcome to be displayed on a screen or printer.

8. A system according to claim 5, where action mappings associate a situation in the source space to actions expressed in the destination space.

9. A system according to claim 8, where the destination space is made of instructions to be carried out by agents.

10. A system according to claim 8, where action mappings are specified by a function or module that can be calculated, using the values of the source attributes that define the situation as parameters.

11. A system according to claim 1, where source and destination space editing sub-systems enables authorised users to define and modify the destination and source spaces or contexts.

12. A system according to claim 1, where a mapping editing sub-system enables experts to define mappings which embody knowledge.

13. A composite system comprising a collection of systems according to claim 1, in which the source contexts of the systems are united, the destination contexts of the systems are united and the mappings of the systems are united to form the composite.

14. A data acquisition method for a computerised generic knowledge management system, comprising the steps of: inspecting a problem that either has no answer or an answer which is deemed to be inadequate, that is a problem for which there is no defined part of the source space; specifying attributes, and if appropriate, explanations relevant to the problem; defining the solution to the problem; generalising the source context to generalise the inquiry to a larger part of the source space; and saving the knowledge item generated.

15. A method according to claim 14, where the solution is defined after the source context has been generalised.