Unformatted text preview: Semantics of Behavioral Inheritance in Deductive ObjectOriented Databases
Hasan M. Jamil Laks V.S. Lakshmanan y Technical Report: TRDB9606 March 1996 Department of Computer Science Concordia University 1400 Maisonneuve Boulevard West Montreal, CANADA H3G 1M8 email: fjamil, [email protected] This author's research was supported in part by grants from the Canadian Commonwealth Scholarship and Fellowship Plan and the University of Dhaka, Bangladesh. y This author's research was supported in part by grants from the Natural Sciences and Engineering Research Council of Canada, the Fonds Pour Formation De Chercheurs Et L'Aide A La Recherche of Quebec. Semantics of Behavioral Inheritance in Deductive ObjectOriented Databases
Department of Computer Science Concordia University Montreal, CANADA H3G 1M8 email: [email protected] Hasan M. Jamil Department of Computer Science Concordia University Montreal, CANADA H3G 1M8 Laks V. S. Lakshmanan email: [email protected] Abstract
We propose a novel semantics for objectoriented deductive databases in the direction of Flogic to logically account for behavioral inheritance, con ict resolution in multiple inheritance hierarchies, and overriding. We introduce the ideas of withdrawal, locality, and inheritability of properties (i.e., methods and signatures). Exploiting these ideas, we develop a declarative semantics of behavioral inheritance and overriding without having to resort to nonmonotonic reasoning. Con ict resolution in our framework can be achieved both via speci cation and by detection. The possibility of speci cation based con ict resolution through withdrawal allows users to state inheritance preference. We present a formal account of the semantics of our language by de ning a model theory, proof theory and a xpoint theory. We also show that the di erent characterizations of our language are equivalent.
Key Words: objectorientation, behavioral inheritance, overriding, withdrawal con ict resolution, deductive databases, declarative semantics, sound and complete proof theory. ii Contents
1 Introduction 2 Overview of ORLog
2.1 Syntax : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.1.1 Atomic and Complex Formulas : : : : : : : : : : : : : : : : : : : 2.2 Informal Semantics of Inheritance : : : : : : : : : : : : : : : : : : : : : : 1 3
3 4 6 3 Interpretation Structures 4 Model Theoretic Semantics 12 17 4.1 Canonical Models : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18 4.2 Correspondence between Herbrand Structures and ORLog Structures : : 21 4.3 Intended Models : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 22 5 Proof Theory 24 5.1 Closure of a Program : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 25 5.2 Proof Rules : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 26 6 Fixpoint Semantics 7 Related Research 8 Conclusion 28 35 36 iii 1 Introduction
In the recent years the database research community has made a signi cant stride in combining the declarative aspects of deductive databases and the superior modeling capabilities of the objectoriented paradigm. Although the appeal of a combined model seems overwhelming, its logical rendition is not so easy. This is largely because of the presence of the concepts such as inheritance of behaviors, code reuse and overriding that are related to nonmonotonic reasoning. Although overriding complicates the underlying theory to a great extent, it is a notion that makes the objectoriented paradigm interesting and useful. The issue gets further complicated when we allow multiple inheritance. We are then required to deal with inheritance con icts and as a consequence may have to settle for multiple minimal models at the declarative level, e.g., as in 16]. Current solutions that are proposed in the literature are based on nonmonotonic reasoning 26], program composition 5], etc. These proposals have been criticized due to the skepticism about their feasibility as an e cient computational platform. Behavioral inheritance has been studied in deductive formalisms like the Ordered Theories of 17], in modular languages such as Contextual Logic Programming 23, 24] and several others. However, the framework in which they accomplish this are quite narrow compared to the needs of objectoriented databases and languages. Logic languages like LOGIN 1] and LIFE 2] incorporate structural inheritance by means of an extended uni cation algorithm for terms, complex typed structures that are used for data representation. Kifer et al. 16] proposed an elegant logic, called Flogic, as a logical foundation for objectoriented databases. Only structural inheritance is captured in its semantics and proof theory, and for this component of the language it was shown to be sound and complete. However, completeness is achieved by taking a monotonic view of inheritance. Behavioral inheritance with overriding in Flogic is captured indirectly by a pointwise iterated xpoint construction. Flogic directly accounts for ground molecules (corresponding to values computed from method execution) being inherited down an isa hierarchy. Code inheritance is left outside the language and has to be simulated by the programmer using higherorder features of the language and Flogic's pointwise overriding in a clever manner. Dobbie and Topor 8, 9] have developed a language called Gulog, inspired by a restricted fragment of Flogic. Gulog is functionfree. For a restricted class of programs which are strati ed with respect to inheritance and deduction, and where schema and data are separated, and the schema is predetermined, they propose a sound and complete query 1 evaluation procedure. They account for (con ictfree) multiple inheritance with dynamic overriding, by forcing the isa hierarchy to be static. However, they only account for value inheritance and do not capture behavioral inheritance. There are some proposals that address the issue of behavioral inheritance but rely on a translation of an objectoriented logic program into a valuebased conventional logic program. In this approach the insight into the meaning of inheritance and its interaction with deduction and overriding is lost, and there is little control on how the translated program would behave. OOLP 7] and L&O 20] are two such proposals which capture a few features of inheritance in a limited way. The goal of this paper is to develop a simple logical account of behavioral inheritance (in the sense of code reuse) with overriding, providing for con ict resolution in the event of multiple inheritance. This we achieve by enriching the syntax of the logic so that the locality (i.e., point of de nition) and inheritability of properties (i.e., methods and signatures) can be asserted and inferred. In addition, our language allows for a syntactic instruction for withdrawing property de nitions to prevent subclasses or instances from inheriting them. A special aspect of this latter feature is that it allows the programmer to in uence the logic's inheritance mechanism to suit her preferred needs. The above features were rst introduced in the context of ORLog (for Object Relationship Logic) 12]. In 12], we developed a declarative semantics for the higherorder features of ORLog, not including inheritance. In a preliminary version of this paper 13], we presented a declarative characterization of behavioral inheritance in ORLog and showed that con ict resolution in ORLog is possible in a relatively simple way. In 6], a stable model semantics for behavioral inheritance was proposed using notions of locality and inheritability similar to those proposed in 12]. By contrast, in the present discussion, we account for behavioral inheritance within the logic, by capturing it within a sound and complete proof theory. We also develop a modeltheoretic and xpoint semantics and establish the equivalence of all three semantics. Before closing this section, we note that a majority of the works on inheritance rely on a form of nonmonotonic reasoning. Of these, 8, 9, 16] capture value inheritance while 17, 6, 4] handle a form of behavioral inheritance. While a nonmonotonic account of inheritance is natural and interesting, it relies on extralogical features to capture inheritance. In addition, most of these proposals incur a high cost for query processing, which can be signi cant for database applications. In comparison, a complete proof theoretic and declarative account of inheritance is at once intellectually more satisfying 2 and o ers a greater promise as an e cient computational platform. The rest of our paper is organized as follows. In section 2 we present the syntax and an informal semantics of inheritance. We then present a formal modeltheoretic semantics of ORLog in section 3, an Herbrand semantics in section 4, a proof procedure in section 5, and nally a xpoint semantics in section 6. In section 6 we also prove that (i) the xpoint semantics and the modeltheoretic semantics are equivalent, and (ii) the proof theory is sound and complete with respect to this semantics. We compare our language with previous works in section 7, and give few critical comments. Furthermore, interested readers are referred to 16] for a detailed survey and an eloquent discussion on the issues related to logic based objectoriented languages. 2 Overview of ORLog
In this section we discuss the salient features of ORLog, its syntax and inheritance semantics using an example. We also discuss, on intuitive grounds, the concepts of clause locality and inheritability that are unique to ORLog. 2.1 Syntax
The alphabet of the language L of ORLog is a tuple hC ; V ; M; T ; Pi, where (1) C is a denumerable set of constants playing the role of basic values and also object id's, (2) V is an in nite set of variables, (3) an in nite set of method symbols M for method names, (4) T is an in nite set of symbols for type names, and nally (5) P is an in nite set of predicate symbols. The set of terms Io = C V are called the idterms. A method denotation is an expression of the form mk , where m is a method symbol, k is a natural 7! number and 7! is one of !; ! ; ), and ) 1. It says that m is a method of arity k ! ) and it takes on the incarnation !; ! ; ), or ) as indicated by 7!. Intuitively, ! and ! ) ! are used to denote data expressions and ) and ) are used for type or signature ! ) expressions, just as in Flogic. Throughout the paper we use the uppercase letters for variables and lowercase letters for constants. We use bold lowercase letters to denote arbitrary terms.
a distinction is not important, we shall also use the notations 7!s and 7!d to stand for an element in f); ) and f!; ! respectively. )g !g
1 When 3 2.1.1 Atomic and Complex Formulas
There are nine types of atomic formulas in ORLog. If ak s, p and q are idterms in Io, tis are type names in T , r is a predicate symbol of arity n in P , and mk is a method 7! denotation as de ned above, then the set of atomic formulas of ORLog is de ned as follows: 1. the idatoms are of the form p ] which assert the existence of objects or types; 2. the isa atoms are of the forms p : q and p :: q that state that object p is an instance or subclass of object q, where : (::) means immediate (transitive) instance/subclass; 3. the data atoms or datoms are of the form p m(a1; : : :; ak ) ! a] or p m(a1; : : :; ak )! b] which means when method m is invoked in the context of object p with ! arguments a1; : : : ; ak , it returns a functional output a, or similarly a set valued2 output of which b is a member; 4. the signature atoms or satoms are of the form p m(t1; : : :; tk ) ) ft01 : : : t0ng] or p m(t1; : : : ; tk ) ) ft01 : : : t0n g] which have a similar meaning as the datoms { when ) invoked in object p with argument types t1; : : :; tk , the method m returns an output (functional or set valued) which simultaneously belongs to the types ft01 : : :t0ng; 5. the locality atoms or latoms are of the form p mk ] which states that the data 7! or signature (as determined by whether 7! is one of !, ! or one of ), ) ) of ! ) method m whose (input) arity is k is locally de ned in object p; 6. the inheritability atoms or iatoms are of the form p [email protected] ] that speci es that the 7! object p may use (or inherit) the method mk from object q; 7! 7. the participation atoms or ratoms are of the form r t1; : : :; tn that states that r is a relationship (relation) involving object types t1; : : :; tn. 8. the predicate atoms or predatoms are of the form r(a1; : : :; an) whose meaning is exactly as in classical logic. 9. and nally, the withdrawal atoms3 or watoms are of the form p mk > q] and 7! k < q ] that captures the fact that the inheritance of the method mk is blocked p m7! 7! ( > ) from the object p to q, or is inhibited ( < ) in p from q. Blocking is used when a superclass prevents an immediate subclass/instance from inheriting a property,
2 Following Flogic, we also permit molecules as a syntactic abbreviation for conjunctions of atoms. E.g., p m1(a1; : : :; ak ) ! b1; : : : ; mn (c1; : : :; cm ) ! bn] p m1 (a1 ; : : :; ak ) ! b1 ]^ : : : ^ p mn (c1 ; : : :; cm ) ! bn]. Similarly, p m(a1 ; : : :; ak )! b1 : : : bng] !f p m(a1 ; : : :; ak )! b1 ] ^ : : : ^ ! p m(a1 ; : : :; ak )! bn ]. A di erence between a set valued method and a functional method is that ! we enforce functionality requirement for the latter but not for the former. 3 It turns out that one of blocking or inhibition is su cient for our purposes. However, we keep both the constructs for data modeling convenience. 4 whereas inhibition is used when a subclass/instance rejects the inheritance of a property from an immediate superclass. The formulas of L are de ned as usual. A literal is either an atom (A) or its negation (:A). Every literal is a well formed formula. If F and G are well formed formulas and X is a variable, then so are F ^ G, F _ G , :F , (F ), 8X (F ), 9X (F ), and F G . A formula that contains no variables is called a ground formula. We follow the standard practice in logic programming and consider only the de nite Horn clause fragment of our language for the rest of the paper. Hence clauses in an ORLog program are of the form A B1; : : : ; Bm, where A is called the head atom and Bis are called the body literals. We assume that all the clauses are universally quanti ed. If the head atom A of a clause A B1; : : : ; Bm is a d or satom, then we call it a d or sclause respectively. When convenient, we use the term property as a neutral term which refers to data or signature of methods. Thus, a propertyclause (pclause) is either a dclause or an sclause. Furthermore, in a pclause of the form o m(a1; : : : ; ak ) 7! a] B1; : : :; Bm, we refer to o as the descriptor, or the context, of the pclause. In an analogous way we de ne isa, l, id, i, r, pred and wclauses based on the head atoms of the form isa, l, id, i, r, pred and watoms respectively. Recall that variables and constants are written in upper and lowercase strings respectively. We use the letters O; P; Q; R (respectively, o; p; q; r or o; p; q; r) for variables (respectively constants, or arbitrary terms) representing object ids; m, s, t, u, v, etc. for method names, a; b; c; d; 1; 2; 3 for constants and basic values; W; X; Y; Z , etc. for variables; and so on. Programs in ORLog specify objects, their structures and behaviors through signature and method de nitions and organize objects in inheritance hierarchies through isa speci cations. Relationships among objects are speci ed using the relationships and predicates. De nition 2.1 (Programs) An ORLog program P is a triple of the form h ; ; i
where, is a (possibly empty) set of isa, l, id, and wclauses where the body literals are either isa, l, id, or watoms. is a (possibly empty) set of iclauses with body literals from isa, l, id, watoms or iatoms, and is a (possibly empty) set of p, pred and rclauses whose body literals are arbitrary atoms in L. 2 Note that in the above de nition, we have introduced an implicit dependency relation \(" such that ( and ( , which means that depends on and depends 5 on . The relation ( is actually a partial order. It should be clear that we do not allow, in particular, the isa hierarchy to depend on inheritability or properties of objects. This restriction helps make the isa hierarchy static and keep the inheritability of properties deterministic. On the other hand, this still allows a large class of meaningful programs. 2.2 Informal Semantics of Inheritance
The objects in our programs are described by a set of dclauses and a matching set of sclauses. Here, sclauses de ne method signature and dclauses de ne method behavior. Objects also inherit and reuse these descriptions (of structures and behaviors) with other objects that are de ned as their subclasses or instances, and they are subject to possible overriding by local de nitions. Consequently, the state of an object depends on the structure of the object hierarchy de ned using the isa de nitions. In our conceptual model, we identify two types of pclauses { local and inherited clauses. Intuitively, a pclause is local to an object o, if it is de ned in o. On the other hand a pclause de ning a method (data or signature) is inherited in o from q, if o does not de ne a similar pclause and q is an ancestor of o such that q de nes the pclause, and there is no other ancestor of o from which such a pclause is inheritable by o. The following de nitions make these notions precise: De nition 2.2 (Locality) Let cl be a pclause such that its descriptor is p, and r1]q1;
: : : rn ]qn are all the isa atoms4 in its body. Then cl is local to every object p such that r i ]q i holds for 1 i n. That is, p mk ] r 1]q 1 ; : : : r n ]qn holds. 2 7!
The notion of inherited clauses depends on the notion of inheritability of pclauses, de ned next. De nition 2.3 (Inheritability) Let S be a set of (ground) id, l, w, and isa atoms,
mk be a method denotation, and o be an object. Then the inheritability of mk in the 7! 7!
4 In this de nition and in the sequel of the paper ] stands for either \:" or \::" in places where the distinction between the two is unimportant. 6 object o is de ned by the context function r as follows: 8 > if o mk ] 62 S and 9q such that o : q 2 7! > > S; r(S; mk ; q) = p, p mk ] 2 S and (8r; such that > 7! 7! > > o : r 2 S; one of the following holds. >p > < k ; o) = r(S; mk ; r) = r, and r mk ] 62 S , or r(S; m7! 7! 7! > > r(S; mk ; r) = p, or o mk < r] 2 S , or 7! 7! > > r mk > o] 2 S .)] > 7! > > : o; in all other cases. 2 The operator r works as follows. Let o be any object and mk any method denotation. 7! k ; o) = p only if o :: p and p mk ], for some object p. Suppose o does not Then r(S; m7! 7! k , as indicated by the absence of an atom o mk ] have its own de nition of method m7! 7! k ] 2 S . Then in S . Also suppose for some superclass p of o (i.e., o :: p 2 S ), p m7! r(S; mk ; o) = p, provided o has an immediate superclass q (which is possibly p) which 7! inherits mk from p, and for every other immediate superclass r of o satis es one of the 7! conditions: (i) r inherits mk from p (same source), (ii) r does not have a local de nition 7! k (r mk ] 62 S ), neither does it inherit from any of its superclasses as indicated by of m7! 7! k ; r) = r, or nally (iii) either o inhibits mk from r, or r blocks mk for o. In r(S; m7! 7! 7! k ; o) = o, indicating either o has a local de nition of mk and all other cases, r(S; m7! 7! k , or it cannot legitimately inherit mk from any of overrides all other de nitions of m7! 7! its superclasses, if at all they exist and de ne such a method. It is possible to show that r is a total function. De nition 2.4 (Inherited Clauses) Let P = h ; ; i be a program, cl A G 2 be a pclause local to an object o, and let meth(A) = mk be a method denotation. Let 7! S be a set of ground isa, l, w and idatoms that are entailed by 5. Then cl is inheritable in an object q if r(S; mk ; q) = o. The inherited clause cl0 in q is obtained by 7! replacing every occurrence of o in cl by q, i.e., cl0 (A G ) o= ], where o= ] denotes =q =q the replacement of the term o by q. 2
We remark that context switch captured by the term replacement of the form % = fo= g =q should not be confused with the usual substitutions (e.g., = fX=pg) where only variables are replaced by terms. We next illustrate with couple of examples our notion our language, this set is always nite and entailment for this part is in the classical sense, as will be seen in Section 4. This set can be determined using classical proof theory or xpoint theory. We present the notion of inheritance here rather than in a later section, to give an intuitive feel for the semantics of inheritance, in advance. 5 For 7 tseat := firstclass + ecoclass tseat ecoclass := 300 inheritance conflict inherits firstclass := 50 noeng := 2 inherits (as a result) inherits noeng := 4 reject overrides firstclass := 25 p_craft
p_craft.noeng:int c_craft r_craft
md10 dc1030 b747 h333 tseat := 325 if inherits code for tseat tseat := 350 if inherits value for tseat l370 h50 Figure 1: An Aircraft Design Database Scheme. of behavioral inheritance (for code reuse) as well as indicate how the various notions developed above play a role in shaping the semantics of inheritance in ORLog. like scheme) in Figure 1. We use this example to intuitively understand the underlying meaning of ORLog programs in terms of the introduced concepts in this section in a close to real life application. In the next example we will explain the working of ORLog in greater detail with a more abstract application. In Figure 1, we abuse the OR notation and in most cases show the values and codes corresponding to methods in the scheme instead of their signatures for brevity and simplicity. The ORLog program P0 = h 0; 0; 0i6 corresponding to this scheme is given in Figure 2. In the diagram of gure 1, p craft, r craft and c craft refers to passenger aircraft, rescue aircraft and cargo aircraft respectively. In the diagram of Figure 1, the attribute rstclass in instance object md10 overrides the corresponding attribute value in its class p craft. Hence, the value of tseat (total
used molecular formula in this example a la 16] as follows: p craft crew ! 4; noeng ! 2] p craft crew ! 4] ^ p craft noeng ! 2].
6 We Example 2.1 Consider an aircraft design database scheme in OR notaion 12] (an ER 8 (1) (2) (3) (4) 0 := (5) (6) (7) (8) (9) md10 : p craft: r craft : p craft: r craft : c craft: h50 : r craft: l370 : r craft: h333 : c craft: dc1030 : p craft: b747 : p craft: 0 r craft noeng! < p craft]: 0 := ; (10) p craft ecoclass ! 300; firstclass ! 50; crew ! 4; noeng ! 2]: (11) p craft tseat ! T ] p craft ecoclass ! E ; 0 := firstclass ! F ]; T = E + F: (12) md10 firstclass ! 25]: (13) c craft noeng ! 4; tseat ! 4]: (14) X makeen ! p&h] X :: c craft: Figure 2: Example program P0 seats) at the p craft level is 350 while the value at md10 will be 325 since md10 inherits the code for tseat, not the value (350) from p craft. But dc1030, for example, will have 350 as the value for tseat since it inherits the value for rstclass and ecoclass from p craft and hence inheriting the code for tseat from p craft does not make any di erence even when the code is evaluated at the dc1030 level. Furthermore, since r craft inhibits noeng from p craft, noeng in c craft can now be inherited in r craft (and onward) since 0 r( 0]; noeng!; r craft) = c craft. Now the question is what P0 entails? Leaving the details to be explained in example 2.2, we expect the following from program P0 among several others. 1. 2. 3. 4. 5. h50 :: c craft p craft tseat ! 350] md10 ecoclass ! 300] { inherited from p craft. md10 tseat ! 325] { using inherited tseat code in p craft. h50 makeen ! p&h] { by deduction. It is interesting to observe how we expect md10 tseat ! 325] rather than md10 tseat ! 350] from program P0. Since r( 0]; tseat0 ; md10) = p craft, the code ! 9 for tseat0 is inheritable in md10. Then we have the clause ! md10 tseat ! T ] md10 ecoclass ! E ; firstclass ! F ]; T = E + F: p craft ecoclass ! E ; firstclass ! F ]; =md T = E + F:) p craft= 10] =md by context switching from p craft to md10 in rule 11 (i.e., apply p craft= 10]) as
(p craft tseat ! T ] which now correctly yields md10 tseat ! 325]. 2 r. Usually, the l and iclauses are not speci ed by the users. Rather the users implicitly assume the locality and inheritability of clauses according to the De nitions 2.2 and 2.4.
(1) (2) (3) 1 := (4) (5) (6) (7) Example 2.2 Consider the following program P1 = h 1; 1; 1i with objects o; p; q and o ]: q ]: q : o: p : o: r : p: r : q: r t0 < p]: ! 1 := ; (8) o m ! X ] o s ! X ]; o v ! g]: (9) o s ! 5]: (10) P u ! d] P : o: 1 := (11) p s ! 2]: (12) p t ! a]: (13) q t ! c]: (14) Q v ! g]: Figure 3: Example program P1 From De nition 2.2 it follows that clauses (8) and (9) are local to object o only. Similarly clauses (11) and (12) are local to p, and clause (13) is local to q only. However, clause (10) is local to p and q since these are the two objects P in P1 for which P : o holds true. Note that (10) is not local to o since o : o never holds in ORLog. In fact, it is local to only p and q. If we change P : o to P :: o in the body, then (10) becomes local to all four objects in P1 since :: is a partial order. Clause (14) is clearly local to all four objects. This is simply because the descriptor of (14) is a variable and is not constrained by any isa literal in the body. Clause (8) is inherited in p since p does not de ne m0 = meth(o m ! X ]). Similarly, ! (8) is inherited in q and r. However, clause (9) is only inherited in q since q does not de ne s0 whereas p has a local de nition for s0 , i.e., clause (11). It is interesting to ! ! note that neither clause (11) nor clause (9) is inherited in r. This is because r can access two distinct de nitions of s0 { the one in o and the one in p { via two nonoverlapping ! 10 paths. On the other hand, clause (13) is inherited in r since the de nition of t0 in p is ! inhibited by r through clause (7), and now there is a unique ancestor q of r that de nes t0 . ! The \intended" model of P1, formalized in section 4.3, is the one in which these de nitions of locality and inherited clauses are respected. Intuitively, (omitting some obvious atoms) we expect the \intended" model of program P1 to contain (among others) the following ground atoms. The complete intended model for the program P1 can be found in Example 4.1. fo ]; q ]; p : o; q : o; r : p; r : q; ; r :: o(for o = o; p; q; r); q u ! d]; o m ! 5]; o v ! g]; p m ! 2]; p s ! 2]; p t ! a]; p u ! d]; p v ! g]; q m ! 5]; q s ! 5]; q t ! c]; q v ! g]; r t ! c]; r v ! g]g. It is interesting to see how we expect p m ! 2] in p. Since clause (8) is inherited in p, it follows by De nition 2.4 that the inherited clause in p is (80) = (o m ! X ] o s ! X ]; o v ! g]:) o= ] = p m ! X ] p s ! X ]; p v ! g]: Since we have p s ! 2] =p in clause (11) and p v ! g] is an instance of clause (14), we now have p m ! 2]. In contrast, (8) inherited in q will become q m ! X ] q s ! X ]; q v ! g]: In a similar way we can show that q s ! 5] follows from clause (9). Hence, we have q m ! 5]. This is code reuse { the code for m0 in o is reused by p; q and r by dynamically interpreting ! the context o as \self", namely, the current context of the method. Nicely enough, we have overriding built into the de nition of inherited clauses. Notice that the code for m0 ! 0 in p, not the de nition of s0 in o. is evaluated in p using the de nition for s! ! We are now also able to resolve con icts in inheritance in two di erent ways { by detection and by preference speci cation. Observe that clauses (9) and (11) de ne s0 at both o and ! p. Let 1] denote the ground closure of 1. According to the de nition of r( 1]; s0 ; r), ! 0 in r is lost. Thus with r inherits neither since intuitively uniqueness of inheritance of s! respect to con ict resolution by detection, we take a conservative approach. In particular, even if p and q (or o in this case) de ne identical values for s0 , our semantics would reject ! both. This is a conservative approach and can be justi ed by the following facts. Methods are usually de ned using programs and are computed. Since testing for equivalence of programs in general is undecidable, we take the view that two de nitions in di erent classes are potentially con icting. Hence we reject all. For the sake of uniformity, we also take a similar view to a ground case, which is a special case of a method de ned via a unit ground atom. However, we go a step further to lend a hand to the users to indicate a preferred inheritance from a particular superclass. In this way, users may 11 resolve con icts using withdrawal. For example, although clauses (12) and (13) de ne method t0 at p and q, r inherits t0 from q by inhibiting t0 from p through clause (7). ! ! ! This is con ict resolution by preference speci cation, where the user has full control of how the con ict is to be resolved. 2 3 Interpretation Structures
A semantic structure S of the language L is a tuple of the form hD; O ; O ; Id; Is; L7!; C7!; W7! i, where D is the domain of interpretation, O is an irre exive binary relation among objects in D, O is a partial order among objects in D which is induced by O, and Id; Is; L7! ; C7!; W7! are interpretation functions that assign meaning to the symbols in L. Intuitively, D includes the objects and basic values needed to interpret the object identities and constants in L. The irre exive relation O is the semantic counterpart of the immediate isa association of objects. The partial order O is induced by the O relation since isa associations are also nontrivially implied by the immediate isa relation. Note that, for every object o in D, o O o trivially holds, but o O o does not. Thus, O is the re ective transitive closure of O . Formally, the domain D of the semantic structure S includes (i) a set of objects O, (ii) a set of elements B corresponding to basic values, and (iii) a set of elements, one each corresponding to each type name 2 T . For simplicity and clarity, we suppose that the set (iv) above is T itself. Clearly, there is no loss of generality in doing so. So we can suppose that D = B O T . Notice that D includes the domain of elements D corresponding to each type 2 T . In order to keep the semantics rstorder, we treat objects and classes as well as subclasses and instances in a uniform manner. Thus, an object could be viewed as an instance of its superclass object as well as a subclass of instances below it in the object hierarchy. This mirrors a standard trick in mathematical logic 10] which is adopted here in order to provide a rstorder semantics for a language which is syntactically higher order. Models such as \HigherOrder" logic 19] and (earlier) Flogic 16] follow a similar approach. We now de ne the interpretation functions of S . The function Id interprets each symbol in L as follows7:
that in what follows we use the notation A ; B ] and A 7! B ] to denote the set of all partial and total functions respectively from A to B .
7 Note Id associates each object id i in IO with a unique object in O.
12 Id maps each constant c of sort in C to an element of the corresponding basic domain D , i.e. Id(c) 2 D B. Each basic type name in TB is associated with a basic domain of the same type, and each constructed (object) type name is associated with an object o 2 O that encodes the domain of objects of type in O. That is, Id( ) = D B for 2 TB , and Id( ) = o 2 O for 2 TO , where o is the semantic counterpart of the object type8 . Each symbol r in P of type 1 : : : n is assigned a relation on D 1 : : : D , i.e. Id(r) D 1 : : : D . Each symbol m in M is associated with a set9 of partial functions of the form f : D 1 : : :D D 1 : : : D ; D 2D ], where there is exactly one such function in the set for a xed type associated with m. That is, 1 D ]]. Here Id(m) :::D D 1 ::: D ; D 2 k=1;j =0; D 1 o 2 TO ; i = 1; : : :; k and l 2 T , l = 0; : : : ; j , and o 2 TO .
n n o ok j o ok k i that we use object ids 2 TO IO to represent object types that are associated with their semantic counterpart { the actual object o 2 O that the id represents. It is useful to think of o as a concise representation of the domain corresponding to all its instances in the structure S . 9 Recall that each method has a set of types associated with it. 10In ORLog, we allow relations to have methods, or virtual attributes, as much the same way the objects do. This follows from the underlying semantic data model, the OR model, on which ORLog is based.
8 Note Note that the set of partial functions associated with m by Id relates m to a unique function for each type associated with m. This helps us overload method names and re ne them by allowing them to accept any number of arguments, and use di erent implementations for each type associated with the same method name. Furthermore, we also allow one function per type. For example, we can de ne a method child with a signature person child(year) ) fpersong] which refers to all the children of a person in a given year, and another method child with a signature person child(spouse) ) fpersong] refers to the set of children with a given spouse. (Here person is the context of the method.) Note that (i) for methods m de ned in objects the index k = 1 and D refers to the implicit argument (the object acting as the context for the method). (ii) for methods in relationships10, k 1 and in this case D 1 : : : D refers to the (explicit) key of the relation r of types 1 : : : k . In this case, the key acts as the context of the method. Also, note that a method may return a single or a set structured value, depending on its signature. We next consider the function Is.
ok o ok 13 Is acts as the identity function on each oid i 2 IO , i.e. Is(i) = i 2 TO . Each constant c in C is associated with its intended type, i.e, Is(c) = , for some type 2 TB . Is acts as the identity function on type names, i.e. Is( ) = ; 8 2 T . Each predicate symbol r 2 P is assigned its type, i.e, Is(r) 2 TOk , where k is the arity of r. Each symbol m in M is associated with a set of type tuples of the form < o1 , : : :, o o , 1 ; : : :; k ; ft1; : : : ; tn g >, which represent the (function) type o : : : j T k 2T ]. 1 1 ::: k ! ft1 ; : : :; tn g. That is, Is(m) j =1;k=0 TO
j j The functions L7! and L7! associate with each symbol m 2 M a set of partial functions of the form f : N ; 2O , where there is exactly one such function in the set for a xed arity associated with m, i.e., L7! : M ! N ; 2O ]. That is, L7! (m)(k) O, and similarly for L7! (m)(k) O. Here k is a natural number in N B and corresponds to an arity of the method m. Intuitively, it means that a method de nition (similarly a method signature) of arity k is locally available at each object o 2 L7! (m)(k) (similarly, o 2 L7! (m)(k)). The functions C7! and C7! associate with each method symbol m 2 M of arity k and object o 2 O, a unique object p 2 O. Formally C7! : M ! N ! O 7! O]], where each m is associated with a total function N ! O 7! O]. Intuitively, whenever C7!(m)(k)(o) = p, it says that object o may use the de nition or signature of m of arity k from the object p. We will later see that de ning suitable additional properties for these functions, it is possible to achieve con ict free inheritance of methods and signatures in the object hierarchies and to capture the semantics of withdrawal in a clean declarative manner. Finally, the functions W7! and W7! associate with each method symbol m 2 M of arity k and object o 2 O, a set of objects in O. Formally W7! : M ! N ! O ; 2O ]]. That is, whenever p 2 W7!(m)(k)(o), it means that method m (both data and signature) if de ned in the immediate superclass p of o, is withdrawn from o (for inheritance purposes). As a result o can not inherit this method from p. A variable assignment : V ! D is a function that assigns each basic domain variable X an element of B of appropriate sort, and assigns each id variable X an object from O. Variable assignments can be extended recursively to all formulas in the obvious manner. Let S be a semantic structure and be a variable assignment. An atom A in L is true
d s d s d s d s d s 14 under the semantic structure S with respect to the variable assignment , denoted S j= A, i S has an object, relationship, or a value with properties speci ed in (A). Formally: For an isa atom q :: p, S j= q :: p i (q) O (p). This says that object (q) is a subclass of object (p), equivalently an instance of (p), in the semantic structure S 11. For an isa atom q : p, S j= q : p i (q) O (p). This says that object (q) is an immediate subclass of object (p), equivalently an immediate instance of (p), in the semantic structure S . For a functional datom of the form p m(a1; : : : ; an) ! v], S j= p m(a1; : : :; an ) ! v ] i Id(m)( (p); (a1 ); : : :; (an )) = (v ). Similarly, for a setvalued datom of the form p m(a1; : : : ; an)! v1; : : :; vng], S j= p m(a1; : : : ; an )! !f ! fv1; : : :; vng] i fv1; : : : ; vn g Id(m)( (p); (a1); : : :; (an)). s For an satom of the form p m(t1; : : : ; tn )7! ftype1; : : :; typekg], S j= p m(t1; : : :; s tn)7! ftype1; : : :; typek g] i < (p); t1; : : :; tn; ftype1; : : :; typek g > 2 Is(m). For a patom r t1; : : :; tn, S j= r t1; : : : ; tn i r is a relation of type t1 : : : tn. For an latom of the form p mk ], S j= p mk ] i (p) 2 L7! (m)(k). 7! 7! For an iatom of the form p [email protected] ], S j= p [email protected] ] i C7! (m)(k)( (p)) = (o). 7! 7! For a watom of the form p mk < o] (or o mk > p]), S j= p mk < o] 7! 7! 7! k > p]) i (o) 2 W7! (m)(k )( (p)). (or S j= o m7! Satisfaction of complex formulas can be de ned inductively in terms of atomic satisfaction. Let and be any formulae. Then,  S j=  S j=  S j=  S j=  S j= S j= .  S j= (9X ) if for some that agrees with everywhere, except possibly on X , S j= .
11Recall the ^ i S j= and S j= . _ i S j= or S j= . : i S 6j= . i S 6j= or S j= (8X ) if for every that agrees with everywhere, except possibly on X , rstorder. dual treatment of instances and subclasses. This is important for keeping the semantics 15 Satisfaction of other formulae can be obviously derived from the above. If is a closed formula, its meaning is independent of a variable assignment, and its satisfaction in S can be simply written as S j= . Since our goal is to account for inheritance directly into the semantic structures of ORLog, we impose additional restrictions on our interpretation structures. It is essential that every ORLog structure assign unique inheritability of properties in the objects in the structure. We now de ne the concept of unique inheritability of properties in ORLog structures in the light of De nition 2.3. De nition 3.1 An ORLog structure S satis es unique inheritability property if the
following holds: For every o 2 O, method symbol m of arity k, the following condition is satis ed: if o 62 L7!(m)(k) & 9q such that o O q & C7!(m)(k)(q) = p & p 2 L7!(m)(k) & (for all other r 2 O: (o O r ! (C7!(m)(k)(r) = r & r 62 L7! (m)(k)), _ C7!(m)(k)(r) = p, _ o 2 W7!(m)(k)(r))) then C7!(m)(k)(o) = p. In all other cases C7! (m)(k)(o) = o. 2 The functions Id and Is in ORLog structures assign meaning to each symbol in the language independently of each other. Similarly the functions L7!; C7! and W7! assign meaning to symbols in isolation. For example, the data concepts into which symbols are interpreted by Id should be consistent with the types associated with these symbols by Is. Hence we require that every ORLog structure satisfy some goodness property to be a candidate for a meaningful structure. The following goodness properties enforce this consistency12. We say that an ORLog structure S is admissible if it satis es the following goodness properties. Id and Is satisfy the following properties: { For each constant c in C , Id(c) 2 Id(Is(c)), where = Is(c) is the type of c
and Id( ) = D is the domain of . That is, each constant is mapped to an element of a domain of its intended type.
our goodness conditions are reminiscent of the well typing conditions of Flogic 16]. However, since our language and semantic structure are quite di erent from those of Flogic, there are important di erences between the two sets of well typing conditions.
12Some of 16 p1; : : : ; pk ) is de ned, then (i) there is a type tuple of the form < o; 1; : : :; k ; ft1; : : : ; tlg >, in Is(m), where o is the type of the context o and i is the type of pi, i = 1; : : : ; k, and (ii) if m is a single valued method, then the value Id(m)(o; p1; : : :; pk ) belongs to all types in ft1; : : :; tng, and if m is a setvalued method, then all the values in Id(m)(o; p1; : : : ; pk ) belong to all types in ft1; : : : ; tng. { For each r in P , if the type of r is Is(r) =< 1; : : : ; n >, then Id(r) D 1 : : : D . If a structure S satis es a clause of the form p m(a1; : : : ak ) 7! a] r1]q1; : : :; r n ]q n ; G , where G is \isa free", i.e., S j= p m(a1 ; : : : ak ) 7! a] r 1 ]q 1 ; : : :; r n ]q n ; G then we require that S j= p mk ] r 1 ]q 1; : : : ; rn ]q n also. 7! For every object o 2 O and method denotation mk , C7! de nes inheritability of 7! mk in o and satis es the unique inheritability property as de ned in De nition 3.1. 7! For every o; m; k and p, o 2 W7!(m)(k)(p) implies o O p.
n { For a method m, an object o 2 O, and elements p1; : : : ; pk 2 D, if Id(m)(o; ORLog structures also satisfy clauses due to structural and behavioral inheritance in a nontrivial and unique way. To this end, we require that every admissible ORLog structure also satisfy the following closure condition: De nition 3.2 An admissible ORLog structure is inheritance closed, or iclosed, if the
following holds. For any clause p m(a1; : : :; ak ) 7! a] G, if S j= p m(a1; : : :; ak ) 7! a] G and S j= o [email protected] ], 7! then S j= (p m(a1; : : : ; ak ) 7! a] G) p= o], where p= o] is a clausewise = = context substitution that replaces every occurrence of p by o. 2 4 Model Theoretic Semantics
We now develop an Herbrand semantics for our language and introduce the notions of satisfaction and models. Given an ORLog language L, the Herbrand universe U of L is the set of all ground idterms { in our case just the individual constants. The Herbrand base H of L is the set of all ground atoms that can be built from U and the vocabulary of L. Let H denote the set of id, r, l, isa and watoms, H denote the set of iatoms, 17 and nally H denote the set of pred, r and patoms (i.e., datoms and satoms) in H such that H = H H H . An Herbrand structure H of L is a triple hH ; H ; H i, where H H , H H , and H H . 4.1 Canonical Models
Ground instances of formulas are de ned as in the classical case. We de ne satisfaction in a manner identical to the classical case. De nition 4.1 (Herbrand Structures) Let H be an Herbrand structure. Then
a ground atom, A, is true in H, denoted H j= A, i A 2 H13; a ground negative literal, :A, is true in H, denoted H j= :A, i A 62 H; a ground conjunction of literals is true in H, denoted H j= B1 ^ : : : ^ Bm, i H j= Bi; i = 1; : : : ; m; a ground clause cl is true in H, denoted H j= A G, i H j= G =) H j= A; and a clause cl is true in H i all ground instances of cl are true in H. 2 To account for the notion of inheritance outlined in the Example 2.2, we require that every Herbrand structure be \proper" in the sense of De nition 4.2 below.
proper i it satis es the following properties, where o; p; q; r; tis are arbitrary ground idterms, m is any method symbol. De nition 4.2 (Proper Structures) An Herbrand structure H of ORLog is called
1. o mk ] 2 H =) o :: o 2 H . Also p : o 2 H =) o :: o 2 H , and o : p 2 H =) 7! o :: o 2 H . 2. o : q 2 H and q :: p 2 H =) o :: p 2 H . 3. Whenever H satis es a ground pclause o m(t1; : : : ; tk) 7! t] r1]q1; : : : ; rn]qn; G, where G is \isa free", we require that H also satisfy the ground lclause o mk ] 7! r1]q1; : : :; rn ]qn. 4. o mk > p] 2 H =) o mk > p] 2 H . Similarly, o mk < p] 2 H =) 7! 7! 7! k < p] 2 H . o m7! 5. Nothing else is in H . 13An atom A is in H i A is either in H , H or H .
s d s d 18 6. Whenever (i) p mk ] 2 H , (ii) for some o, o :: p 2 H , and (iii) r(H ; mk ; o) = p, 7! 7! k ]2H . we have o [email protected]! 7. Whenever H satis es a ground pclause cl = o m(t1; : : : ; tk) 7! t] G and k ] 2 H , we require that H also satisfy the ground pclause p [email protected]! cl0 = (o m(t1; : : :; tk ) 7! t] G ) o= ], which denotes the clause obtained from =p cl by replacing every occurrence of o by p. (See also De nition 2.4.) 2 The purpose of a proper structure is intuitive and is a modeltheoretic counterpart of the informal semantics of inheritance we discussed earlier. Conditions (1)(2) establish \::" as the re exive transitive closure of \:". Condition (3) says whenever H satis es a ground pclause, it also asserts the locality of the pclause. (4) and (5) say signature withdrawal implies withdrawal of the corresponding method. (6) says the inheritability as de ned by the operator r (see De nition 2.3) must be respected. (7) correctly enforces what it means for a structure to respect behavioral inheritance. This is accomplished by the context switch o= ]. =p In practice, as in the case of Flogic, we only want those models of a program where the method data respects the signature de nitions associated with that method. This notion of \welltyping" is left outside the proof theory again as in Flogic, but can be dealt with using an approach similar to that adopted in 16]. We do not elaborate on this issue further here, as our main interest here is in inheritance. De nition 4.3 (Proper Models) An Herbrand structure M is a proper model of a program P i it is proper and for every ground instance cl of any clause Cl 2 P, M j= cl.
2 De nition 4.4 (Local Properness of Models) Let P be a program and M be any model such that M = hM ; M ; M i. Then M is locally proper if it satis es conditions (1) through (5) of de nition 4.2. Likewise, M and M are locally proper if they satisfy condition (6) and (7) of de nition 4.2 respectively. Furthermore, M is proper, if M ; M , and M are locally proper. 2
However, not every proper model is an \intended" model. An intended model must respect certain consistency criteria. These are formalized below. In De nition 4.5 below and the sequel, we treat equality as syntactic identity.
heritance consistent, or iconsistent, i the following conditions are satis ed: De nition 4.5 (Iconsistent and Canonical Models) A proper structure M is in19 Object o Object p immediate isa p:o transitive isa o :: o p :: p; p :: o
locality inheritability withdrawal data Object q q:o q :: q; q :: o o m 0 ; s0 ; p s 0 ; t0 ; q t 0 ; u0 ; !! !! !! 0] 0 ; v0 ] 0 v! u! ! v! ] o [email protected] ; p [email protected] ; q [email protected] ; r [email protected] ; ! ! ! ! 0; 0 ; [email protected] ; 0 ; q @t0 ; [email protected]! [email protected]! ! [email protected]! ! [email protected] ; ! 0 0 0 0 [email protected]! ] [email protected] ; [email protected]!] [email protected] ; [email protected]!] [email protected]!] ! ! r t0 < p] ! o m ! 5; p m ! 2; s ! 2; q m ! 5; s ! 5; r t ! c; s ! 5; t ! a; u ! d; t ! c; u ! d; v ! g] v ! g] v ! g] v ! g] Object r r : p; r : q r :: r; r :: p; r :: q; r :: o 0 r v! ] Figure 4: Intended model M1 for the example program P1. 1. o :: p 2 M and p :: o 2 M =) o = p { no cycles in object hierarchy. 2. o [email protected] ] 2 M and o mk ] 2 M =) p = o { overriding is respected. 7! 7! 3. o m(a1; : : :; ak ) ! v] 2 M and o m(a1; : : : ; ak ) ! w] 2 M =) v = w { functionality of methods is not violated. 4. o [email protected] ] 2 M and o [email protected] ] 2 M =) p = r { uniqueness of inheritability is 7! 7! respected. A canonical model of a program P is a model of P that is iconsistent as an Herbrand structure. 2 A program is iconsistent if it has a canonical model. In the sequel we only consider iconsistent programs. formally captures the ideas informally discussed in Example 2.2 concerning locality and inheritability. We shall see later in section 4.3 that MP1 above is indeed the intended model of P1, in a sense to be made precise (see also Example 2.2). Example 4.1 The table below in gure 4.1 shows a canonical model MP1 of the program 0 P1 of Example 2.2, where we use molecular abbreviations like o m0 ; s0 ; v!] o m0 ] ^ ! !! 0 o s0 ] ^ o v!], o m ! 5; s ! 5] o m ! 5] ^ o s ! 5], etc. The model MP1 below ! 20 4.2 Correspondence between Herbrand Structures and ORLog Structures
The correspondence between Herbrand structures and general ORLog structures can be stated in a way similar to 16] as follows : Given a general structure for a set of clauses S, the corresponding Herbrand structure is the set of ground atoms that are true in the general structure. Conversely, for an Herbrand structure, H, the corresponding general ORLog structure, IH = hD; O ; O; Is; Id; L7! ; C7!; W7!i, is de ned as follows: The domain D is identical to U . The orderings O and O are derived from the transitive and immediate isa assertions in H : For all p; q 2 D, we assert q O p i q :: p 2 H , and q O p i q:p2H . ( s ftg if o m(t1; : : : ; tk)7!t] 2 H Is(m)(o; t1; : : :; tk ) = unde ned otherwise ( t if o m(t1; Id(m)(o; t1; : : :; tk ) = unde ned otherwise: : :; tk ) ! t] 2 H ( ! Id(m)(o; t1; : : :; tk ) = ftg ned if o m(t1; : : :; tk )! t] 2 H unde otherwise L7!(m)(k) = ffog j o mk ] 2 H g: 7! C7!(m)(k)(o) = fp j o [email protected] ] 2 H g: 7! k < p] 2 H or p mk > o] 2 H g. W7!(m)(k)(o) = ffpg j o m7! 7! It is easy to see that IH = hD; O ; O; Is; Id; L7!; C7!; W7!i is wellde ned and is indeed an ORLog structure. The following proposition, adapted from 16], follows from the above correspondence between the two structures. The proof for this proposition is similar to the corresponding proof in 16] and hence omitted. Proposition 4.1 Let S be a set of clauses. Then S is unsatis able i S has no Herbrand
model.
Proof: It is easy to verify that for every Herbrand structure H, the entailment H j= S takes place if and only if IH j= S, where IH is the ORLog structure corresponding to H as de ned above. 2 21 4.3 Intended Models
We de ne the declarative semantics of an ORLog program P as the least canonical model MP of P. An ordering relation v over Herbrand structures can be derived from the partial order (set inclusion) as in the classical case. For any program P, if I1 = hI1 ; I1 ; I1 i and I2 = hI2 ; I2 ; I2 i are two structures, then I1 v I2 () I1 I2 ; I1 I2 ; I1 I2 Consequently, for every program, the set of associated structures P (H) is a complete lattice L with join and meet operators de ned respectively as follows. (join) I1 t I2 = hI1 I2 ; I1 I2 ; I1 I2 i (meet) I1 u I2 = hI1 \ I2 ; I1 \ I2 ; I1 \ I2 i I? = h;; ;; ;i and I> = hH ; H ; H i denote respectively the bottom and top elements of this lattice. I> may be veri ed to be a proper model (see De nition 4.3) of any iconsistent program. However, it is not necessarily an iconsistent model itself (see De nition 4.5) and hence not canonical. Clearly, our interest is only in canonical models of programs. First we show that the model intersection property holds for proper models. as well. We prove this proposition in two steps. M1 u M2 is a Model: If cl is a unit clause, then it must be the case that cl 2 (M1 u M2) since Mi j= cl =) cl 2 Mi, for i = 1; 2. Hence the claim follows immediately. If cl is a clause of the form A G , then the implications Mi j= G =) Mi j= A, for i = 1; 2 hold true by hypothesis. We then proceed by induction on the structure of G . Basis: If G is atomic, then Mi j= G =) G 2 Mi, for i = 1; 2, and the proof is identical as for the unit clause case. Inductive Step: Assume that the claim holds true for any goal G. Consider now that G 0 = G 1; G 2, and assume that Mi j= G 0 holds for i = 1; 2. Then by de nition Mi j= G1 and Mi j= G2, i = 1; 2. This implies that G1 2 Mi and G 2 2 Mi, i = 1; 2. Then by inductive hypothesis (M1 u M2) j= G1 and (M1 u M2) j= G 2 =) (M1 u M2) j= G 1; G 2. 22 Theorem 4.1 (Model Intersection Property) Let M1 and M2 be two proper models of a program P. Then M1 u M2 is also a proper model of P. Proof: We show that for any ground clause cl, if M1 j= cl and M2 j= cl, then M1 u M2 j= cl, and that if M1 u M2 is not proper then either M1 or M2 is not proper Properness of M1 u M2 : Observe that a canonical model is always proper but the converse is not always true. Hence a proper model M corresponding to a program P is not required to be consistent. By de nition 4.2, properness of M only ensures (i) the partial ordering of the isa hierarchy, (ii) locality of pclauses, (iii) withdrawals implied by P, (iv) minimality of M , (v) exact inheritability of pclauses implied by the program and nally (vi) inheritance of pclauses captured by the inheritability assertions in (iv). Note that for any program P, and for any two proper models M1 and M2 of P, M1 = M2 holds true by condition (5) of de nition 4.2. From the minimality of M , the property of inheritability function r, and the condition (6) of proper structures, it follows that every proper model of P, M to be precise, satis es a minimum set of iatoms depending on the M component of the model that is common to every proper model of P. Now since M1 and M2 are two proper models by hypothesis, then M1 = M2 . Let us assume that M1 u M2 is not proper. Then there are three possible cases: either (i) M1 \ M2 , (ii) M1 \ M2 , or (iii) M1 \ M2 is not locally proper. Case (i): Assume (M1 u M2) = M1 \ M2 is not locally proper. Note that from condition (5) of de nition 4.2, M1 \ M2 = M1 = M2 . It can now be veri ed that (M1 u M2) satis es each of the conditions (1) through (5) of de nition 4.2, and hence is locally proper. Case (ii): Assume that (M1 u M2) = M1 \ M2 is not locally proper. Then it must be the case that for some objects o and p, and a method denotation mk , either 7! k ; o) = p, and o [email protected] ] 2 M but o [email protected] ] 62 M \ M , or (ii) (i) r(M1 ; m7! 1 2 1 7! 7! k ; o) = p, and o [email protected] ] 2 M2 but o [email protected] ] 62 M1 \ M2 . But this is r(M2 ; m7! 7! 7! not possible since M1 = M2 , and for objects o and p, and method denotation mk , 7! k ; o) = r(M2 ; mk ; o) = p, and o [email protected] ] must be in both M1 and M2 , r(M1 ; m7! 7! 7! hence in M1 \ M2 making M1 \ M2 a proper model. A contradiction. Case (iii): Suppose (M1 u M2) = M1 \ M2 is not locally proper, i.e., it violates condition (7) of de nition 4.2. So, let M1 \ M2 satisfy a ground pclause cl = o m(t1; : : :; tk ) 7! t] G and suppose that p [email protected] ] 2 M1 \ M2 but 7! M1 \ M2 6j= cl o==p]. This implies that Mi j= cl, and p [email protected] ] 2 Mi , i = 7! 1; 2. By the properness of Mi, we also have Mi j= cl o= ], i = 1; 2, which implies =p M1 \ M2 j= cl o==p], contradicting the above. 2 23 We have already seen that every program has at least one proper model, namely I>. In view of Theorem 4.1, we can conclude that every program P has also a least proper model de ned as MP = ufM j M is a proper model of Pg. But what can we say about canonical models of P, since we would like to declare the intended meaning of a program as its least canonical model? The answer is given in Theorem 4.2. Theorem 4.2 Let P be an iconsistent program and M be its least proper model. Then M is iconsistent. Furthermore, M is the least canonical model of P. Proof: Let P be an iconsistent program, and M be its least proper model. First, recall that every canonical model, by de nition, is proper. This implies, for every ground atom A 2 M , A is in every proper model of P, and hence in every canonical model of P. Let N be any canonical model. The above argument shows that M N. This implies that M is canonical, since no superset of an iinconsistent model can be iconsistent. Since M is included in every canonical model, it follows that M is the least canonical model of P. 2 From Theorem 4.2, it follows that every iconsistent program P has a least canonical model MP. We call MP the intended model of P and say that the declarative semantics of a program is given by its intended model. It can be veri ed that the canonical model MP1 in Example 4.1 is the intended model of P1. provided they have the same class of canonical models. De nition 4.6 (Logical Entailment) Let P be an ORLog program and A any ground atom. We say that P logically implies A, denoted P j= A, provided A is true in every canonical model of A. We say that two ORLog programs P1 and P2 are equivalent
2 5 Proof Theory
In this section, we develop a proof theory for ORLog and establish that it is sound and complete with respect to the intended model semantics developed in Section 4. Intuitively, our approach to proof theory is summarized by saying that we precompute the \closure" (see De nition 5.1 for a formal de nition) of an ORLog program P with respect to the set of all isa, l, w, id and iatoms that are entailed by P in the sense of De nition 4.6. The rationale for this approach is as follows. (1) We can show that a program is equivalent to its closure. (2) Because of the separation between the , and components of a program, and the static nature of the isa hierarchy, the closure of an ORLog program can 24 be e ectively precomputed. (3) This approach makes the determination of inheritability simpler, and helps keep the proof theory modular and cleaner. Besides, we are able to ensure that the inheritability is deterministic. 5.1 Closure of a Program
Let P = h ; ; i be a de nite ORLog program. We rst de ne a preclosure of P = h ; ; i as follows. Recall that the locality of clauses is not usually supplied by the programmers. By taking the preclosure, we account for the locality of clauses in P. The preclosure of a program P is the smallest set of clauses P satisfying P P , and the conditions below. 1. ;=;=. 2. Whenever a pclause p m(a1; : : : ; ak ) 7! a] r1]q1; : : : ; rn ]qn; G 2 is \isa free", we have p mk ] r1]q1; : : :; rn]qn 2 . 7! k > q] G 2 =) p mk > q] G 2 . 3. p m7! 7! 4. p mk < q] G 2 =) p mk < q] G 2 . 7! 7! k]2 . 5. P :: P P m7! 6. P :: P P : Q 2 . 7. P :: P Q : P 2 . 8. P :: Q P : R; R :: Q 2 .
s d s d , where G For a set of clauses , we let ] denote its ground closure, which is the set of ground atoms derivable in the classical sense from its Herbrand instantiation. Let P = h ; ; i be the closure of a program P and let Pg = h ]; ]; i. It is important to note here that we do not require a ground closure of the component of P , which presumably is the largest component of P . We refer to Pg as the partial ground closure of P . Finally, the closure Pc of a program P is obtained from Pg by applying the operator r as follows. 1. c = ]; c ] and c = . k ] 2 c and p :: o 2 c , r( c; mk ; p) = o =) p [email protected] ] 2 2. for every o m7! 7! 7! 3. Nothing else is in c. Theorem 5.1 below establishes that a program is equivalent to its closure. 25
c. equivalent. Proof: We show that an Herbrand structure is a proper model of P i it is a proper model of Pc by showing that there is a oneone relationship between the conditions that an Herbrand structure must satisfy to be proper and the axioms in the set (Pc ? P). Conditions (1) through (4) in de nition 4.2 are satis ed by an Herbrand model M of a program P i M satis es the rules (1) through (8) that are added to the preclosure of P. Rules (9) and (10) added to the closure of P exactly capture condition (6) of de nition 4.2. Since and are logically equivalent, in the sense that considered as programs by themselves, their classes of (classical) Herbrand models are the same, the operator r behaves identically on and . From this, it follows that P and Pc have the same classes of proper models, which implies the theorem. 2 Theorem 5.1 Let P be a program, Pc be its closure. Then P and Pc are logically 5.2 Proof Rules
In this section we develop a goal directed sequent style proof system for ORLog programs. We adopt this style along the lines of 21, 22]. In gure 5.2 below, we present four inference rules which de ne the properties of the proof predicate `. We use the notation Pc ` G to represent the fact that the goal G is derivable from the closed program Pc with a substitution14 , i.e., Pc ` G . Following 22], the structure of the proof rules are as shown below where we read them from bottom up. Note that the application of a proof rule is contingent upon the satisfaction of the conditions speci ed at the right hand side of each rule. The following are the inference gures or proof rules for ORLog. We use , , etc. to represent most general uni ers, and to represent the empty substitution. 2 denotes the empty goal, which is always true. Our proof theory consists of four inference rules { empty, and, deduction and inheritance. For the sake of clarity, we present the rst three inference rules rst and explain their intuition and our conventions. Then, we present the last inference rule. As in 21], a proof for Pc ` G is a tree rooted at Pc ` G with internal nodes that are instances of one of the four inference rules and with the leaf nodes that are labelled with the gure empty. The height of a proof is the maximum of the number of nodes in all the branches in the proof tree, and the size of a proof is the number of nodes in the proof
classical notions of substitution and uni cation can be adapted to ORLog with minor modi cations.
14The 26 (empty) (and) (deduction)
P P c` 2 c` G 1 Pc ` G 2 ] Pc ` G1 ^ G2
P c` Pc ` G] A C = A0 G 2 P c ; = mgu(A; A0) ! Figure 5: Classical inference rules. tree. The interpretation of the provability relation ` is straightforward. The rst three rules capture the operational semantics of classical logic with the only di erence that our language has a di erent syntax, and an elaborate set of atoms. The rule empty says that the empty goal can be proved with the empty substitution. The rule and for conjunctive goal is intuitive: to prove G 1; G 2, we have to prove G1 and G 2 from left to right as in Prolog. The rule deduction for logical inference (or backchaining) is as expected. To prove A, we need to prove the body G of a clause A0 G such that A and A0 unify with . In this context, we would like to make the following remark about the composition of substitutions in our proof rules. Consider, for example, the deduction rule. Initially the lower sequent is Pc ` A that states that A is derivable from Pc. Now to prove A from the clause A0 G , we incur a substitution on A through which A and A0 unify. Then we are left to prove G , since should be applied to the body as well. To prove G we may similarly incur another substitution . Note that similar to classical logic it is customary that A must inherit the substitutions that are applied to G at a later proof. Thus must be applied to A after we apply since was incurred rst. This explains our convention of right composing the substitutions in the proof rules. We denote by the composition of substitutions with as de ned in 18]. Finally, the rule inheritance below is unique to ORLog. This rule accounts for the structural and behavioral inheritance in our language. The key idea is that to prove a ground pgoal (a patom) of the form o m(a1; : : : ; ak) 7! a] via inheritance, we must nd a unit iclause o [email protected] ] in Pc and a pclause cl such that cl de nes mk at p. Then we 7! 7! apply a clausewise term replacement fp= g and prove the body of the clause. Note that, =o the term replacement fp= g captures the idea of context switching which is central to the =o realization of code reuse in ORLog. This is the basic idea. However, it is cumbersome and ine cient to force inheritance to the ground level. Consequently, our inheritance 27 0 o0 [email protected] ] 2 ; 1 c 7! B p m(a01; : : :; a0k ) 7! a0] G 2 c; C B = mgu(o; o0); = mgu(p0 ]; p); C B C Pc ` G % ] B % = fp ==o g; C (inheritance) P ` B C o m(a1; : : :; ak ) 7! a] B c @ = mgu(< o; a ; : : :; a ; a > ]; C A
< p; a01; : : :; a0k ; a0 > %])
1 k Figure 6: Inheritance rule of ORLog. inference rule in gure 5.2 below incorporates this idea on general (nonground) pclauses, by using the context switch judiciously. Recall that % = fp = o g is a term replacement implementing context switching, not = a substitution. The way this inference rule works is as follows. In order to prove a patom, determine by looking in the closure Pc where the descriptor of the patom is supposed to inherit the property from. Once this is established, locate any clause de ning this property at the source of the inheritance, and prove the body of this clause after performing the appropriate context switch (%). All this is accomplished modulo uni cation since we are dealing with nonground clauses. Below is an example of a proof using our proof theory. Example 5.1 Revisit Example 2.2. Let us add the isa de nition k : p as clause (15): k : p then belongs in the component 1 in program P1 of Example 2.2. Let P1 be the closure of P1. Now consider proving the goal k m ! W ] from the program P1 using the proof rules above. A proof tree corresponding to P1 ` k m ! W ] is given below where % is the context switch as shown. The proof returns the answer substitution fW=2g.
c c c (empty) (empty) " # " # P1c ` 2 (deduc) (14), (inherit) (9), = fQ=kg %2 = fp==kg P1c `fQ=k g k v ! g ] P1c `fX=2g k s ! X ] ] (and) # " P1c `fQ=k gfX=2g k s ! X ]; k v ! g ] (inheritance) (8), %1 = fo==kg P1c `fW=X gfQ=k gfX=2g k m ! W ]
Pc 1 `2 6 Fixpoint Semantics
We now de ne a constructive way of de ning the least model for a program P. Notice that in any ORLog program P = h ; ; i, there is an implicit strati cation among its 28 components. Namely, for a program P = h ; ; i, the dependencies ( , and ( hold, as stated in De nition 2.1. Note that to compute inheritability of property clauses, as required by the algorithm for r, we need to have a complete knowledge of the object hierarchy and the locality of clauses de ned in program P. These observations and the depends on relation \(" suggest a way of constructing a model for any program P in general. We can compute a \local model" M for the component , and then compute another local model for M for the component from the \local program" M . This approach will give us the required knowledge for computing inheritability of pclauses. The closure Pc of a program P embodies the knowledge required for this purpose. Because of this and since Pc is equivalent to P, we base our xpoint theory on the closed program Pc . We have already established that every ORLog program P has a unique intended model MP which is obtained as the intersection of all proper models of P. Recall that MP is always canonical (see Theorem 4.1 and Theorem 4.2). We will show in this section that it is possible to obtain the intended model MP of a program P (which by Theorem 4.2 is the same as the intended model MP of the closure Pc of P), by means of a bottomup least xpoint computation, based on the immediate consequence operator TP , de ned below.
c c De nition 6.1 Let Pc be the closure of a de nite ORLog program and let c Pc = h cc ; cc; cci be its Herbrand instantiation de ned as usual. Let I be an Herbrand structure for Pc. We de ne TP to be the immediate consequence operator that transforms Herbrand structures to Herbrand structures, i.e., TP : P (H) 7! P (H), such
c that c TP (I ) = fo m(a1; : : :; ak ) 7! a] o==p] j o m(a1; : : : ; ak) 7! a] B 2 cc; p [email protected] ] 2 I; I j= B o= ]g fA j A B 2 cc; I j= Bg =p 7!
c Furthermore, since ORLog captures (multiple) inheritance with overriding, not surprisingly, the operator TP is not monotone in general, as suggested by the following example.
c Example 6.1 Let P2 = h 2; 2; 2i be a program such that
(1) p :: p: 2 := (2) o :: o: (3) q :: q:
2 := ; 29 2 := (4) p m ! a]: Now, consider two interpretations I1 and I2 such that I1 = fp :: p; o :: o; q :: q; o : pg I2 = I1 t fo : qg
While o m ! a] 2 TP (I1); o m ! a] 62 TP (I2). So, in general, TP is not monotone. 2 c c c Thus a fundamental challenge is, how can we build a \ xpoint semantics" using an operator that is not monotone. The following lemma is important in this respect. Lemma 6.1 Suppose I1 v I2 and furthermore, (i) (I1) = (I2) , (ii) (I1) = (I2) , and (iii) both I1 and I2 satisfy all the clauses in (Pc) (Pc ) . Then TP (I1) v TP (I2).
c c Proof: The proof is almost identical to the classical case. The only observation required are: (1) since I1 and I2 agree on their and components and since they satisfy the and components of Pc , (a) the operator r will behave identically with respect to I1 and I2, and (b) all atoms in TP (I1) ? I1 (as also those in TP (I2) ? I2) are p, pred, and ratoms. (2) Whenever I1 j= F o= ], we have I2 j= F o= ] for any formula F , since =p =p I1 v I 2 . 2
c c hierarchy and inheritability requirements of Pc and are in agreement in this regard, TP is indeed a monotone operator. This result is signi cant since TP "1=def TP (TP "0) = TP (;), satis es all the and clauses in Pc and furthermore 8n > 1 : (TP "n) = (TP "1) and (TP "n ) = (TP "1) . The latter simply follows from the de nition of Pc and of TP . This suggests the iterative applications of TP on TP "1 will indeed produce a monotonically increasing sequence of interpretations suggesting some hope of reaching a xpoint. The monotonicity of TP on the above class of interpretations guarantees the existence of a xpoint. Now we have the following theorems that establish the equivalence of the model theoretic and the xpoint theoretic semantics.
c c c c c c c c c c c c c Remarks: Lemma 6.1 simply says that on the class of interpretations which satisfy the isa Proposition 6.1 Let I1; I2; : : : be an in nite directed sequence of interpretations such that I1 v I2 v : : :. Then if t1 Ii j= G, then 9k Ik j= G . i=1 Proof: We proceed by inducing on the structure of the goal G .
30 Basis: If G is atomic, then t1 Ii j= G if and only if G 2 t1 Ii . Therefore, there exists i=1 i=1 a k such that G 2 Ik and then Ik j= G . Inductive step: Assume that the claim is true for any ground goal G. Now consider a goal G 0 = G 1; G2. By inductive hypothesis there exists k1 and k2 such that Ik1 j= G1 and Ik2 j= G 2. Now by choosing k = max(k1; k2), it follows that Ik j= G1 and Ik j= G 2, and therefore Ik j= G1; G2. 2 proper as a structure. Proof: We show implications in both directions. ): Suppose I is a proper model of P. Then by theorem 5.1, I is a proper model of Pc. Since I , being proper, satis es condition (7) of de nition 3.2, it immediately implies that TP (I ) v I . (I ) and (: Suppose TP (I ) v I and I is a proper structure. Since (Pc) (Pc ) (I ) , I satis es the and clauses in Pc . That it also satis es the p, rand predclauses follows from the de nition of TP and of satisfaction. Notice that since (Pc ) (I ) and (Pc ) (I ) , all the atoms in TP (I ) are p, r and predatoms. An inspection of the conditions (1) through (7) in de nition 4.2 of proper structures 2 immediately reveals that TP (I ) is proper as long as I is.
c c c c c Theorem 6.1 Let P be a program, Pc be its closure, and I be a structure such that (Pc ) (I ) and (Pc) (I ) . Then I is a proper model of P i TP (I ) v I , and I is
c The bottomup xpoint iteration of TP is de ned as follows:
c TP "0 = I? TP "n+1 = TP (TP "n ) TP "! = tn<! TP "n :
c c c c c c Note that owing to the monotonicity of TP it has a least xpoint lfp(TP ) and since ORLog is functionfree, we trivially have lfp(TP ) = TP "! . One of our main results is the following theorem, proved analogously to the classical case. The only subtlety is handling clause inheritance via context switch.
c c c c Theorem 6.2 Let P be a program and Pc be its closure. Then,
1. MP = MP = lfp(TP ), where MP = MP is the least proper model of P, and
c c c 31 2. lfp(TP ) can be computed in a nite number of bottomup iterations.
c Proof: (1). MP = ufI j I is a proper Herbrand model of Pc g;
c by Theorem 4.1 Note that whenever I is a (proper) model of P (and hence of Pc ), (Pc) (Pc ) (I ) . From this, we can see that (I ) and MP = ufM j M is a proper model of Pc g = ufM j TP (M) v M; M is proper and (Pc)
c c c c by proposition 6.1 = lfp(TP ); by the monotonicity of TP on the class of Pc satisfying the conditions in Lemma 6.1, and KnasterTarski xpoint theorem, proving (1) (I ) , (Pc ) (I ) g, (2). Since ORLog programs are function free, the least xpoint above can be computed in a nite number of steps, just as for Datalog, which proves (2). 2 Observation 6.1 Let P be an iconsistent program and Pc be its closure. Then MP = MP = lfp(TP ) = TP "! is the intended model of P. 2
c c c Theorem 6.2 establishes the equivalence between the declarative semantics based on intended models and the xpoint semantics based on the least xpoint of the operator TP . It remains to establish their equivalence to the prooftheoretic semantics given in Section 5. As in the classical case, we accomplish this by relating the stage of a ground atom A { the smallest number of iteration k such that A 2 TP "k { to the height of a proof tree for an atom more general than A.
c c c Theorem 6.3 (Soundness) Let Pc be a closed program, Pc be the Herbrand instantib ation of Pc , G be an atomic p, r or predgoal, and G be all the ground instances of G. d If Pc ` G is provable then 9k such that G v TP "k .
c 32 (ii) non pgoals (pred and rgoals). Note inheritance only applies to pgoals. Basis: Suppose the proof tree has height 1. Then there are two possible cases { (i) either G is a pclause local to some object, a predclause or an rclause, or it is an inherited pclause in some object from another object where it is local. Case 1: There exists a unit clause A 2 Pc such that mgu(G; A) = . Case 2: There exist unit clauses A; B 2 Pc such that A is a unit pclause of the form p m(a01; : : : ; a0k ) 7! a0] and B is a unit iclause of the form o0 p0 @mk ], and G is of 7! the form o m(a1; : : :; ak ) 7! a]. Then the inheritance rule must be applied. Hence it must be the case that = mgu(o; o0), = mgu(p0 ]; p), % = p = o ] and = 0 ; : : : ; a0 ; a0 > %]). = mgu(< o; a1; : : : ; ak ; a > ]; < p; a1 k dc Let = for the rst case and = for the second case. Since G Pc in both the d cases, it follows from the de nition of TP that G v TP "2. Inductive step: Assume that the claim is true for any proof of height k ? 1 of a goal of the form Pc ` B . Then we have again two cases. Case (i): There must exist a clause of the form A B 2 Pc such that = mgu(G; A), and = and we have a proof of height k for Pc ` G where = and the root node labelled deduction. Case (ii): There must exist a pclause A B 2 Pc and a unit iclause C 2 Pc such that A is of the form p m(a01; : : : ; a0k ) 7! a0] and C is of the form o0 [email protected] ], and G is of the 7! form o m(a1; : : :; ak ) 7! a]. We can now construct a proof tree of height k for Pc ` G such that the root node is labelled inheritance, and = mgu(o; o0), = mgu(p0 ]; p), % = fp = o g and = mgu(< o; a1; : : : ; ak ; a > ]; < p; a01; : : :; a0k ; a0 > %]). Also = = and = % . dd d By inductive hypothesis, B v TP "k?1 holds. Since G = A in both the cases, it d d follows from lemma 6.1 that A v TP "k because either (i) B v TP "k?1, or (ii) d 7! fBd ; o0 [email protected] ] g v TP "k?1, o0 [email protected] ] being unit clauses and 7! d c d [email protected] 2 o0 p0 @mk ] o0 pdmk ] Pc . Hence G v TP "k . 7! 7!
c c c c c c c Proof: By induction on the height k of a proof tree. There are two cases, (i) pgoals and Theorem 6.4 (Completeness) Let Pc be a closed program and G be a ground p, ror predatom. For any k, if G 2 TP "k then there is an atom A and a substitution , d such that there exists a proof tree of height k for Pc ` A, and G 2 A .
c Proof: Again we proceed by induction on k . 33 Basis: Suppose G 2 TPc "1. Then there must exist a unit clause A 2 Pc such that either (i) = mgu(G; A) and = , or (ii) there exist unit clauses A; B 2 Pc such that A is a unit pclause of the form p m(a01; : : :; a0k ) 7! a0], B is a unit iclause of the form o0 [email protected] ], and G is of the form o m(a1; : : :; ak ) 7! a] such that = 7! 0 ), = mgu(p0 ]; p), % = fp = mgu(o; o =o g and = mgu(< o; a1; : : : ; ak ; a > ]; < p; a01; : : :; a0k ; a0 > %]). Then there is a proof for Pc ` A of height 1 which is labelled either (i) by deduction where = , or (ii) by inheritance where = respectively. It immediately implies that G = A . Inductive step: Assume that the claim holds true for k ? 1. From the de nition of TPc , if G 2 TPc "k , then there are two cases.
c Case (i): There must exist a clause A B 2 Pc such that = mgu(G; A), = , d G = A , and TP "k j= B . Case (ii): There exists a pclause A B 2 Pc and a unit iclause C 2 Pc such that A is of the form p m(a01; : : :; a0k ) 7! a0], C is of the form o0 [email protected] ], and G is of the form 7! o m(a1; : : :; ak ) 7! a] such that = mgu(o; o0), = mgu(p0 ]; p), % = fp = g and =o = mgu(< o; a1; : : :; ak ; a > ]; < p; a01; : : :; a0k ; a0 > %]). b Since G 2 A (because G uni es with A) and G 2 TP "k , by monotonicity of TP it must be the case that TP "k?1j= B. Then by inductive hypothesis, we must have a proof for Pc ` B of height k ? 1. From this, we can then construct a proof for Pc ` A of height k from this whose root node is labelled either (i) by deduction where = and = , or (ii) by inheritance where = and = % respectively. It d. immediately implies that G 2 A 2
c c c As a corollary, we have the following equivalence between the intended model semantics and the proof theory. Theorem 6.5 Let P be a program, Pc be its closure, MP be the intended model for P, and G be a ground goal. Then, we have that Pc ` G is provable i MP j= G.
Proof: Pc ` G is provable () G 2 TP "! by theorems 6.3 and 6.4 () MP j= G from theorem 6.2
c c 2 34 7 Related Research
There are several important di erences between our language and others'. Behavioral inheritance has been studied in the context of Ordered Theories 17], Contextual Logic Programming 23, 24], arti cial intelligence, nonmonotonic reasoning, and a few others such as 5, 6]. Research in arti cial intelligence and nonmonotonic reasoning is mainly concerned with inheritance of properties and con icts, and do not consider behaviors and structures of objects in objectoriented databases. Some of the proposals also sacri ce completeness, or are highly nondeterministic. The proposals in 5, 17, 23, 24] are essentially modular languages that de ne collection of predicates in named modules. Inheritance is then captured by algebraic operations, called program composition, on the modules, to obtain new modules that inherit the predicates from a super module. In SelfLog 5], inheritance with overriding is captured by statically de ning an ordering among the modules and using program composition to de ne inheritance. A similar approach is taken in 17, 23]. Although behavioral inheritance is captured in the semantics, program composition in itself is very costly in the context of objectoriented databases, where number of method de nitions in the modules could be large and number of objects in practical databases may be much more than the static number of modules considered in these proposals. Besides, they achieve their functionality by giving up multiple inheritance and by avoiding the di cult issue of con ict resolution. Also the class of programs they allow is much smaller than a language such as Flogic 16], Gulog 8, 9], ORLog, etc. The istrati cation in Gulog 8, 9] and the stable model for inheritance proposed in 6] are based on a preferred model construction. Clearly a framework such as ours, which captures behavioral inheritance within a sound and complete proof theory has a greater intellectual appeal. Also, the approaches above have a very high computational complexity. In addition Gulog does not deal with inheritance con icts and disallows programs with con icts. On the other hand 6] does not recognize con icts since it takes a relational approach to methods by treating them as set valued methods. Flogic does not directly capture behavioral inheritance as in code reuse. The only way to realize it is by simulating it via Flogic's pointwise overriding and deduction. But then, this makes it the programmer's responsibility. Consider Example 2.2. In our case clause (8) produces p m ! 2] by code reuse (as discussed in example 2.2), while Flogic (for the program as it is in Example 2.2) will inherit the ground data expression o m ! 5] from o to produce p m ! 5] which is not behavioral inheritance as in code reuse. Furthermore, 35 due to clauses (12) and (13), Flogic will have two minimal models { in one model it will inherit (12) in r and override (13); and in another model it will inherit (13) in r and override (12). By contrast, in ORLog we have only one model in which we inherit neither. By analogy with the literature on negation 11], we can say that Flogic's approach to multiple inheritance is brave while ours is cautious. Rather than debate on which is better, we would like to remark that a brave semantics for multiple inheritance destroys any hopes of a complete proof theory15. Besides, a nice feature of our framework is the ability to simulate the brave semantics at a \local" level, to a limited extent. This can be accomplished by using the withdrawal atoms. E.g., in Example 2.2, clause (7) withdraws method t0 de ned in p from being inherited in r. Since t0 is also de ned in q, r can ! ! 0 from the unique source q . now inherit t! A second di erence with Flogic is that in Flogic a necessarily monotonic signature inheritance is built into the logic. There are situations where a signature de ned in a superclass may have to be withdrawn from a (not necessarily immediate) subclass. Flogic's inheritable and noninheritable method expressions help solve this problem to a limited extent. However, consider the situation where a signature is de ned in o, and is inherited up to the class r, where r : q, q : p, p : o and suppose it has to be withdrawn from s, where s : r. It is not clear how this can be accomplished in Flogic. In ORLog, this can be done rather easily by using an appropriate withdrawal atom. Finally, we remark that the concepts of locality, inheritability, and withdrawal of properties are quite useful in themselves and we are not aware of any other logic where they are given a formal status. 8 Conclusion
In this paper, we considered a simple and intuitive objectoriented logic called ORLog and developed an elegant model theoretic and xpoint theoretic characterization of the semantics of its de nite clause fragment, accounting for multiple behavior inheritance with con ict resolution and overriding. We also provided a simple sound and complete proof theory. This was achieved by keeping the isa hierarchy nite and static. While, compared to other logics such as Flogic, our language has limited expressive power, we have exploited the restricted setting and successfully captured the nontrivial concepts of multiple behavior inheritance within the model theory and a sound and complete proof
not to say, a complete proof theory for the cautious semantics is straightforward, as can be seen from this paper.
15That is 36 theory, to our knowledge, for the rst time. On the other hand, our simple setting still admits a large class of practically useful programs. In addition, we have proposed the notions of locality, inheritability, and withdrawal of methods and signatures, as rst class concepts within the logic. These are useful concepts in their own right, as demonstrated earlier. We note that even though for the sake of simplicity, the proof theory was presented based on the closure of a program, in an actual implementation, it is really not necessary to compute the entire closure of a program. More precisely, it may be possible to compute only a small and relevant subset of the closure in order to prove a given goal. Similarly, the bottomup xpoint computation can be made more e cient, by incorporating ideas similar to the wellknown magic sets method 3]. We are currently investigating these and other optimization opportunities. We have completed a prototype implementation 14, 15] based on translation to coral 25], and are working on a direct implementation. We are also investigating relaxations to the present restrictions on ORLog programs while still capturing behavioral inheritance within the logic. References
1] H. A tKaci and R. Nasr. LOGIN: a logic programming language with builtin inheritance. Journal of Logic Programming, 3:182{215, 1986. 2] H. A tKaci and A. Podelski. Towards a Meaning of LIFE. Technical Report 11, Digital Paris Research Labs, 1991. 3] C. Beeri and R. Ramakrishnan. On the power of magic. In Proceedings of the 6th ACM Symposium on Principles of Database Systems, pages 269{283, 1987. 4] S. Brass and U. W. Lipeck. Semantics of inheritance in logical object speci cations. In Proceedings of the Intl. Conf. on Deductive and ObjectOriented Databases, pages 411{430, 1991. 5] M. Bugliesi. A declarative view of inheritance in logic programming. In K. Apt, editor, Proc. Joint Int. Conference and Symposium on Logic Programming, pages 113{130. The MIT Press, 1992. 6] M. Bugliesi and H. M. Jamil. A stable model semantics for behavioral inheritance in deductive object oriented languages. In G. Gottlob and M. Y. Vardi, editors, 37 Proceedings of the 5th International Conference on Database Theory (ICDT), pages 222{237, Prague, Czech Republic, 1995. SpringerVerlag. LNCS 893. 7] M. Dalal and D. Gangopadhyay. OOLP: A translation approach to objectoriented logic programming. In Proceedings of the First DOOD Conference, pages 593{606, 1990. 8] G. Dobbie and R. Topor. A Model for Inheritance and Overriding in Deductive ObjectOriented Systems. In Sixteen Australian Computer Science Conference, January 1988. 9] G. Dobbie and R. Topor. A Model for Sets and Multiple Inheritance in Deductive ObjectOriented Systems. In Proc. 3rd Intl. DOOD Conf., pages 473{488, December 1993. 10] H. B. Enderton. A Mathematical Introduction to Logic. Academic Press, London, 1972. 11] M. Fitting. The family of stable models. Journal of Logic Programming, 17(2/4):197, November 1993. 12] H. M. Jamil and L. V. S. Lakshmanan. ORLog: A Logic for Semantic ObjectOriented Models. In Proc. 1st Int. Conference on Knowledge and Information Management, pages 584{592, 1992. 13] H. M. Jamil and L. V. S. Lakshmanan. A declarative semantics for behavioral inheritance and con ict resolution. In John Lloyd, editor, Proceedings of the 12th International Logic Programming Symposium, pages 130{144, Portland, Oregon, December 1995. MIT Press. 14] H. M. Jamil and L. V. S. Lakshmanan. An objectoriented frontend for deductive databases. In V. S. Alagar and M. Nivat, editors, Proceedings of the 4th International Conference on Algebraic Methodology and Software Technology (AMAST), pages 581{584, Montreal, Canada, July 1995. SpringerVerlag. LNCS 936. 15] H. M. Jamil, L. V. S. Lakshmanan, and I. Orenman. Reducing inheritance to deduction by completion. Technical report, Department of Computer Science, Concordia University, Montreal, Canada, March 1995. 16] M. Kifer, G. Lausen, and J. Wu. Logical Foundations for ObjectOriented and FrameBased Languages. Journal of the Association of Computing Machinery, July 1995. 38 17] E. Laesen and D. Vermeir. A Fixpoint Semantics for Ordered Logic. Journal of Logic and Computation, 1(2):159{185, 1990. 18] J. W. Lloyd. Foundations of Logic Programming. SpringerVerlag, 1987. 19] S. Manchanda. Higherorder" logic as a data model. In Proc. of 2nd International. Workshop on Data Base Programming Languages, pages 330{341, June 1989. 20] F.G. McCabe. Logic and Objects. Prentice Hall International, London, 1992. 21] D. Miller. A Logical Analysis of Modules in Logic Programming. Journal of Logic Programming, (6):79{108, 1989. 22] L. Monteiro and A. Porto. Contextual Logic Programming. In 6th ALP Intl. Conf. on Logic Programming, 1989. 23] L. Monteiro and A. Porto. A transformational view of inheritance in Logic Programming. In D.H.D. Warren and P. Szeredi, editors, Proc. 7th Int. Conference on Logic Programming, pages 481{494. The MIT Press, 1990. 24] L. Monteiro and A. Porto. Syntactic and Semantic Inheritance in Logic Programming. In J. Darlington and R. Dietrich, editors, Workshop on Declarative Programming. Workshops in Computing, SpringerVerlag, 1991. 25] R. Ramakrishnan, D. Srivastava, and S. Sudarshan. CORAL : Control, Relations and Logic. In Proc. of 18th VLDB Conference, 1992. 26] D. S. Touretzky. The Mathematics of Inheriance Systems. Morgan Kaufmann, Los Altos, CA, 1986. 39 ...
View
Full Document
 Fall '09
 ObjectOriented Programming, Databases, Inheritance, Method, De nitions, behavioral inheritance, ORLog

Click to edit the document details