General information about the NéOpus system
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
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.
match any Smalltalk object in the rules
use any Smalltalk expression in the rules'condition as well as action
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:
| Doctor d. Patient p|
p bloodPressure > d maxBloodPressureForPatient: p.
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
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
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
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
How to get the system
For Unix workstations
the source for VisualWorks 1.0 , or for
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.
There is a only the VisualWorks 2.5 version, available as 2 zipped files
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.
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.
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.
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:
Universite Paris 6
Tour 46-00, 75252 Paris Cedex, France
Tel : (33).126.96.36.199.04
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.