Artificial Intelligence in Medicine 5(1993) 431-446

Logic-based integrity constraints and the

design of dental prostheses
P Hammond

a,b

, J C Davenport , F J Fitzpatrick

The School of Dentistry, The University of Birmingham, St Chad's Queensway,

Birmingham B4 6NN, UK
b

Advanced Computation Laboratory, Imperial Cancer Research Fund, Lincolns Inn Fields, London
WC2A 3PX, UK
Received September 1992
Revised February 1993

Abstract
Hammond, P., J.C. Davenport and F.J. Fitzpatrick, Logic-based integrity constraints and the design of
dental prostheses, Artificial Intelligence in Medicine 5 (1993) 431-446
This paper describes the ongoing development of a design assistant, RaPiD, for use in prosthetic dentistry.
RaPiD integrates computer-aided design, knowledge-based systems and databases, employing a logicbased representation as the unifying medium. The user's manipulation of icons representing the
developing design is interpreted as a set of transactions on a logic database of design components. The
rules of design expertise are represented as constraints in first order predicate logic and design alterations
are subject to the checking of the constraints. When design rules are contravened as the result of some
proposed alteration, a suitable critique is presented to the user. RaPiD is being developed for use in both
dental education and practice.
Keywords Computer-aided design, critiquing, knowledge-based systems, logic databases, Prolog,
prosthetic dentistry.

1. Introduction
The substantial literature that has accumulated in recent years bears testimony to the
level of interest in the application of artificial intelligence (AI) techniques in automating or in
assisting the design process. Software engineering has been an obvious candidate to receive
such attention and programmers' assistants have been developed for a variety of programming
languages, notably for the two major AI programming paradigms of LISP and PROLOG [7, 8,
38]. However, in order to appreciate the sophistication and the variety of intelligent design
assistants one must turn to architectural and engineering design ([39] and excellent survey
papers in [26] for process design, [31] for control systems design, [9] for mechanical
engineering design and [1] for aerospace).
a

Correspondence to: P. Hammond, The School of Dentistry, The University of Birmingham, St Chads
Queensway, Birmingham B4 6NN, UK, tel: +44 21 269 3171, fax: + 44 21 269 3186, email:
ph@acl.icnet.uk

Artificial Intelligence in Medicine 5(1993) 431-446

The development of computer-based assistants for the design of prostheses has

traditionally been based in bioengineering and biomechanics, for example in hip prosthesis
design [10]. More recently, efforts have been made to integrate design expertise using
knowledge-based and expert system techniques ([25] also for hip prostheses; [13] for hip and
knee prostheses). This paper describes a knowledge-based assistant for the design of a dental
prosthesis known as a removable partial denture (RPD) [23]. This application of AI to RPD
design suggested the adoption of the acronym RaPiD.
Design applications frequently require the manipulation of many component types,
each with a multitude of attributes, geometrical properties, constraints and related computations
or methods. Therefore, object-oriented models of the design process and the designed artefact
are popular [12, 34]. The major benefits of an object-oriented approach to the implementer of a
design assistant include code reusage, data abstraction and a clear, coherent organisation.
For systems manipulating a large number of components, the introduction of objectoriented database management techniques is often unavoidable [28]. The objects designed in
RaPiD, removable partial dentures, have a small enough number of components not to warrant
a special purpose database management subsystem. However, the design of RaPiD itself does
borrow techniques from a related area, logic databases [20]. The use of predicate logic to
represent design constraints is being taken up in other intelligent design systems [27, 34]. In
this approach, the rules of expert design, or even the commonsense geometrical properties of
design components, can be represented as integrity constraints and design alterations can be
viewed as transactions on the database of design components subject to the validation of the
constraints. Various methods have been proposed for checking such integrity constraints,
usually with the aim of avoiding the evaluation of all constraints when only "local" changes are
made [14, 15, 17, 21, 40].
When a designer makes an alteration to a design that contravenes a constraint, a
suitable warning describing the violation can be presented immediately or recorded for
subsequent repair later, as in RaPiD and in the ArchObjects system [34], a building design
assistant concerned with fire hazard regulations. Such a critiquing style of computer-based
advice was pioneered in the anaesthesia advice system ATTENDING [35] and subsequently
used in kitchen design in the CRACK system [18], the latter being an intelligent design
assistant with the explicit representation and application of integrity constraints but with no
reported exploitation of deductive database techniques. The use of a critiquing style interface in
RaPiD will certainly enhance its value in training.
In the remainder of this paper, we explain the motivation behind our project and
describe an initial evaluation of the prototype version of RaPiD. The main section of the paper
describes how logic-based integrity constraints are being introduced as a development of the
initial version of RaPiD.

2. Background and motivation

A removable partial denture is a prosthesis for replacing missing teeth in partially
dentate patients. It has the important functions of restoring the patient's appearance, improving
speech, assisting mastication and maintaining a healthy, stable relationship between the
remaining natural teeth.

Artificial Intelligence in Medicine 5(1993) 431-446

2.1 Design of removable partial dentures

The artificial teeth are carried by a metal framework which is attached to the natural
teeth by specialised components, for example rests to gain support and clasps to gain retention
for the denture. The efficient design of these components requires a detailed knowledge of
design principles, properties of materials and the response of the oral tissues to prostheses. The
production of the design is therefore the responsibility of the dental surgeon who undertakes
this after a careful, clinical evaluation of the patient's oral condition and health, and after a
detailed analysis of plaster models of the patient's jaws. The dentist records the resulting design
as an annotated diagram (Fig. 1) which is supplied to the dental technician as instructions to aid
the manufacture of the denture. The metal framework is cast by the dental technician in cobaltchromium alloy using the lost wax process. The artificial teeth and gumwork are subsequently
attached to this framework to produce the finished denture.

Figure 1: A design produced by hand

The design of removable partial dentures is a clinical responsibility yet there is ample
evidence that this responsibility is commonly delegated to the dental technician. Basker et al [2,
3] undertook two surveys 10 years apart of design information provided by dentists. They
found that a modest improvement in design practice had occurred in that period (1978- detailed
designs provided by dentists in 21% of cases, no instructions 54%; 1991 - detailed designs
40.3%, no instructions 27.3%). However, as approximately 60% of cases in the second survey
were still not accompanied by detailed instructions, the authors concluded that the situation was
still far from satisfactory. A similar pattern of delegation of design by dentists to technicians
has been reported in the United States [24], Australia [37] and Sweden [36, 42]. It is likely
therefore that to improve design procedures in dental practice, attention will need to be given to
better training in design and more effective design tools.
The increasing computerisation of dental practices raises the possibility of applying
computer-aided learning and knowledge-based systems techniques to this problem. The
introduction of such systems has several potential advantages:-

Artificial Intelligence in Medicine 5(1993) 431-446

(a) the availability of expert knowledge to guide the practitioner towards a design which
conforms to accepted criteria;
(b) effective undergraduate and postgraduate instruction in design by employing a critiquing
approach (vide supra) and by utilising clinical problems which are real and relevant to the
participating dental practitioner;
(c) the production of clear, comprehensive, high quality design instructions which will be easy
for the technician to follow;
(d) the possibility of monitoring design procedures and recording changes in partial denture
provision locally, regionally or even nationally.
2.2 Knowledge-based systems and removable partial denture design
There are a number of interesting and usable computer systems for removable partial
denture design currently under development, some of which are knowledge-based. The first
recorded in the literature was produced in a joint project of the Universities of Osaka and Kyoto
in Japan [32, 33]. A similar, but more sophisticated, system has been implemented in the USA
by Wicks and Pennell [44]. Both of these systems expect the user to indicate edentulous areas
(missing teeth) and to provide other information describing the oral condition of the patient as
they generate and present a graphical representation of the design. In addition, both apply
internal design expertise to deduce where some components of the design should be positioned.
The user can accept the system's suggestions or make some limited alterations.
Beaumont [5, 6] uses the Hypercard software as the basis for his "browsing" style
system. As with the two previous systems, the computer is very much in control of the design
process, offering the user menu choices which dictate the direction in which the design will be
developed. A graphical representation of the design is also presented at all stages. The
Beaumont system does allow some graphical alteration using "paint-like" tools, but as the
changes are at the pixel level it is difficult to subject them to checks for clinical correctness.
Indeed, the graphics generated in each of the three systems discussed so far does not support
any sophisticated reasoning about the shape or positioning of denture components. A feature
common to the system produced by Beaumont and that by Wicks and Pennell is the use of an
underlying decision tree structure to guide the design process. Progress can be made either
linearly under the guidance of the computer system or by selectively revisiting earlier decision
points in the design. This is a useful feature for exploring alternative designs but is too
restrictive to be practicable in cases other than those explicitly covered.
A group at the University of Bristol in the UK [43] are using a combination of video
and computer graphics for computer aided learning in prosthetic dentistry. Partial denture
design is viewed as an ideal vehicle for testing the pedagogical approach as well as the
underlying technology. Once more, the design is built up in stages but here each is separated by
a question and answer exercise designed to test the student user's knowledge before allowing
further progress. Some interaction with the graphical presentation of the design is allowed, for
example to suggest locations for some components.
Most recently, another system, Stelligraphe, has been launched commercially in France
[19]. Public domain descriptions of the software are yet to be made available and little is
known of the methodology used in its design and implementation.

Artificial Intelligence in Medicine 5(1993) 431-446

2.3 Some drawbacks of the approaches previously taken

The reproduction of important clinical features of individual patients is not always well
catered for. The systems either present the user with a limited number of clinical cases or are
unable to simulate variations such as teeth movement into gaps along an arch (of the jaw), tooth
rotation, or the precise location of undercut areas (positions on sound teeth where the retaining
components of the denture might grip).
Selection of some denture components is often made from a palette of icons predrawn
to fit individual teeth and allow juxtaposition of denture components. To cover all possible
clinical permutations would require a very large library of pre-drawn components. The icons
representing teeth and denture components make use of bit-mapped graphics. The icons are not
manipulated directly by the user to show which teeth are missing, or to indicate the type and
location of denture components, or to reposition the components if initially placed incorrectly.

3. The prototype RaPiD system

The authors have prototyped a design system for removable partial denture design,
primarily to test the feasibility of implementing a realistic, intelligent design assistant on a
desktop micro-computer. The prototype [23] was implemented in the logic programming
language PROLOG on a Macintosh IIfx micro-computer. The particular version of PROLOG
used, MacPROLOG [30], provides built-in object-oriented graphics and excellent dialogue
construction tools besides the usual support for the PROLOG programmer.
Two important objectives in the prototype were to avoid unnecessary requests for
additional information from the user and to restrict the use of keyboard and pointing device to
the minimum necessary for indicating a preferred design solution. The majority of the earlier
design systems expect the user to identify edentulous areas at worst by answering yes-no type
questions for each tooth, or better, but still not ideal, by entering a list of tooth numbers in a
dialogue separate from the graphical display. We consider it to be more natural and more
efficient to make selections directly on the graphical display by positioning a cursor and
pressing a button on a mouse, roller ball or similar device.
The design rules adopted in the prototype were obtained from an atlas for the design of
removable partial dentures [16] which itself is influenced by the proceedings of an international
conference [4]. Subsequent development of the system will incorporate rules based on a
comprehensive evaluation of all the relevant dental literature with emphasis being given to
those aspects for which there is convincing scientific evidence.
3.1 The user interface in the prototype RaPiD system
The current prototype version of RaPiD contains three major components: a graphical user
interface, a design knowledge base and an inference engine. The user of RaPiD is presented
with a design window with three areas. The first, the toolpane on the left in Fig. 2, is a
collection of tools for building the design; the second (lower left) gives an overall view of the
design and the third (large expanse to the right) contains the drawing area where the design is
constructed. The design tools enable the user to indicate missing teeth and to position and alter
denture components by editing their outlines and by translating or rotating them.

Artificial Intelligence in Medicine 5(1993) 431-446

Figure 2: A design window in the RaPiD prototype

Each component in a design has two interpretations [22]. One has a meaning in terms
of the clinical problem of producing a prescriptive design for a particular patient. The other
concerns the component's two-dimensional, geometric description and juxtaposition with
respect to the remainder of the design. The declarative nature of the graphics subsystem in
MacPROLOG and the pure PROLOG representation adopted in the implementation means that
any reasoning about components can easily shift between the two; at one point interpreting the
spatial arrangement and movement of the components by the user and at another checking the
clinical correctness of the alteration with respect to the in-built design expertise.
When an inappropriate alteration or addition is made to the design and the in-built
design rules/constraints are contravened, the user is informed and suitable corrective action can
be taken (see Fig. 3). Some design constraints, mainly those concerning default size, shape and
orientation of components, are applied automatically and so are beyond the users control.
However, most of the automatically computed features of a component can be altered
subsequently and, of course, re-validated with respect to the design rules.
A more detailed account of the features and functionality of the prototype is given
elsewhere [23].
3.2 An initial evaluation of the prototype
A preliminary evaluation of the prototype has been undertaken by using it to produce designs
for 22 patients. Printed computer-generated designs have been sent to both the clinician and
technician involved in each case together with a copy of the original hand-drawn prescription.
Each was asked to complete a short questionnaire which involved the grading of seven aspects
of the design regarding the design diagram, the design instructions and the patient description.
Using a simple range of summary descriptors (poor/adequate/good/very good), all but 3 of the

Artificial Intelligence in Medicine 5(1993) 431-446

154 responses were good or very good. One response of poor was related to a typing error and
two responses of adequate have formed the basis of further improvements to the prototype.

Incorrectly Placing A Rest

Rests for bounded saddles are best placed
adjacent to the saddle
OK

Fig 3. Critiquing rest placement

4. The development of RaPiD

While the prototype was being implemented (1990/91) and subsequently improved
(1991/92), the authors became convinced of the appeal and elegance of representing the design
as a logic database of components and the rules capturing design expertise as integrity
constraints. However, redesign was not possible until much later and after funding from the UK
Universities Finance Committee was attracted to begin a full-scale and properly designed
reimplementation starting in March 1992.
4.1 Design rules and constraints in RaPiD
There are three types of design rule in RaPiD. To begin with, there are those that are
applied automatically when certain design components are initially generated. These describe
characteristics such as the default size of rests (those components transferring pressure during
mastication from denture to sound teeth), the orientation of certain rests on the supporting,
sound teeth and the "unbreakable" connection between rests and clasp arms (the retaining and
reciprocating components of the denture). These are design rules which the user is typically not
given the opportunity to break. Hence, they need not be represented as explicit constraints.
However, if other actions by the user make them inapplicable or redundant, (for example,
major alteration of a rest's shape might subsequently make orientation ill-defined) they may
need to be ignored even as design rules.
The most common type of design rule in RaPiD is applied as a constraint immediately
after the relevant design alteration has been made. Straightforward examples of such
constraints are

Artificial Intelligence in Medicine 5(1993) 431-446

the limitation of the placement of rests onto sound supporting teeth;

a single supporting flange (the acrylic material into which artificial teeth are set) for a
saddle (a sequence of artificial teeth);
the undesirable covering of soft tissue by a major connector (the component connecting all
other subcomponents together);
the correct placement of a rest on an abutment tooth (as illustrated in Fig. 3) in terms of its
relative positioning to the front or back of the jaw.

Any contravention of such a constraint causes the user to be notified immediately

whereupon corrective action can be taken. Thus, the constraint contravention, the critique and
the users subsequent modified design alteration is a process of negotiation.

Figure 4: In this partial denture the indirect retainers* are inefficient because they are
placed too close to the clasp axis (dotted line).

The four examples of constraints listed above require only simple geometrical
reasoning. A more complicated spatially-oriented constraint concerns axes of rotation
that can be produced by certain combinations of rests. Figures 4 and 5 below illustrate
the potential complexity of the geometrical reasoning required. Such constraints are
essentially the same as those listed above but with one important difference. They
cannot be checked until the user decides that the design specification is sufficiently
complete and then invokes their application (rather like a programmer might invoke a
compiler/interpreter in a PROLOG programming environment). Of course, in some
situations, it may not be suitable for the user to take on such responsibility.

Artificial Intelligence in Medicine 5(1993) 431-446

Fig 5. If the clasp axis is moved closer to the saddle and the indirect retainers*
further away, the effectiveness of the indfirect retention is improved

In this case, the constraint may be applied automatically and, when contravened, be recorded as
a failed constraint requiring attention before the design can be submitted for manufacture.
A third type of constraint checking involves correcting a user's contravention
dynamically but with minimum or no fuss. For example, over a period of time teeth can drift
naturally into edentulous areas unless some corrective action is taken, such as the fitting of a
removable partial denture. To simulate this drifting, tooth icons must be manipulable into these
gaps. However, any such movement must be constrained to the natural arch formed by the
underlying shape of the jaw. If the user attempts to manipulate a tooth too far away from the
arch, the attempted movement is corrected continuously, during the repositioning. The
constraint checking mechanism corrects each small step of the users tooth repositioning
without negotiation and reflects this correction on the screen by projecting the users intended
position to one that is acceptable on the arch. (N.B. This is in addition to providing feedback to
a user by producing intermediate positions of a component graphically as it is being moved.)
Some other design rules are proving difficult both to define and to apply. For example,
since users are given considerable freedom in altering the default shapes of components, there
will need to be some constraints on the acceptance of the amended shape. Whereas computed
shapes are guaranteed to be well-formed, RaPiD must contain some knowledge of which edited
shapes are acceptable. There may also be situations where spatially or cosmetically oriented
constraints conflict with clinically oriented ones. For example, a constraint concerned with the
placing of components where they may be unsightly requires careful judgement as to what
might be cosmetically acceptable.
Table 1 lists a variety of situations that arise with some simple constraints and the
corresponding critique or negotiation that might ensue:

Artificial Intelligence in Medicine 5(1993) 431-446

10

Table 1: A list of simple design alterations, related constraints and an action/critique

to take/present to the user upon their contravention
Design alteration
Make tooth artificial
Genertate flange for saddle
Place rest on tooh

Position clasp on tooh

Movement of tooth

Examples of constraints
1 Tooth must not already be artificial
2 Edentulous are must exist and not
already have a flange
3 Tooth must be present
4 Tooth must be sound
5 Some rests must be associated with a
saddle
6 Rest must have correct orientation to
centre of tooth
7 Rest must have correct mesial/distal
position
8 Tooth must be present
9 Tooth must have a unique rest for
connection
10 Clasp shape is initially contoured to
tooth
11 Clasp arm runs between rest and
undercut point
12 Final position of tooth should be on
arch
13 Cosmetically acceptable

Critique
Simple beep warning
Beep
Beep
Detailed message
Ask user
Initially unbreakable
Ignored after editing
Detailed message
Beep
Beep
Initialliy unbreakable
Unbreakable
Continuous automatic repair
Detailed message

4.2 Integrity constraints and logic databases

A deductive database [40] is a finite set of deductive rules or closed logical formulae
(here extended Horn clauses) of the form
A B1 ... Bn

where the head A is an atom and each Bk, 1 k n, n 0, in the body of the clause is a positive
or negative literal. All variables appearing in the atoms are assumed to be universally
quantified with maximum scope. Integrity constraints are clauses of the form
A1 ... A m B1 ... Bn

where each Ak, 1 k m, m 0, is an atom and each Bj, 1 j n, n 0, is a positive or

negative literal; once more all variables are assumed to be universally quantified with
maximum scope. Sometimes, we shall represent integrity constraints in the equivalent form as a
denial
B1 ... Bn

A1 ... Am

where we separate the variables appearing in any Ak but not in any literal Bj and quantify them
existentially.
Integrity constraints in general are syntactically non-Horn clauses. It should be noted
that any rule in a deductive database is syntactically indistinguishable from an integrity
constraint. However, where a rule contributes to the definition of a relation, an integrity

Artificial Intelligence in Medicine 5(1993) 431-446

11

constraint restrains the definition of a relation. Note that integrity constraints in general cannot
be handled by PROLOG directly, because they are non-Horn clauses.
A deductive database db satisfies a set of constraints ic if and only if every formula in
ic is a logical consequence of comp(db), the completion of db. comp(db) comprises db itself
along with the only-if versions of each rule in db plus appropriate axioms of equality. In
practice, the only-if halves of the rules are omitted and we reason about the completed database
through the negation as finite failure rule [11]. The integrity constraints, then, are not used to
deduce new information but to restrain alterations to the associated database.
To check an integrity constraint in the denial form
B1 ... Bn

A1 ... Am

we simply set this formula in the PROLOG interpreter as a goal clause

: B1 , ... , Bn,

not A1 , ... , not Am

By taking negation as negation by finite failure, an integrity constraint (a non-Horn clause in

general) becomes a generalised Horn clause, which can be interpreted by PROLOG.
If we map the design of removable partial dentures to the logic database model, then
we need to start with a representation of the design components and their relative
juxtapositions. For example, we might have a database of the form:
tooth(t(1,1), present).
tooth(t(1,2), artificial).
tooth(t(1,3), artificial).
Etc
saddle(saddle1, [t(1,3), t(1,2)] ).
Etc
rest_on_tooth(rest1, t(1,4)).
rest_on_tooth(rest2, t(2,1)).
Etc
clasp_complex(clasp1, t(1,4), rest1).
clasp_complex(clasp2, t(2,1), rest2).
Etc

where t(Q,N) represents the tooth in position N (N {1,2,3,4,5,6,7,8} ) of quadrant Q (Q

{1,2,3,4} ), according to a recognised UK convention, and we might have the following
definitions
tooth(Tooth,State)
saddle(Saddle, TeethList)
rest_on_tooth(Rest, Tooth)
clasp_complex(Clasp, Tooth, Rest)
associated with Rest

: tooth Tooth is in state State

: there is a saddle Saddle comprising the set
of artificial teeth TeethList
: the rest Rest is on Tooth
: there is a clasp complex Clasp on Tooth

Artificial Intelligence in Medicine 5(1993) 431-446

Now, adding a new rest to the design is interpreted as adding an additional fact for
rest_on_tooth to the database - similarly for saddles and clasps. Changing a tooth's state will
involve the deletion of the "tooth" fact describing its old state (e.g., present) and the insertion of
a new "tooth" fact describing its new state (e.g., artificial). These design alterations need to be
checked against the integrity constraints associated with the database.
For example, we could represent constraints 3, 7 and 12 of table 1 in the following
form as denials:
rests can only be placed on present teeth

IC3:

rest_on_tooth(Rest, Tooth)
not tooth(Tooth,present).

rests must be placed in a correct mesial/distal relationship relative to abutment teeth

IC7:

rest_on_tooth(Rest, Tooth)
centre_position(Rest, PointR)
supports_saddle_type(Tooth, SaddleType)
correct_relative_position(SaddleType, Position)
not relative_position(PointR, Saddle, Position).

teeth can only drift along the arch of the jaw

IC12:

tooth(Tooth, present)
in_arch(Tooth, Arch)
centre_position(Tooth, Point)
not on_arch(Point, Arch).

assuming suitable definitions are provided for the predicates with relation names
centre_position, supports_saddle_type, correct_relative_position, relative_position, in_arch
and on_arch.
4.3 Assimilating database updates and accepting design alterations
We model the assimilation of database updates in terms of a meta-relation assimilate in
the style of Kowalski [29]. assimilate(Old_db, IC, Input, New_db, Result) holds if and only if
Result is the result of an alteration Input to the data base Old_db in terms of the consistency of
Old_db+Input IC where Db+Input would be the state of the database Db after making the
updates corresponding to Input and New_db is the state of the database after the
acceptance/rejection of Input. In the context of RPD design, Input is usually assumed to be the
cause of any inconsistency, is rejected and the user is informed accordingly. The incorrect
placement of rests relative to abutment teeth (see Fig. 3) is an example of such an
inconsistency. Alternatively, the Input might be amended (before being accepted) with or
without negotiation with the user. The restricted movement of teeth along an arch has already
been noted as an example of such a constraint.
Following Sergot [41], the assimilate predicate is defined as follows:
assimilate(Old_db, IC, Input, New_db, Result) :update( Input, Old_db, New_db),
assimilation( IC, New_db, Result).

12

Artificial Intelligence in Medicine 5(1993) 431-446

where
assimilation( IC, New_db, rejected) :- inconsistent(New_db, IC).
assimilation( IC, New_db, accepted) :- not inconsistent(New_db, IC).

and inconsistent is defined in terms of checking the constraints against the new version of the
database. Thus the integrity constraints are checked against the new database state only.
Next, we allow Input to represent the action or event which results in the database
update/design alteration. For example, we could name actions such as
place_rest(Rest, Tooth).
make_artificial(Tooth).
place_clasp(Clasp, Tooth, Rest).
remove_clasp(Clasp, Tooth, Rest).
move_rest(Rest, Position1, Position2).

To use this approach we would need to define update :

update(place_rest(Rest, Tooth), Old_db, New_db) :insert(rest_on_tooth(Rest, Tooth), Old_db, New_db).
update (make_artificial(Tooth), Old_db, New_db) :delete(tooth(Tooth, State), Old_db, Intermediate_db),
insert(tooth(Tooth, artificial), Intermediate_db, New_db).
update (place_clasp(Clasp, Tooth, Rest), Old_db, New_db) :insert(clasp_complex(Clasp, Tooth, Rest), Old_db, New_db).

4.4 Use of pre-conditions

Most of the constraints described so far only have an effect on individual states of the
database, they do not affect transitions between database states. Restrictions on redundant
updates, such as trying to make artificial a tooth that is already artificial, are better expressed
with reference to the associated action rather than the underlying, primititve insert/delete
operations. We can catch such updates by checking the consistency of the database
update/design alteration against the existing state of the database before constructing the new
version. We do this by introducing pre-conditions [41], for example,
pre_condition(make_artificial(Tooth), (tooth(Tooth, absent) ; tooth(Tooth, present)) )

which states that a tooth must either be absent or present before it can be made artificial. If we
introduce such dynamic constraints, then an alternative definition of assimilate needs to be
provided in addition, for example, something like
assimilate1(Old_db, Input, New_db, Result) :assimilation1(Old_db, Input, Result),
result(Result, Input, Old_db, New_db).
assimilation1(Old_db, Input, accepted) :not ( pre_condition(Input, Condition), not deducible(Old_db, Condition) ).
assimilation1(Old_db, Input, rejected) :-

13

Artificial Intelligence in Medicine 5(1993) 431-446

pre_condition(Input, Condition), not deducible(Old_db, Condition).

result(rejected, Input, Old_db, Old_db).
result(accepted, Input, Old_db, New_db) :- update(Input, Old_db, New_db).

where deducible simply represents the relevant database query evaluation (in our
implementation, this will simply mean executing Condition as a PROLOG goal). In the case of
a failed integrity constraint, the output message could be more informative, e.g., expressed as a
term containing some description of the constraint that has been contravened rather than as the
simple string rejected. This would then be used as the basis for the critiquing message to the
user.

5. Concluding remarks and future work

The positive reaction to the RaPiD prototype that we have received from dental practitioners,
dental students and dental technicians is encouraging evidence that the RaPiD design assistant
is likely to be popular for both teaching and prescribing. The performance of the prototype also
supports the authors view that the hardware and software adopted provide a robust, efficient
and easy-to-use interface. However, the first important test of RaPiD will be the scaling up of
the size of the design knowledge base (currently less than 50 rules). We are taking the naive
approach of checking all integrity constraints against each design alteration during the initial
adoption of the logic databases approach. Thereafter, we shall compare the approaches
described in the literature for more efficient checking of constraints. The most demanding task
that we shall be investigating next concerns the automatic generation of a design of a
removable partial denture with all the complex spatial reasoning that that will entail.
The logic-based approach to computer-assisted design supports descriptions of
artefacts and components in declarative terms rather than, for example, as sequences of
instructions to draw them on a computer screen. This abstract representation of a design
provides additional opportunities for defining higher-level rules which can capture an expert
designers knowledge for comparing design solutions. To support this work we anticipate
collecting a large number of designs from a wide audience of users of the RaPiD system.

Acknowledgements
FJF is funded under the KBS Initiative of the UK Universities Funding Council. The
authors are indebted to Marek Sergot for providing advice on the use of integrity constraints
and for making available his lecture notes on logic databases; the referees suggestions for
improving the paper are also much appreciated.

References
[1]
[2]

M. Ali, Intelligent systems in aerospace, The Knowledge Engineering Review Vol 5 No 3 (1990)
147-166.
R. M. Basker and J. C. Davenport, A survey of partial denture design in general dental practice,
Journal of Oral Rehabilitation 5 (1978) 215-222.

14

Artificial Intelligence in Medicine 5(1993) 431-446

[3]

[4]
[5]
[6]
[7]
[8]

[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]

[23]

[24]
[25]

[26]
[27]

R. M. Basker, J. C. Davenport and A. Harrison, Designing removable partial dentures in general

dental practice, Proceedings of the 38th Annual Conference of the British Society for the Study of
Prosthetic Dentistry (1991).
J. F. Bates, D. J. Neill and H. W. Preiskel, Restoration of the partially dentate mouth (Quintessence,
Chicago, 1984).
A. J. Beaumont and H. J. Bianco, Micro-computer removable partial denture design, Journal of
Prosthetic Dentistry Vol 6 No 2 (1989) 417-421.
A. J. Beaumont, Micro-computer removable partial denture design: the next evolution, Journal of
Prosthetic Dentistry Vol 6 No 2 (1989) 551-556.
J. Bonar and R. Cunningham, BRIDGE: an intelligent tutor for thinking about programming, in J.
Self (Ed.), Artificial Intelligence and Human Learning (Chapman and Hall, 1988), 391-409.
P. Brna, A. Bundy, H. Pain and L. Lynch, Programming tools for Prolog environments, in J.
Hallam and C. Mellish (Eds.), Advances in Artificial Intelligence (Society for the Study of
Artificial Intelligence and Simulation of Behaviour, John Wiley and Sons, 1990) 251-264.
I. M. Carter, Applications and prospects for AI in mechanical engineering design, The Knowledge
Engineering Review Vol 5 No 3 (1990) 167-180.
P. B. Cinquin, D. Chalmond, D. Berard et al, Hip prosthesis design. Lecture Notes in Medical
Informatics 16 (Springer, Berlin, 1982) 195-200.
K. L. Clark, Negation as failure, in H. Gallaire and J. Minker (Eds.), Logic and Databases (Plenum,
New York, 1978).
C. M. Coupal, P. G. Sorenson and J-P. Tremblay, A constraint-driven approach to object-oriented
design representation, in J. Gero (Ed.), AI in Design'91 (Butterworth Heinemann, 1991).
H. Crawford and P. Unwin, The CADCAM contribution to customised orthopaedic implants,
Effective CADCAM91, Proceedings of Institute of Mechanical Engineers, to appear.
S. K. Das and M. H. Williams, A path finding method for constraint checking in deductive
databases, Data & Knowledge Engineering 4 (1989) 223-244.
S. K. Das, Deductive databases and logic programming (Addison-Wesley, 1992) .
J. C. Davenport, R. M. Basker, J. R. Heath and J. P. Ralph, A Colour Atlas of Removable Partial
Dentures (Wolfe Medical Publications Ltd, Ipswich, 1988).
C. F. Eick, S. Kumar and J. L. Liu, Tolerant consistency enforcement for knowledge-based
systems, Methodologies for Intelligent Systems 4 (1989) 94-101.
G. Fischer and A. Morch, CRACK: A critiquing approach to co-operative kitchen design. ITS-88
Montreal, June 1-3, (1988) 176-185.
J. Gaillard, Appolline Productions, Sainte-Usage - 71500 Louhans, FRANCE.
H. Gallaire and J. Minker (Eds.), Logic and Databases (Plenum, New York, 1978) .
J. Grant and J. Minker, Integrity constraints in knowledge-based systems , in H. Adeli (Ed.),
Knowledge Engineering Applications Vol III (McGraw Hill, 1990) 1-25.
P. Hammond, L. K. S. A. Aye and J. D. S. Kay, PROLAB - PROLOG-based assistant for
biochemical data interpretation, Proceedings of First International Conference on the Practical
Application of PROLOG, London, 1992.
P. Hammond, J. C. Davenport and A. J. C. Potts, Knowledge-based design of removable partial
Dentures using direct manipulation and critiquing, Journal of Oral Rehabilitation (1992), to appear
in 1993.
F. Hardy and L. M. Stuart, A critique of materials submitted by dentists to dental laboratories for
the fabrication of removable partial dentures, Quintessence Dent Tech 7 (1983) 93-95.
G. R. Harvey and R. A. H. Harvey, The use of intelligent CAD in the design/analysis of primary
and revisional arthroplasties. International Computers in Engineering Conference, ASME San
Fransisco, July 31 - Aug 3, 1988.
D. Hutton, J. W. Ponton and A. Waters, AI applications in process design, operation and safety,
The Knowledge Engineering Review Vol 5 No 2 (1990) 69-96.
M. Inui and F. Kimura, Design of machining processes with dynamic manipulation of product
models, in J. Gero (Ed.), AI in Design'91 (Butterworth Heinemann, 1991).

15

Artificial Intelligence in Medicine 5(1993) 431-446

[28] A. Kemper, P. Lockerman and M. Wallrath, An object-oriented database system for engineering
applications, Proceedings of ACM-SIGMOD'87, San Fransisco (1987) 299-310.
[29] R. A. Kowalski, Logic for Problem Solving (North-Holland, New York, 1979) .
[30] Logic Programming Associates Ltd, RVPB, Trinity Road, London, SW18 3SX.
[31] D. Linkens, AI in control systems engineering, The Knowledge Engineering Review Vol 5 No 3
(1990) 181-214.
[32] Y. Maeda, S. Tsutumi, M. Minoura, M. Okada, T. Nokubi and Y. Okuno, An expert system for
designing removable partial dentures - preliminary report, Journal of the Osaka University Dental
School 25 (1985) 79-84.
[33] Y. Maeda, S. Tsutumi, M. Okada, M. Minoura, T. Nokubi and Y. Okuno, An expert system for
designing removable partial dentures - the role of database, Journal of the Osaka University Dental
School 27 (1987) 75-82
[34] B. K. MacKellar and F. Ozel, ArchObject: design codes as constraints in an object-oriented KBMS,
in J. Gero (Ed.), AI in Design'91 (Butterworth Heinemann, 1991).
[35] P. L. Miller, ATTENDING: A Critiquing Approach to Expert Computer Advice (Pitman, Boston,
1984).
[36] B. Owall, Design of removable partial dentures and dental technician education, Svensk Tandlk
Tidskr 67 (1974) 21-29.
[37] D. A. S. Parker, N. H. Cheung and L. C. Richards, A survey of removable partial denture
prosthodontics: attitudes of dentists to treatment planning, Aus Dent J 32 (1987) 343-353.
[38] C. H. Rich and E. Shrobe, Initial report on a LISP programmer's apprentice, IEE Transactions on
Software Engineering 4 (6) (1978) 456-467.
[39] M. A. Rosenman, J. S. Gero, P. J. Hutchinson and R. Oxman, Expert Systems Applications in
computer-aided design, in A. Smith (Ed.), Knowledge Engineering and Computer Modelling in
CAD (Butterworth and Co, 1986) 218-225 .
[40] F. Sadri and R. A. Kowalski, A theorem-proving approach to database integrity, in J. Minker (Ed.),
Foundations of deductive databases and logic programming (Morgan Kaufmann, Los Altos, Calif.,
1988) 313-362.
[41] M. J. Sergot, Lecture notes on logic databases, Department of Computing (1991), Imperial College
of Science, Technology and Medicine, 180 Queens Gate, London SW7 2BZ.
[42] G. D. Stafford, P-O. Glantz, A. Harrison and W. M. Murphy, A comparison of some aspects of
dental technology in commercial laboratories in England and Sweden, Swed Dent J 6 (1978) 81-86.
[43] A. D. Telford, A. Harrison, R. Hugget, J. A. Longstaffe and M. Whittlestone, Computer-aided
learning in prosthodontics, International Journal of Prosthodontics 2 (1989) 515-517.
[44] R. R. A. Wicks and M. E. Pennell, A computer-assisted design guide for removable partial denture
frameworks, Dental Practice 29 No 6 (1990) 14.

16