WO2007016717A1

WO2007016717A1 - System for knowledge acquisition and re-use

Info

Publication number: WO2007016717A1
Application number: PCT/AU2005/001087
Authority: WO
Inventors: Megan Margaret Vazey; Deborah Christina Richards
Original assignee: Macquarie University
Priority date: 2005-08-05
Filing date: 2005-08-05
Publication date: 2007-02-15

Abstract

Methods, apparatus, and computer program products are disclosed for processing conclusions in a knowledge-based system using multiple-classification-ripple-down rules for generating an output conclusion in response to an input case, the system using cases, classifications and conclusions. In one embodiment, the method comprises adding a RuleNode at the end of a rule tree path for a live RuleNode that has been rejected to provide a conclusion and to refer to a parent conclusion of the added RuleNode.

Description

SYSTEM FOR KNOWLEDGE ACQUISITION AND RE-USE

TECHNICAL FIELD The present invention relates to knowledge-based systems.

BACKGROUND

Knowledge has become recognized as a key resource in organizations and one that is more important and more difficult to manage than data and information. The successful management of knowledge may offer a competitive advantage to organizations.

Knowledge based systems, also known as expert systems, offer a means by which knowledge may be acquired from experts and reused by other experts or novices. Capture and maintenance of knowledge in traditional expert systems has been problematic due to a number of factors including: the need for a knowledge engineer to act as a mediator between the domain expert and the expert system itself; the brittleness of knowledge based systems (KBS) when queried outside of their narrow domain of focus; and the maintenance problems which occur when the number of rules in the knowledge base grows beyond small to medium in size. Ripple Down Rules were developed to address these shortcomings.

Multiple classification RDR (MC-RDR) has been proposed by Kang, Compton and Preston 1995, and Kang 1996, which is referred to hereinafter as conventional MC- RDR. A number of limitations with the architecture and design of conventional MC- RDR exist. Known MC-RDR systems do not support multiple experts to collaboratively resolve their classification or conclusion conflicts inside the scope of a set of MC-RDR interactions.

Known MC-RDR systems have not allowed previously seen cases, including cornerstone cases, to be changed. As well, known MC-RDR systems do not allow cases to be "Tracked" in the sense that such systems do not automatically re-evaluate the conclusions for cases when the knowledge base changes. Conventional MC-RDR systems allow a case to be evaluated against the knowledge base, and the conclusions determined. But then the case is "let-go".

To support classifications at different levels of abstraction, conventional MC- RDR allows separate rule paths to conclude both the higher level classification, such as 'mammal', and the lower level sub-classifications, such as 'dog' or 'cat' by providing at least two separate rule paths to these conclusions. However, this has two shortcomings: the relationship between dog and mammal is lost, and in many cases, redundant knowledge is stored. For example, if a RuleNode concludes that the case represents a mammal and the expert wishes to say the case is also a dog, then the expert must override the current case with a node that concludes dog and add a new RuleNode higher up the tree to conclude that the case is also a mammal. This is because in conventional MC-RDR the conclusions on parent RuleNodes are always over-ridden by TRUE child RuleNodes.

SUMMARY

In accordance with an aspect of the invention, there is provided a method of processing conclusions in a knowledge-based system using multiple-classification- ripple-down rules for generating an output conclusion in response to an input case, the system using cases, classifications and conclusions. The method comprises adding a RuleNode at the end of a rule tree path for a live RuleNode that has been rejected to provide a conclusion and to refer to a parent conclusion of the added RuleNode. The adding step may refine a general classification of a RuleNode to be more specific, wherein general information presented to a user is refined to be more specific rather than replaced or rejected.

The adding step may comprise creating a child (referring) RuleNode and pre- populating a conclusion set with conclusions that refer to a parent (referred) RuleNode. A rule may be provided for the added RuleNode, and a list of one or more cornerstone cases may be provided that satisfy the rule of the added RuleNode. The rule and the list of cornerstone cases can be changed. The adding step may comprise creating one or more RuleNodes to reject and deregister a live, registered RuleNode that has been rejected.

The adding step may comprise creating one or more RuleNodes to reject a live, unregistered RuleNode that has been rejected.

The method may further comprise the steps of: if a live but unregistered classification is accepted, registering the live but unregistered classification; if a not live, registered classification is accepted , creating and registering a new RuleNode with the existing not-live, registered classification and conclusions; if a not live and unregistered classification is accepted , creating and registering a new RuleNode with the not-live and unregistered classification and conclusions; and if a not live, registered classification is rejected, deregistering the classification. The method may, for a live classification that is rejected, perform the steps of stopping the classification, or modifying the classification. The step of modifying may comprise, if a new rule is a refinement of a parent rule, creating and registering a new child RuleNode with a replacement classification and conclusion.

The knowledge-based system may be implemented using a collaborative knowledge management system.

A computer system may implement the method.

The RuleNode may have classification labels that are different from their conclusions.

The method may further comprise linking conclusions at the added RuleNode that represents a subclassification of the parent RuleNode to conclusions at the parent RuleNode.

The method may further comprise referring to one or more other RuleNodes from the added RuleNode to reuse classifications and conclusions across the knowledge base system. The method may further comprise copying conclusions from one or more other RuleNodes to the added RuleNode and editing the copied conclusions.

The method may further comprise combining RuleNode paths with a logical "OR" using a shared child RuleNode structure. The method may further comprise prompting a user to perform the combining step.

Multiple conclusions may be associated with each RuleNode and stored in a separate data structure that allows centralized updating of the conclusions.

In accordance with a further aspect of the invention, there is provided an apparatus for processing conclusions in a knowledge-based system using multiple- classification-ripple-down rules for generating an output conclusion in response to an input case, the system using cases, classifications and conclusions. The apparatus comprises: a module for storing RuleNodes, cases, classifications and conclusions and relationships amongst the RuleNodes, cases, classifications and conclusions; and a module for adding a RuleNode at the end of a rule tree path for a live RuleNode that has been rejected to provide a conclusion and to refer to a parent conclusion of the added RuleNode.

In accordance with a still further aspect of the invention, there is provided a computer program product having a computer readable medium storing a computer program for processing conclusions in a knowledge-based system using multiple- classification-ripple-down rules for generating an output conclusion in response to an input case, the system using cases, classifications and conclusions. The computer program product comprises: a computer program code module for storing RuleNodes, cases, classifications and conclusions and relationships amongst the RuleNodes, cases, classifications and conclusions; and a computer program code module for adding a RuleNode at the end of a rule tree path for a live RuleNode that has been rejected to provide a conclusion and to refer to a parent conclusion of the added RuleNode.

In accordance with another aspect of the invention, there is provided a method of processing conclusions in a knowledge-based system using multiple-classification- ripple-down rules for generating an output conclusion in response to an input case, the system using cases, classifications and conclusions. The method comprises: evaluating one or more intermediate RuleNodes each having one or more intermediate conclusions in a rule tree by evaluating one or more rule paths in reverse up the relevant paths in the rule tree.

In accordance with yet another aspect of the invention, there is provided a method of processing conclusions in a knowledge-based system using multiple- classification-ripple-down rules for generating an output conclusion in response to an input case, the system using cases, classifications and conclusions. The method comprises: maintaining a live RuleNode data structure, a registered RuleNode data structure, a live case data structure, a registered case data structure, a live path case data structure, and a live RuleNode to case associative data structure in respect of a rule tree and cases.

One or more of the data structures may be a list.

The method may further comprise the steps of tracking, untracking and retracking cases using one or more of the live RuleNode to case associative data structure, the live case data structure, and the live RuleNode data structure.

The method may further comprise the step of updating the live RuleNode to case associative data structure, for a change in a case, a conclusion, a RuleNode, an attribute or an ontological entry.

The maintaining step may be performed in the background at a specified time or specified time interval.

The method may further comprise the step of supporting modification, addition, and deletion of a case already processed, and presenting a comparison of previously registered conclusions with new live conclusions for the case. For deletion of a cornerstone case, one or more representative cornerstone cases may be fabricated and constructed.

For deletion of a cornerstone case, a new rule view to formulate one or rules may be provided.

The method may further comprise the step of notifying a user according to a corresponding user profile when a change in the knowledge base occurs. i

-6-

In accordance with still another aspect of the invention, there is provided a method of processing conclusions in a knowledge-based system using multiple- classifϊcation-ripple-down rules for generating an output conclusion in response to an input case, the system using cases, classifications and conclusions. The method comprises generating the input case by working up the input case by answering questions provided by one or more classifications from one or more RuleNodes that fetch more attribute details for the case.

In accordance with any of the foregoing aspects involving methods, the method may further comprise the step of updating knowledge acquisition statistics on a per user basis, including statistics of how often RuleNodes of an expert are used, corrected, augmented, approved and disapproved, and the number of times the expert's cases are revisited and previous decisions are corrected.

In accordance with any of the foregoing aspects involving methods, the method may further comprise the step of providing a user with a corresponding profile that grants access privileges. The method may further comprise the step of changing the user's view according to the profile that has been provided for the user.

In accordance with another aspect of the invention, there is provided a method of using MCRDR in the task of collaborative problem determination and solution matching for the support centre. In accordance with another aspect of the invention, there is provided a method of

MCRDR in the task of collaborative and guided classification in any domain.

In accordance with still another aspect of the invention, the system can track, untrack and retrack cases. The system may allow users to change the global tracking settings of tracked cases with macros. In accordance with yet another aspect of the invention, the system can record and manage the live RuleNode to case associations, and the registered RuleNode to case associations for tracked cases.

In accordance with still another aspect of the invention, the system can update its live RuleNode to case associations in the background and immediately when a case, conclusion, RuleNode, attribute, or ontological entry changes, with or without the use of a live path case list (LPCL).

In accordance with anOther aspect of the invention, the system can be queried to reveal cases where the Live non-stopping RuleNodes differ from the Registered RuleNodes for the case.

The system provides support for the modification, addition or deletion of cases already seen and evaluated by the knowledge base, and presentation of the comparison of the previously registered conclusions with the new live conclusions for this case to the user. The system can substitute a more representative Cornerstone case for a given

RuleNode when the currently referenced cornerstone case is no longer live for that RuleNode due for example to the edit of cases, RuleNodes, attributes, or ontology data.

Users may be notified when the knowledge in the system changes in such a fashion that a case that the user may be interested in now fetches a new set of RuleNodes. Similarly, the user can be notified when a RuleNode that the user is interested in fetches a new cornerstone case.

The default behaviour of the system can be configured in recommending acceptance or rejection of RuleNodes on the basis of whether they are live, registered, or approved in one of that user's approval partitions. The system provides support for the various scenarios for accepting and rejecting

RuleNodes on the basis of whether they are live or registered.

The system allows knowledge workers to collaboratively enter getAttribute() conclusions to the system and thereby share problem determination and classification determination questions with each other. The system allows knowledge workers to work-up a case by answering questions provided by one or more classifications from one or more RuleNodes that fetch more attribute details for the case via a getAttribute() conclusion or a template that translates natural language entered by a user into this special conclusion type. The system can update its knowledge acquisition statistics on a per user basis, including the statistics of how often an expert's RuleNodes are used, corrected, augmented, approved, or disapproved; and the number of times their cases are revisited and their previous decisions are corrected.

Separate simple views may be provided for novice users, optionally determined by their approval status; and to provide queued updates of their responses for later evaluation by an expert.

The system allows users to set the RuleNode approval status via setting bits or flags in the approval partition for the RuleNode.

Users may have their views changed according to the approval partitions that have been configured for them, and according to which RuleNodes have been approved.

The system can identify classification labels for RuleNodes in the system, which are different from their conclusions. The system may link the conclusions at a RuleNode that represents a subclassification of the parent RuleNode, to the conclusions at the parent RuleNode.

The system can refer to other arbitrary RuleNodes in the system from the current RuleNode, and thereby reuse classifications and conclusions across the system.

The conclusions from Arbitrary RuleNodes can be copied to the present RuleNode and the copied conclusions can be edited.

The system may have cases with attributes whose type is defined by the conclusions given at other RuleNodes in the system. For example, a RuleNode may have the conclusions: getAttribute('length'), getAttribute('breadth') and this can be used to define an attribute that defines the length and breadth of an object. RuleNode paths in the system can be combined with a logical 'OR' using the shared child RuleNode structure.

The system can prompt users when a situation arises that may mean that two or more RuleNodes may be suitable for combining using the shared child RuleNode structure. The system may use hyperlinks to process and display case and conclusion information using external resources available on an intranet or internet in the task of classifying cases.

The system may have multiple conclusions associated with each RuleNode and stored in a separate data structure that allows the centralized update of those conclusions.

The system can fabricate and construct one or more representative cornerstone cases on the fly for the user to differentiate their present case against.

A rule view can be provided instead of a cornerstone view to formulate rules.

Intermediate RuleNodes can be evaluated by evaluating the rule paths in reverse up the relevant paths in the rule tree.

These and other aspects of the invention are described hereinafter in greater detail with reference to the embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention are described hereinafter with reference to the drawings, in which:

Fig. 1 is a block diagram of the top-level architecture in accordance with an embodiment of the invention;

Figs. 2A and 2B are flow diagrams illustrating a process of accepting or rejecting live versus registered RuleNodes in accordance with an embodiment of the invention;

Fig. 3 is a flow diagram illustrating a process for creating one or more RuleNode(s) to reject a classification;

Fig. 4 is a block diagram illustrating a number of RDR training cases; Fig. 5 is a flow diagram illustrating a MC-RDR knowledge base system; Fig. 6 is a block diagram of a registered RuleNode list for Case 101 of Fig. 4;

Fig. 7 is a conventional view of case conclusions for Case 101 of Fig. 4; Fig. 8 is a developer's view of case conclusions for Case 101 of Fig. 4; Fig. 9 is a novice view of case conclusions for Case 101 of Fig. 4; Fig. 10 is a customer view of case conclusions for Case 101 of Fig. 4;

Fig. 11 is a top-level data flow diagram in accordance with an embodiment of the invention; Fig. 12 is a block diagram of a legacy system implementation in accordance with a further embodiment of the invention;

Fig. 13 is a flow diagram illustrating a "case drop-down" situation in a multiple classification RDR KB S ;

Fig. 14 is a flow diagram illustrating working up a case; Fig. 15. is a flow diagram illustrating fabricating cornerstone cases; and

Fig. 16 is a flow diagram illustrating shared child RuleNodes.

DETAILED DESCRIPTION

Methods of processing cases, classifications and conclusions in a knowledge- based system using multiple-classification-ripple-down rules for generating an output conclusion in response to an input case, and knowledge-based systems using multiple- classification-ripple-down rules are described hereinafter. In the following description, numerous specific details are set forth. However, from this disclosure, it will be apparent to those skilled in the art that modifications and/or substitutions may be made without departing from the scope and spirit of the invention. In other circumstances, specific details may be omitted so as not to obscure the invention.

The methods may be implemented in modules. A module, and in particular its functionality, can be implemented in either hardware or software. In the software sense, a module is a process, program, or portion thereof that usually performs a particular function or related functions. Such software may be implemented in C, C++, JAVA, JAVA BEANS, Fortran, PHP, HTML, JAVASCRIPT, Perl, Python, Visual Basic, SQL, or a combination thereof, for example, but may be implemented in any of a number of other programming languages/systems, or combinations thereof. In the hardware sense, a module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using discrete electronic components, or it may form at least a portion of an entire electronic circuit such as a Field Programmable Gate Arrays (FPGA), Application Specific Integrated Circuit

(ASIC), and the like. A physical implementation may also comprise configuration data for a FPGA, or a layout for an ASIC, for example. Still further, the description of a physical implementation may be in EDIF netlisting language, structural VHDL, structural Verilog, or the like. Numerous other possibilities exist. Those skilled in the art will appreciate that the system may also be implemented as a combination of hardware and software modules.

One or more embodiments of the invention may be implemented using a client- server model with or without the use of a web browser module. The knowledge base may be a database, or a system of flat files or persistent objects, or may be implemented in hardware.

Some portions of the following description are presented in terms of algorithms and representations of operations on data within a computer system or other device capable of performing computations. Such algorithmic descriptions and representations may be used by those skilled in the art to convey the substance of their work to others skilled in the art. An algorithm is a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or electromagnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. These signals may be referred to as bits, values, elements, symbols, characters, terms, numbers, or the like.

The above and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to such quantities. Unless specifically stated otherwise, and as apparent from the following, discussions utilizing terms such as "inputting", "accepting", "determining", "creating", "registering", "deregistering", "rejecting", "using", "stopping", or the like, refer to the action and processes of a computer system, or a similar electronic device. Such a system or device manipulates and transforms data represented as physical quantities within the registers and memories of the computer system into other data similarly represented as physical quantities within the computer system registers, memories, or another form of storage, transmission or display devices. Apparatuses and systems for performing the operations of the methods are also described. Such an apparatus may be specifically constructed for the required purpose. Alternatively, the apparatus may comprise a general-purpose computer or another computing device (e.g., a PDA), which may be selectively activated or reconfigured by a computer program read by the computer. The algorithms presented herein are not inherently related to any particular computer or other apparatus; various general-purpose machines may be used with programs.

The embodiments of the invention also relate to a computer program(s) or software, in which method steps may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language, operating environment, and implementation thereof. A variety of programming languages, operating systems, and coding thereof may be used. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing the scope and spirit of the invention. Furthermore, one or more of the steps of the computer program may be performed in parallel rather than sequentially.

The computer program may be stored on any computer readable medium. The computer readable medium may comprise storage devices, such as magnetic media disks, CD-ROMs, DVDs, flash RAM devices, memory chips, memory cards, magnetic tape, other storage devices and media suitable for interfacing with and being read by a general- purpose computer, and combinations thereof. The computer readable medium may also include a hard-wired medium, such as a local area network or the Internet, or wireless medium, such as an IEEE 802.11 wireless network, a GSM mobile telephone system, PCS, and GPS. The computer program when loaded and executed on such a general- purpose computer effectively results in an apparatus that implements the method steps of the embodiments. The methods of the embodiments comprise particular control flows. However, different control flows can be practised without departing from the scope and spirit of the invention.

Glossary The following terms are used hereinafter to describe embodiments of the invention and are in a logical order, rather than in an alphabetical order.

Case

A Case is a set of one or more possibly temporal attribute-value pairs that describes our observations of an object or of a scenario. In defining the attributes of a case, and therefore parameterising the case, a user asks the question - what is our sense of the case? That is, how does the object look, sound, smell, taste, and feel? What are its properties? Cases and their attributes are observation oriented.

For example, in geology a case may refer to a rock object with properties or attributes such as {weight, dimensions (height, width, depth), colour, composition, and temperature as measured every minute for the last 5 minutes}; and their corresponding values such as {950g, (100mm,50mm,25mm), grey, iron 98% nickel 1.5% and cadmium 0.5%, (100 deg C, 89 deg C, 80 deg C, 72 deg C, 64 deg C)}. Cases based on observations of an object may also be observed in many domains where taxonomies naturally apply, for example: pathology, biology, botany, zoology, and chemistry.

Fig. 4 shows some examples of cases in the LT. support domain. These cases represent a troubleshooting scenario being faced by a customer or employee of an LT. organisation. Cases based on observations of a scenario might also be used in the legal or medical domains. Cases need not remain static and represent observations of an object or a scenario over time. Cases may be given a unique integer identifier.

Case Status

The status of cases can be for example: new, assigned, open, resolved, verified, closed, expired in accordance with the natural workflow of a case through the system. A new case is one that is new in the system and has not yet been assigned. An assigned case has been assigned to a user for the user to work the case and attempt to find a solution to the case. An open case has been opened, i.e. accepted by a user. A resolved case has been solved by a user, i.e. a solution has been found .for that case. A verified case has been verified as being correct by some user, possibly a user with extra "verify" privileges compared to a regular user. A closed case has been closed by a user. An expired case has been in the system so long that the system has decided to mark the case as expired.

In an alternate embodiment, the status of cases is not tracked or altered. For example, all cases in the system could be considered to be open cases.

Tracked Case

A "Tracked" Case is one whose Live and Registered RuleNodes are being remembered by the system. These may be recorded in a Live RuleNode to Case association data structure, or a Registered RuleNode to Case association data structure, or in an LRL, LCL, RRL, or RCL as described in the sections entitled "Registering RuleNodes" and "Recording Live RuleNode and Case Associations".

Cornerstone Case

This is a case that has been stored by the system in association with one or more RuleNodes. It may be that when this case was executed against the knowledge base, one or more conclusions given by the system were found to be in error, either by a human or software agent. As a result one or more new RuleNodes were added to the knowledge base to correct the conclusions given. All of the RuleNodes that were added because of this case become associated with this case and likewise the case becomes known as the cornerstone case for these RuleNodes.

Alternatively, the case may have been substituted as the cornerstone case for an existing RuleNode in accordance with the section entitled "Knowledge Evolution and Case Drop-down". Cornerstone cases are retrieved and may be shown to an expert when the rule/s to which the case is associated are deemed to be incorrect on a new case. Cornerstone cases are used for system validation by providing the context behind a modification to the knowledge base and ensuring that new knowledge does not invalidate previous knowledge. Cornerstone cases also assist the user in selection of features that form the rule conditions as cornerstone cases provide the context and a counterexample to the new case that is motivating the knowledge in the system to be changed.

Attributes

Attributes may be in the form of any of the standard data types one expects to see in a programming language, or as fields in a database; or some combination of those types. For example, attributes may be binary, integers, floats, characters, strings, one of a set of strings/integers/floats, some of a set of strings/integers/floats, or free text; or even combinations of the above types.

Table 1 shows some of the set and numeric types that are available when creating attributes in the system.

Table 1

In addition, attributes may be hyperlinks, including hyperlinks to uploaded files. In the system, users are able to configure templates that translate a function used in a field of type 'hyperlink'. For example, the user can configure the syntax casetracker(lθl) used in an attribute (or a conclusion) for a case to translate to the hyperlink http://casetracker.com/mvcasetracker.php?casenumber=101. Table 2 shows some of the text and link types that are available when creating attributes (as well as conclusions) in the system:

Table 2

In one embodiment of the invention, allowing attributes to be combinations of other attributes permits a class hierarchy of attributes to be created. In another embodiment, attributes may also be of the same type as that defined by classifications within the system. For example, a RuleNode may have the conclusions: getAttribute('length'), getAttribute('breadth') and this can be used to define an attribute that defines the length and breadth of an object.

Hyperlink

Hyperlinks are links to information resources, such as web pages or documents accessible via the internet via some protocol, including but not limited to http or ftp, including hyperlinks to uploaded files or other software applications with parameters that can be used to configure those instantiated web pages or software applications. There are two components to a hyperlink in the system: the URL and the parameter link. The URL includes the access protocol for example http:// and the resource descriptor with its file type for example freyatech.com.au/index.html. The protocol and / or the mime type of the resource descriptor can be used to determine the software application that should handle a request to access a hyperlink.

Classification

A classification is a grouping or category or a set of things that share one or more common properties. A classification is a conceptual extension of a set of things. A classification is defined by a set of rules that all members of the classification obey. A classification is the result of a case evaluating to TRUE through a sequential set of

RuleNodes, where each RuleNode has a Boolean test that may examine the attributes of the case. A classification may be labeled or unlabelled in the system, for example, as text or using a hyperlink.

In pathology, classifications may be diagnosis-oriented, for example some classifications may include "kidney stones", "breast cancer", and "blood sugar too high".

In LT. support, classifications may or may not attract labels. Examples of some labeled classifications include the following ones used in Fig. 5: "product B", "windows platform", "old software".

Classifications may have more than one label or name as in the sciences (geology, biology, physics, chemistry). For instance in botany, unique species of plants may have a scientific name, and a common name.

Conclusion

A Conclusion represents one or more propositions, or final statements, including actions that one should take as a result of arriving at a given classification. In pathology, conclusions may be prescription-oriented, for example some conclusions may include "eat lOOg fibre bran for breakfast each morning", "do 15 mins aerobic exercise per day", and "drink 2L water per day".

In LT. support, conclusions may be action-oriented. The conclusions may include instructions for example to: click on a web link such as http://lookatme.pdf: run a particular software application with a particular set of parameters; read a document located in a particular place; go to a search engine and search with a given set of keywords; ask the customer a particular question; or enter a value for a particular attribute. A conclusion may be of any of the types that an attribute can be, including a hyperlink. But the conclusion can also be one of these special types: a stopping conclusion i.e. the word 'stop' that indicates that the parent RuleNode's conclusion is no longer an appropriate classification; or a getAttribute('attributeName') conclusion that indicates that the user should be prompted to enter the value of a particular attribute, in this case the 'attributeName' attribute; or a set Attribute('attributeName',' attribute Value ',confirm=true) conclusion that may be used to indicate that the 'attributeName' attribute should have its value set to 'attribute Value', that the changes should optionally be confirmed by a user, and that the case should then be re-evaluated against the rule tree. Previous MC-RDR implementations have not distinguished between classification labels and conclusions. Rather, previous MC-RDR have allowed both classification labels and conclusions to be the conclusion at a RuleNode. In the system conclusions are explicitly allowed that are classification labels to be separately identified from other types of conclusions so that the classification labels can be reused between RuleNodes in an enriched way.

As well, previous MC-RDR implementations only allowed one conclusion per RuleNode, whereas the system allows multiple conclusions per RuleNode where those conclusions can be stored in a common data structure in the system, and reused as one of several conclusions for multiple RuleNodes across the system. The only exception is that a RuleNode with a stopping conclusion is a stopping RuleNode and can have no other conclusions.

User

A user can be a human user, or a computer user such as an intelligent agent, or a computer robot. Users can have different profiles, views, and privileges assigned to the users. For example, an expert user may have a profile that allows the user to update the knowledge base, i.e. the expert user may have read and write access in all areas of the knowledge base, but perhaps not the system configuration. An expert user might also be able to see RuleNodes approved in any approval partition, as well as pending RuleNodes. A novice user may only have read access to the knowledge base, and the ability to register conclusions for a given case. An administrator user may have update privileges for every aspect of the system, including read and write access in all areas of the knowledge base, as well as the system configuration. An intelligent agent might have write access in the knowledge base that gives the agent the ability to create RuleNodes, but perhaps not to approve the RuleNodes or register cases against the RuleNodes. A master user might have global approval privilege in a particular set of approval partitions such that every RuleNode that the master user creates is automatically approved in those partitions. A developer user might have all the same privileges as an expert user, as well as the ability to see the approved stopping conclusions in the case view, whereas other users would perhaps never see RuleNodes with approved stopping conclusions in the case view. A customer user might have read only access, and the ability to view only those RuleNodes that have been approved for viewing in the customer approval partition.

Expert An expert can be a human expert, or a computer expert such as an intelligent agent, or a computer robot.

RuleNode

A RuleNode in the system is one of the nodes in the rule tree. Each RuleNode in the system may be given a unique integer identity.

Live RuleNodes

A Live RuleNode for a given Case is one that is currently the last TRUE RuleNode on a given path through the knowledge base for that case. Its conclusions are part of the set of current conclusions derived from the knowledge base for the case. Live conclusions may be correct or incorrect. Correcting incorrect live conclusions is the primary role of a (human or computer) expert who trains and hence builds up the knowledge in the rule tree and hence the knowledge base.

In the embodiments of the invention, the system remembers its Live RuleNodes for "Tracked" cases.

Registered RuleNodes

A Registered RuleNode is one that has been confirmed by a User as being correct and TRUE for that Case. For each case, each RuleNode registration may be current or expired as described in the section entitled "Registering RuleNodes".

RuleNode Status

RuleNodes may have several states, including pending (i.e. awaiting approval), approved, or disapproved.

Note that if a RuleNode is disapproved, then the RuleNode is stopped with an unconditional stopping rule. This means that the RuleNode is given a child RuleNode with a rule that returns TRUE for every case that is evaluated against the RuleNode, and a "stop" conclusion.

Note that approval of a RuleNode may be automatically set for a particular set of approval partitions if the user updating the system has global approval privilege in that set of approval partitions as described in the glossary entry entitled "User".

Stopping RuleNode

A stopping RuleNode has a single conclusion which is the keyword "stop".

A special type of stopping RuleNode is an unconditional stopping RuleNode. This is a stopping RuleNode with a rule condition that returns TRUE for every case evaluated against the RuleNode.

Ontology

Ontology with a capital 'O' refers to the philosophical discipline that studies the nature of being that was introduced by Aristotle and attempts to address questions such as: 'What is being? ' and 'What characteristics do all beings have in common? '. Ontology with a lowercase O' is generally regarded as a designed artefact consisting of a specific shared vocabulary used to describe entities in some domain of interest, as well as a set of assumptions about the intended meaning of the terms in the vocabulary (Guarino, 1998). A taxonomy can be considered a simple type of ontology showing the taxonomic relationship between different objects. A frequently cited, and perhaps the most prevalent within the Artificial Intelligence community, definition of ontology is attributed to Tom Gruber who defines ontology as "α« explicit specification of a conceptualisation " (Gruber, 1993: 199). Generally also attached to that description is the notion of the conceptualization being shared. An ontology may be included in the system to allow users to use alternative terms, such as synonyms, that can be mapped to correspond to terms used in the knowledge base. This includes the terms used in cases, conclusions, conditions and classifications.

Wiki An evolution of the web forum is the Wiki. Wikipedia at http://wikipedia.org/ is a massive undertaking by the global internet community to collaboratively build an online encyclopedia spanning every conceivable topic in every conceivable language.

A Wiki is the collaborative software and resultant web forum that allows users to add content to a website and in addition, to collaboratively edit it.

Rules

The following operators listed in Table 3 are available when creating rule expressions:

Table 3

Note also that brackets are recommended for combinatorial rules.

Note also that natural language processing may be used to translate user articulated rules into the system's rule syntax. For example, the natural language statement "that the product contains 'product A'" may be translated into the rule expression: "grep(' product A', 'product')". User configured templates may be used to define these translations.

High-Level Concept

The system in accordance with one or more embodiments of the invention allows knowledge workers in any domain to collaboratively refine and expand a topic using an expert systems approach by consistently asking the workers to confirm, add to, or refine the knowledge presented, typically within the context of a current case. The system goes beyond the collaborative capture of solution knowledge, to promote the collaborative capture and re-use of tacit problem solving knowledge, including classification and problem determination knowledge. The approach adopted does this by capturing and sharing the questions that experts ask themselves when classifying incoming cases. Our solution lends itself to knowledge domains where users rely on heuristics to form classifications, and where users can apply a reusable set of conclusions on the basis of a given classification. Domains where this technology may be applied include, for example, botany, zoology, biology, chemistry, pathology, geology, and technical analysis in financial markets. Another application is troubleshooting client problems, or resolving customer enquiries in a support or call centre.

The system extends significantly the Multiple Classification Ripple Down Rules (MC-RDR) algorithm. For example, new data structures and algorithms are presented to facilitate conflict resolution between multiple sources of expertise, to allow experts to more effectively collaborate in building up a knowledge base and rule tree.

Fig. 1 is a block diagram showing a top-level conceptual diagram 100 of the invention. Input is provided to the system 100 in the form of cases 110. The cases 110 are parameterized in module 120 giving sets of attribute-value pairs that identify each case. A human or a computer user may undertake the processes in this module 120, or the incoming cases 110 may already be parameterized upon arrival to the system.

The case parameterization output is provided as input to the case-classification- conclusion indexer step or module 130, which manages the classification rule tree. Step 130 provides possible conclusions that are output to the conclusion selection module 150, which may be carried out by a human or a computer user. Classifications are identified for a case 110 by evaluating the case's attributes against multiple paths of sequential rule nodes in a rule tree. The case 110 is found by the system 100 to fit zero or more classifications according to the current rule tree.

Module 130 may also include an ontology that can be used to enrich the meaning of parameterized cases inputted from module 120, articulated rules inputted from module 180, and articulated conclusions inputted from conclusion articulation module 140, as well as to enrich the meaning of cases, classifications, conclusions, and rules within the rule tree managed by module 130. Along with many other things, module 130 also manages the details of attributes that are used to parameterize cases, and the details of users that interact with the system. Zero or more possible conclusions associated with zero or more possible RuleNodes in the rule tree are provided to the conclusion selection step 150. The human or computer user is offered zero or more conclusions for each RuleNode that the case 110 complies with. The user is asked to accept or reject the presented conclusions, or alternatively to edit the case to provide more or different case information. The conclusion selection step 150 provides accepted conclusions 158 ("Conf Concl") as its output.

User interaction at step 150 may also feed an error condition 152, if one occurs, to the case parameterization step 120 to edit and/or modify the set of case attributes. The error condition 152 may be in the form of a conclusion that the user should provide more or different attribute details for the case on hand. Using the error condition 152, the user may be guided by the system to interact with the case recursively to make the case explicit enough for the system 100 to identify useful classifications for the case.

User interaction at step 150 may further feed another error condition 154, if one occurs, to the case-classification-conclusion indexer step or module 130 to include an exception condition in the classification rule tree. In that case, conclusion knowledge is input by a human or computer user in the conclusion articulation step or module 140. Conclusions 142 are input to step 140. As well, the human or computer user must articulate rules in the rule articulation step or module 180. Rules 170 are input to module 180. The articulated rules of module 180 are input to the indexer at module 130. The indexer at module 130 can use the input from 180 and 140 and 154 to create one or more new RuleNodes in the rule tree at module 130.

User interaction at step 150 may feed another error condition 190, if one occurs, to the rule articulation step or module 180 to modify a rule at a particular RuleNode. The rule articulation output is provided as input to the case-classification-conclusion indexer step or module 130, which handles the classification rule tree.

User interaction at step 150 may feed another error condition 156, if one occurs, to the conclusion articulation step or module 140 to modify the conclusion set at a particular RuleNode. The conclusion articulation output is provided as input to the case- classification-conclusion indexer step or module 130. In summary at step 150, where a given conclusion is rejected, the user is asked to either modify the set of attributes for the case so that the case fetches a different conclusion (error 152), or update the system knowledge to include an exception condition (error 154), or update the system knowledge for a set of conclusions to reflect the new knowledge (error 156), or update the system knowledge for a rule to reflect the new knowledge (error 190).

System Features

Registering RuleNodes

In the embodiments of the invention, the final set of RuleNodes confirmed as being TRUE by the user are recorded against each case. This becomes known as the Registered RuleNode List (RRL).

So for example, when Case 101 in FIG. 4 is evaluated against the rule tree in Fig. 5 the last true RuleNode in each path through the rule tree gives RuleNodes 1, 5, and 7. In this example, the expert agrees with all the conclusions presented. The Registered Rulenode List for Case 101 is recorded as {1,5,7}.

In addition, the name of the user who registered each RuleNode as being correct for this case may also be recorded, together with the most recent date and time at which the RuleNode was created or modified.

For instance, in a Registered RuleNode to Case associative data structure, the following entries may exist: [Case 101, RuleNode 1, User 1, 20050722:11:43:45 (EST)], [Case 101, RuleNode 5, User 1, 20050722:12:43:45 (EST)], [Case 101, RuleNode 7, User 1, 20050722:14:43:45 (EST)] where user 1 is for example 'vazeym' and the times given are the Eastern Standard times when the RuleNodes were last created or modified. If another user, such as another human user or an intelligent agent re-registered the given RuleNodes against the case, the user and registration date is updated for that entry in the Registered RuleNode to Case association data structure.

Using the Registered RuleNode to Case associative data structure, at every RuleNode in the system, one can derive a list of all of the cases that are currently registered for that RuleNode. This list is called the Registered Case List (RCL). One may also separately or alternatively maintain the RCL at each RuleNode. As well, for every case, one can derive a list of all of the registered RuleNodes for that case. This list is called the Registered RuleNode List (RRL). As shown in Fig. 6, one may also separately or alternatively maintain the RRL at each case. Fig. 6 shows a registered RuleNode list 600 for Case 101.

If one of the RuleNodes is edited the question remains about whether the RuleNode - Case registration remains valid? In that case, the modification date on the RuleNode changes, and the system may compare the date on the registered case-rulenode association to indicate to the user that the registration is no longer current, but rather that the registration has expired.

If the case itself is edited the question remains about whether the RuleNode - Case registration remains valid? In that case, the modification date on the RuleNode - Case associations can be set to the modification date of the case. The system can therefore compare this to the date on which the RuleNodes were last created or modified, to indicate to the user that the registration is no longer current, but rather that the registration has expired.

The test for RuleNode-Case registration expiry is therefore that if the last modification or creation date of the RuleNode is the same as the date on the RuleNode- Case association, then the registration is current. Otherwise, the registration is expired.

Approving and Disapproving RuleNodes

The development philosophy for the knowledge base is in line with an open systems approach like that taken by the Wiki community (see the Wiki entry in the glossary). The Wiki philosophy reflects the belief that most times, knowledge that is mostly true, but which may have some error, is better than no knowledge at all and that by providing a collaborative forum for knowledge acquisition, knowledge conflicts are resolved more rapidly than such conflicts might otherwise be, and knowledge acquisition is more likely to occur.

Providing for different levels of Approval in the knowledge base goes against the grain of this open knowledge acquisition philosophy. However, some groups or organizations may be unreceptive to an open approach. In the system, an Approval structure for the knowledge in the rule tree is allowed for. RuleNodes may have several states, including pending (i.e. awaiting approval), approved, or disapproved. The approval may be set for different audience partitions. Conceptually, one can imagine a bit for each partition in an approval variable for each RuleNode such as ObOlOO. For example, approved for the service level 1 organisation (bit 0), approved for the service level 2 organisation (bit 1), approved for engineering (bit 2), or approved for customers (bit 3). Levels of approval i.e. approval partitions may be added or removed from this list without compromising the design of the system. In practice, rather than using an approval variable, one can imagine a separate field to identify each separate approval partition, for example in a relational database table, or in an XML file, or in an object oriented data structure.

Approval of a RuleNode may be automatically given for a particular set of approval partitions if the user creating or editing the RuleNode has global approval privilege enabled for those partitions as described in the section entitled "User" in the glossary. As well, a computer or robot user may automatically approve RuleNodes for a selection of approval partitions based for example on the frequency of acceptance, the infrequency of rejection, and the frequency of registration of that RuleNode in each of the approval partitions, and perhaps also based on the authoring user's credibility in the system as captured by the user statistics described in the section entitled "User-based knowledge acquisition statistics".

A user with approval rights in particular partitions may also manually enable or disable the approval status of the RuleNode in those partitions while creating or editing it.

If a RuleNode is disapproved, then its approved partitions are set to zero, and the RuleNode is stopped with an unconditional stopping rule. This means that the RuleNode is given a child RuleNode with a rule that returns TRUE for every case that is evaluated against the rule, and a "stop" conclusion.

A RuleNode that is not approved in any partition, and which has not been disapproved is spending RuleNode. A RuleNode that is not approved in a particular partition, and which has not been disapproved, may be pending approval for that particular partition, depending on the approval status of its ancestor RuleNodes. This is described in more detail in the section entitled "Viewing Case Conclusions - Applying Approval Profiles".

Viewing Case Conclusions - Users with Update Privileges

In conventional RDR systems, once a case is evaluated against the rule tree, and the last true RuleNode in each path through the rule tree is determined, the expert is provided with a view of the final conclusions given by the system. As shown in Fig. 7, for conventional MC-RDR systems, this view can possibly include for each case: the RuleNode identifier; the trace of rules through the rule tree that have been evaluated in the course of arriving at this RuleNode, and that are TRUE for this case; and the resultant conclusions for each TRUE RuleNode. The symbol O represents a FALSE radio button, and the symbol • represents a TRUE radio button. The user is also presented with the opportunity to accept or reject the conclusions provided. This figure is representative of the type of data that might be provided to a user of a conventional MC-RDR system. Other implementations exist that provide alternate but similar data when viewing the conclusions of a case.

In the system, each user's profile is configured to allow that user to view RuleNodes that have been approved in particular approval partitions. For the purposes of this section, a developer user is assumed to have the ability to view and update RuleNodes approved in every partition, as well as pending RuleNodes. An example case view is provided for a developer user in Fig. 8. The symbol O represents a FALSE radio button, and the symbol • represents a TRUE radio button.

In the system, the status of the RuleNode can be indicated, for example, that the RuleNode has been approved and the approval partitions that the RuleNode is approved for, or that the RuleNode is pending approval in this particular user's view. As well, conclusions that are actually classification labels can be extracted. In the example provided in Fig. 8, the classification labels "product A" and "windows XP platform" have been extracted and shown in the "classification label" column.

In addition, whether a RuleNode has been previously registered for this case by some user and whether that registration is current or expired can be indicated. As well, all of the RuleNodes that may have been previously registered for this case, but which are no longer live for the case, can be shown.

In Fig. 8, it is assumed that at some time in the past, before RuleNode 5 existed, Case 101 was evaluated against the rule tree and one of the resultant live RuleNodes was RuleNode 3, which was subsequently registered for Case 101 by the user: 'vazeym'. Assuming that the rule tree is presently that shown in Fig. 5, and that RuleNode 3 was previously registered for Case 101, Fig. 8 shows that RuleNodes 1, 5 and 7, are currently live but not registered for Case 101 ; and RuleNode 3 is registered but not live for Case 101. The system allows the live RuleNodes that have been evaluated for the case to be accepted or rejected or ignored on a RuleNode by RuleNode basis.

For example in the system, the user can accept agreeable RuleNodes in the early stages of evaluating a case, and the user can defer their decision on the contentious RuleNodes until a time when the user can be more informed about the decision the user need to make. This may be a useful strategy for example when dealing with RuleNodes that are pending, rather than approved.

The user can re-enter the case view at some later time to accept or reject the conclusions provided for this exact case. When the user does decide to take action, the user can choose to "do nothing" for some RuleNodes, and separately "Accept" or "Reject" other RuleNodes.

Default recommendations for whether the user should be prompted to accept / reject / or do nothing for the live and / or registered RuleNodes of a case are shown in Table 4, and explained below. In the table, 0 represents FALSE, and 1 represents TRUE. Table 4

These recommended default actions may be changed by system configuration settings. In Table 4 above, independent of whether a RuleNode is disapproved, pending, or approved, if the RuleNode is neither live nor registered for the case, the RuleNode does not appear in the case view and hence that scenario can be ignored.

In the system, if a RuleNode is disapproved, then the RuleNode is stopped with an unconditional stopping rule. Therefore in the table, no cases are live for a disapproved RuleNodes. However, a RuleNode that may have been registered in the past, may become disapproved. In that case the recommended default action to the user is to reject that RuleNode.

In the Table 4, the recommended default action to the user is to "do nothing" with live and/or registered RuleNodes that are pending approval. This is a conservative strategy for when users are less experienced. But if users have a high degree of experience, an administrator or other user may want to change this strategy so that the default action to the user is to "reject" pending RuleNodes that are no longer live but which are still registered, to "accept" pending RuleNodes that are live and unregistered, and to "do nothing" with pending RuleNodes that are already live and registered. In the above table, the recommended default action to the user is to reject approved registered RuleNodes that are no longer live. In the above table, the recommended default action to the user is to accept approved RuleNodes that are live but not registered.

In the above table, the recommended default action to the user is to "do nothing" for approved RuleNodes that are already live and registered. Note that users with update privileges need to see all of the RuleNodes in the rule tree, whether the RuleNodes be pending or approved for this particular user's view. If a RuleNode is live for the case being viewed, but the RuleNode is not approved in any of the approval partitions that the user belongs to, then the RuleNode should be treated as pending for that user. For example, a novice user with update privileges viewing a case in Fig. 9 has the approved live, pending live and registered unlive RuleNodes included in their view. Whether a live and / or registered RuleNode is pending or approved depends on the user's approved partitions. In this example, using the partition examples from the previous section, the user's approved partitions are service levels 1 and 2 in the organization, i.e. their approval profile is ObI 100. Note that the classification label headings could optionally be excluded from this view.

In Fig. 9, the user may optionally right click with their mouse on the RuleNode text, or hover above text to view similar RuleNode details to that provided in Fig. 8. Their acceptance or rejection of the RuleNodes provided may result in RuleNode registrations, and may fetch recommendations for alternate RuleNodes or RuleNode modifications, which may be created with an approved status in the partitions configured in their approval profile, or alternatively, with a pending status in all partitions for later approval by a more expert user.

In an alternate embodiment, the novice user's updates may be temporarily queued and only optionally acted upon by a more expert user at some later time.

Autonomous Handling of Cases

Cases may be generated autonomously, for example by equipment automatically "dialing-home" error reports to a central server. As well, cases may be submitted to the knowledge base for example by clients interacting through a self-service internet kiosk, or by support staff working in a support centre. In the system, incoming cases may be automatically detected and tracked, for example by reading the cases off an input queue, and evaluating the cases against the knowledge base. If all the live RuleNodes for a case are also Approved RuleNodes, then an autonomous agent acting within the system could automatically accept the system conclusions and register the live non-stopping RuleNodes against the incoming case. The case could be automatically verified, closed, and have "Tracking" disabled for it, and the results of the evaluation of that case against the knowledge base could be notified to the relevant party, for example the customer and / or other relevant personnel such as a field service technician.

Recording Live RuleNode and Case Associations.

The system maintains a Live RuleNode to Case associative data structure.

Using the Live RuleNode to Case associative data structure, at every RuleNode in the system, one can derive a list of all of the "Tracked" cases that are currently live for that RuleNode. This list is called the Live Case List (LCL). One may also separately or alternately maintain the LCL at each RuleNode. As well, for every case, one can derive a list of all of the live RuleNodes for that case. This list is called the Live RuleNode List (LRL). One may also separately or alternately maintain the LRL at each case.

For instance, for the scenario shown in Fig. 8: in a Live RuleNode to Case association data structure, the following entries exists: [Case 101, RuleNode 1], [Case 101, RuleNode 5], [Case 101, RuleNode 7].

Updating the Live RuleNode to Case Associations

The system permits users to directly edit cases, including cornerstone cases. When a "Tracked" case is changed, the system will re-evaluate the case against the rule tree and derive possibly new Live RuleNodes for the case. Hence the Live RuleNode to Case associations change, the LRL for the case change, and the LCL for each previously live RuleNode and each new live RuleNode change.

As well, users are allowed to directly edit RuleNodes, including their rules, classifications and conclusions. When the rule for a RuleNode is changed, the old LCL for that RuleNode and each of its dependent RuleNodes can be used to update the LCL for each of the affected RuleNodes and the LRL of all of the affected cases. Alternatively, the old LPCL for that RuleNode as described in the section entitled "7¹Ae LivePathCaseList" can be used to update all of the affected LCLs, LRLs, and LPCLs.

This happens in the background for all the affected cases so that the live RuleNode to Case association are always maintained and current for all cases in the system. So when an old tracked case is re-opened, that case does not have to be reevaluated against the rule tree because all of its live RuleNode to Case associations are already up to date.

Knowledge Evolution and Case Drop-down

In the system the need to explicitly differentiate the current case from the set of cornerstone cases for the parent RuleNode, has been relaxed. One consequence of relaxing this need to differentiate the present case from all its cornerstone cases, is the possibility of "case drop-down". This is where a live case at the parent RuleNode or one of it's dependent RuleNodes drops-down into the new child RuleNode and becomes live for that child RuleNode. The example provided in Fig. 13 illustrates the "case drop- down" situation in a multiple classification RDR KBS. In this example, relationship between RuleNodes and Cases are shown as dashed lines. The red arrows indicate cases where case drop-down might occur. .

In this simple example, there are two sources of expertise that are able to modify the knowledge base: 'Expert A' prefers general conclusions and 'Expert B' likes to be specific. In the example, 'Expert A' tends to use general conclusions compared to

'Expert B' because the 'Expert A' doesn't know as much as 'Expert B' in this particular domain. In a different example, 'Expert A' could be more cautious and reserved in drawing specific conclusions for legal, personal or reputation related reasons. In any case, it may be that both experts may have different objectives concerning the knowledge acquisition task. For domain coverage there is the need for balance of both general and specific as appropriate to the cases seen.

In the example given, the following simplified sequence of events occurred when the knowledge base was built by the two experts:

• First of All, Case 1 (cat A) was evaluated against the knowledge base. 'Expert A' added RuleNode 1 that checked to see if the case was 'warm-blooded', which it was, and the expert entered the conclusion "mammal". Case 1 became the cornerstone case for RuleNode 1.

• Next, Case 2 (a dog) was evaluated against the knowledge base. 'Expert B' saw the conclusion "mammal" but wanted to be more specific. 'Expert B' rejected the conclusion from RuleNode 1 and created RuleNode 2 that tested that the case

'barks', and concluded that Case 2 was a "dog". Case 2 became the cornerstone case for RuleNode 2.

• Next, Case 3 (cat B) was evaluated against the knowledge base. 'Expert B' again wanted to be more specific. The expert rejected the conclusion "mammal" and created a RuleNode 3 that tested that the case 'meows', and concluded that Case

3 was a cat. In providing this RuleNode, the expert accepted that the link between the previous cornerstone case for RuleNode 1 would now be invalidated. Case 1 remains as the cornerstone case for RuleNode 1 in the knowledge base. Alternatively, if cornerstone compression had been used Case 1 would have been substituted for Case 3 as the cornerstone case for possibly both RuleNode 1 and

RuleNode 3; or else just for RuleNode 3, in which case RuleNode 1 would have been without any cornerstone case at all.

• Next, Case 4 (a whale) was evaluated against the knowledge base. 'Expert A' saw the conclusion "mammal" and was satisfied with that conclusion. • Next, Case 5 (a seal) was evaluated against the knowledge base. 'Expert B' saw the conclusion "mammal" from RuleNode 1 and again, wanted to be more specific. The only cornerstone cases that the expert had to differentiate this case from were the cornerstones associated with RuleNode 1 and all its dependent RuleNodes. This cornerstone case list comprised of case 1 (cat A) from RuleNode 1 and / or RuleNode 3 (as described above depending on whether cornerstone compression was in use), case 2 (a dog) from RuleNode 2, and possibly case 3 from RuleNode 3 (if cornerstone compression wasn't in use). Since Case 4 was not a cornerstone case, it was not included in the cornerstone case list for RuleNode 1. 'Expert B' rejected the conclusion from RuleNode 1 and created RuleNode 4 that tested that the case has an 'ocean habitat', and concluded that Case 5 was a "seal". Case 5 became the cornerstone case for RuleNode 5.

• Next, Case 6 (an unknown mammal) was evaluated by the empty knowledge base. 'Expert A' saw the conclusion "mammal" and was satisfied with that conclusion.

The system solves the problem of case drop-down that occurs for example when the knowledge base evolves, when a case is changed, when a RuleNode is changed, or possibly when an ontological entry or attribute is changed.

The system provides tracking of cases and hence the notification and tracking of case drop-down scenarios. It also automates the correction of cornerstone cases in the knowledge base. The case tracking mechanism lets users capitalize on the knowledge acquisition opportunity presented by the case drop-down scenario, and this in turn may result in quicker coverage of the domain and greater learning opportunities for users.

It does this in the following respects: • Firstly, if a parent cornerstone case drops-down to a new child RuleNode, it may be used as the cornerstone case for that RuleNode, and eliminated as the parent RuleNode cornerstone case. This is not an act of cornerstone compression, but rather it is an act of achieving accuracy in the knowledge base. If a parent cornerstone case drops through to the new child RuleNode, it is because in terms of knowledge acquisition, it no longer represents a valid cornerstone case for the parent RuleNode. The policy for setting the cornerstone case for new RuleNodes may be configured to be a FIFO (first in first out) or LIFO (last in first out) policy ordered for example by the age of "Tracked" cases in the system (or possibly just for "Tracked" cases that are resolved and/or verified) where the RuleNode in question is both registered and live for the replacement cornerstone case. If there are no such cases, then this policy can be relaxed in stages, for example to first look for a replacement cornerstone case from all verified cases that are live and registered, then all resolved cases that are live and registered, then any case that is live and registered, then perhaps just any case that is live. • Secondly, when a case does drops-through then if that case is being "Tracked" in the system as described in the section "Case Tracking to reduce the size of LCL and RCL per Case", a user could for instance be notified in every instance where a case assigned to the user has dropped-through. This notification may be for example in the form of an email, an instant message, an SMS, or similar. At some later stage the expert could view the case and see that there is a difference between its live and registered RuleNode lists. This or another user could use the system facility provided to search for cases for a particular user, or for all users, where the set of live RuleNodes differs from the set of registered RuleNodes for the case. The user could view each such case and accept or reject the unregistered live RuleNodes and the registered but not live RuleNodes and in so doing, train the system with the necessary knowledge to ensure that all the RuleNodes for the case become both registered and live and hence that the consistency of the knowledge across all the "Tracked" cases is maintained. This knowledge acquisition process is described in the section: "Accepting and

Rejecting RuleNodes".

In the system, users can also be notified when knowledge evolution occurs in such a manner that the registration of live non-stopping RuleNodes for cases assigned to the user expires. This strategy assists with more rapid knowledge acquisition since it can be used to highlight inconsistencies between expert opinions.

As well, the user could be notified when a RuleNode that the user is interested in fetches a new cornerstone case.

Case Tracking to reduce the size of LCL and RCL per Case

As volumes of cases are evaluated by the knowledge base, the Live Case List (LCL) and Registered Case List (RCL) per RuleNode are likely to become sizeable. In comparison, the number of live and registered RuleNodes for a given case may be quite limited. In the system, the number of cases being tracked can be reduced, for instance, by allowing cases to be tagged as 'untracked', and by removing untracked cases from the Live Case List and the Registered Case List per RuleNode, and by removing the Live RuleNode List from the untracked cases, and by removing any corresponding associations from the Live RuleNode - Case data structure. However, the RRL is still kept for untracked cases. Note that an untracked case is simply a case that is not ~ "Tracked".

When an untracked case is reopened by a user, the case then gets re-evaluated against the rule tree, and all of the live data structures are updated in accordance with the normal processes for newly opened cases. In addition, the Registered RuleNode to Case associations and / or the RCL for each RuleNode registered to the case is updated using the associations provided in the RRL at the case.

Case-RuleNode Data Structures

An example data structure that could be used to manage the Case-RuleNode associations is as follows: [101, 1, 1, 0, " , "], [101, 3, 0, 1, 1, '20050722:11:43:45'], [101, 5, 1, 0, ", "], [101, 7, 1, 0, ", "] where the first element in each set is the case identity; the second element in each set is the RuleNode identity; the third element in is a bit to indicate whether the RuleNode is live; the fourth element is a bit to indicate whether the RuleNode is registered for the Case; the fifth element contains the identity of the user who registered the RuleNode for the case; and the sixth element is the registration date as described in the section entitled "Registering RuleNodes". An exclusive or (XOR) of the live and registered bits could be used to indicate whether there were any discrepancies between the live or registered RuleNodes for the given case. This could further be compared with the RuleNode's details to determine whether it is a stopping RuleNode that can therefore be eliminated from the live and registered RuleNode comparisons.

Other data structures can be envisaged including relational database tables or persistent object structures with hash style indices with references to the described data structure for cases and RuleNodes, and even for just live RuleNodes, live non-stopping RuleNodes, or just registered RuleNodes. As well, the Case identity could be removed to form the LRL and RRL at each case. Also, the RuleNode identify could be removed to form the LCL and RCL at each RuleNode.

The LivePathCaseList Depending on the size of the system, and the effective cost of memory compared to processing speed, it can also be useful to maintain the list of all tracked cases that are live for a given RuleNode, or for one of its dependent RuleNodes, at the RuleNode. In the system this list is known as the LivePathCaseList (LPCL). When the RuleNode is augmented with a new child RuleNode, the system evaluates every case in the LPCL at the parent node to see if it drops through to the new child RuleNode. One can also reconstruct the LPCL for each RuleNode on the fly from its own LCL and the LCL of each of its dependent RuleNodes.

In a different example, if a RuleNode is edited, cases in the LPCL of the RuleNode before the RuleNode was edited can be re-evaluated against the RuleNode and its child RuleNodes to see if the cases still arrive at the same live RuleNodes in the system. As well, cases in the LPCL of its parent node can be re-evaluated against this child RuleNode.

Live vs Registered System Queries

Approved and optionally also pending live RuleNodes with stopping conclusions are typically eliminated from view when an expert with update privileges views a case. Including or excluding these RuleNodes from the view may optionally be toggled on or off by a user.

If such a user registers the non-stopping RuleNodes but does not register the live stopping RuleNodes, because the RuleNodes are hidden from view, a difference may appear between the sets of live and registered RuleNodes for that case.

RuleNodes with live stopping conclusions may be excluded when comparing the set of live RuleNodes with the set of registered RuleNodes for a given case.

Similarly, some users with read-only privilege may not be presented with the pending RuleNodes in their case view. A useful comparison between live and registered RuleNodes includes a comparison of the set of Approved live non-stopping RuleNodes with the registered RuleNodes for all Tracked cases. Differences in these lists may highlight knowledge acquisition opportunities that help to mature the knowledge base more quickly than was possible for conventional MC-RDR systems. For users with update privilege where the pending RuleNodes are included in their case view, an additional comparison of the Pending live non-stopping RuleNodes with the registered RuleNodes for all Tracked cases are useful. Differences in these lists may also highlight knowledge acquisition opportunities that help to mature the knowledge base more quickly than was possible for conventional MC-RDR systems. These queries may be provided as standard queries in various embodiments of the invention.

Untracking and Tracking Cases

In the system, a case is "Tracked" if its link to live RuleNodes are maintained in the Live RuleNode - Case associative data structure and / or in its derived or separately kept LRL together with the derived or separately kept LCL.

A tracked case does not need to be re-evaluated against the rule tree when a user wants to view its live RuleNodes and hence conclusions, because its live RuleNode list is already known by the system.

Conversely, a case is untracked if its- Live RuleNode associations are not maintained in the knowledge base. An untracked case needs to be re-evaluated against the rule tree when a user wants to view its live RuleNodes and hence conclusions.

The system allows a user to select a macro that untracks sets of cases identified by the user. Some examples include: all cases, all non-cornerstone cases, all expired cases, all resolved cases except the cornerstone cases, and all closed cases except the cornerstone cases.

The system allows a user to select a macro that tracks sets of cases identified by the user. Some examples include: all cases, all cornerstone cases, all open cases, all assigned cases. The system allows a user to select for each case individually whether or not the case should be tracked.

The system allows a user to set up global rules to define the default tracking treatment for new cases, for example, that the new cases are tracked as soon as the new cases are assigned until the cases are closed, after which the new cases are no longer tracked, unless the cases are a cornerstone case, or unless the new cases are one of the first five cases to be registered and live for any RuleNode.

Working Up a Case

The system goes beyond the collaborative capture of classification and solution knowledge to promote the collaborative capture and re-use of tacit problem solving knowledge, including classification and problem determination knowledge. It does this by capturing and sharing the questions that experts ask themselves when classifying incoming cases.

In the system, a conclusion can be a getAttribute(' attributeName') conclusion that indicates that the user should be prompted to enter the value of a particular attribute, in this case the 'attributeName' attribute, for the case. Alternatively, a conclusion can be a set AttributeC attributeName', 'attribute Value \confirm=true) conclusion that may be used to indicate that the 'attributeName' attribute should have its value set to 'attribute Value', that the changes should optionally be confirmed by a user, and that the case should then be re-evaluated against the rule tree.

Note also that natural language processing may be used to translate user articulated conclusions into the system's conclusion syntax. For example, the natural language statement "find out the product type" could be translated into the conclusion expression: get AttributeC product type'). User configured templates could be used to define these translations.

These features can be used to collaboratively manage attribute lists used by the system, as well as to facilitate problem determination and classification determination.

An example of working up a case is provided in Fig. 14. In this example, the user brings an empty case to the system that is evaluated against the rule tree. The user is having trouble knowing how to proceed with defining the case and searching for a solution to the problem on hand. The user is experiencing performance problems on a windows XP deployment of Product A with software version 2.5 and suspect that the user needs to upgrade their software but the user doesn't know the details.

Referring to Fig. 14, firstly, rule 1 tests that the 'product type' attribute has not been defined for the case. Note that in this syntax, !? tests that the RHS of the expression does not (!) exist (?). Obviously this is TRUE for an empty case so the user is prompted by the live RuleNode 1 to edit the case and enter the 'product type'. As well, rule 2 tests that the Operating system' has not been defined for the case. This is also TRUE for the empty case so the user is prompted by the live RuleNode 2 to edit the case and enter the 'operating system'.

Assuming that the user edits the case and enters the product and operating system details as 'product A' and 'windows XP',- now rule 3 and rule 4 both evaluate to TRUE. At this point rule 5 also evaluates to TRUE and the user is prompted to enter the 'software version'. Again, the user obliges and enters the software version as 2.5. The case then evaluates to TRUE for rule 6 and the user receives the recommendation: "It is recommended that the software be updated using update patch 7.8.9.". This example demonstrates several benefits of the invention. Firstly, since the rule tree is collaboratively built, a number of experts can document the relevant questions that a novice should ask themselves when attempting to define and classify the problem on hand, and subsequently navigate the knowledge base. Secondly, for a novice user who may not have any clue where to start in attempting to find a solution to their problem, this mechanism provides a guided troubleshooting methodology that leads the user through the rule tree to possible scenarios that the user may be experiencing, and possible solutions. Thirdly, the user only has to enter attributes relevant to their particular problem. This provides an effective and efficient way to manage potentially large lists of attributes for users, and it minimizes the time and effort that a user must expend in defining and classifying their problem, and finding a solution to it.

Analogous examples could easily be constructed for other domains. In the preferred embodiment of the system, when the user attempts to first create a case, the near-empty rule base will not present any attributes for the user to enter. The user will first need to populate the rule tree with RuleNodes checking for a lack of existence of the relevant attributes, and concluding with getAttribute() statements defining those attributes that should be fetched at that top level of the rule tree.

In summary, an interactive and recursive IR-MCRDR approach has been presented which helps users to collaboratively capture problem determination and classification determination knowledge, to navigate the solution or classification space in the knowledge base, to quickly classify the case on hand, and to find matching conclusions for the case on hand.

Using Hyperlinks

The system provides hyperlinks as either case attributes or conclusions. A hyperlink here means not just an internet URL, but the ability to have a user select a link via their mouse or keyboard, and use that link to launch an instance of any given software application, with any given protocol, and with any desired parameters that can be used to initialize that launched instance of the application. For example, the conclusion "myresource(num)" may be used to launch a web browser with http://myresource?mvvalue=num. The translation between the "myresource()" function and the http://myresource website can be defined in the system configuration settings.

In one embodiment, a lightweight implementation can accept cases simply from a hyperlink to that case in a separate case tracking system, and that can offer hyperlinks as conclusions. In this manner, the system can capture, process and display information from existing resources for example available on intranets; across the internet; and within a multitude of private and public knowledge bases, library and documentation systems. This data can be used to define and display the case, and to define and display conclusions associated with one or more RuleNodes.

Multiple Conclusions

The system allows multiple conclusions per RuleNode where those conclusions can be stored in a common data structure in the system, and reused as one of several conclusions for multiple RuleNodes across the system. The exception is that a RuleNode with a stopping conclusion is a stopping RuleNode and can have no other conclusions.

Indicating that the conclusion is actually a classification

The system allows users to identify whether a particular conclusion is in fact a classification, and then the system allows that classification to be reused in several unique and powerful ways throughout the system.

The system allows the user to identify the type of the conclusions that the user is assigning at a RuleNode. Conclusions may be identified for example, as a classification label for the present node, or as some other conclusion for the present node. If one of the conclusions at the present node has been previously defined in the system as a classification label, then the classification label can be presented as a highlighted hyperlink for example in the color purple, when the case is displayed and the user may for example, hover over the hyperlink with their mouse or click on the hyperlink to bring up the details for that other classification. Alternatively, the referenced classification data may be preprocessed and presented in an integrated fashion as part of the conclusion view for the case. This display choice may be made for example by a user explicitly using a show() or link() function in the conclusion, as discussed in the next section, or via user configuration settings.

For example, at a RuleNode that is used to define the classification "dog" and thereby catch all "dog" cases in the system, the user identifies the following conclusions as classification labels for this RuleNode: "dog" and "canine", and makes the following conclusions: "show('mammar,'aH')", and "barks". The "mammal" classification is preprocessed when any dog case is viewed, and the classification label and conclusions of the "mammal" classification are displayed as conclusions in the view of any dog cases.

In many domains, an expert may not be able to think of an appropriate label or name for a classification. For instance in the health domain, perhaps the expert can observe a set of symptoms without knowing the exact disease. However, the expert knows what actions need to be taken as a result of arriving at a particular live RuleNode, and the corresponding unlabelled classification. For example the actions may be that the patient should "drink more water", "cut out refined sugars", "eat more fibre" and so on. Providing a classification label at a given RuleNode is therefore optional. Where a RuleNode does have one or more conclusions that have been identified as classification labels, the alternate classifications, and the actions one should take as a result of arriving at that live RuleNode, can be linked to the RuleNode as a set of conclusions that can be reused elsewhere in the system. Note that some RuleNodes have multiple conclusions identified as classification labels. For example, in the biological and botanical sciences, both a scientific name and a common name are commonly recorded when labeling the classification of a species.

Moving from the General to the Specific

The following Table 5 lists four ways in which new RuleNodes correct a knowledge base and in particular introduces a new way, Scenario D, in which RuleNodes may be added by a user to correct a knowledge base.

Table 5

Scenario D in Table 5 presents a new scenario not previously handled by conventional MC-RDR systems. In this Scenario D, the user feels that the information presented to the user is not incorrect, but rather that the information is imprecise, and that the information needs refining rather than replacing. This scenario commonly occurs in taxonomies where one moves from more general classifications to more specific classifications, for example, when moving from mammal to a dog or a cat.

In this scenario, the user can indicate that the user wishes to refine the information provided rather than replace or reject the information. In that case, when the system presents the user with the user interface that allows the user to create the new child (referring) RuleNode, the system may pre-populate the conclusion set with conclusions that refer to the parent (referred) RuleNode. Table 6 provided some conclusion examples for the referring RuleNode:

Table 6

Similarly, if the referred classification is unnamed, a numeric reference to the referred classification can be used such as show(43) or link(43) where these functions preprocess and extract the conclusions from the given classification (in this case RuleNode 43) as required, and display the conclusions in accordance with the examples provided in Table 6.

Note that this referral mechanism can also be used for arbitrarily referred to classifications across the rule tree. In other words, the conclusions for a RuleNode can refer to any other RuleNode in the system with the showQ and/or linkQ function. The behavior of the show and link functions for conclusions depends upon the particular implementation and implementation platform. Behaviors may also be defined by system and user specific configurations.

Accepting and Rejecting RuleNodes

The following Table 7 shows the RuleNode acceptance scenarios that the user- system interaction must handle. In the table, 0 represents FALSE, and 1 represents TRUE. An example embodiment for this truth table is described by the flowcharts in FIG 2 A and FIG 2B. The processes in those flowcharts have been referred to in the following table.

Table 7

As can be seen in the above Table 7, independent of the RuleNode Status (i.e. whether the RuleNode is a Disapproved, Pending or Approved RuleNode), if the RuleNode is neither live nor registered for this case then the RuleNode does not appear in the case view so the reject (0) scenario can be ignored.

If the RuleNode status is Disapproved then the RuleNode is stopped by an unconditional stopping rule by a child RuleNode hence the RuleNode is not live for the case. However, if the RuleNode is still Registered for the case, the user is given an option to reject (0) the RuleNode and "De-register this RuleNode" for the case or alternatively, accept (1) the RuleNode and therefore "create a new RuleNode to accept the conclusions" from that unlive RuleNode. In that case, the conclusions for the Disapproved RuleNode may be copied over and possibly edited or augmented for a new RuleNode that is created elsewhere in the rule tree.

If the RuleNode status is Pending or Approved then the following scenarios are possible:

• A user can "Create a New RuleNode to accept the conclusions" by constructing and accepting a brand new RuleNode for the case. • For a RuleNode that is not live, but which is registered, a user can either reject

(0) the RuleNode to "Remove the RuleNode from the Registered List" or alternatively, accept (1) the RuleNode to "Create a New RuleNode to accept the conclusions" from that RuleNode. In that case, the conclusions for the unlive RuleNode may be copied over and possibly edited or augmented for a new RuleNode that is created elsewhere in the rule tree.

• For a RuleNode that is live, but not registered, a user can either reject (0) the RuleNode and "Create a New RuleNode to reject the conclusions" or alternatively, accept (1) the RuleNode and "Register the RuleNode".

• For a RuleNode that is both live and registered, a user can either reject (0) the RuleNode and "Create New RuleNode to reject the conclusions and de-register the RuleNode", or alternatively the user can re-accept (1) the RuleNode and "Update the Registration details" including the registration username and timestamp for the RuleNode. RuleNode Acceptance and Rejection Flowcharts

FIG 2A and FIG 2B show one possible embodiment from the above truth table. Note that other embodiments are possible which remain in the spirit of the truth table presented above. The flowcharts apply to RuleNodes with either a Pending or Approved status. For RuleNodes with a Disapproved status, the processes shown in steps 234, apply.

Figs. 2 A and 2B illustrate a process 200 of accepting or rejecting live versus registered RuleNodes. Processing commences in step 210. In decision step 212, a check is made to determine whether to accept or reject the RuleNode currently being processed. In the event that decision step 212 determines that the user does not want to do either, processing continues at step 213. In step 213, nothing is done and processing terminates. If decision step 212 determines that the conclusion is to be rejected, processing continues at decision step 214. Otherwise, if decision step 212 determines that the RuleNode is to be accepted, processing continues at decision step 228, which is depicted in Fig. 2B.

Reiectinε a RuleNode (FIG 2A)

In decision step 214, a check is made to determine if the RuleNode is live. If the RuleNode is not live, processing continues at step 216. In decision step 216, a check is made to determine if the RuleNode is registered. If the RuleNode is not registered, processing continues at step 218. In step 218, the system must commence error handling since this scenario should never occur in practice - a RuleNode that is neither live nor registered should never be presented to a user for rejection. Otherwise, in step 216, if it is determined that the RuleNode is registered, processing continues at step 220. In step 220, the RuleNode is deregistered. In this case, the registration, together with the registered username and registration date is removed from the RuleNode-Case association data structure that has previously been defined in the section entitled "Registering RuleNodes".

Referring again to decisions step 214, if the RuleNode is live, processing continues at step 222. In decision step 222, a check is made to determine if the RuleNode is registered. If the RuleNode is not registered, processing continues at step 226. In step 226, one or more RuleNode(s) are created to reject this RuleNode. The possibilities have been described in Table 5. Referring to that table, the user may select to do A, B, a combination of A and C, or D. Processing then terminates.

Otherwise, if decision step 222 determines that the RuleNode is registered, processing continues at step 224. In step 224, one or more RuleNodes are created using the possibilities described in Table 5 in order to reject the RuleNode, and the RuleNode is deregistered. Referring to that table, the user may select to do A, B, a combination of A and C, or D. This process is described in greater detail hereinafter with reference to Fig. 3. Processing then terminates.

Acceptim a RuleNode (FIG 2B) Referring again to step 212, if the decision step 212 determines to accept the

RuleNode, processing continues at step 228.

In decision step 228, a check is made to determine if the RuleNode is live. If step 228 determines the RuleNode is not live, processing continues at step 230. Otherwise, if decision step 228 determines that the RuleNode is live, processing continues at step 236. In step 230, a check is made to determine if the RuleNode is registered. If step

230 determines that the RuleNode is not registered, processing continues at step 232. In step 232, a new RuleNode is created and registered with the new conclusions provided by the user. Processing then terminates.

If step 230 determines that the RuleNode is registered, processing continues at step 234. In step 234, a new RuleNode is created and registered with the conclusions copied from the previously registered RuleNode, and with those copied conclusions possibly edited and / or augmented with additional conclusions by the user.

In decision step 236, a check is made to determine if the RuleNode is registered. If decision step 236 determines the RuleNode is not registered, the RuleNode is registered in step 240 as described in the section entitled "Registering RuleNodes" and processing then terminates. Otherwise, if step 236 determines that the RuleNode is registered, then the registration details as described in the section entitled "Registering RuleNodes" are updated with the new registered user, and by overriding the registration date with the most recent creation or modification date of the RuleNode. Processing then terminates. Creatins Rulenode(s) to Reject a RuleNode (FIG 3)

Fig. 3 illustrates in greater detail step 224 and 226 of Fig. 2 A. Processing commences in step 310. In decision step 312, a check is made to determine whether the wrong classification is to be stopped or replaced. If step 312 determines that the classification is to be stopped, processing continues in step 314. This decision to stop the RuleNode correlates with the reject (A) scenario described previously in Table 5 to add a stopping RuleNode at the end of the path to prevent the classification. In step 314, the user must offer a rule for the stopping RuleNode. The user is presented with a list of cornerstone cases that satisfy the user's rule. The user can modify the rule and hence change the list of cornerstone cases that user is seeing that satisfy the user's rule. This process can help the user in forming a sufficiently narrow rule to correctly define the new RuleNode. The user confirms their intention to create a new RuleNode with that rule and a new child RuleNode is created for this user with a stopping conclusion. Processing then terminates. Otherwise, if step 312 determines that the classification is to be replaced, processing continues at step 316.

In decision step 316, a check is made to determine whether the wrong classification is to be replaced with a new independent classification. If step 316 determines that yes, a new independent classification is required, then processing continues at step 322. In step 322, the user must offer a rule for the stopping RuleNode. This decision to stop the RuleNode correlates with the reject (A) scenario described previously in Table 5 to add a stopping RuleNode at the end of the path to prevent the classification. The user is presented with a list of cornerstone cases that satisfy the user's rule. The user can modify the rule and hence change the list of cornerstone cases that the user is seeing that satisfy the user's rule. This process can help the user in forming a sufficiently narrow rule to correctly define the new RuleNode. The user confirms their intention to create a new RuleNode with that rule and a new child RuleNode is created for this user with a stopping conclusion.

In step 324, the user must decide where in the rule tree to locate the new RuleNode. This decision to create a new independent RuleNode correlates with the new (C) scenario described previously in Table 5 to add a RuleNode at a higher level to give a new classification. The user must offer new conclusions for the RuleNode. The user may decide to copy the conclusions from one or more other RuleNodes in the rule tree, and edit those conclusions. The user may also decide to refer to another classification or RuleNode in the rule tree, for example by using the show() or link() functions. The user must offer a rule for the new RuleNode. The user is presented with a list of cornerstone cases that satisfy the user's rule. The user can modify the rule and hence change the list of cornerstone cases that the user is seeing that satisfy the user's rule. This process can help the user in forming a sufficiently narrow rule to correctly define the new RuleNode. The user confirms their intention to create the new RuleNode with that rule and conclusions and a new child RuleNode with its replacement conclusions is created. Processing then terminates. Otherwise, if step 316 determines that the classification is not to be replaced with a new independent classification, but rather with a dependent classification, then processing continues at step 318.

At decision step 318, a check is made to determine whether the wrong classification is to be replaced with replacement conclusions, or refining conclusions. If step 318 determines that the classification is to be replaced with replacement conclusions then processing continues at step 330. In step 330, the user must offer new conclusions for the RuleNode. This decision to create a replacement RuleNode correlates with the replace (B) scenario described previously in Table 5 to add a RuleNode at the end of the path to give a new classification. The user may decide to copy the conclusions from one or more other RuleNodes in the rule tree, and edit those conclusions. The user may also decide to refer to another classification or RuleNode in the rule tree, for example by using the show() or link() functions. The user must offer a rule for the new RuleNode. The user is presented with a list of cornerstone cases that satisfy the user's rule. The user can modify the rule and hence change the list of cornerstone cases that user is seeing that satisfy the user's rule. This process can help the user in forming a sufficiently narrow rule to correctly define the new RuleNode. The user confirms their intention to create the new RuleNode with that rule and conclusions and a new child RuleNode with its replacement conclusions is created. Processing then terminates. Alternatively, if decision step 318 determines that the wrong classification is to be refined then processing continues at step 340. In step 340, the parent RuleNode is referred to in one of the conclusions of this new child RuleNode. This decision to create a refining RuleNode correlates with the refine (D) scenario described previously in Table 5 to add a RuleNode at the end of the path to give a new more specific classification and to refer to the parent classification in the conclusions. The user may also decide to copy conclusions from one or more other RuleNodes in the rule tree, and edit those conclusions. The user may also decide to refer to another classification or RuleNode in the rule tree, for example by using the show() or link() functions. The user must offer a rule for the new RuleNode. The user is presented with a list of cornerstone cases that satisfy the user's rule. The user can modify the rule and hence change the list of cornerstone cases that user is seeing that satisfy the user's rule. This process can help the user in forming a sufficiently narrow rule to correctly define the new RuleNode. The user confirms their intention to create the new RuleNode with that rule and conclusions and a new child RuleNode with its replacement conclusions is created. Processing then terminates.

Copying the Details from Arbitrary RuleNodes

It can be seen in Fig. 5 that RuleNodes 4 and 5 are variations on the same theme - both conclusions recommend an upgrade with a software patch. Therefore, if RuleNode 4 was allowed the additional conclusion for example, "refer to the upgrade procedure document available at: http://myintranet/upgrade.pdf where the latter text string is an Internet URL that the viewer can click on to be directed to the relevant document in their web browser, then it would be of benefit to allow a user creating RuleNode 5 to indicate that it is a variation on the theme of RuleNode 4 so that when RuleNode 5 is created, the user can simply edit and modify the text provided at RuleNode 4, and apply it to RuleNode 5. In the system when a user is constructing a new RuleNode, a request can be made to copy the details from another RuleNode in the system. In that case, the other RuleNode' s rule and / or conclusions and conclusion types are copied to the view where the new RuleNode is being constructed, and the user can edit them to form the new RuleNode. Missing Cornerstone Cases

Some RuleNodes in the rule tree won't have any cases that are live for them, due for example to case drop-down, or in some cases, where a RuleNode has been directly created in the rule tree without reference to any case. In the system, it is recognized that since some RuleNodes in the rule tree won't have any cases that are live for them, that when a user wants to reject a set of conclusions from an ancestor RuleNode, a suitable cornerstone case may not exist for this dependent RuleNode in the ancestor RuleNode 's cornerstone case list which is comprised of its dependent RuleNode's cornerstone cases.

Fabricating Cornerstones

The system can construct one or more representative cornerstone cases on the fly for the user to differentiate their present case against.

An example is provided in Fig. 15. In this example, RuleNode 1 has as its cornerstone case, Case 1. However, RuleNode 2 has no cornerstone case. So when case 5 is presented to the system, and the user rejects the conclusion at RuleNode 1 in order to make a more specific conclusion, the system fabricates cases Fl and F2 which can appear in the cornerstone case list for RuleNode 1, together with Case 1 and Case 8. Note that the '*' is a wildcard indicating an unknown sequence of letters. The user can therefore more easily construct the differentiating rule 4 and formulate their conclusion for RuleNode 4.

Using a Rule View instead of a Cornerstone view to formulate rules

An alternative to fabricating the missing cornerstone cases, is that the system simply presents a rule-based view to users instead of a cornerstone case view. Some users may prefer this type of view. The rule based view that would be presented to a user trying to formulate a new child exception rule would include the conjunction of all the ancestor rules at the parent RuleNode, together with a negation of each of the sibling rules. In Fig. 15, the rule presented to the user who is attempting to construct RuleNode 4 would therefore be the rule sequence that characterizes the set of cases that are classified at RuleNode 3, namely [rule 0 && rule 1 && ! (rule 2 || rule 3)].

Using the mutually distributive nature of the Boolean AND and OR operators' this rule statement can be broken down into a conjunction of rules that contain ORs and NOTs inside them, but no ANDs. The aim is to produce a rule statement that contains no double negatives, and which only contains conjunctions of simple ORed rules. For example, using the distributive rules of Boolean Algebra we know that the rule sequence (A & B) I (C & D) can be re-written as (A|C) & (A|D) & (B|C) & (B|D). As well, it is known that !(A | B) can be re-written as (!A & !B).

In the example given, the rule sequence that characterizes the set of cases that are classified at RuleNode 3, namely [rule 0 && rule 1 && ! (rule 2 || rule 3)] can therefore be re-presented as [(rule 1 && !rule 2 && !rule3). Rule 0 is eliminated since it is always

TRUE. Hence the whole rule sequence can be presented simply as: grep ( 'product A' , 'product type' ) && ! grep ( ' 95 ' , 'operating system' ) && l grep ( ' 98 ' , 'operating system' ) && ! grep ( ' linux' , Operating system' ) .

Introducing Shared Child RuleNodes

A structure is introduced where a child node can have multiple parents, and therefore that a parent node may have one or more related parent nodes that each share a child RuleNode. An OR-ing structure is used for those rule paths that arrive at the same conclusion. The structure solves the problem of the same conclusion being offered up in multiple parts of the rule tree - the structures correct the rule tree. The structure also allows that paths like (rule A and rule B) or (rule C and rule B) that arrive at identical conclusions can be abbreviated as ((rule A or rule C) and rule B). The structure also

¹ For example see: http://mathworld.wolfram com/BooleanAlgebra.html. eliminates the need for actions that modify the outputted rules in the example scenario identified.

To support shared child RuleNodes, it is necessary to identify the different rules from the parents sharing the child node. As well, the shared child node may have siblings at different levels in the rule tree according to each different parent node.

In the supporting data structure, every RuleNode has the form:

< m * < P, r>, n * <C>, cc, p * <cs> > where this means that each RuleNode has:

• zero or more (m) duplets of the parent RuleNode (P) and the rule (r) that leads from it to this RuleNode,

• zero or more (n) child RuleNodes (C),

• optionally one cornerstone case (cc), and

• zero or more (p) conclusion statements (cs)

Table 8 uses this new data structure to describe the rule tree shown in Fig. 16. For the sake of simplicity, the cornerstone cases and conclusion statements have been omitted from the table.

Table 8

With this data structure, processing commences at the root RuleNode. For each RuleNode that evaluates to TRUE for the case on hand, the case is evaluated against each of that RuleNode's child RuleNodes as identified in the child RuleNode list shown in Table 8. The rule for each ChildNode depends on which parental rule path the evaluation is coming through. The <Parent RuleNode, Rule> list for each child RuleNode records which rule should be evaluated for each parental path. If a rule evaluates to FALSE then no further processing is required through that path. The last TRUE rule on each path through the rule tree constitutes the conclusions given.

For example, referring to the table above, if the case evaluates to TRUE for RuleNode 1 then it is evaluated against RuleNode 1 's child RuleNodes 5 and 6. The system must lookup the rule for parent RuleNode 1 at child RuleNode 5 and see that rule 5a is the appropriate rule to evaluate for this particular path through the rule tree. The system evaluates rule 5a and if it is TRUE for the case on hand then RuleNode 5 will become live for this case. Otherwise RuleNode 1 will be live for the case. RuleNode 5 may be evaluated as live for the case through multiple paths in the system. In that case as with all RuleNode-Case associations in the system, it is only recorded once for this case that RuleNode 5 is live for the case. Similarly if RuleNode 5 gets registered for the case by a user, it will only be registered once for the case.

Note that the order of execution for rule trees using this data new structure (with or without shared child RuleNodes) can be defined by re-ordering the "Child RuleNode list" at the parent RuleNode. For example, the user could view RuleNode 0 defined in Table 8 of { 1 ,2,3 } . Processing of the child RuleNodes for RuleNode 0 would therefore be done in the order of RuleNode 3, then RuleNode 2, then RuleNode 1. This mechanism can be used to manipulate the order of conclusions being presented to users.

Other Notes for Shared Child implementations

Before the system allows a new shared child RuleNode to be created, the system must check that a continuous dependency loop cannot be established where for instance a dependent (eg child, grandchild etc) node becomes its own ancestor node through any path.

If the user tries to use the same classification label or set of conclusions somewhere else in the system, the user can be automatically prompted to do a rule path combine using a shared child RuleNode. Typically this would be an unconditional rule path combine. In this context, unconditional means that the rules on the paths from each of the combined parent RuleNodes would be "TRUE" for all cases evaluated against the RuleNodes. As well, the system can provide a query to find all RuleNodes with the same classification label, or all RuleNodes with the same conclusion set, and the user can request to unconditionally combine those paths with a shared child RuleNode.

Another useful application of this data structure may be in defining the order of presentation of RuleNode conclusions under certain conditions. For example, a set of RuleNodes with rule paths (A, B, C) can be combined with a shared child RuleNode that tests for parent A the conditions B&C, for parent B the conditions A&C, and for parent C the conditions A&B i.e. the conjunction of the rule paths for each of the other

RuleNodes. The conclusions from each of these paths can be referred to at the shared child RuleNode using the show function, in the desired display order, for example show(C,'all'), show(B,'all'), and show(A,'all').

The normal user accept/reject mechanism for RuleNodes applies for systems using a shared child RuleNode data structure.

Note that the cornerstone case list at any RuleNode can still be constructed from the dependent RuleNodes using either shared child structure.

Ordered Intermediate Conclusions

In the system, a list of all those RuleNodes that have been identified as intermediate conclusions is kept. When a case is evaluated against the rule tree, if it comes to a rule that depends in some way upon an intermediate conclusion, evaluation proceeds backwards up the rule tree from that intermediate RuleNode to the root RuleNode. If a shared child RuleNode is encountered, only one of its parental paths need to be TRUE in order for the intermediate RuleNode to be TRUE for the case in question. An intermediate RuleNode will be determined to be TRUE if all the rules on at least one path back to the root rule node can be determined to be TRUE for the case in question. If it is discovered that the evaluation process depends on yet other intermediate RuleNodes in the rule tree, the RuleNodes can be evaluated in the same manner by progressing up the rule tree from their location, and the results of each intermediate evaluation can be stored for this particular case and reused if a test of that intermediate RuleNode is called upon a repeat time.

Note that in order to avoid endless loops of intermediate conclusions in the system, when a rule is constructed for some arbitrary RuleNode that depends on an intermediate RuleNode, the rule is checked to see if it can actually be satisfied without creating an endless dependency loop. An endless dependency loop could exist for example where RuleNode A tests for RuleNode B, and RuleNode B tests for RuleNode A.

Viewing Case Conclusions - Users without Update Privileges

In the system, some users, such as customers may have read-only privileges when viewing a case. In this case, the user can select whether the conclusions provided helped or did not help or if the user is unsure whether the user helped, and this can be recorded by the system. This interaction may not result in any further knowledge acquisition from this user, or changes to the knowledge base by this user, but the interaction can help more expert users to assess confidence levels in the RuleNodes seen by this type of user. An example is provided in Fig. 10. Note that the classification label headings could optionally be excluded from this view. This view may be more suited to customers than the more complex views shown in Fig. 8 and Fig. 9.

Viewing Case Conclusions - Applying Approval Profiles

In many cases, users of the system have update privileges and if a case falls through a parent approved RuleNode to a pending child node, the pending child node is shown in the case view. However, an alternate user profile may be provided where only live RuleNodes that are approved in one or more of the user's approval partitions are shown.

Users with profiles that only let the users have a glimpse of a snapshot of the rule tree according to their approved partitions, are able to indicate whether or not the information presented was helpful as described in the previous section, but the user is not be able to directly modify the rule tree. Note that a RuleNode that is not approved in a particular partition, and which has not been disapproved, may be pending approval for that particular partition, depending on the approval status of its ancestor RuleNodes.

The method by which a user's approval partition(s) can be used to determine that user's snapshot of the rule tree for a particular case is now described, particularly with reference to shared child RuleNodes:

1. Determine the live RuleNodes for the case.

2. For each live RuleNode, if that RuleNode's ancestors all meet the approval profile required by the viewer, then that RuleNode remains live for this customer profile and case.

3. Otherwise, find the nearest ancestor RuleNode whose ancestors all meet the approval profile required by the viewer. If a shared child RuleNode is encountered, proceed upward towards the root node through all paths leading from that shared child RuleNode, and report the nearest ancestor RuleNodes on each path where that ancestor RuleNode's ancestors all meet the approval profile required by the viewer. Note that for shared child RuleNodes, only one path back to the root node need meet the approval profile required by the viewer for that RuleNode to be considered live for the viewer's profile.

For example, a read-only customer user has an approval profile of ObOOOl meaning that the user can only see live RuleNodes that have an approval status of Obxxxl where x is the logical symbol for "don't care" - i.e. it can be a 0 or a 1 and it does not affect the outcome. Using the above algorithm against the rule tree shown in Fig. 5 where the approval status of the relevant RuleNodes is as documented in Fig. 8, and assuming that the root RuleNode has complete approval in every partition i.e. its approval status in this example is ObI 111 , and assuming that RuleNode 2 has an approval status of ObOOOl, then Fig. 10 shows the resultant case view. In Fig. 10, RuleNodes 0, 1, 2, 3, and 7 have all been approved in the customer approval partition. Therefore, the customer partition approved parent RuleNode 3 of the pending live RuleNode 5 is shown and the live customer partition approved RuleNodes 1 and 7 are shown. Tracking Attribute Changes

Conceptually, attributes may change in a number of ways. The attributes may be deleted. If the attributes are one of a set or some of a set type attributes, the attributes may have options added to the attributes or deleted from the attributes. Attributes may also be edited, for example, an integer type attribute may be converted to a float type attribute.

In the system, some of these possibilities are limited to enable cases to be tracked more meaningfully. In the system, attributes and their values are allowed to be decommissioned, rather than deleted. A decommissioned attribute or attribute value is not shown to the user when the user is creating a case. When the user edits the case, the old attribute or value may be shown but an indication is provided showing that the attribute or value has been decommissioned from the system, and therefore that an alternate attribute or value should be chosen.

Tracked cases that are affected by an attribute change may have the registration date for all affected registered RuleNodes set to the modification date of the attribute and hence the case. This allows the registration to be identified as expired next time that the user views the case. The change history for the case may also be modified. As well, the user assigned to the case may be notified that one or more RuleNode registrations has expired for that case.

Tracking Conclusion Changes

Note that if the user edits a conclusion, then all the RuleNodes in the system that reference that conclusion can be considered to be edited. In that case, the last modified date on the affected RuleNodes is updated. Therefore, all the tracked cases that have one or more of these RuleNodes registered for the cases show that the registrations have expired. In one embodiment of the system, this change to the tracked cases may be recorded in their change history (described in the next section).

Change Histories

The system can optionally record the change history for every element in the system. For cases, we can record the following items: the date and time when the modification occurred; the identity of the user who made the changes; the nature of the change such as: case creation, case edit, adding a RuleNode, registering a RuleNode, rejecting a RuleNode, or case drop-through; possibly the case summary and / or selected attribute-values for the case after the change was effected; the live RuleNodes for the case after the change was effected; and the registered RuleNodes for the case after the change was effected.

For RuleNodes, the following items can be recorded: the date and time when the modification occurred; the identity of the user who made the changes; the nature of the change such as: that a particular case was added or removed from the live case list (LCL), registered case list (RCL), or live path case list (LPCL); that a child RuleNode was created or deleted; the live cases for the RuleNode after the change was effected; the registered cases for the RuleNode after the change was effected; and the cases in the livepathcaselist for the RuleNode after the change was effected. Similarly the change history can be kept for conclusion statements, user details, attributes, ontologies, and configuration settings. In those cases the type of data recorded can include the date and time when the modification occurred; the identity of the user who made the changes; the nature of the change; and the new status of relevant data after the change was effected.

Discussion Forums

In keeping with the desire to promote collaborative knowledge acquisition, the system can allow an internet-style user discussion forum to be included at each System Page, RuleNode, Case, Conclusion, and Attribute view in the system. Such discussion forums may have an N to N thread to post relational structure, meaning that the same item may be posted to multiple threads. Those threads may be referred to at multiple locations in the system, for example across multiple System Pages, RuleNodes, Cases, Conclusions and / or Attribute pages.

User-based knowledge acquisition statistics

The system is focused on capturing collaborative classification and classification determination knowledge. The system captures statistics that help users to get confidence in the information presented, and in their peers. Statistics are captured that encourage, publish and promote the credibility of the users, and the collaboratively acquired knowledge.

Table 9 below shows some of the user-based knowledge acquisition statistics that may be recorded in the system.

Table 9

Embodiments of the Invention

General Embodiment

System Architecture

The system architecture of the general embodiment of this system may include hardware, software, people, processes and data. Various combinations of hardware and/or software may be practiced without departing from the scope and spirit of the invention. The software processes and data may reside all on one or more computer servers; client devices such as computer clients, mobile phones, PDAs, and other handheld or non handheld computer wares; and may involve storage mediums such as hard disks, or other forms of computer memory. The software design may be client- server, for example with a model-view-controller paradigm; dependent-on or independent-of a web browser; or. it may be single host and single user and stand-alone. The human processes may involve one or more human or computer or robot users working concurrently, individually or in sequence.

Software Design

Fig. 11 provides a detailed process flow diagram for the general embodiment of this invention. The transition between processes indicated in Fig. 11 may be immediate / synchronous or delayed / asynchronous. Delayed and asynchronous transitions between modules may be achieved using software queues and messages. This technique is well known to those skilled in the art. Additional features are provided which are not described in detail including those processes that deal with recovery from failed concurrent database transactions. These mechanisms are well known to those skilled in the art of software development.

The software modules described below may interact with data stores not shown in Fig. 11. These include internal or external data stores of attributes, cases, conclusions, classifications, rules, and ontology data.

Where the following descriptions include the statements "ontology data may be used to clarify word usage", or "the system may... display... ontology data", each displayed word that is recorded in an internal or external ontology may be able to be selected by the user, for example via a hyperlink, to display the meaning and synonyms for that word. As well, where the user is presently in a software view that permits data to be edited or entered, a substitute word may possibly be selected automatically, or by the user, from the ontology provided. The components of the system 1100 shown in Fig. 11 are now described. Note that the processes in Fig. 11 that involve interaction with a user have been displayed with a connecting line attached to a symbolic stick man user.

START

This subsection refers to sub-process 1103 in process 1100 of Fig. 11. The user may first commence interacting with the system by starting up the software application and / or web browser, and registering themselves as a user. For this and all subsequent accesses to the system the user can then log on to the system.

In an alternate embodiment, the user may be given a login name and password by a system administrator, or using some other existing authentication mechanism. In a different alternate embodiment, perhaps there is only one user, in which case the login mechanism is not be required.

VIEW. CREATE OR EDIT ATTRIBUTE

This subsection refers to sub-process 1106 in process 1100 of Fig. 11.

Users may view, enter and modify attribute details. Ontology data may be used to clarify word usage. The user may commit their changes for insertion or update.

ATTRIBUTE INSERT OR UPDATE

This subsection refers to sub-process 1109 in process 1100 of Fig. 11.

ATTRIBUTE INSERT OR UPDATE follows VIEW, CREATE OR EDIT ATTRIBUTE. Note that when an attribute changes, cases that use that attribute may evaluate to a new set of live RuleNodes in the rule tree. The system may examine which rules rely on the changed attribute and may determine if any "Tracked" cases or RuleNodes need updating. The system inserts or updates the relevant attribute, and may update the RuleNode registration details for the relevant "Tracked" cases as described in the section entitled "Tracking Attribute changes".

CASE CREATION

This subsection refers to sub-process 1112 in process 1100 of Fig. 11. [A] A user may enter and modify details to create a new case. The user may identify external case resources in the attributes of the case for example by using hyperlinks that refer to other software applications and that provide initializing parameters to those applications, or that simply contain internet URLs such as: http://findme.com/fetchme.html. A user may also be able to change the tracking status of the case, depending on their user profile.

[B] The system may fetch and process and display internal and external conclusion, attribute, and ontology data as necessary. The type of processing that may occur for data fetched from external resources may include string parsing, extraction, calculation, and/or highlighting, or conversion to other data formats like :avi or .mpeg sound files, or .png or .gif or jpeg or .bmp or .svg image / vector files, or conversion to .pdf or .doc or .html or .xls files. The system may upload and store these converted files and then create a hyperlink to the files in an attribute of the case. Note that external conclusion data may be accessed via hyperlinks.

[C] The system evaluates the case against the rule tree.

CASE INSERTION

This subsection refers to sub-process 1115 in process 1100 of Fig. 11.

CASE INSERTION follows CASE CREATION.

Case or system settings determine whether this case is "Tracked". The system inserts the case and updates any affected RuleNodes in the rule tree. If the case is not being tracked, then no RuleNodes are affected. However, if the case is being tracked, the set of affected RuleNodes will be those that the system evaluates as 'live' for the case. The corresponding RuleNode to Case live associations will be updated, and hence the LRL may be updated for the case, and the LCL and LPCL may be updated for the affected RuleNodes as described previously in the sections entitled: "Updating the live RuleNode to Case Associations", and "The LivePathCaseList" .

CASE SEARCH

This subsection refers to sub-process 1118 in process 1100 of Fig. 11. [A] The user provides the search criteria and the system searches for cases.

Search criteria might be the case status, as defined previously in the glossary; it might be a keyword search; it might be a search against a particular attribute matching criteria. Searches of particular interest have been described in the section entitled "Live vs Registered System Queries". Artificial intelligence or data mining techniques may be used to enrich the search, for instance using a nearest-neighbor or genetic or neural net algorithm; or by using an ontology. For example, the user may configure whether the user want to include or exclude similes from their cases searches.

[B] The system lists the cases found. [C] The user selects an existing case for viewing or editing.

CASE SELECTION

This subsection refers to sub-process 1121 in process 1100 of Fig. 11.

Where-as in the CASE SEARCH process, a user might identify a particular case for viewing or editing by clicking on that case; in this particular CASE SELECTION process, the user may identify an existing case for editing or viewing by entering the system identity of that case, and by selecting whether the user would like to view or edit the case.

CASE VIEW

This subsection refers to sub-process 1124 in process 1100 of Fig. 11. [A] The system may fetch and process and display internal and external case, conclusion, attribute and ontology data as necessary. The system recalls and re-evaluates cases that are "Untracked" or "Tracked" changed cases, against the rule tree, or it simply recalls "Tracked" cases. "Tracked" and "Untracked" cases are as described in section entitled "Case Tracking to reduce the size of LCL and RCL per Case". Note that a "Tracked" case may be changed if an attribute indicates that external data needs to be fetched every time this case is viewed, for instance via a hyperlink, and that fetched data has changed. Note also that data fetched in this manner for cases may be cached, and the mechanism for testing whether that external data has changed may be to compare the newly fetched data against a previous cached copy.

[B] The user views the case with its Registered and/or Live RuleNodes. The RuleNode data can be displayed for example as shown in Fig. 8, 9, or 10 according to the user's viewing profile and / or selection. Users with both update and read permission may be offered a selection of views to choose from. Words that appear in the case view that are stored elsewhere in the system such as in the ontology, as a classification label, or as an intermediate conclusion, may be highlighted and color coded.

CASE EDIT

This subsection refers to sub-process 1127 in process 1100 of Fig. 11. [A] The user may enter and modify details in order to edit an existing case. The user may identify external case resources, or may modify references to those resources. A user may also be able to change the tracking status of the case, depending on their user profile.

[B] The system may fetch and process and display internal and external case, conclusion, attribute, and ontology data as necessary.

[C] The system may evaluate the case against the rule tree in order for example to fetch additional getAttribute() directives from the rule tree.

CASE UPDATE

This subsection refers to sub-process 1130 in process 1100 of Fig. 11. CASE UPDATE follows CASE EDIT.

The case or system settings determine whether this case is "Tracked". The system updates the existing case and updates any affected RuleNodes in the rule tree. If the case is not being "Tracked", and the tracking status of the case is unchanged by the case edit, then no RuleNodes are affected. However, if the case is being "Tracked", the set of affected RuleNodes may include a selection of the RuleNodes that were previously, but that are no longer 'live' for this case ; and those that were not previously, but now are 'live' for the case. The corresponding RuleNode to Case live associations are updated, and hence the LRL for the case may be updated, and the LCL and LPCL for the affected RuleNodes may be updated as described previously in the sections entitled: "Updating the live RuleNode to Case Associations^'" and "The LivePathCaseLisf '.

PROVIDE RULENODE DETAILS

This subsection refers to sub-process 1133 in process 1100 of Fig. 11. The user provides new details for the new RuleNodes that need to be created as a result of the RuleNodes that the user has accepted or rejected in the CASE VIEW process. This mechanism is described next.

The details may include rules; conclusions; and conclusion types for example, whether the conclusion is a classification label, or an intermediate conclusion. The rule statements may be stored separately from the rule tree in a rule statement data structure referred to for each RuleNode in the rule tree. Similarly, the conclusion statements may be stored separately from the rule tree in a conclusion statement data structure. The benefit of this is that expired hyperlinks or errors in the conclusions can be easily updated and the updates apply globally. The user may be able to change the approval status of a RuleNode depending on their user profile and their approval partition profile.

Ontology data may be used to widen or restrict the meaning of the rules used. Otology data may be used to clarify word usage in the conclusion statement data.

The user may indicate that a conclusion is actually a classification label for the RuleNode. This means that RuleNode represents this particular labeled classification. More than one conclusion may be identified as a classification label. For example, in a scientific taxonomy a classification may warrant a common name and / or a scientific name. Two approaches are suggested for the RuleNode creation and edit view: a "classification label" conclusion type may be applied as described in the section "Indicating that the conclusion is actually a classification". Alternatively, one or more separate entry fields may be provided for the classification labels that will apply to this RuleNode.

The user may also provide a parent classification as one of the conclusions as described in section "Indicating that the conclusion is actually a classification" . Words that appear in the case view that are stored elsewhere in the system such as in the ontology, as a classification label, or as an intermediate conclusion, may be highlighted and color coded.

The system may fetch and process and display internal and external case and conclusion data.

RULENODE ADDITION

This subsection refers to sub-process 1136 in process 1100 of Fig. 11.

The user may add additional live RuleNodes to the case from the CASE VIEW process, or to the rule tree from the RULENODE VIEW process. If the RuleNodes are added from the CASE VIEW, the user may select where to locate the RuleNodes in the rule tree and the RuleNodes must evaluate to TRUE for the case. If the RuleNodes are added from the RULENODE VIEW, the RuleNodes are added below the currently selected RuleNode.

The mechanism is the same as that described in the PROVIDE RULENODE DETAILS process.

RULE TREE UPDATE

This subsection refers to sub-process 1139 in process 1100 of Fig. 11.

RULE TREE UPDATE follows RULENODE ADDITION and PROVIDE RULENODE DETAILS.

The system updates any existing RuleNodes and inserts any new RuleNodes, and updates any affected "Tracked" cases as described in the sections entitled "Updating the Live RuleNode to Case Associations" and "The LivePathCaseList" and "Registering RuleNodes". RULENODE SEARCH

This subsection refers to sub-process 1142 in process 1100 of Fig. 11.

[A] The User provides search criteria and the system searches for RuleNodes. Search criteria might be the RuleNode approval status, as defined previously in the glossary, or a keyword search, or a search against a particular rule statement or conclusion matching criteria.

Artificial intelligence or data mining techniques may be used to enrich the search, for instance using a nearest-neighbour or genetic or neural net algorithm; or by using an ontology. Ontology data may be used in the same manner as described for the CASE

SEARCH process.

[B] The system lists the RuleNodes found.

[C] The user selects an existing RuleNode for viewing or editing.

RULENODE SELECTION This subsection refers to sub-process 1145 in process 1100 of Fig. 11.

Where-as in the RULENODE SEARCH process, a user might identify a particular RuleNode for viewing or editing by clicking on that RuleNode. In this particular RULENODE SELECTION.process, the user may identify an existing RuleNode for editing or viewing by entering the system identity of that RuleNode, and selecting whether the user would like to view or edit the RuleNode.

RULENODE VIEW

This subsection refers to sub-process 1 148 in process 1100 of Fig. 11.

The user can view the RuleNode and can optionally view all of its associations to parent, sibling and child RuleNodes, and can optionally view all of its dependent RuleNodes, or just its immediate child nodes.

The system may fetch and process and display internal and external case and conclusion data. Ontology data may be used to clarify word usage. RULENODE EDIT

This subsection refers to sub-process 1151 in process 1100 of Fig. 11.

The user may modify an existing RuleNode where the mechanism is as described in the PROVIDE RULENODE DETAILS process.

VIEW / EDIT USER(S)

This subsection refers to sub-process 1154 in process 1100 of Fig. 11.

Users can view details and statistics of themselves and other users in the system. The users can edit their own details, and if the users have an administrator profile, the users can edit the details of others in the system. The system may determine user statistics from a user statistics data structure and / or from the rule tree and / or from existing cases. The system may also present aggregate statistics for groups of users within the system.

EDIT CONCLUSION(S)

This subsection refers to sub-process 1157 in process 1100 of Fig. 11. Users can edit existing conclusions, for example to update an expired hyperlink.

Hyperlinks can expire, for instance, when a website, internet or intranet resource or software application is moved, renamed, or decommissioned. The system may update affected cases and RuleNodes, and may update affected case and RuleNode histories.

CONFIGURE SYSTEM This subsection refers to sub-process 1160 in process 1100 of Fig. 11.

Users can update and view the system configuration, including the configuration parameters that define the behavior of zero or more of the following:

• any intelligent agent(s),

• the house keeper, • the data integrity checker,

• the ontology builder, and

• the hyperlink checker; As described in the system features, a number of additional items are available for configuration, including:

• The policy for finding a new or replacement cornerstone case.

• The policy on which cases are getting tracked in the system, and when the tracking for a case should be changed e.g. on case closure or expiry.

• User notification in the event of case drop-through.

• The configuration options for the "recommended default actions" described in the " Viewing Case Conclusions - Users with Update Privileges" section.

• The behavior of the show() and link() functions for conclusions. • The macros that translate a function used in a field of type 'hyperlink'. For example, the user can configure the syntax casetracker(lθl) used in an attribute (or a conclusion) for a case to translate to the hyperlink http://casetracker.com/mycasetracker.php?casenumber=101.

• User viewing profiles and the approved partitions for users. • The Natural Language Processing (NLP) templates for conclusions and for rules.

INTELLIGENT AGENT(St

This subsection refers to sub-process 1163 in process 1100 of Fig. 11.

One or more intelligent agent software processes may be employed to mine external case and conclusion resources to attempt to automatically deduce links between the cases and conclusions, possibly create RuleNodes, and update a corresponding log file.

HOUSE KEEPER

This subsection refers to sub-process 1166 in process 1100 of Fig. 11.

A house keeper may be used to sweep away any unused and unnecessary data, and to update a corresponding log file. DATA INTEGRITY CHECKER

This subsection refers to sub-process 1169 in process 1100 of Fig. 11.

A data integrity checker may be used to check the integrity of the stored rule tree and cases, and to update a corresponding log file.

ONTOLOGY BUILDER

This subsection refers to sub-process 1172 in process 1100 of Fig. 11.

An ontology builder may be used to build an ontology that can be used throughout the system to provide a reference for domain terms for example in case attributes, rule statements, and conclusions. The ontology builder may update a corresponding log file.

HYPERLINK CHECKER

This subsection refers to sub-process 1175 in process 1100 of Fig. 11.

A hyperlink checker may be used to check that hyperlinks used throughout the system in configuration settings and in case attributes, and in RuleNode details, aren't expired, and to update a corresponding log file.

VIEW LOGS

This subsection refers to sub-process 1178 in process 1100 of Fig. 11.

Users can view the output logs of the:

• intelligent agent(s), • house keeper,

• data integrity checker,

• ontology builder, and

• hyperlink checker.

System logs may also be kept to record any errors that may occur in any of the system processes. These system logs may be made available for viewing by some users. EDIT CASE TRACKING

This subsection refers to sub-process 1181 in process 1100 of Fig. 11.

Users can apply macros in the system to update the set of cases that are currently being tracked by the system as described in the section entitled "Untracking and Tracking Cases". The system must update the relevant cases and RuleNodes. This task may be completed by the house keeper.

UPLOAD FILES

This subsection refers to sub-process 1184 in process 1100 of Fig. 11.

Users can upload files to the system that can be referred to as attributes or conclusions in a case. Users can also replace previously uploaded files with a more recent version if appropriate. Some cases may evaluate to new live RuleNodes if their uploaded files referred to in their attributes change. In that case, the system will update the relevant "Tracked" cases and RuleNodes.

For example, the executable file containing "update patch 7.8.9" may be uploaded for the system and linked in the conclusion 5 as shown in Fig. 5.

VIEW AND EDIT ONTOLOGY

This subsection refers to sub-process 1187 in process 1100 of Fig. 11.

Users can view and edit the ontology. Some cases may evaluate to new live RuleNodes if rules that refer to the ontology change. The system may update the relevant cases and RuleNodes.

KNOWLEDGE VIEWER

This subsection refers to sub-process 1190 in process 1100 of Fig. 11.

A knowledge viewer may be included that for example uses Formal Concept Analysis and other knowledge browsing techniques to restructure the knowledge captured in the rule tree and present the knowledge in a navigable and structured way. Other Embodiments

Those skilled in the art will recognize in view of this disclosure that modifications and/or substitutions can be made to features of the General Embodiment without departing from the scope and spirit of the invention.

No Ontology - Minimalist Embodiment

If access to an ontology is eliminated, the system still works without ontological creation, modification, and without reference to an ontology.

No Shared Child RuleNode Structure - Minimalist Embodiment

If the shared child RuleNode structure is discarded, the system still works without this feature. In that case a post-processing mechanism may be used to combine or filter RuleNodes as required.

Removing Live and Registered and Tracked Cases

If the live, registered and tracked cases in our embodiment are not recorded, but other features such as shared child RuleNodes, or classification labeling are used, the system functions well for sequential or single expert updates with multi-user reads.

View A Case - Minimalist Embodiment

The features necessary for a view-only minimalist embodiment where the user wishes for a just a view of the conclusions derived for a given case, are the features of: START; CASE SELECTION; and CASE VIEW.

View The Knowledge - Minimalist Embodiment

The features necessary for a view-only minimalist embodiment where the user wishes for a view of the knowledge base is the feature of: START; and KNOWLEDGE VIEWER.

View, Edit and Update - Minimalist Embodiment The features needed for a view, edit and update minimalist embodiment are the features of START; VIEW, CREATE OR EDIT ATTRIBUTE; ATTRIBUTE INSERT OR UPDATE; CASE CREATION; CASE INSERTION; CASE SELECTION; CASE VIEW; PROVIDE RULENODE DETAILS; RULE TREE UPDATE; and RULENODE ADDITION. These features by themselves are sufficient to allow a user to populate a rule tree and hence knowledgebase. In a minimalist embodiment, user management and system configuration settings may be hard-coded for instance in text files. Such a process is well known to those skilled in the art of software development.

Thin Client Embodiment

In this embodiment, an in-between thin / fat client-server solution may be used, where most of the rule tree data resides on a central server and only some data, such as the infrequently changing ontology and attribute lists, reside on the client. A client-side process is notified by a server-side process if any of the client-loaded elements, such as the ontology and attribute elements are updated on the server. The client-side process is also notified when the knowledge base changes.

A model-view-controller paradigm is used to provided immediate feedback to the case view on RuleNode acceptance or rejection; and possibly on case edit with the getAttribute conclusions being thrown up as detail is added to the case.

This structure reduces the impact of knowledge discrepancies that result with a pull only model where multiple players are updating the system. This structure is like an "instant messenger" and reduces data-store collisions and consequently transaction rollbacks.

Fat Client Embodiment

In a different embodiment, once the knowledge base is mature, the knowledge base may also be moved to the client and a client process may receive update notifications from a central server.

As well, for users with view only privileges this fat client structure may make sense.

The Support Center Embodiment

The solution implemented lends itself to a dynamic knowledge environment where people need rapid access to the latest knowledge, and where many different users with different experience levels, are working in the same domain, trying to solve the same problems or make the same informed classifications, across many different possibly global locations.

The corporate call centre / support centre, where staff receive and solve large volumes of customer problems around the globe, 24 hours a day and 7 days a week, is one organisation where intensive knowledge capture, refinement, and reuse is vital to business success.

In this environment, incoming problems are often solved via reference to a range of materials, including databases and documents from other vendors, and often involve a chain of people who may contribute to one or more (possible) solutions. Therefore feedback and collaboration become important parts of the process.

Software solutions for the support-centre are typically focused on providing defect tracking by recording: who raised the call; what product is involved; what are the environment variables such as the operating system; to whom the problem is assigned; and the current status. More recently vendors have offered software that documents solutions turning the troubleshooting task into one of searching and matching a database of known solutions.

Between the case tracking and solution tracking vendor offerings there is a big gap that troubleshooting know-how can fall through. Uninformed troubleshooters may have difficulty knowing how to progress from the case on hand to the most relevant solution in a solution knowledge base. First of all, the troubleshooters need to know how to filter and augment the information provided in the case to determine the class of problem on hand. Secondly, on arriving at that problem class the troubleshooters need to know where to search, and what to search for in order to find relevant solutions. The embodiments of the invention improve troubleshooting effectiveness and efficiency by providing a framework for guided problem determination and guided solution matching. The system allows a team of informed troubleshooters to collaborate in defining the classes of problems being dealt with by a support centre, the additional information (attribute-value pairs) required by cases that fall into each of those classes, and the most relevant solutions for these classes of incoming problems. The system thereby simplifies and encourages solution reuse.

In the system, when a new problem ticket comes in, the customer service personnel may be presented with a set of questions enabling the personnel to more specifically describe the type of problem being observed by the customer. As new information is entered, relevant conclusions will be presented to the user including for example, useful internet links to relevant solutions in external knowledge-bases, and so on. The user may then be prompted to either rate or refine the system's knowledge.

In this embodiment attributes, cases, conclusions, classifications, rules, and ontology data may be stored internally or externally to the system. Where data is stored externally from the system, the data may be referenced by the system using for example, unique identifiers, or hyperlinks.

External Cases and Conclusions Embodiment

Fig. 12 shows the system architecture 1200 of one embodiment of the invention. The system software operates on one or more servers 1210, with one more clients

1260 accessing the system via an internet or intranet.

The system has access to system data 1220 that may be co-located with the server(s) 1210, or may in part or wholly reside elsewhere on the internet or intranet. Amongst other things, such as the system log files, the system data includes the following: attribute data; possibly ontology data; user data; case and case hyperlink data; classification and rule and rule tree data; and conclusion and conclusion hyperlink data. The system data could be stored for example in a relational database, flat files or as persistent objects.

The case hyperlinks in the system data 1220 may reference external cases 1230, for example in a legacy defect tracking system. The system 1210 may use those hyperlinked cases to display, process or reference the external case data 1230 when preparing content for display to the client(s) 1260.

Similarly, the conclusion hyperlinks in the system data 1220 may reference external solutions 1240, for example in a legacy solution knowledge base. The system 1220 may use those hyperlinked conclusions to display, process or reference the external solution data 1240 when preparing content for display to the client(s) 1260.

The software on the system server(s) may or may not be developed using a model-view-controller paradigm. It could be stand alone and implemented in many different software languages such as Visual Basic, Visual C, or Java. Or it may use a web server such as Apache or IIS to serve up web content, for example by running Java VBScript, and/or PHP code.

Client software may include an internet browser plugin, a stand alone software application, or a internet browser without plugins executing for example HTML and / or Javascript and / or VBSCRIPT and / or Java code.

The Open Systems Embodiment

In this embodiment, there are no approval partitions for RuleNodes and RuleNodes do not get approved. Rather, all users can insert and update knowledge in the knowledge base and a change history is kept for all RuleNodes. Every RuleNode can be considered to be approved by default.

The system therefore becomes a classification wiki, where a community of users can collaboratively classify cases in the domain in questions and provide conclusions for those classifications.

In this embodiment, the system has internal data stores for attribute, case, conclusion, classification, rule, and ontology data, though these may refer to external resources via hyperlinks.

The clients may use Internet browsers executing HTML/Javascript and possibly Java code, or custom browsers or plug-ins may be used.

The server is capable of serving up content to the clients and may use technologies such as PHP / Java / or ASP.

The rule base and other data may be stored in a relational database but may be equally well implemented as a persistent object store.

A small number of embodiments of the invention have been described. In the light of the foregoing, it will be apparent to those skilled in the art in the light of this disclosure that various modifications and/or substitutions may be made without departing from the scope and spirit of the invention.

List of References

Kang, B., P. Compton and P. Preston (1995). Multiple Classification Ripple Down Rules: Evaluation and Possibilities. Proceedings of the 9^th AAAI- Sponsored Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, Banff, Canada, University of Calgary.

Claims

CLAIMS We claim:

1. A method of processing conclusions in a knowledge-based system using multiple-classification-ripple-down rules for generating an output conclusion in response to an input case, said system using cases, classifications and conclusions, said method comprising: adding a RuleNode at the end of a rule tree path for a live RuleNode that has been rejected to provide a conclusion and to refer to a parent conclusion of said added RuleNode.

2. The method according to claim 1, wherein said adding step refines a general classification of a RuleNode to be more specific, wherein general information presented to a user is refined to be more specific rather than replaced or rejected.

3. The method according to claim 1, wherein said adding step comprises creating a child (referring) RuleNode and pre-populating a conclusion set with conclusions that refer to a parent (referred) RuleNode.

4. The method according to claim 1, wherein a rule is provided for said added RuleNode, and a list of one or more cornerstone cases is provided that satisfy said rule of said added RuleNode.

5. The method according to claim 4, wherein said rule and said list of cornerstone cases can be changed.

6. The method according to claim 1, wherein said adding step comprises creating one or more RuleNodes to reject and deregister a live, registered RuleNode that has been rejected.

7. The method according to claim 1, wherein said adding step comprises creating one or more RuleNodes to reject a live, unregistered RuleNode that has been rejected.

8. The method according to claim 1 , further comprising the steps of: if a live but unregistered classification is accepted, registering said live but unregistered classification; if a not live, registered classification is accepted , creating and registering a new RuleNode with said existing not-live, registered classification and conclusions; if a not live and unregistered classification is accepted , creating and registering a new RuleNode with said not-live and unregistered classification and conclusions; and if a not live, registered classification is rejected, deregistering said classification.

9. The method according to claim 1 , wherein for a live classification that is rejected, performing the steps of stopping said classification, or modifying said classification.

10. The method according to claim 9, wherein the step of modifying comprises, if a new rule is a refinement of a parent rule, creating and registering a new child RuleNode with a replacement classification and conclusion.

11. The method according to claim 1 , wherein said knowledge-based system is implemented using a collaborative knowledge management system.

12. The method according to claim 1, wherein a computer system implements said method.

13. The method according to claim 1, wherein said RuleNode has classification labels that are different from their conclusions.

14. The method according to claim 1, further comprising linking conclusions" at said added RuleNode that represents a subclassification of the parent RuleNode to conclusions at the parent RuleNode.

15. The method according to claim 1, further comprising reierring io one or more other RuleNodes from said added RuleNode to reuse classifications and conclusions across said knowledge base system.

16. The method according to claim 1, further comprising copying conclusions from one or more other RuleNodes to said added RuleNode and editing said copied conclusions.

17. The method according to claim 1, further comprising combining RuleNode paths with a logical "OR" using a shared child RuleNode structure.

18. The method according to claim 17, further comprising prompting a user to perform said combining step.

19. The method according to claim 1, wherein multiple conclusions are associated with each RuleNode and stored in a separate data structure that allows centralized updating of said conclusions.

20. An apparatus for processing conclusions in a knowledge-based system using multiple-classifϊcation-ripple-down rules for generating an output conclusion in response to an input case, said system using cases, classifications and conclusions, said apparatus comprising: means for storing RuleNodes, cases, classifications and conclusions and relationships amongst said RuleNodes, cases, classifications and conclusions; and means for adding a RuleNode at the end of a rule tree path for a live RuleNode that has been rejected to provide a conclusion and to refer to a parent conclusion of said added RuleNode.

21. A computer program product having a computer readable medium storing a computer program for processing conclusions in a knowledge-based system using multiple-classification-ripple-down rules for generating an output conclusion in response to an input case, said system using cases, classifications and conclusions, said computer program product comprising: computer program code means for storing RuleNodes, cases, classifications and conclusions and relationships amongst said RuleNodes, cases, classifications and conclusions; and computer program code means for adding a RuleNode at the end of a rule tree path for a live RuleNode that has been rejected to provide a conclusion and to refer to a parent conclusion of said added RuleNode.

22. A method of processing conclusions in a knowledge-based system using multiple-classification-ripple-down rules for generating an output conclusion in response to an input case, said system using cases, classifications and conclusions, said method comprising: evaluating one or more intermediate RuleNodes each having one or more intermediate conclusions in a rule tree by evaluating one or more rule paths in reverse up the relevant paths in said rule tree.

23. A method of processing conclusions in a knowledge-based system using multiple-classification-ripple-down rules for generating an output conclusion in response to an input case, said system using cases, classifications and conclusions, said method comprising: maintaining a live RuleNode data structure, a registered RuleNode data structure, a live case data structure, a registered case data structure, a live path case data structure, and a live RuleNode to case associative data structure in respect of a rule tree and cases.

24. The method according to claim 23, wherein one or more of said data structures is a list.

25. The method according to claim 23, further comprising the steps of tracking, untracking and retracking cases using one or more of said live RuleNode to case associative data structure, said live case data structure, and said live RuleNode data structure.

26. The method according to claim 23, further comprising the step of updating said live RuleNode to case associative data structure for a change in a case, a conclusion, a RuleNode, an attribute or an ontological entry.

27. The method according to claim 23 or 26, wherein said maintaining step is performed in the background.

28. The method according to claim 23 or 26, wherein said maintaining step is performed at a specified time or specified time interval.

29. The method according to claim 23, further comprising the step of supporting modification, addition, and deletion of a case already processed, and presenting a comparison of previously registered conclusions with new live conclusions for said case.

30. The method according to claim 29, wherein for deletion of a cornerstone case, fabricating and constructing one or more representative cornerstone cases.

31. The method according to claim 29, wherein for deletion of a cornerstone case, providing a new rule view to formulate one or rules.

32. The method according to claim 23, further comprising the step of notifying a user according to a corresponding user profile when a change in the knowledge base occurs.

33. A method of processing conclusions in a knowledge-based system using multiple-classification-ripple-down rules for generating an output conclusion in response to an input case, said system using cases, classifications and conclusions, said method comprising: generating said input case by working up said input case by answering questions provided by one or more classifications from one or more RuleNodes that fetch more attribute details for the case.

34. The method according to any one of claims 1-19 and 23-33, further comprising the step of updating knowledge acquisition statistics on a per user basis, including statistics of how often RuleNodes of an expert are used, corrected, augmented, approved and disapproved, and the number of times said expert's cases are revisited and previous decisions are corrected.

36. The method according to any one of claims 1-19 and 23-33, further comprising the step of providing a user with a corresponding profile that grants access privileges.

37. The method according to claim 36, further comprising the step of changing the user's view according to said profile that has been provided for said user.