Logic-based integrity constraints and the design of ... - Semantic Scholar

Artificial Intelligence in Medicine 5(1993) 431-446

1

Logic-based integrity constraints and the design of dental prostheses P Hammond

a,b

a

, J C Davenport , F J Fitzpatrick

a

a

The School of Dentistry, The University of Birmingham, St Chad's Queensway, Birmingham B4 6NN, UK b

Advanced Computation Laboratory, Imperial Cancer Research Fund, Lincoln’s 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 Chad’s Queensway, Birmingham B4 6NN, UK, tel: +44 21 269 3171, fax: + 44 21 269 3186, email: [email protected]

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.

2

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:-

3

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.

4

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.

5

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 user’s 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

6

Artificial Intelligence in Medicine 5(1993) 431-446

7

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

• • • •

8

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 user’s 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

∗

9

∗

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 user’s tooth repositioning without negotiation and reflects this correction on the screen by projecting the user’s 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 designerÕs 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 CADCAMÕ91, 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 TandlŠk 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 QueenÕs 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