'M2 1 2 . 0 n • i e

i Reprinted from8 9 HY : f ,

COMPUTERS & GEOSCIENCES

Vol. 15, No. 3, pp. 255-267

HYDROLAB®: AN EXAMPLE OF A NEWGENERATION OF COMPACT EXPERT SYSTEMS

PATRICE POYET1 and MICHEL DETAY2

'ILOG S.A., 2 Avenue Galicni, B.P. 85, 94253 Gentilly Ccdcx and Université de Nice,Laboratoire de Geologie et Géocliimie, Parc Vahóse, 06034 Nice Cédex and 2GEOLAB,

Sophia Antipolis, B.P. 15, 06560 Valbonnc Cédex and Institut. Méditerranéen des Géosdtmces,Avenue Paul Arène, 83300 Draguignan, France

PERGAMON PRESS PLCOXFORD • NEW YORK • BEIJTNG FRANKFURT

SÃO PAULO • SYDNEY • TOKYO • TORONTO

1989 ~-^

Computers & Getwienn'i Vol. 15, No, 3, pp. 255-267, 1989Printed in Grcul Britain. All rights reserved

0098-3004/89 $3.00 + 0.00Copyright CCS 19X9 Pergamon Press pic

HYDROLAB AN EXAMPLE OF A NEW GENERATION OFCOMPACT EXPERT SYSTEMS

PATRICE POYET1 and MICHEL DETAY2

'ILOG S.A., 2 Avenue Galicni, B.P. 85. 94253 Gentilly Cedex and Université de Nice, Laboratoire deGeologie et Géochimie, Parc Valióse, 06034 Nice Cedex and 2GF.OLAB, Sophia Antipolis, B.P. 15,

06560 Valbonnc Cédex and Institut Méditerranéen des Géosciences, Avenue Paul Arène,83300 Draguignan, France

(Received 28 January 1988; revised 22 July 1988)

Abstract- The system described in this paper is an expert system implemented on a PC. The aim was todevelop efficient software, running on hardware available in the developing countries, with a high level ofexpertise in the field of village water-supply programs. The hardware constraints led us to develop aspecialized and sophisticated software architecture in order to reach a high-performance level that includedmany of the useful features generally available for the user on mainframes with larger tools or withexpert-system shells. The underlying mechanisms of IIYDROLAB do not rely on fully generic schemes,but rather on well-suited solutions to application-dependent problems.

Key Words: Artificial intelligence, Expert systems. Personal computers, Hydrogeology.

INTRODUCTION

During the last 20 yr, African countries have beenimproving the water supplies for their rural popu-lations. The search for water has become crucial, andin 1988 more than 80% of the rural population in thedeveloping countries are yet without drinkable water.In the past 20 yr hydrogcologists have carried outnumerous studies which have led to the definition ofwell-location techniques for village water-supply pro-grams.

The primary importance of a drinkable water sup-ply, the existence of a large amount of statistical datathat could be applied to the location criteria, therepetitive nature of the steps to be carried out for ahydrogeological search and the African technicians'training needs, all led us to develop an expert system.HYDROLAB embodies the major techniques used byexperts in the field and draws on a considerable wealthof practical knowledge gained from numerous drillingcampaigns that were carried out in Africa, particular-ly in North Cameroon. HYDROLAB is the result ofa close partnership between P. Poyct who developedand implemented the program architecture and M.Detay who brought hydrogeological expertise to theproject.

We believe that the system should run on micro-computers, in order to be available and useful widelyto geologists who are faced with the real problems ofdeveloping countries. For this reason, HYDROLABwas written in Turbo-PrologIM, a high-level languagethat includes some of the main characteristics ofprolog as defined by Colmerauer (1977, 1983) andClocksin and Mellish (1984), but that also allows anefficient complication on microcomputers. Some of

the original Prolog interpretative mechanisms havebeen suppressed in this dialect because they wereresource consuming. The global performance and thecompactness of the generaled code however are im-pressive. For more details on Prolog efficiency refer toWarren (1977) and Borland (1986).

The ability of Turbo-Prolog1M to permit a modu-lar approach to large-system design, enabled us towrite IIYDROLAB in fourteen modules, represent-ing a global package of about 5000 lines of Prologsource code. An executive is generated by the linker,and may be distributed as a standalone on a floppydisk, whereas the complete system, with the relateddatabases is distributed on two floppy disks.

As far as the user is concerned, the system acts atthe dialog level as a diagnostic-like expert system,asking questions, analyzing user answers, and build-ing plans in order to schedule the appropriate set ofactions and to explore constrained parts of a largesearch tree. Interaction with the system is achievedthrough a natural language module. We developed awide set of self-explanation functionalities in order touse this system in computer-aided learning, mainly forAfrican technicians, in the water-supply domain.

A control panel is associated with the inferenceengine, in order to display the internal activity of thesystem at a high symbolic level. The user is informedin this way of the current goal and subgoal pursued bythe system and of the branching factor of the searchtree. The panel also shows the current position andthe depth in this tree, the current rule fired from theconflict set and the number of solutions encounteredso far during the run.

The aim of the system is to build a model of theuser's problem and to try to match it initially, using a

255

256 P. PoYET and M. DETAY

fuzzy logic, with a set of typical known well patternsthat have emerged from well-drilling campaigns inAfrica and are stored by HYDROLAB in a database-like structure. When this reasoning step fails, thesystem builds a new plan and schedules it in order,first, to get more data related to information that islacking, which could help to reach a solution. It thentries to rematch the currently described situation withreal solutions and finally with generic ones.

For all situations, the system is able to make adiagnosis about the user's situation, to give advice inorder to increase the user's average success, and toevaluate the hydrodynamic characteristics of the fu-ture well, according to the experience based on thestatistical processing of 1080 boreholes in Africa(Detay, 1987; Bcrnardi and Detay, 1988).

THE GENERAL ARCHITECTURE OF HYDROLABAINU THE DOUBLE PASS MODEL OF CONTROL

The control structure of HYDROLAB is derivedfrom previous research on expert-system shells thatarc suited for the development of large tools written inLe-Lisp* (Haren and others, 1985a, 1985b; Poyet andcoworkers, 1986-1988; SMECI, 1988).

The main parts of HYDROLAB are a planner thatcollects tasks and a scheduler that activates them.Each task stores partial results in the Prolog mainmemory database independently of the work ac-complished by other modules, in a blackboard-likemanner (Hayes-Roth, 1984; Nii, 1986a, 1986b). Thescheduler starts its work on an initial plan which isbuilt according to a set of responses given by the userto some discriminant questions that arc asked in theinitialization phase.

Replies given to questions relative to the geo-graphical well location (X, Y, Z), lead HYDROLABto make some assumptions on the geological contextaccording to structural data stored in a country-specific database, and to initialize a plan well suited tothe relevant context.

This set of initial actions corresponding to thesupposed geological context then is scheduled, andeach task in the list is activated by a recursivescheduler. During the scheduling, the user may back-

track on each of these tasks, as they are stored in astack, in order to modify some of the previously givenparameters. Tasks are viewed by the scheduler as a listof actions to be accomplished, or as a set of predicatesto be scheduled in a particular order. This list of tasksis constructed dynamically and may be modified in areflexive way by the system as reasoning goes on.

The simplest possible code for such a schedulercould be (Fig. 1):

scheduler([]):-!.scheduler([Task | Other^tasks]) :-

task (Task),scheduler(Other_tasks), ! .

Figure 1. Simplest sort of scheduler.

Another simplified version of such a taskscheduler, enabling each task to modify the list oftasks can be written as (Fig. 2):

The questions asked by the system represent thevisible part of the activated tasks. They tend to befocused on a subpart of the overall problem as theycorrespond to subgoals previously identified andpushed into the list of tasks by the planner.

Each task scheduled is processed by a generic andcompact code: the task predicate which is built up ofthree clauses described in the following way (Fig. 3):

When the initial plan is accomplished, the systemactivates the inference module and tries matching theuser data kept in the blackboard with the knownsolutions stored in a Prolog disk database (these aretermed analogical references), and loaded in mainmemory by a "consult" system call. This is done usingfuzzy logic (Arrivet, 1987). If this step fails for all theavailable boreholes databases, the system switchesback to the control module and tries to evaluate moreaccurately the user situation in terms of water supplyand water-bin, in order to identify lacking or com-plementary data that could help to reach a knownanalogical solution or even, later on, a generic one.

The associated tasks are identified and again push-ed by the planner into the list of tasks, and the controlis passed for the second time to the scheduler. Apossible way to write such a task collector is in asimplified way (Fig. 4):

scheduler : -t a s k s _ o n _ b l a c k b o a r d ( [ ] ) , ! . ; nothing to schedule, then slash.

scheduler : -tasks_on_blackboard([First_current_task,_]),

; a global factt a sk ( F i r s t _ c u r r e n t _ t a s k ) , ; but each task can modify the task listpop_the__f irst_task, ; pop if doneadjust_task__structure_if_necessary,

; what should be done next ?scheduler. ; each task leaves pending choices and the

, ; recursive call pushes them into the PROLOG; stack.

Comments appear as in LISP: ; This is a comment.

Figure 2. Simplified code for dynamic scheduler.

Compact expert system 257

t a s k(Ta s k_f i 1 1 e r ) : - ; descending clause of the search tree,get J>anel(Task_filter,Goal,Context, Rule,Probability) ,

; obtains some variables according to the task filter,get_message(Task_filter,Message),

; obtains the message associated with tfi£ task filter,update_control_panel(Goal,Context,Rule,Probability) ,

¡updates the control panel of the interface module,optional_message_pririting (Task_f liter) ,

; special messages if needed,change_activity(activate,toggle) ,

; the backtrack is now activatednl_processing(Message,Response, Task_filter)

; obtains and analyses user reply. If a backtrack is; required, asserts the destination then cuts and fails.

change_activity(inactivate,toggle) ,; no backtrack available from this point,

task_entry(Task_filter. Response) .; effective entry for the task.

task (Task_f ilter) : - ; first possible clause for backtrack,backtrack (Symbol) , ; a backtrack control fact was asserted in the

; blackboard and a destination has to be reached,symbol <> Task_f i l ter , ; the destination not yet Iws been reached,clear (Task_f ilter) , ; undo previous actions,! , ; no pending choices should be left,fail. ¡fails, in order to pop the tasks stack.

: , t a sk (Task_f i l t e r ) : - ; second possible clause for backtrack which can be; used either when: symbol - TaskJilter (destination; reached) or in a step-by-step backtrack.

not(generate_backtrack(Task_filter)),; the current task did not generate the backtrack,

! , ; no pending choices should be left,clear (Task_f ilter) , ; undo previous actions,ret ract_backt rack, ; retract the control fact used to explore the tasks

; stack,task (Task__f ilter) . ; recursive entry.

Figure 3. Simplified code for three clauses of generic task predicate. .

At the end of this cycle, the blackboard is supposed using a forward-chaining strategy or to prove someto be complete and the control is transferred defi- goals according to a backward inference model,nitively to the inference module, which always is able Generally both strategics are used simultaneouslyto conclude, even if the only solution located is a (Clayton, 1985; Poyet and Dc I ..a Cruz, 1987; Poyet,generic one. This will be explained later. Haren, and De La Cruz, 1987). In powerful control

We termed this type of model the double pass model structures, when the reasoning is stopped in someof control. Usually, knowledge-based systems use a context, the system is able to react and selects a taskcorpus of knowledge to try to deduce some new facts (viewed as a set of rules) from among a set of actions

task_col lec tor( [Datum_tes ted I Q], [Datum_tested | Tai l ] ) ; -is_datum_to_be_pushed_in_task_list(Datum_tested),

• • • . ! , " . '

task_COllector (Q,Tail) . • .. • :task_collector(Task_list,[_ I Tail]) :- •

task_collector(Task_list,Tail).task_collector([],[]). '

; The task ̂ collector predicate is called with an adapted filter in order to; recognize the plausible list of tasks to be tested for scheduling by;

evaluate_possible_lacking_data(L_water_supply_tasks,Some_filter) :-get_candidates_according_to_filter(Some_filter,Candidates),task_collector( L_water_supply_tasks,Candidates).

; The appropriate list oftask is then activated. According to the first simplified; scheduler this could be written as:

schedule(L_water_supply_tasks).

Figure 4. Simplified code for task collector.

258 P. PoYET and M. DKTAY

HYDROLAB

System's startup

Determino: tha context

auociatad with the location

Figure 5. Simplified HYDROLAB system flowchart.

considered to be useful in such a situation (Poyet,1987). If no task selection can be done and no otherrule can be fired in the current context, the reasoningprocess stops and aborts.

According to the model of control presented here,once the first pass has been accomplished in responseto the first dynamic planning phase and if theproblem-solving process fails, the system is able toreason about what it should know or acquire from thepresent set of data stored in the blackboard in orderto reach a solution. The system knows how to react,according to the current and incomplete descriptionof the problem, so as to identify new goals and togenerate a new plan dynamically. HYDROLAB in-cludes a reflexive and explicit description of its sol-ution space which is used by a specialized knowledgesource. This knowledge source is dedicated to identi-fying crucial but lacking data in the current black-board to construct new plans that are suited to recog-nizing existing solutions or generating original ones.

Briefly, we can say that the first pass tries to collectsome appropriate data according to a supposedgeological context and to recognize an analogicalsolution. When this step fails, the system uses a re-flexive description of its solution space in order toidentify the culprit-lacking data which could be usefulduring the matching process or necessary for buildingup generic solutions that rely on criteria of a highsymbolic level. Then the second pass is scheduled forcatching the culprits and for reaching a solution. Inthe worst situations, this double-pass model of con-trol leads to generic solutions.

Figure 5 illustrates of the double-pass model ofcontrol. Once the context has been determined by thesystem, rejecting problems located outside NorthCameroon, a plan is generated by the dynamic plan-ner and then scheduled. Each task becomes the cur-rent system task, and in the situation of the normalcontrol cycle, generates facts and data which are as-serted in the Prolog main memory database (heretermed the pscudoblackboard) according to the re-sults of the natural language analysis. When a back-track is requested during the control cycle and detec-ted thanks to the natural language module, itsprocessing is done according to Figure 3 and is re-presented by the dotted lines in Figure 5. The visual-ization module controls the display of the system'sinternal activity. When the last task is reached, thematching is done between the blackboard data andthe analogical references. If this step fails, a new planis generated thanks to the system's reactivity andtransmitted again to the scheduler. This second con-trol phase leads to the two concurrent models ofsolutions described in the relevant section.

The graphic representation of the general architec-ture of the system illustrates the major componentsinvolved and the logical links that exist between them(Fig. 5). We previously described the top modules ofthe diagram which are responsible for the apparentbehavior of the software, including the planner, thescheduler and the associated control strategy; we willfocus now on the deductive capabilities of HY-DROLAB which rely on knowledge representation,inference policies, pattern matching and the two con-

Compact expert system 259

curent models of solutions. We finally will look insome detail at the user interface.

KNOWLEDGE REPRESENTATION

An interesting feature of HYDROLAB is its abil-ity to reason on a set of static databases which can beupdated through a simple text editor. No modifi-cation needs lo be done within the expert system codein order to take into account the new informationstored in the databases. The databases that relate tothe characteristics of the wells, store the modelizationof objects and of relations existing between them,through the declaration of Prolog structures that arcrecorded as facts and loaded by a "consult" systemcall. The structure of Prolog objects is declared in theexecutive, and cannot be changed at the user level;only the amount of data manipulated by the systemmay be updated. The inference mechanisms are ableto handle in a generic way an arbitrary number of wellor drilling descriptions. The aim is to match as a firstapproach and using a fu/./.y logic, the user data withat least one of the known well patterns stored in thedatabases. If this step fails, as was noticed during thecontrol description, the system activates a new plan,and is able to draw inferences for generic solutions.

A large part of the knowledge embedded in thesystem relies on a static description of the geologicaland hydrodynamic characteristics of a large numberof wells and boreholes that we carried out in Africa.This knowledge describes, for each database record,the observed characteristics of the drillhole, and thesuccess encountered. One of the main objectives of theHYDROLAB architecture conception process was tomix, in an efficient manner, an object oriented re-presentation of the declarative knowledge stored invarious Prolog databases, with a powerful controlstructure based on task scheduling. The reader canrefer to Albert (1985), for an introduction to theProlog implementation of objects.

INFERENTIAL KNOWLEDGE

The inferential knowledge of HYDROLAB relieson the usual Prolog features. We did not develop aspecific-rule language which could be expanded andinterpreted at run-time as in (SMKCI, 1988) or com-piled as for a RETE match (Forgy, 1982) or for aninference net (Konolidgc, 1979). If the user needs tomodify the content of the inferential strategies, therule modules have to be recompiled by the Turbo-Prolog™ compiler. Taking hardware constrains intoaccount, the flexibility induced by a rule languagewould not have justified the code overhead inherent inthe rule compiler. The loss of flexibility is obvious butfrom a semantic point of view, the Prolog rules ofHYDROLAB can express, using specialized predi-cates, the same type of expressions as other sophis-ticated first-order rule languages; it should be remem-

rule__predicate_name (some_f ilter) : -condition^(attribute^,...,fuzzy-range^),condition (attribute j , . . , , fuzzy-range j ) ,

conditionn (attribute^, ...,fuzzy-range^),associated_action.

Figure 6. Pseudocode for generic rule predicate.

bered that HYDROLAB is able to run on machines of512 kbyte of main memory. A HYDROLAB rulewhere rule_prcdicate_name is the name of a clausethat represents a rule is similar to a set of Prolog rulesand uses specialized predicates to verify the precon-ditions of the premises (Hg. 6). The predicates con-dition, (attribute;, ..., fuzzy-range,), ..., condition,,(attribute^,..., fuzzy-ranget ) are the names of special-ized predicates which verify the precondition ; for theattribute, according lo the fuzzy range "fuzzy-range,"which is the deviation for the attribute, to be usedduring the matching process; associated action is theconclusion, the effects of which are to produce eithercontrol or deductive reasoning actions. From an in-ferential viewpoint, the main associated action of arule is to update the dynamic Prolog database used byHYDROLAB as a blackboard. The valid actions areto assert or retract dynamically Prolog structures orto modify existing ones.

FUZZY LOGIC FOR AN EFFICIENT MATCHING

When the first phase of the task scheduling processends, facts relevant to the user situation are all asser-ted and stored in the blackboard. As was noticed inthe control section, the system may ask for com-plementary data later on, if the primary inference stepfails. The next phase therefore is to pass the controlfor the first time lo the inference module. For eachsolution known in the many available databases, thesystem tries to match the user data for each parameterwith the currently considered solution. The matchingis done for each parameter with specialized predicatesthat give a measure, according to a slot-dependentmetric, of the distance between the user-given valueand the recorded value for the supposed solution.When this processing is done for each attribute, thesystem is able to deduce a matching level which is ameasure of the similarity between the plausible sol-ution and the user data; the system also is able tocompute a consistency measure which is significant ofthe number of channels used during the matchingprocess to compute the previous similarity.

Expression (1) can be used to match the user datawith a model and computes a global percentage ofsimilarity:

distancc(user data, model) — min

• oo., j 100|slot'- - ú a t A ••"(„,= i «.slot,, /

where slot,, is the fth slot of the object 1 (a compoundobject which contains the user ..data), slot2, is the <th

260 P. PoYHT and M. DETAY

— Analogical Solution»

Solutions

Bitumant Context Sedimentary Context | | Mixed Context)

Djiml| | Kaba | |_F|guHj | Polar» | | Mora | | Medakar | |Sed»k| |Tingu9lln| | Pola | | Gode |

Favorabla| [Fair Context] [cautious

-Control Panel-

Number _ of „states66

Pepth in search trea41

State, number6G

Current, goalResistivity

Branching _tree „factor4

Current .contextGeophysics

Nu m ber_of_ solutions0

Rule Prob834 1

HYPROLAB® Release V1.«-Copyright Patrice POYET, 1987-1988

Figure 7. Example of analogical solutions tree, displayed during matching phase.

slot of the object 2 (the compound object taken as amodel), and n is the number of slots used during thematching. In fact a similar calculation is processedslot by slot according to the appropriate metrics,before a sum can be done.

Predicates used to compute related distances, attri-butc-by-aUributc, arc context-dependent and have tobe called with fuzzy ranges to take into account thediversity of the encountered metrics for the differentattributes. A variant of this method was implementedfirst in a Naval expert simulator (Poyet and De LaCruz, 19X7; Poyel, Haren, and De La Cruz, 1987),and is described fully in Arrivet (1987). We implemen-ted an efficient subset of the complete method forHYDROLAB.

When the system is able to recognize at least asolution during this phase, the inference process isstopped, because an analogical solution correspond-ing to a real reference has been determined, and thecontrol is transferred to the solutions' printing mod-ule. If not, the planner arranges a new plan which isactivated by the scheduler as described in the controlsection. At the end of this second control cycle, thesystem rematches the blackboard's data with the re-ferences as a second attempt to identify some analogi-cal solution; the system then elaborates a genericsolution.

During the matching process, solution trees arcdisplayed by the system (Fig. 7); the highlightedreverse-video items representing the current situationand the control panel window enabling the user tofollow the reasoning. The trees are built up using thestandard semigraphic IBM characters and do notrequire any enhanced graphic capabilities from thehardware. Scrolling functions are provided to visual-ize the large trees encountered in operational appli-cations.

DIFFERENT MODES OF REASONING LEAD TOMANY TYPES OF SOLUTION

As was explained briefly, when the system is able torecognize a solution during the first inference cycle,we say that a real or analogical solution has beendetermined as the user data has been matched success-fully with a known pattern stored in an object data-base. In this situation, we suppose that no other in-ference processing is necessary and the system stopsreasoning. If not, we make an accurate analysis of theuser's problem in order to schedule a new plan, whichhas to be suited perfectly to the peculiarities of theuser situation. When all the complementary taskshave been scheduled, the blackboard is supposed tobe as complete as possible, and the second phase ofthe inference process may start. The system looks firstfor analogical solutions then for generic ones. In allsituations the system is able to elaborate a genericsolution. A generic solution is a model conceived byHYDROLAB which does not rely on informationobtained from a database. The model is based onabstract concepts such as the water-resource suppliesand the characteristics of the water-bin, concepts of ahigh semantic level which have been elaborated fromthe primary user data. According to these concepts,the system always is able to draw an opinion from thecurrent user situation, and to give related advice.Different types of aids in decision making areprovided by the system, concerning the recommendedlocation for the future drillhole, the estimated riskwhen drilling evaluated as a percentage of the chancesof obtaining a positive drilling, as well as the forese-eable yield and specific yield which are predictablestatistically in the given environment according to thedeveloped models (Detay, 1987; Bcrnardi and Detay,1988).

Compact expert system 261

A REASONED PRINTING OF THE RESULTS

When a solution has been recognized, and theinference process stops, the system takes charge of theprinting of the results. The analogical solutions recog-nized are supposed to match the user data, with a highdegree of confidence, but according to the fuzzy logicused, a few attributes may be remote from the data-base model. For the latter, and according to an adapt-able confidence threshold, no printing is carried outthat could confuse the user. The best way to do this,is to use the same specialized predicates as thosedescribed in the fuzzy matching section, in order toverify the plausibility of each attribute on which thediagnosis is based before printing. This reasoningactivity, considered by the system as normal tasks, isdisplayed by the control panel module, through theinterface module side effect. This strategy leads to anintelligent printing, which visualizes only the reliableattributes, according to the same fuzzy logic used fortheir initial evaluation.

INTERFACE OVERVIEWTHE NATURAL LANGUAGE PROCESSING

MODULE

A specialized module manages the user interac-tions, and traps all the answers given by the user to thequestions asked by the tasks. Each task activated bythe scheduler, communicates with the user throughthe available entry points in this module; this guaran-tees the homogeneity of the interaction between thesystem and user.

This module is nested within the natural languagemodule which is in charge of the lexical and syntaxicalanalysis of the input sentences. When a concept or adesired action is recognized in the input stream, theassociated functions are activated as in a compilercode generation phase. Any of the following actionsmay be valid at any time: backtracking to the previoustask, backtracking to a user-determined destination inthe tasks stack, an action that is termed goal-directedbacktracking (Poyet, 1987); explaining the reason be-hind the current goal or why something is being donecurrently, obtaining symbolic or numerical data withmagnitude order checking; asserting or retractingfacts in the blackboard; or switching to an on-lineeditor that displays all the documentation stored in adisk database to help the user.

All the user requests arc expressed in a naturallanguage form, and are interpreted by the system asone of the interactions described previously. For ex-ample, we can give the following sentences, and theirassociated meanings to the system:

The user sentence: < There are cretaceous limestonesnear the village}

is interpreted by the system as: a new fact has to beasserted by the system into the blackboard. The newfact is a Prolog structure dynamically constructed bythe system and recorded in the main memory Prologdatabase.

The user sentence: (I'd like to come back on therainfall measures}

is interpreted by the system as: a goal directed actionhas to be accomplished by the control structure, inorder to pop control blocks from the stack and tobacktrack to a task previously achieved.

The user answer (why}: to the system request:enter lhe depth of the traditional wells (where a nu-merical value is expected), is interpreted by the systemas: a user request has been made to the "teachingmodule" (why may be entered at any moment duringthe dialog). The current goal and a variable related tothe user model are carried on by the tasks and areused by the teaching module to determine the appro-priate explanation messages.

Finally, the user sentence: </ need somebody'shelp} (or any sentence having the same meaning) isinterpreted by the system as: the user needs to accessthe on line documentation!

The system is able to help the user in two ways.Each time a task queries the interface module services,a short explanation of the type of answer expected bythe system is displayed to the user in an on-line helpwindow. However the user also may call explicitly theon-line editor by a help query at any time, and in thisway access the complete detailed documentationstored by the system in a database. The database isloaded in the heap area of the main memory, whichmay be reallocated for other purposes. This is aneconomical memory management strategy. The basicvocabulary used by HYDROLAB for the naturallanguage processing is stored in an ASCII database,and may be modified or updated if necessary. Thedescription and representation of the grammar usedby HYDROI.AB is internal to the system and cannotbe modified or accessed at the user level.

THE CONTROL PANEL MODULE

When a task makes a request to the interface mod-ule, a main side effect is to update a control panel thatdisplays the current state of the expert system (as wasdone by the update.control panel call of Fig. 3). Thepanel shows the depth and the branching factor of thesearch tree, the current goal, and subgoal pursued bythe system, the current rule fired from the conflict setand the number of solutions so far encountered.When the control is passed to the inference module,the user may ask for a step-by-step reasoning anddiscover each rule or action applied, and the level ofsuccess encountered by the system when attempting toschedule it.

Each task activated by the scheduler, and each rulefired by the task, updates a global Prolog structure oftype panel stored in the blackboard. The current stateof this structure is displayed in the panel window; it isachieved by means of a specialized part of the inter-face module. When the reasoning process is running,the user can visualize the activity of the system as the

262 P. PoYET and M. DHTAY

inference module queries the services of this subpartof the Interface Module.

AN OUTLOOK ON THE HYDROLAB SCREEN

The IIYDROLAB screen is composed of threeareas. The first, an interactive window is devoted tolhe dialog with the user; the second is used to switchfrom a help window to a reasoning window where thesystem displays lhe heading of the current rule fired,and the third area is the control panel described in theprevious section. The on-line documentation isaccessed by a full-screen editor which can be poppedat any time over an active screen. The results aredisplayed through other windows with specializedtemplates. Figure 8 is an English reconstruction of thestartup screen, showing the answer given by the sys-tem to a teaching request.

A working session with HYDROLAB appeals tothe user (apart from the system's ultimate objectives),because of its ability to explain its own reasoning,understand a natural language dialog, explain its ap-proach, and to visualize its internal state at any giventime.

HYDROIAB-WHAT FOR?

HYDROI.AIÎ is a practical tool for the followingreasons:

— a specialist who needs support on fieldworkwhen facing an unusual problem that requiresa large amount of comparative data, and adap-ted inference mechanisms to match the obser-ved data with the references stored in manydatabases. In this situation the system acts as ina fuzzy automatic-classification system, exceptthai. IIYDROLAB is able to elaborate a gen-eric solution from concepts of a high symboliclevel and to work on a set of fully integrateddatabase of Prolog objects with the expert sys-tem.

— a specialist who wishes to forecast some of thehydrodynamic properties of the future drillholeaccording to a large sel of heuristic and nu-merical data. The numerical data manipulatedby HYDROLAB may be the result of a statisti-cal processing of the primary data. HYD-ROLAB includes some of the statistical resultsobtained by Detay (1987), many of them beingrelated closely to heuristic criteria (as, for ex-ample, the foreseeable delivery of a drillholeequipped with a pump).

— a student who is learning the strategies of vil-lage water-supply programs. The system is ableto explain the steps followed during the reason-ing, and can be used to teach the hydrogeologi-cal step.

— any decision-maker who needs advice in orderto increase his success rate.

The system is being used currently by GEOLAB inorder to increase the percentage of productive drill-holes in North Cameroon (Detay and others, 1986a,1986b). Complete databases have been developed inthis context and will be extended to other countries inorder to handle a larger set of applications. NorthCameroon is itself a large area (155,000 km2), andincludes many different structural and geological con-texts.

EXAMPLE OF HYDROLAB USER SESSION

Here is included a simplified example of a sessionin order to give the reader an idea on lhe implementa-tion of the system's hydrogeological approach. A usersession normally lasts for 20 min and the number ofquestions asked ranges from 75 to 200 according tothe complexity of the problem to be solved.

To make this session understandable, and refer-ring to the notations adopted for the windowing sys-tem (HI, H2, H3) for Figure 8, we use the following

Interactiva window of th« Expert System

My name is HYDROLAB

My domain, is the water supply in North Cameroon.

What it the X coordinate of the village ?< why >

-Help window or current reesoning-

The location of the well is important in order to determine the relevant

tasks. These tasks will be identified by the planner and pushed into the task

: liit. Then the scheduler will activate these tasks.

H1

H2

-Control Panel-

Number^of — States State,, number5 5

Depth in search tres Current_gaal5 tasks, list

Branch ing _tree-_ f actor0

Current —contextPlanner

Number^ of— Solutions0

Rule Prob

624 sys

H3

Figure 8. English reconstruction of HYDROLAB screen at startup time. Different parts of windowingsystem devoid lo specific logical functions arc referred to as HI, H2, H3. This notation will be reused in

section describing "Example of IIYDROLAB user session".

Compact expert system 263

symbols:

H.: means HYDROLAB and corresponds toHI—the questions asked by the system (HI subwin-

dow),H2d—the deductions made by the system (H2 sub-

window),H2H—the Computer Assisted Learning answers

given by the system (H2 subwindow),H2h—the help in entering the answers (H2 subwin-

dow),H3—the state of the inference engine thanks to the

control panel (H3 subwindow),HH—the on-line help function, where HH refers to

the full page display (full screen editor).U.: means User and corresponds to the user's answersmade using the HI subwindow. They can be of severaltypes:

(D)—numerical data,(Y/N)—answer yes or no,(NL)— answers in natural language,(W)—questions asked to the system as: Why and

CAL function,(H)— help requested,(B)—backtrack: for example if the user has made a

mistake and would like to go back to thequestion where the error is located.

In all situations, the possible answer is put intobrackets, followed by the selected answer in the givenexample of the session.C : indicates comments designed to either explain thesystem's approach or the ins and outs of the questionsasked, and so on. The following font will be used.

As the H3 subwindow contains nine subasscmblies(Fig. 8), we decided not to detail its contents, in ordernot to make this example considerably heavy. Wehave not presented the Help function either whichincludes several do/ens of screens. The backtrackfunction has not been presented either; it is possible togo back at any time on any type of question askedpreviously.

C. At the beginning of the session, the system tries firstto define the general environmental conditions: geo-graphical, geological, hydrological, climatic, mor-phological, and so on.

H.IU : What is the longitude of the village (X coor-dinate)?H2h:I expect a numeric value in degrees and mi-nutes

U. (D/W/H):12°23'H.HI :What is the latitude of the village (Y coor-

dinate)?H2h:l expect a numeric value in degrees andminutes

U.(D/W/H):10°40'H.HI :What is the altitude of the village (Z coor-

dinate)?H2h : I expect a numeric value in meters

U.(D/W/H):450.H.HI :Did you perform photo-interpretation?

H2h: Enter your answers in natural languageU.(Y/N/W/H):YcsII.HI :Can you see faults on the aerial views?U. (Y/N/W/H):YesH.HI:Main fault trend?

H2h:The answer must be entered in relation to theNorth on the basis of 360°U. (D/W/H):47H.HI:Other fault trend?U (Y/N):Yes .

H.HI:Main fault trend?H2h :The answer must be entered in relation to theNorth on the basis of 360°

U. (D?W/H):123H.HI:Other fault trend?U. (Y/N):No .H.HI : Describe the fault state and quantify the fault

network.H2h: Enter your answers in natural language

U. (NL/W/H/B): there are several faults over kil-ometers in the village area

H.H2d: Fault state valid and storedH2d : Fault density valid and stored

H.I II : Considering the important fracturing, do youknow if there are any nodal points near the village?

U. (Y/N/W/!l/BJ:NoH.H1 :Do you have precise indications on the lithol-

°gy?U. (Y/N/W/H/B):YcsH.H] [Describe the lithological blocks observed, one

after the other, with their characteristics.H2h: Enter your answers in natural language

U. (NL/W/H/B): after analysis of the aerial views, thevillage is situated in a crystalline block. It has to benoted on the geological map the presence of gra-nitic rocks with alkali feldspar dating back fromthe Cambrian era

H.H2d: name of rock validH2d:age of rock validH2d: valid texture characteristicsH2d:as far as I can see, you arc in the "basementcontext"

H.H] :Do you know the pluviometry of the area con-cerned?

U. (Y/N/W/H/B):Why?H.H2h : The pluviométrie data correlated with the size

of the watershed, the field and geomorphologicaldata, give an idea of the portion of infiltrated waterand thus of the aquiferous possibilities in the re-gion.

H.H I : Do you know the pluviometry of the area con-cerned?

U. (Y/N/W/H/B):YesH.HI : What is the average pluviometry in the area?

H2h:l expect a numeric value in mmU. (D/W/H):900H.HI : What is the geomorphological context?

H2h: Enter your answers in natural languageU.(NI.,/W/H/B): the village is at the bottom of a mass-

ifH.H2d:You are in a mountainous region

264 P. POYET and M. DETAY

H.Hl:What is the size of the watershed upstreamfrom the village?H2h:T expect a numeric value in km2

U. (D/W/H):12H.HI : Is there a brook in the area concerned'?U. (Y/N/W/H/B):YcsH.H 1 : For how many months per year does it flow?

H2h:I expect a numeric value in monthsU. (D/W/H):8H.H 1 : How far is it from the village?

H2h: I expect a numeric value in kmU. (D/W/H): 0.4H.HI : According to you what is its hydrogeological

importance?H2h: Enter your answers in natural language

U.(NL/W/H/B):the brook is near the village, it iscertainly of major importance

H.H2d : Consequently, I consider the brook as playingan important part

H.H 1 : Considering the importance of the brook, doyou have its detailed characteristics?

C. If you answered yes, the system would have tried toknow the degree of inclinât ion of the stream, the sizeof its channel, the aspect of the bed, and so on. Allthis information will enable an estimation of thepossible supply of the underground water flow fromthe underflow sheet of the brook.

H.HI :Can you give the difference of altitude betweenthe stream bed and the village?

C. The system understood that the village is in thebasement zone. It also knows that the decompressedand fractured ume of the basement is generally 30 mdeep. It tries to know the difference of altitudebetween the village and the brook. This parameterwill enable it to estimate the possible supply of thedecompressed zone of the basement under the vill-age.

U. (Y/N/W/H/B):YesH.H 1 : What is the difference in level?

H2h : I expect a numeric value in mU. (D/W/H):5H.H 1: During the dry season, do the villagers dig

catch basins in the brook?

C The system tries to estimate the possible supply ofthe basement decompressed zone in the dry season.

U. (Y/N/W/H/B):YcsH.HI :How deep arc these catch basins?

H2h : I expect a numeric value in mU. (D/W/H): 1.2H.H 1 : Arc they supplied during the entire dry season?U. (Y/N/W/H/B):Yes

C. The catch basins supplied in the dry season show the

presence of a perennial underflow sheet. The lattersupplies the decompressed zone of the underlyingbasement. Thus, the system has identified a deter-mining hydrogeological element.

H.HI .Did you carry out a field study?

C. The system asks this question but cannot make anyrelevant recommendation if this field study has notbeen carried out. HYDRO LA B is designed as afieldsystem.

U. (Y/N/W/H/B):YesH.HI :Do field studies give more information on the

lithology?U. (Y/N/W/H/B):YesH.HI : Describe the lithological blocks you identified

H2h:Enter your answers in natural languageU.(NL/W/H/B): there are gneiss outcrops intersected

by quartz sillsH.H2d : Name of rock valid

H2d:I acknowledge the presence of metamorphicrocks in the given series

H.H 1 : Can you give the current water supply (wells,springs, catch basins, drillings)?

U. (Y/N/W/H/B):YesH.H 1 : Are there traditional wells?U. (Y/N/W/H/B):YcsH.HI : Describe the characteristics of the wells one

after the otherHI tradit ional well 1, depth?H2h: I expect a numeric value in m

U. (D/W/H): 17H.HI :Is it supplied all year or sometimes dry?

H2h: Enter your answers in natural languageU. (NL/W/H/B):this well does not run dry in the dry

seasonH.H 1 : What is the static level of this well?

H2h: I expect a numeric value in mU. (D/W/H): 16.65H.HI : Are there other traditional wells?U. (Y/N/W/H/B):NoH.HI : Are there modern wells?U. (Y/N/W/H/B):NoH.H 1 : Arc there drillings previous to the current cam-

paign?

U. (Y/N/W/H/B):NoH.HI :Did you carry out a geophysical surveying?U. (Y/N/W/H/B):YesH.HliWhat is the depth of the infinite resistance

level?H2h : I expect a numeric value in m

C. Considering we are talking about the basement, thesystem tries to estimate the thickness of the sa-prolite reservoir.

U. (D/W/H): 19H.H2d: Therefore, I consider this value as the

geophysical thickness of the basement hangingwall.

Compact expert system 265

H.HI : Are there local anomalies in the thickness ofthe hanging wall?

C. The geophysical surveying makes it possible to drawa map of the basement hanging wall. One then canlocate areas with higher alteration which can becorrelated with fractured zones.

U. (Y/N/W/H/B):YcsH.HI :Can these anomalies be correlated with faults

observed on the aerial views?U. (Y/N/W/H/B):YcsH.HI : Are these anomalies near the brook?U. (Y/N/W/H/B):YcsH.HI :What is the resistance of the hanging wall in

the area concerned?H2h:l expect a numeric value in ohm/m

C. The value of the hanging wall resistance coupledwith the thickness enables the calculation of theoverall longitudinal conductance which is a way ofestimating the aquiferous potentialities of the area.

U. (D/W/H):25 .H.H 1 : Do you want to carry out a step-by-step reas-

oning?

C. The step-by-step reasoning allows the user to visual-ize the inferences carried out by the system (subwin-dow system 1/3) and to understand the expert'sreasoning.

V. (Y/N/H):No

C. The system then goes through the inference cycle. Itanalyses the data set described by the user.Therefore it uses its analogical database. There maybe several situations:— either it locates a similar context in its analogi-cal database, it then will make recommendations forthe implementation of the drilling and determine theanalogical type situations— or it does not locate any similar situations to thedescribed context in its analogical database. Thesystem then will evaluate the missing data, plan itsapproach again, and ask the user a set of questionswhich may lead to the solution.

We have not presented the replanning phase as inall situations it is too long and extensive. After replan-ning, the system tries to locate an analogical solutionthen jumps to the generic solutions and finally makesall its recommendations in relation to implemen-tation. It will use a certain number of mathematicalfunctions to evaluate the nature of the risk, the per-centage of chances to have a positive drilling, theaverage yield and the average specific yield predict-able in the said context (Detay, 1987).

For the described session, a simplified report of thesystem's recommendations is:H.Hd 3lO:The village is in a basement environment.

Hd 425 ; The size of the watershed considering thepluviometry seems sufficient.

Hd 565: The presence of a brook near the villagemust be considered.Hd365:The alteration thickness is satisfactory.Hd 450 : The nature and the importance of the frac-tures are favourable.Hd 820 : The water supply is indeed moderate.Hd 850: The conductance values lead to predict awater logged bed in the hanging wall of the frac-tured zone.Hd 235: The presence of a fractured zone must beconsidered.Hd 655: Locate the drilling on the fractured zone,in declivous zone if possible and near the brook.Hd 495 : The drilling must also consider the decom-pressed zone of the crystalline basement.Hd 960 : Your percentage of success in relation to astatistical study on 1080 drillings in North Came-roon is estimated at 86%.Hd 965 : The average specific yield which is statistic-ally predictable in relation to a statistical study on1080 drillings in North Cameroon is estimated at0.16mVh/m.Hd 970: The average statistical yield deduced inrelation to a statistical study on 1080 drillings inNorth Cameroon and the conductance, is esti-mated at 2.9 m'/h.

C. The type examples of analogical solutions then aredisplayed. In the selected example:

H. Type case Manawatchi—Département: MayoSava—Arrondissement: Mora.H. Type case Doleré—Departement: Bénoué—Arr-ondissement: Pitoa.

C. The number of type examples is related to the im-portance of the analogical database, which can beundated with a simple text editor as the drillingworks progress. Similarly for a generic solution, amessage indicates that the solution is derived fromun analysis by IIYDROLAB of the described con-text only referring to rules without standard drill-ings.

CONCLUSIONS

HYDROLAB is a practical system running onmicrocomputers that includes many features usuallyavailable only with expert-system shells on main-frames. Its architecture is modular and flexible andallows the substitution of packages of static know-ledge, as the system is able to operate on various databelonging to different geographical areas or even todifferent countries. Because it has to run on a personalcomputer, the system is compact and docs not includegeneric tools such as an object-oriented editor or aspecific-rule language. We focused our efforts de-veloping a powerful and reflexive control structure,on completely integrating domain-related databasesinto the expert-system inference mechanisms, and onbuilding a natural language interface (includingpowerful explanation capabilities and backtracking

266 P. PoYET and M. DKTAY

strategies), and an efficient fuzzy matching mechan-ism.

The fuzzy reasoning achieved by HYDROLAB isimproved by the dynamic task scheduling and by thedouble-pass model of control which is able to focusthe system's attention on pertinent data. In the worstsituations, where the matching fails for the manydatabases available, the system is able to elaborate anoriginal solution based on abstract hydrogeologicalconcepts; this is termed a generic solution, as it doesnot correspond to any observed real situation. Fi-nally, the system includes the synthesis of a largeamount of statistical processing for the North Came-roon area, and is able to forecast, according to nu-merical models and hcuristical parameters, some ofthe drillhole characteristics, and to give an estimate offoreseeable successes.

In the near future, the spread of cheap powerfulcomputers, based on the generation of the Intel 80386or Motorola 68020 chips, will reduce the challenginghardware limitations encountered in this project andwill contribute to the success of this expert-systemapproach to the water-supply problem in developingcountries. This will lead to a considerable reduction inthe cost of studies, thanks to the training and theincreased involvement of African experts in the de-velopment of their countries' water resources. Artifi-cial Intelligence therefore should be able to help solvethe water problem in Africa, especially within thescope of programs for village water supplies.

Acknowledgments—We arc grateful to Pierre Haren whoalways has encouraged us in our research. We also wouldlike to thank the SMEC1 team ut INRIA Sophia Antipolis,as many of the ideas presented here are the result of closecollaboration with them. Thanks also arc due lo Yves Em-sellem who supported the project and to Pierre Leymarie andRichard Sinding-Larsen, who introduced us to the subject.

A free copy of HYDROLAB* can be obtained by univer-sity members and students. 11'interested, write to the authorsand include two floppy disks.

REFERENCES

Albert, P., 1985, Prolog et les objets: Proc. Fifth Intern.Workshop on Expert Systems and their Applications,Avignon, [-Vance, p, 332-350.

Arrivet, L., 1987, Introduction du flou dans un systèmeexpert: Mémoire d'Ingénieur de l'Ecole Supérieure d'In-formatique d'Electronique et d'Automatique, Paris,Prance, 44 p.

Bernardi, A., and Detay, M., 1988, Corrélations entre lesparamètres géoélectriques et les caractéristiques hy-drodynamiques des forages en /.one de socle: Revue duBRGM Hydrogéologie, no. 4, 15 p.

Borland International, 1986, Turbo Prolog, owner's hand-book: Borland, Scotts Valley, California, 221 p.

Clayton, B., 1985, ART™ reference manual: Inference Cor-poration, Los Angeles, California, v. I, 138 p., v. 2,158 p., v. 3, 102 p.

Clocksin, W. [•'., and Mellish, C. S., 1984, Programming inPROLOG: Springer. Berlin, 304 p.

Cohnerauer, A., 1977, Programmation en logique du pre-mier ordre: Actes des journées La compréhension, IRIA,France, p. 124-132.

Colmcrauer, A., 1983, Prolog in ten figures: Proc. EighthIntern. Joint Conf. on Artificial Intelligence, p. 487-499.

Detay, M.. 1987, Identification analytique et probabilistedesparamètres numériques et non-numériques et modélisa-tion de la connaissance en hydrogéologic sub-sahélienne:Thèse de Doctorat d'Etal ¿s Sciences, Université de Nice,France, 456 p.

Detay, M., Goulnik, Y., Casanova, R., Ballestracci, R., andEmscllcm, Y,, 1986a, HYDROLAB an expert system forgroundwater exploration in Africa: Bull. 1WRA—Intern. Conl'. Water Resources Needs and Planning inDrought Prone Areas. Khartoum, Sudan, 6 p.

Detay, M., Boulnik, Y., Casanova, R., and Ballestracci, R.,1986b, IIYDROI.AB un système expert pour larecherche des eaux souterraines en Afrique: Actes dudeuxième colloque Int. Eau Gestion des données et aideà la Décision, Montpellier, France, p. 94-99,

Forgy, C. L., 1982, A fast algorithm for the many pattern—many object pattern match problem: A. I. Jour. no. 19,p. 17 -37.

Haren, P., Neveu, B., Corby, O., and Montalban, M., 1985a,MEPAR: Un Moteur d'inférences pour la conception eningénierie: 5 éme Congrès Reconnaissance des Formes etIntelligence Artificielle, C.îrenoblc, France, p. 1273-1280.

Haren, P., Neveu, B., Giacomcui, J, P., Montalban, M., andCorby, O., 1985b, SMECI: Cooperating Expert Systemsfor Civil Engineering Design: SIGART Newsletter (April1985), no. 92. p. 67-69.

Hayes-Roth, B., 1984, BB1: An architecture for blackboardsystems that control, explain and learn about their ownbehavior: Heuristic Programming Project, Report no.HPP-84-16, Stanford Univ., 22 p.'

Knolidge, K., 1979, An inference net compiler for the PROS-PECTOR rule based consultation system: Proc. of SixthIntern. Joint Conf. Artificial Intelligence, p. 487 489.

Nii, P., 1986a, Blackboard systems: the blackboard model ofproblem solving and the evolution of blackboard archi-tectures: A.I. magazine (July 1986), p. 38 53.

Nii, P., 1986b, Blackboard system, blackboard applicationsystem, blackboard systems from a knowledge engineer-ing perspective: A.I. magazine (August 1986), p. 82-106,

Poye!, P., 1986, Discrimination des anomalies géochimiquesmulti-élémentaircs significatives: Thèse de Doctoratd'Etal es Sciences, Université de Nice, France, 436 p.

Poyet, P., 1987, l a structure de contrôle dans les systèmesexperts de simulation: Proc. 6èmc Congrès Recon-naissance des Formes et Intelligence Artificielle de l'Ass-ociation Française de Cybernétique Economique etTechnique, Antibcs, France, p. 723-738.

Poyct, P., and Lie La Cruz, P., 1987, Simulation navale enenvironnement hostile: Proc. Ecole d'Autonme sur l'in-telligence Artificielle, THOMSON et Ecole NormaleSupérieure d'Ulm, Jouy en Josas, France, 10 p.

Poyet, P., Haren, P., and De La Cru/, P., 1987, Un systèmeexpert de simulation navale: Proc. 6ème Congres Recon-naissance des Formes et Intelligence Artificielle de l'As-sociation Française de Cybernétique Economique etTechnique, Amibes, France, p, 587 592,

Poycl, P., 1988, Cours de Modélisation Assistée par Ordina-teur: Les problèmes, les langages, les machines et lestechniques de l'I.A.: Laboratoire de Géologie et Géochi-mie, Université de Nice, France, 78 p.

Poyet, P., and De La Cruz, P., 1988, Une nouvelle classe desimulateurs destinée aux aides tactiques et aux systèmesd'armes: Proc. Eighth Intern. Workshop on Expert Sys-tems and their Applications, Specialized Conferences A.Iand Defense, Avignon, France, p. 89-99.

Poyct, P., and Detay, M., 1988a, Aide à l'implantationd'ouvrages d'hydraulique villageoise: Proc. Eight Intern.Workshop on Expert Systems and their Applications,Avignon, France, p. 397-410.

Poyct, P., and Delay, M., 1988b, HYE>ROLAB VersionVI.4, Un système expert d'aide à l'implantation de for-

Compact expert system 267

ages en hydraulique villageoise, Manuel d'introductionet de référence: INRIA Research Report no. 936, InstitutNational de Recherche en Informatique et en Automa-tique, Sophia Antipolis, France, 42 p.

SMECI, 1988, Le manuel de l'utilisateur SMECI VI.3:ILOG S.A., France, 112 p.

Stelik, M., Bobrow, D. G., Mittal, S., and Conway, L., 1983,

Knowledge programming in LOOPS: A.I. Magazine(Fall 1983) p. 3-13.

Stefik, M. J., Bobrow, D. G., and Kahn, K. M., 1986,Integrating access oriented programming into a mulli-paradigrn environment: IEF.F. Software (January 1986),p. 10-18.

Warren, 1977, Implementing PROLOG: D.A.I. ResearchRept. Vols. 1 and 2, Univ. Edinburgh.

CAGEO 1 5 : 3 - C