General information about the NéOpus system

Background

The NéOpus system is basically an extension to Smalltalk-80 with first order, forward chaining production rules. It originated from an OOPSLA '87 paper by B. Atkinson and J. Laursen (ParcPlace), that described the "Opus" system, a transposition of OPS5 rules in Smalltalk-80.

The NéOpus system is a rewriting of the Opus system that started in 89, and includes a number of original features (described below). It has been the core of a number of research projects in Knowledge Representation at LAFORIA (AI lab of Paris 6 University) and other research labs in France and in the world.

The system's implementation, as well as a discussion of the conceptual hypothesis and methodological issues may be found in my Ph.D. thesis (in French, available at LAFORIA on request). Some other papers describe various aspects of the system (see publications). NeOpus is being used in a number of applications (ventilator management in Intensive Care Units, automatic analysis of tonal music, database model transformation, etc.) You can get the system for free.

Quick description of the system

NéOpus is a trademark. The name was deposited by UPMC in March 13th 1993. NéOpus adds a facility for writing 1st order forward-chaining rules to Smalltalk-80. Those rules may be seen as "conditional actions" and are expressed as if-then statements. The main characteristics of the system is its ability to

match any Smalltalk object in the rules
use any Smalltalk expression in the rules'condition as well as action parts.

Practically this means that NéOpus respects encapsulation : writing rules does not require to know the structure of the objects (as in other rule-based systems, where the structure of objects is explicitely manipulated in rules via attributes). Also, no extra "rule language" is introduced : rules parts are exclusively composed of Smalltalk messages defined by the classes of the objects that match it. Rules are compiled in an extended Rete network for efficiency (Cf. works of Charles L. Forgy). This means that "partial matches" are computed only once. When a object is created or modified, the system (Rete network) minimizes the number of update operations.

Here is an example of a NéOpus rule. If we supose the classes Doctor and Patient, we can write a rule that says that "when the blood pressure of the patient is greater than the maximum blood pressure, then the doctor considers a treatment", as follows:

considerTreatmentForHyperTension
        | Doctor d. Patient p|
        p bloodPressure > d maxBloodPressureForPatient: p.
actions
        d considersTreatmentFor: p.
        d modified. p modified.

This rule is to be interpreted as "For any d instance of Doctor, and any p instance of Patient, if "p bloodPressure > d maxBloodPressureForPatient: p" is true then execute "d considersTreatmentFor: p". Of course bloodPressure, maxBloodPressureForPatient: and considersTreatmentFor:, are standard Smalltalk methods implemented in the classes of the corresponding variables.

The last line of the rule is called a modified statement. It is necessary to indicate the system which objects have been modified after the rule is executed. To know more about this general problem, you can read the proceedings of the OOPSLA'94 workshop on eoops.

Besides the standard first-order forward-chaining scheme, a couple of original and powerful features have been added to the basic Rete-based mechanisms:

Taking of class inheritance into account: In the preceding rules, the expression "For any x instanceOf Patient" may mean several things depending on wether class inheritance is taken into account or not. NéOpus gives the posibility of specifying 2 types of typing for rule variables: "simple" typing (only the instances of the class are considered) or "natural" typing(instances of subclasses are also considered). In our example, this can be useful to have natural typing, and to have subclasses of Doctor that redefine method maxBloodForPatient: for instance. The same rule may therefore be used with different classes of objects, and yield different results.
Rule base inheritance: Rules are written using the basic facilities for writing methods. Rules are grouped in rule bases which are abstract classes. A novel meachnism has been implemented to transpose the notion of class inheritance to rule bases. This allows structuring rule bases in hierarchies so as to factorize common rules, specialize existing rule bases, and redefine rules locally. The rule base inheritance may also be used as a default control strategy where rules defined in the lowest base are preferred in case of conflicts.
Declarative control architecture: Control in NéOpus may be specified using NéOpus itself. In this scheme, rule bases are not activated by the procedural inference engine, but by the activation of other rule bases (called meta-bases). These meta-bases are standard NéOpus rule bases. This allows to use all the functionalities of NéOpus to specify control. The benefits are : - complete separation and independance of control knowledge with domain knowledge - ability to factorize control specification (using rule base inheritance)
Other more technical facilities: These include local variables in rules, possibility of mixing 0-order with 1st order reasining, possibility of specifying initial sets of objects to be matched against the rules (context) to avoid combinatorial explosion, the possibility to retain the current state of instanciation to perform non-continuous inferences.
Facilities for multi-agent programming: Rule bases may be "instanciated" so as to have completely indepedendent yet "identical" rule bases. Each instance has its own set of objects to be matched, initial context, conflict set, control strategies. This is particularily useful in multi-agent environments where several agents may have the same rule base, but with its own set of execution objects and parameters.
The programming environment: for rules and rule bases follows the same spirit than the standard Smalltalk environment for writing methods and classes : rule browsers, hierarchy browsers, cross-references (implementors, senders, messages) for rules, file in/out and so forth. Some tools are specially dedicated to rule-based programming: steppers, conflict set views, graphical conflict set views (using the orchestra score metaphor), instance browser, and dedicated rule base browsers.

How to get the system

For Unix workstations

get the source for VisualWorks 1.0 , or for VisualWorks 2.5.

You will get a compressed tar file sourcesNeOpus.tar.Z, uncompress and untar it and you will get the correct directory with one subdirectory called "kb" in which there are the examples.

For PC

There is a only the VisualWorks 2.5 version, available as 2 zipped files : system and examples.

One of the files in the sourcesNeOpus directory is the file you are reading know (README). An another one is the fileIn.st file, which loads all the necessary Smalltalk files to build a NéOpus image. You have to edit the fileIn.st file to indicate the directory where you put the source files, before actually filing it in.

The directory (kb) contains example files (sources for classes and rule bases), that you can load at your convenience.

Requirements

NéOpus runs on VisualWorks 2.5, on all platforms supported by Smalltalk. It uses (and therefore requires) the Parser generator from Object Kit (APOK). Ask your local Smalltalk distributor for info on APOK.

A collaborative project with Canadian compagny OTI is in progress to implement the NéOpus ideas in other dialects of Smalltalk.

Related stuff

You can also know everything about the OOPSLA'94 Workshop on Embedded Object-Oriented Production Systems. If you like Smalltalk, inquire about The European Smalltalk User Group. The BackTalk system follow sthe same philosophy than NeOpus, with constraint satisfaction techniques.

Publications

You can access to some publications about NéOpus, with papers (in French and in English), and a user's manual in English, that describe how to start up the engine. I suggest using the examples to understand the system's philosophy.

Those wanting to have information on the development of NéOpus and associated work may send me their electronic address, and I will forward them all news concerning updates and news on NéOpus in general.

If you do use the system and like it, you can send me a postcard at the following address:
Francois Pachet
LIP6
Universite Paris 6
Tour 46-00, 75252 Paris Cedex, France

Tel : (33).1.44.27.70.04
Fax: (33).1.44.27.70.00

If you have any sort of comment, suggestion for improvement, bug-report, you can use the same address of mail me directly at Francois.Pachet@lip6.fr ; I am particularily interested in any ideas for improvement, modification and by your ideas in using Smalltalk for knowledge representation in general.

Finally, NéOpus is not a commercialized product. I will try to maintain the system in good working condition but it remains basically a research product.

Main Page