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
Logic
1
Programs
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
Search
Logic
Instance-Based
of Default
29
with Two Negations
in Semantic
in Finetely-Valued
L. Giordano Denning Variants
Guided
19
Three-Valued
J . Posegga Compiling Proof R. Hähnle Short CNF
in Semantically
39
Tableaux
49
Logics
Logic:
a Modal
59
Approach
E x p e r t Systems L . - Y . Shue & R. Z a m a n i An Admissible
Heuristic
Search
S.-J. Lee k C . - H . W u Building an Expert System Network Technique G. Valiente Input-Driven
Control
Language
Interpreter
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
69
Algorithm
Expert
Systems
96
Diagnosis
for Expert
Systems
86
Development
106
Invited Talk I I F. Bry T o w a r d s Intelligent
Databases
116
VIII
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
Programs
Framework
142
for 152
P. L a m b r i x k R. Rönnquist Terminological Logic Involving A Preliminiary Report
Time
and
Evolution: 162
Intelligent Databases L.V. Orman Knowledge
Management
172
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
Balancing
of Parallel
Database 186
for Processing
Negation
and
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
Software
Engineering
219
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
Logic
235
Programs
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
Using
Unskolemization
Lattices
245
255
IX A . Rajasekar Controlled Explanation
265
Systems
N . V . M u r r a y k E. Rosenthal Signed Formulas: A Liftable Meta-Logic
for Multiple-Valued
Logics
275
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
Concepts
Text-Based
for the FLINS-Fuzzy
and Fuzzy-Centered
Lingual
System:
Architectures
285
Rules
295
A . Skowron Boolean
Reasoning
for Decision
Generation
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
Order
C M . Rauszer Approximation
for Knowledge
Methods
Uncertainty
Using
Compatible 306
in Possibilistic
Representation
Logic
316
326
Systems
Invited Talk I V L. Ljung Modelling
of Industrial
338
Systems
Constraint Programming J . - F . Puget On the Satisfiability
of Symmetrical
Constrainted
Satisfaction
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
Problems
350
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
Techniques:
in Computer-Aided
Their
Process
Search
Methods 375
Combination Planning
385
χ
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
or
from 395
H . Lounis Integrating Machine-Learning Systems Verification
Techniques
in
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
415
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
425
Invited Talk V L . De R a e d t k N . Lavrac The Many Faces of Inductive
Logic
435
Programming
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
of
Distributed 450
H. Gan Script
and Frame:
with Default
Mixed
Natural
Language
Understanding
System 466
Theory
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
Creative
or
Intelligent 476
the Requirement
Engineering 486
for Intelligent
Robotics
496
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
Problem
in
Concept 508
518
XI
Κ. T h i r u n a r a y a n Expressive Extensions
to Inheritance
G. Bittencourt A Connectionist-Symbolic
528
Networks
Cognitive
538
Model
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
Temporal
Evolution
548
Invited Talk V I E. Sandewall Systematic Autonomous
Assessment
of Temporal
Reasoning
Methods
for Use in 558
Agents
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
System
in CAD/CAM
Analysis
in
571
Automated 581
B.-T.B. Chu k H. Du CENTER: A System Architecture Manufacturing M . Sobolewski Knowledge-Based Environment
for Features
for Matching
Design
and 591
Integration
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
Problem
of Rule
Solving
Uncertainties
Knowledge
Authors Index
and Their
Integration 622
Bases
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
612
Model
of Preferential
632
in Data
Attitude
in
Multi-Criteria 642
653
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.
1
Introduction
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.
117
2
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.
2.1
Deduction
Rules
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
118
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)
=>
flight(D,
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
0725
0900
LH4356
119
Xe67
1110
1245
LII4384
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
122
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.
2.4
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