Methodologies for Intelligent Systems

J. Komorowski Z.W. Ras (Eds.) Methodologies for Intelligent Systems 7th International Symposium, ISMIS '93 Trondheim, Norway, June 15-18, 1993 Proce...
Author: Martha Higgins
4 downloads 0 Views 2MB Size
J. Komorowski

Z.W. Ras (Eds.)

Methodologies for Intelligent Systems 7th International Symposium, ISMIS '93 Trondheim, Norway, June 15-18, 1993 Proceedings

Springer-Verlag Berlin Heidelberg NewYork London Paris Tokyo Hong Kong Barcelona Budapest

Table of Contents Invited Talk I J . M i n k e r & C. R u i z On Extended Disjunctive




L o g i c for A r t i f i c i a l I n t e l l i g e n c e I H . C h u & D . A . Plaisted Model Finding Stategies Theorem Proving D . R . Busch An Expressive




of Default


with Two Negations

in Semantic

in Finetely-Valued

L. Giordano Denning Variants




J . Posegga Compiling Proof R. Hähnle Short CNF

in Semantically






a Modal



E x p e r t Systems L . - Y . Shue & R. Z a m a n i An Admissible



S.-J. Lee k C . - H . W u Building an Expert System Network Technique G. Valiente Input-Driven




with the

Rule 76

of Rule-Based

B . Lopez k E. Plaza Case-Based Planning for Medical J . P . Klüt & J . I I . P . Eloff MethoDex: A Methodology







for Expert





Invited Talk I I F. Bry T o w a r d s Intelligent




L o g i c for A r t i f i c i a l I n t e l l i g e n c e I I L . P a d g h a m k B . Nebel Combining Classification Reasoning: A First Step

and Nonmonotonic

Inheritance 132

H . Rasiowa k V . W . M a r e k Mechanical Proof Systems for Logic I I , Consensus and Their Processing (Extended Abstract) J . Chen The Logic of Only Knowing Nonmonotonic Reasoning

as a Unified




for 152

P. L a m b r i x k R. Rönnquist Terminological Logic Involving A Preliminiary Report



Evolution: 162

Intelligent Databases L.V. Orman Knowledge



by Example

H . M . Dewan k S.J. Stolfo System Reorganization and Load Rule Processing T . Gaasterland k J . L o b o Using Semantic Information in Logic Programs


of Parallel

Database 186

for Processing



Disjunction 198

P. Bosc, L . L i e t a r d k 0 . P i v e r t On the Interpretation of Set-Oriented and Their Evaluation in a Database

Fuzzy Quantified Management System

Queries 209

Invited Talk I I I M . R . Lowry Methodologies

for Knowledge-Based




L o g i c for A r t i f i c i a l I n t e l l i g e n c e I I I N . Leone, L . P a l o p o l i k M . R o m e o Updating




D . R o b e r t s o n , J . A g u s t i , J . Hesketh k J . L e v y Expressing Program Requirements using Refinement R . C h a d h a k D . A . Plaisted Finding Logical Consequences






IX A . Rajasekar Controlled Explanation



N . V . M u r r a y k E. Rosenthal Signed Formulas: A Liftable Meta-Logic

for Multiple-Valued



Approximate Reasoning S. T a n o , W . O k a m o t o k T . I w a t a n i New Design



for the FLINS-Fuzzy

and Fuzzy-Centered







A . Skowron Boolean


for Decision


C . W . R . C h a u , P. L i n g r a s k S . K . M . W o n g Upper and Lower Entropies of Belief Functions Probability Functions C.J. L i a u k B.I-P. L i n Reasoning About Higher


C M . Rauszer Approximation

for Knowledge




Compatible 306

in Possibilistic






Invited Talk I V L. Ljung Modelling

of Industrial



Constraint Programming J . - F . Puget On the Satisfiability

of Symmetrical



A . L . B r o w n J r . , S. M a n t h a k T . W a k a y a m a A Logical Reconstruction of Constraint Relaxation in Logic Programming



Hierarchies 362

P. Berlandier A Performance Evaluation of Backtrack-Bounded for N-ary Constraint Networks M . A . Meyer k J . P . Müller Finite Domain Consistency and Application


in Computer-Aided




Methods 375

Combination Planning



Learning and Adaptive Systems I I . F . I m a m k R.S. M i c h a l s k i Should Decision Trees be Learned Decision Rules?

from Examples


from 395

H . Lounis Integrating Machine-Learning Systems Verification



Knowledge-Based 405

R. B a g a i , V . Shanbhogue, J . M . Z y t k o w k S.C. C h o u Automatic Theorem Generation in Plane Geometry


A . G i o r d a n a , L . S a i t t a k C. B a r o g l i o Learning Simple Recursive Theories


Invited Talk V L . De R a e d t k N . Lavrac The Many Faces of Inductive




Methodologies M . B a t e m a n , S. M a r t i n k A . Slade CONSENSUS: A Method for the Development Intelligent Systems


Distributed 450

H. Gan Script

and Frame:

with Default





System 466


M . F r a n o v a , Y . K o d r a t o f f k M . Gross Contructive Matching Methodology: Formally Inductive Theorem Proving? G . Grosz k C. R o l l a n d Representing the Knowledge Used During Activity with Generic Structures S. Caselli, A . N a t a l i k F . Zanichelli Development of a Programming Environment



Intelligent 476

the Requirement

Engineering 486

for Intelligent



Knowledge Representation A . Schaerf On the Complexity of the Instance Checking Languages with Existential Quantification S. A m b r o s z k i e w i c z Mutual Knowledge



Concept 508



Κ. T h i r u n a r a y a n Expressive Extensions

to Inheritance

G. Bittencourt A Connectionist-Symbolic






M . D i M a n z o k E. G i u n c h i g l i a Multi-Context Systems as a Tool to Model




Invited Talk V I E. Sandewall Systematic Autonomous


of Temporal



for Use in 558


Manufacturing C h . K l a u c k k J . Schwagereit GGD: Graph Grammar Developer K. Wang A Knowledge-Based Approach Manufacturing Systems

to Group






Automated 581

B.-T.B. Chu k H. Du CENTER: A System Architecture Manufacturing M . Sobolewski Knowledge-Based Environment

for Features

for Matching


and 591


in a Concurrent

Engineering 601

Learning and Adaptive Systems I I P. C h a r l t o n A Reflective Strategic B . Wüthrich On the Learning into Probabilistic


of Rule




Authors Index

and Their

Integration 622


R. Zernbowicz k J . M . Z y t k o w Recognition of Functional Dependencies R. S l o w i r i s k i Rough Set Learning Decision Making



of Preferential


in Data



Multi-Criteria 642


Towards Intelligent Databases Frangois B r y E C R C , Arabellastraße 17, 81925 München 81, Germany [email protected]

A b s t r a c t . T h i s article is a presentation of the objectives a n d techniques of deductive databases. T h e deductive approach to databases aims at extending with intensional definitions other database paradigms that describe applications extensionaUy. We first show how constructive specifications can

be expressed with deduction rules, and how normative conditions can be defined using integrity constraints. We outline the principles of bottom-up and top-down query answering procedures and present the techniques used for integrity checking. We then argue that it is often desirable to manage with a database system not only database applications, but also specifications of system components. We present such meta-level specifications and discuss their advantages over conventional approaches.



Deductive Databases have been studied since more t h a n a decade. Theoretical issues have been investigated (see e.g. [28, 29, 30, 3 1 , 65, 2 1 , 8, 48, 64, 17, 18, 44, 45] for an overview), and experimental deductive database management systems have been and are s t i l l implemented (e.g. [54, 9, 23, 26, 32, 34, 5 1 , 56, 66, 33, 68, 40, 52]). Industrial products are currently developed from research prototypes (e.g. [69]). T h i s article is informal presentation of the notions and objectives of deductive databases. Instead of emphasizing technical aspects (that are explained i n a number of articles and tutorials, e.g. [28, 29, 30, 3 1 , 65, 2 1 , 8, 17, 18]), we prefer to insist on the goals of the deductive approach to databases. A first p a r t of the presentation is devoted to recall how two complementary notions are used i n deductive databases for declaratively specifying an application. O n the one hand, deduction rules are used for constructive definitions. On the other hand, normative specifications are expressed through integrity constraints. We i n formally describe how deduction rules are evaluated for answering queries (see e.g. [17, 18, 1, 2, 4, 7, 55, 57, 60, 6 1 , 67, 13]), and how integrity constraints are checked when the database is updated (see e.g. [17, 18, 15, 25, 39, 43, 47, 49, 53, 19]). I n a second part of the presentation, we argue t h a t i t is often desirable to manage w i t h the database system, not only an application, but also specifications of components of the database sytem itself, the description of an application, or various kinds of interpretations of this application. We informally introduce a few such meta-level specifications, t h a t rely on meta-programming [58, 62, 63, 59]. F i n a l l y , we briefly mention further applications of meta-level specifications towards enhanced database management systems.



A n I n t r o d u c t i o n to Deductive Databases

A m a i n trend i n database research is the enhancement of data modeling facilities. Deductive database techniques a i m at extending conventional, nondeductive databases, in which d a t a are extensionally specified, w i t h intensional definitions in form of deduction rules and integrity constraints. Database management systems historically developed from file managers, in which applications are specified in terms of records and structured according to storage and retrieval criteria. T w o d a t a models were proposed at the end of the sixties/beginning of the seventies for i m p r o v i n g the descriptions of applications: the hierarchical and the network data models. Like a file, a hierarchical or network database consists of records. However, i n contrast to files, records are structured i n trees and pointers express relationships between records. B o t h the hierarchical and the network d a t a models have a m a j o r drawback: T h e pointers these data model rely upon make the design and the querying of databases rather difficult. Database users must be aware of rather complex networks even for posing simple queries. The relational data model, defined by Codd [24] at the end of the seventies, overcomes this difficulty in an elegant manner: no pointers are used and the conceptual links between records (called tuples) are expressed through regular data. A relational database consists in a set of relations. Relations are set of tuples. The semantical relationship between tuples are expressed through the values they contain. Thus, for example, the presence of a same character string (say, a name) in a tuple of a "salary" relation and i n a tuple of an "address" relation links salaries, addresses, and employee's names. Because they are value-based, relational databases can be i n terpreted i n mathematics as logical theories consisting of formulas or, alternatively as logical models consisting of relations. Relational databases can be seen as more declarative than hierarchical or network databases since less knowledge of their internal structure is necessary for querying t h e m . Indeed the knowledge of the relation's names, the so-called database schema, and, possibly, of some values occurring i n tuples, suffices for posing queries.




Deductive databases can be seen as an extension of the relational model. I n a relational database, the data are specified extensionally. T h a t is, the tuples of a relational database are explicitly defined. Deductive databases i n contrast, also give rise to specifying data intensionally by means of general properties, expressed using deduction rules. Consider for example the time-table of the Lufthansa airline. The Lufthansa direct flights from Munich to Paris can be specified by the following " f l i g h t " relation: Monday Tuesday Wednesday Tursday Friday Saturday

0725 0725 0725 0725 0725 0725

0900 0900 0900 0900 0900 0900

LII4356 LII4356 LH4356 LH4356 LH4356 LH4356


Monday Tuesday Wednesday Thursday Friday

1110 1110 1110 1110 1110

1245 1245 1245 1245 1245

LH4384 LII4384 LH4384 LH4384 LH4384

T h e first a t t r i b u t e (column) of this relation indicates the day of the flight, the second and t h i r d are the departure and arrival times, respectively, and the last attribute is the flight number. These eleven flights could b e specified by the following two deduction rules t h a t somehow "factorize" the d a t a common t o several tuples: f l i g h t ( D , 0725, 0900, lh4356) < - d a y ( D ) , not D = Sunday. flight(D, 1110, 1245, 1H4384) < - d a y ( D ) , not D = Saturday, not D = Sunday. As usual, character strings beginning w i t h a n upper case letter (e.g. D ) are used for denoting (logical) variables. The membership of a tuple (called "fact" i n deductive databases) " t " in a relation " r " is expressed by the term " r ( t ) " . We assume that "day" denotes the relation containing the seven days of the week (monday, tuesday, etc.). Lower case letters are used for distinguishing these constant values f r o m vari­ ables. The expression " d a y ( D ) " can be thus evaluated to the facts " d a y ( m o n d a y ) " , "day(tuesday)", etc. The meaning of the first rule is t h a t the facts "fiight(monday, 0725,0900, lh4356)", "ilight(tuesday, 0725, 0900, l h 4 3 5 6 ) " , " f l i g h t ( s a t u r d a y , 0725, 0900, lh4356)" are derivable, i.e. are true facts in the database. I n more technical terms,the variable D is ( i m p l i c i t l y ) universally quantified. T h e first deduction rule is thus a shorthand n o t a t i o n for the following formula: V D

[ (day(D) AO φ Sunday)



0725, 0900, lh4356) ]

T h i s simple example illustrates two i m p o r t a n t advantages of deductive databases compared w i t h relational ones: (1) they require less storage, and (2) they give rise to more natural specifications. The possible size reduction is sometimes d r a m a t i c : A n analysis of the time table of the Munich public transportation shows for example a reduction factor of about 200! Database applications whose d a t a cannot be speci­ fied according to general principles do not benefit as much of deductive techniques. Most databases nevertheless contain some d a t a t h a t were i m p l i e d f r o m general laws (e.g. business rules, legislation, scientific laws, etc.) and therefore can benefit from deductive database techniques. One could object t h a t no deductive techniques are needed for achieving the fac­ torization described above. T h i s is true. There are indeed, for this example, two alternative ways to avoid the undesirable duplication of d a t a using relational data structures. T h e first approach consists in s p l i t t i n g the original relation in two dis­ t i n c t relations, the first one giving the day and the flight number (which obviously is a key), the second relation giving the times and the flight numbers. A j o i n then permits ones to reconstruct the original relation at query t i m e . T h e second approach consists in using codes like in the following table for expressing on which days a flight is available. Xe7









I n this r e l a t i o n , X stands for every day of the week, 6 for Saturdays, 7 for Sundays, Xe7 for every day except on Sundays, and Xe67 for every week days. 1

We argue t h a t b o t h approaches have severe drawbacks. T h e first approach (the split o f the original relation i n two distinct smaller relation) examplifies an often criticized (although necessary) practice in relational database design: For reasons of storage (size) and coherency of the data (when updates are performed), the natural description of an application usually needs to be modified. T h e two rules given above as opposed achieve the same eiTect w i t h o u t compromising the natural character of the specifications. T h e second approach (the encoding of the days i n the tuples) is very close to a specification by means of deduction rules. T h e difference however is t h a t the encoding is a notation " u n k n o w n " to the database management system, while deduction rules are "understood" by a deductive database system for what they are. Such an encoding is specific to a given application and must be interpreted in the application programs, that is outside the database system. Deduction rules in contrast give rise to interpreting intensional knowledge within the database system. Deduction rules can also be used i n lieu of relational views. Views are in relational databases means for expressing predefined queries. One could for example define connecting flights using a view: Λ connecting flight f o r m A to Β is defined from a flight f r o m A to C and a flight from C to Β such that some conditions on the departure and arrival times in C, and on the location of the airport C arc satisfied. A recursive definition give rise to specifying connections involving an indefinite number of flights. Such a definition is quite naturally expressed by the following deduction rule: connection(D, Τ Ι , T 2 , [Nb]) < - flight(D, Τ Ι , T 2 , N b ) . connection(D, T l , T 2 , [Nb | L]) f - f l i g h t ( D , T l , T 3 , N b ) , connection(D, T 3 , T 2 , L ) , compatible(Nb, L ) . The first rule specifies a connection consisting of one single flight. T h e list of flight involved i n this connection ([Nb]) thus contains only one flight number. T h e second rule " l i n k s " a flight to a connection and extends its list of flight numbers. The pred­ icate "compatible" is assumed to express whether times and airports are compatible in a connection. I t m i g h t be specified intensionally by means of deduction rules, or extensionally by a relation. Recursive specification are i m p o r t a n t in practice for specifying several natural properties that apply on an indefinite number of object. Another example is the definition of a " b i l l of m a t e r i a l " : the price of a complex object is obtained by s u m m i n g up the prices of its parts, whose prices are in turn similarly defined. Like for flight connections, i t is desirable to have a specification at our disposal which is not l i m i t e d to a given number of components (e.g. flights or parts). I t has often been observed that recursive specifications are hardly avoidable in real life applications. Deduction rules thus are very similar to relational views. Since the first relational database systems were not capable of handling recursive views, deduction rules are 1

This representation is taken from the time table booklet published by Lufthansa.

120 often seen as the extension of relational views to recursion. I n our o p i n i o n , deduction rules are more than extended views. Views are not handled like regular d a t a , i.e. tuples and relations, i n a relational database management systems, while deduction rules should be seen as first class citizen i n a deductive database system. T h i s means that a l l the facilities that are provided by the system for storing, retrieving, updating, and querying extensional specifications (i.e. facts) should also be a p p l i cable to intensionally defined d a t a (i.e. d a t a defined by deduction rules) and to the intensional specifications themselves. T h e full realization of this objective is s t i l l the subject of active research. 2.2

Remarks on the Language of D e d u c t i o n Rules

T h e deduction rules specifying connecting flights (cf. previous section) contain c o m plex, nested terms, namely lists. I t is often believed t h a t nested terms and t e r m constructors should be prohibited i n deductive databases. We t h i n k t h a t nested terms are needed (as in the above example). Moreover, the known techniques are (almost) sufficient to acommodate them like flat, so-called first-normal f o r m facts. I t is probably the concept of Datalog, i.e. the language of rules w i t h flat terms and no negation, which has widespread the idea that deductive databases should only specify first-normal form tuples. I n deductive databases, the same form of negation is needed as in relational databases. T h i s negation has been formalized in various manner and under different names (negation as failure, non-monotonic negation, negation according t o the closed-world assumption, etc.). C o m m o n to these formalizations is the basic n o t i o n that an expression can be considered as false i f i t cannot be proved. T h i s interpretation of negation is a rather intuitive form of reasoning. T h i s is this way of t h i n k i n g that leads us to conclude, for example, that there are no direct flights from M u n i c h to Trondheim i f we do not find any in the t i m e table. A l t h o u g h there is a general agreement on the semantics of this form of negation for relational databases, i t is not always clear how to formalize i t i n deductive databases. Rules like the f o l l o w i n g ones are difficult to interpret, indeed: a 2300 ]

A n y a t t e m p t to specify a flight landing after 23:00 would lead to a violation of this integrity constraint. T h i s violation would be reported to the database user who could then either modify the update, or, i f i t appears to be no more valid, the integrity constraint instead. A n integrity constraint can thus be viewed as a yes/no query which is evaluated when the database is updated. Integrity constraints are needed not only for specifying negative properties, as i n the previous example, b u t also for stating disjunctive or existential conditions, like i n the following examples stating t h a t at least one of two flights must be recorded (i.e. specified) i n the database, and that there exists at least one day on which there is a flight, respectively: flight(saturday, 0700, 0745, lh0345) V flight(saturday, 3 D [ d a y ( D ) Λ flight(D, 0700, 0745, lh0345) ]

0735, 0810, lh0346)

A l t h o u g h marketed database management systems can only m a i n t a i n very limited types o f integrity constraints ( i f at all!), normative specifications arc i m p o r t a n t in all kinds o f database applications. Integrity constraints are expressed and maintained through application programs in current databases, t h a t is outside the scope of the database system. T h i s is undesirable because this makes the specification and the maintenance of integrity constraints a (generally complex) p r o g r a m m i n g task. I n deductive databases, this is part of the database design, for which tools should be available [16]. Integrity constraints are not declaratively specified b u t are expressed by means of imperative programs. Moreover these programs usually combine the specifications of the normative conditions and their efficient evaluation. I n deductive databases in contrast, one only has to specify integrity constraints. T h e i r efficient evaluation is left to the database management system (cf. Section 4 below). T h i s is not only more convenient for the database designer. T h i s also ensures that integrity constraints are efficiently checked. T h i s is hardly the case when application programs


are modified for acommodating the modifications of integrity constraints t h a t are unavoidable i n any real life applications. Range restriction is needed for integrity constraints like for deduction rules. A universal quantification V X F [ X ] is range restricted i f the expression F [ X ] is of the form R[X] => G [ X ] and i f X appears positively i n R (cf. [10] for a precise definition). Thus V X [ p ( X ) => q ( X ) ] is range restricted, while V X [ ( - 1 p ( X ) ) => q ( X ) ] is not. A n existential constraint 3 X F [ X ] is range restricted i f F [ X ] is of the form R [ X ] Λ G [ X ] and i f X appears positively i n R [ X ] [10]. Range restriction ensures t h a t only updates affecting expressions occurring i n a constraint (directly or indirectly through deduction rules) m i g h t violate this constraint. T h i s is an essential condition for an efficient integrity checking (cf. Section 4). I t is w o r t h noting t h a t range restriction is a very natural requirement: i n natural languages, i t is almost impossible to ex­ press properties t h a t are not range restricted. Moreover, formulas that are not range restricted have "semantically equivalent" counterparts t h a t are range restricted.


C o n s t r a i n t s as R u l e s

Deduction rules can be used for expressing integrity constraints in two different ways. The first one consists in expressing quantifiers by means of rules, the sec­ ond approach, i n rewriting the integrity constraint as special rules. The following deduction rule express a range-restricted universal quantification: f o r a l l ( X , R = > F) < - not (R, not F ) . Consider for example the following universal formula: V X p ( X ) => q ( X ) . I t would be expressed as " f o r a l l ( X , p ( X ) = > q ( X ) ) " using the formalism defined by the above given rule. T h i s expression evaluates to true i f and only i f i t is impossible to satisfy the conjunctive query "p(X)> not q ( X ) " , i.e. to find a value X i n the relation " p " which is not also i n the relation " q " . The deduction rule given above thus specifies a constructive evaluation of range restricted universally quantified expressions [12]. Existential quantifications are even easier to express i n the formalism of deduction rule: exists(X, F) < - F. Instead of relying on the above given rules for quantifiers, one can also d i r e c t l y rewrite the integrity constraints as rules. A n integrity constraint C is expressed as a rule, called denial^ corresponding to "false