Semantics of Inheritance in Logical Object ... - Semantic Scholar
Second International Conference (DOOD’91), Springer-Verlag, LNCS 566, 1991, 411–430 (Typing errors corrected in this version 19.12.1991)
Semantics of Inheritance in Logical Object Specifications∗ Stefan Brass
Udo W. Lipeck
Institut f¨ ur Informatik, Universit¨at Hannover Lange Laube 22, D-W 3000 Hannover 1, Fed. Rep. Germany e-mail: {sb|ul}@informatik.uni-hannover.dbp.de
Abstract Our goal is to integrate the paradigms of object-oriented structuring and of rule-based specifications for databases. In this paper, we consider hierarchical specifications of objects and object types with attributes defined by logical rules, and we explain their local (single object) semantics as well as their composite (object society) semantics. In order to allow inheritance with exceptions (overriding) even for rules, the defining formulas are interpreted like defaults of different priorities corresponding to levels in the object type hierarchy. Here, minimal model semantics known from default reasoning in artificial intelligence or from database completions can be utilized, but must be modified to respect object-oriented issues, in particular locality. We prove that intended models exist for object and composite specifications under natural conditions, even if general clauses are used as defaults.
1
Introduction
Much has already been said about the relative merits of the object-oriented and the logic paradigm, and about the potential advantages of integrating them both; the reader might compare many of the contributions to the first conference in this series [KNN90]. One of the roots of object-orientation is the concept of a module in a programming language: an encapsulation of data and procedures belonging together. From this perspective it seems fairly obvious that in an object-oriented and at the same time logical language each object should contain a module of a logic program. This means that objects can have derived attributes which are defined by a set of logical rules given by, for instance, Datalog clauses. Another origin of object-orientation is the requirement to reuse code: Software should be designed in a “differential” way — select a module from a library, refine it by adding new functions, and modify it by overriding some old ones. This leads to the famous inheritance hierarchies in object-oriented specifications. This work was partially supported by the CEC under ESPRIT-2 BRA Working Group No. 3023 IS-CORE (Information Systems — COrectness and REusability) ∗
1
Let us now consider how such an inheritance mechanism can be incorporated into logical object specifications. The problem is how to override inherited rules. An obvious syntactical way might be to replace or re-define the affected inherited rules which, however, have to be named explicitly for that purpose. Apart from the inconvenience to remember rule names, such an approach does not allow to specify just a few, maybe conditional, exceptions to inherited rules instead of replacing them completely. There is an alternative semantical approach, and this is the one our proposal is based on: We could as well view the inherited rules as “defaults” which can be overridden by specifying additional information which may partially be contradictory. This kind of non-monotonic reasoning has been studied in artificial intelligence, where in particular the famous “bird and penguins” example comes from; here is an object-oriented variant: Assume a database for the classification of animals which stores their typical characteristics. So in the object type “bird ” (which is a subtype of “animal ”) facts like “characteristic(able to fly)” and “characteristic(feathered )” are specified. Further down in the inheritance hierarchy, there is a subtype “penguin” where we would like to override the property of flying by introducing a formula of the form color (black and white) → ¬characteristic(able to fly) (black-and-white pinguins do not fly; we don’t know what colored penguins can’t do). Note that this rule is a negative clause which is needed to override inherited positive information. Of course, overriding the ability to fly should not change other inherited characteristics like the property of being feathered. Default rules are not new in deductive databases as well, but only a fixed set of rather simple defaults has been used there: negative ground literals or at most hierarchies of such literals for stratified logic programs. Such a form of completion or “closed world assumption” is always needed in deductive databases as long as only positive knowledge is to be given explicitly and negative knowledge is assumed “by default”. We, however, want to use arbitrary disjunctions of arbitrary literals, i.e. general clauses, as defaults. So, the difference to standard completions of deductive databases lies in the ability to use a big class of formulas as defaults and to specify the defaults explicitly, i.e. to have “user-specifiable defaults”. In fact, the AI community has been studying more general forms of default rules for quite a long time ([Rei80], e.g.), as well as inheritance hierarchies ([Tou86], e.g.), but not a composition of both directions. We have suggested in [BL89] an extension of the closed world assumption [Rei78], which was motivated by the database view and allowed the specification of fairly general default rules (“possible assumptions” called there). Properties of general database completions have been investigated in [Bra90]. Although it is usually possible to code defaults in such a way that only negation is used implicitly, such attempts lead to clumsy and artificial formulations (in the example above: “black-and-white penguins are an exception to the rule that birds are flying”). Thus the power of general defaults greatly simplifies the task of knowledge specification. In most of the approaches to deductive object-oriented databases, e.g., [Abi90, Bee90, HS89], inheritance has been applied to attribute or method names (together with their definitions) only, and deduction rules have been introduced over objects, i.e. on top of a set of object modules, but not inside the objects where they would be subject to inheritance. 2
A remarkable exception is the language proposal by [Abi90] who includes rules into objects and discusses inheritance and overriding by examples; he even presumes that “this is perhaps the core of the integration between the logic-programming and object-oriented paradigms”. We are aiming at that core and want to study semantic issues of such kind of inheritance. So, we consider in this paper hierarchical specifications of objects and object types with attributes defined by logical rules, and we explain their local (single object) semantics as well as their composite (object society) semantics. In order to allow inheritance with exceptions (overriding) even for rules, the defining formulas are interpreted as defaults of different priorities corresponding to levels in the object type hierarchy. Here, minimal model semantics can be utilized, but must be modified to respect object-oriented issues, in particular locality. We prove that intended models exist for object and composite specifications under natural conditions, and we show that our semantics has several useful properties. The rest of the paper is structured as follows: To illustrate our scenario, section 2 introduces a simple example of logical object-oriented specification in a concrete, but adhoc syntax. In section 3, the complete object specifications resulting from such description elements are defined formally. Their local objectwise semantics which is determined by the inheritance hierarchy of default rules is explained in section 4, and properties of this semantics are shown in section 5. Section 6 deals with the composition of object specifications to an object society. In section 7, we give a short comparison of our approach with related work.
2
An Example
Let us start with a simple example that should give an impression how our kind of logical object specification might be expressed in an ad-hoc specification language, which specification elements are needed here, and what their intuitive semantics is. We consider a small “computer market” society of customers, some of them being computer scientists, of computers and of operating systems. There is an object type “os type” (operating system type), and there are two objects (“msdos” and “unix”) of that type: type os type end object msdos: os type end object unix: os type end The next object type “computer” introduces two attributes for each object of that type, the operating systems available for that computer (predicate “os”) and its price (predicate “price”). Obviously, price should be a functional attribute which we indicate by “→”. 3
Since the specification of computers refers to another object type (the operating systems), the name of that type must be imported. The intention of import declarations is to make each object specification self-contained so that we are able to give it a local semantics without knowing anything outside this specification. Of course, the imported references must exist when all object specifications of an object society are composed. Data types like “integer” are assumed to be given without further notice. For the computer object called “AT386” we know its price and that it supports two operating systems (whose object names must be imported). The other computer object called “RISC” is a “unix” machine. type computer imports os type attributes os(os type); price(→integer) end object AT386: computer imports msdos: os type; unix: os type known os(msdos); os(unix); price(1500) end object RISC: computer imports unix: os type known os(unix) end The “customer” object type given below introduces an attribute “interested in” about which we can assume as a default that a usual customer is not interested in any specific computer. (This would be the usual default in a relational database storing customers and their interests). Computer scientists, however, who are a special class — a subtype — of customers usually get so enthusiastic, if they are interested in some “unix” computer, that they are interested in every “unix” computer. Since defaults represent only possible knowledge, they may be overridden by more specific knowledge on an object subtype or a concrete object: a customer may be interested in a certain computer or a computer scientist may not be interested in a certain “unix” computer. Please note that an expression like “x.os(. . .)” in a rule refers to the attribute “os” of the object “x”. So each predicate actually has an additional object-valued argument. As 4
it is usual in object-oriented languages, this argument is written as a prefix and may be omitted for the current object “self ”. type customer imports computer attributes interested in(computer) assume [x: computer] ¬interested in(x) end subtype computer scientist of customer imports os type; unix: os type; computer.os(os type) assume [x,y: computer] interested in(x) ∧ x.os(unix) ∧ y.os(unix) → interested in(y) end object SB: computer scientist imports RISC: computer known interested in(RISC) end object UL: computer scientist end What we know about computer scientists like UL comes from combining the defaults of the type and its supertype “customer”: if he is interested in some “unix” computer then he is interested in a computer if and only if it is a “unix” computer: Formally, we have (using general predicate logic, not the specification language which is restricted to clauses): ∃x: computer (interested in(x) ∧ x.os(unix)) → ∀y: computer (y.os(unix) ↔ interested in(y)). For the object SB, who is interested in the RISC computer, we can locally conclude, for instance: RISC.os(unix) → ∀y: computer (y.os(unix) → interested in(y)). Only globally, however, i.e. from composition of object specifications, we get to know that he is indeed interested in all “unix” computers, since “os(unix)” holds for the object RISC: ∀y: computer (y.os(unix) → SB.interested in(y)). 5
In summary, the following types and objects have been specified: The boxes denote objects, ovals object types, solid arrows the instance relation, dashed arrows the import relation and downward lines the subtype relation. -
#
customer
" #
#
-
os type
"
unix
@
@
! @ R @
msdos
@
- AT386
@
!
- computer scientist
@ R @
" 6
RISC
6
3
#
computer
"
!
-
SB
@
@
!
@ R @
UL
6
Object Specifications
In this section, we will define what constitutes an object specification resulting from a description in a specification language like that in the example above. The two main issues that we will consider are inheritance and locality. As indicated in the introduction, a specification consists of rules assigned to the object types and to the objects. Typically, the objects store facts only. To be able to write down such rules we first need syntactic constituents (predicates, variables, constants) in form of a signature. For each object type and for each object, a local signature will be defined. This signature consists of symbols introduced in the current object type, symbols inherited from supertypes, and symbols explicitly imported from other object types. We assume that there is a set D of data types given, e.g. D := {int, string, date} including the usual constants, functions, and predicates of these sorts. Given a set S of ˆ object sorts, we denote S ∪ D by S. Definition 3.1 (Signature): A signature Σ = hS, ≺, P, Oi consists of • S, a finite set of object sorts. • ≺, a strict partial order (transitive and irreflexive) on S, the subsort relation. • P , an S × Sˆ∗ × Sˆ∗ -indexed family of disjoint predicate sets, which are also disjoint from S. If p ∈ Ps0 ,s1 ...sn ,sn+1 ...sm , the predicate p is local to s0 , has arity (argument sorts) s1 . . . sm , and s1 . . . sn are a key of p. • O, an S-indexed family of disjoint object name sets, also being disjoint from S and P . If o ∈ Os , the object o has sort s. 6
In the example of section 2, signatures can be built from the symbols defined or imported in an object or object type, together with all those from its supertypes. The symbols defined in the whole specification also form a signature (the global one). Note that multiple inheritance is possible since the subsort relation can be any strict partial order. We use So to denote the sort so of o together with all supersorts and the object name o itself, i.e. So := {o} ∪ {s ∈ S | so s, o ∈ Oso }. The subsort relation ≺ is extended to So by defining o ≺ s for each s ∈ So ∩ S. Definition 3.2 (Rule): Let Σ = hS, ≺, P, Oi be a signature and so ∈ S. ˆ • A variable declaration is a finite S-indexed family X of variable sets. It is written as an enumeration [x1 : s1 ] . . . [xm : sm ] listing all xi ∈ Xsi (i = 1, . . . , m). • A hΣ, so i-rule ϕ has the form [x1 : s1 ] . . . [xm : sm ] ϕ1 ∨ · · · ∨ ϕn with hΣ, X, so iliterals ϕi , where X is the variable declaration corresponding to [x1 : s1 ] . . . [xm : sm ]. • A hΣ, so , Xi-literal is a hΣ, so , Xi-atom or the negation of such an atom. • A hΣ, so , Xi-atom has the form: - t0 .p(t1 , . . . , tm ), where p ∈ Ps0 ,s1 ...sn ,sn+1 ...sm , and each ti is a hΣ, so , Xi-term of sort s′i with s′i si (i = 0, . . . , m), - p(t1 , . . . , tm ), where ti as above and so s0 , - or a datatype predicate applied to data terms. • A hΣ, so , Xi-term of sort s ∈ Sˆ is - an object name from Os (if s ∈ S), - a variable from Xs , - the special symbol self (if s = so ), - or a datatype constant or term of sort s (if s ∈ D). The rules can equivalently be written as implications with a conjunction of literals in the body and a disjunction of literals in the head. In contrast to other approaches, we do not consider the partition of literals into head and body of a rule as significant. In our view, if such an extralogical information is important, then one should declare it explicitly and not intermixed with the actual logical knowledge. To define the complete local specification of an object o, we must include knowledge about its type and all supertypes in So , but not about imported types S − So or objects O − {o}. That knowledge is represented by rules for which we make a distinction between strictly constraining rules and overridable ones. Therefore, a specification contains two So -indexed families of rule sets, one with the constraints, the other with the defaults. Definition 3.3 (Object Specification): An object specification S = hΣ, o, Φ, ∆i consists of • Σ = hS, ≺, P, Oi, a local signature. • o ∈ O, the name of the specified object. Let so be the sort of o. • Φ, an So -indexed family of sets of hΣ, so i-rules, the “known” rules (or constraints). • ∆, an So -indexed family of hΣ, so i-rules, the “assumed” rules (or defaults). 7
The indexing of rule sets by a partially ordered set of sorts will be crucial for the semantics of the defaults, since it attaches priorities to them. For the constraints, however, the indexing could be neglected. They can equally well be seen as defaults of highest priority. Note that this definition allows the rules in some object to assert things about other objects. This should be avoided by further restrictions, since it violates locality. We will come back to this problem when we try to compose specifications in section 6. where we will define (semantically) “tolerant” object specifications.
4
Local Semantics
Now we have to define the model-theoretic semantics of the specifications introduced in the last section, i.e. their set of intended models. Let a signature Σ = hS, ≺, P, Oi be given. Definition 4.1 (Interpretation): A Σ-interpretation I defines • A set I[s] for each object sort s ∈ S such that s1 ≺ s2 implies I[s1 ] ⊆ I[s2 ] for arbitrary s1 , s2 ∈ S. • A relation I[p](d0 ) ⊆ I[s1 ]×· · ·×I[sm ] satisfying the key dependency (as known from relational database theory) (s1 . . . sn ) → (s1 . . . sm ) for each p ∈ Ps0 ,s1 ...sn ,sn+1 ...sm and each d0 ∈ I[s0 ]. • An element I[o] ∈ I[s] for each object name o ∈ Os , s ∈ S, such that distinct names are interpreted by distinct elements. • The standard interpretation of data types. Definition 4.2 (Reduct, object core): The reduct of a Σ-interpretation I to a subsignature Σ′ , written Σ′ -reduct(I), is the interpretation restricted to the elements of the subsignature. For an object o ∈ O, the o-core of an interpretation I is the interpretation of the predicates for that object only, i.e. the relations I[p](I[o]) for all p ∈ P . Definition 4.3 (Evaluation): Let a Σ-interpretation I and a current object do ∈ I[so ] be given. ˆ • An assignment α defines an element α(x) ∈ I[s] for each variable x ∈ Xs , s ∈ S. • The value hI, do , αi[t] of a hΣ, so , Xi-term t under an assignment α is defined by - hI, do , αi[o] := I[o] for object names o ∈ O, - hI, do , αi[self ] := do , - hI, do , αi[x] := α(x) for variables x ∈ X, - and for datatype constants or terms as usual. • The validity of a hΣ, so , Xi-literal ϕ wrt hI, do , αi is defined as follows: - For ϕ ≡ t0 .p(t1 , . . . , tm ): hI, do , αi |= ϕ iff (hI, do , αi[t1 ], . . . , hI, do , αi[tm ]) ∈ I[p](hI, do , αi[t0 ]). 8
- For ϕ ≡ p(t1 , . . . , tm ): hI, do , αi |= ϕ iff (hI, do , αi[t1 ], . . . , hI, do , αi[tm ]) ∈ I[p](do ). - For datatype predicates as usual. - For ϕ ≡ ¬ψ: hI, do , αi |= ϕ iff hI, do , αi 6|= ψ. • Let ϕ ≡ [x1 : s1 ] . . . [xm : sm ]ϕ1 ∨ · · · ∨ ϕn be a (Σ, so )-rule. Then we define: - hI, do , αi |= ϕ iff there is at least one i ∈ {1, . . . , n} such that hI, do , αi |= ϕi . - hI, do i |= ϕ iff hI, do , αi |= ϕ for all assignments α of the variables x1 , . . . , xm . Let an object specification S = hΣ, o, Φ, ∆i be given in the following definitions. A model of S is an interpretation that satisfies all the constraining rules from Φ: Definition 4.4 (Model): A Σ-interpretation I is a model of S (I |= S) iff hI, I[o]i |= ϕ for each ϕ ∈ Φ. A model does not necessarily respect the defaults, so the next goal is to define the intended models as a subset of all models. The intuitive semantics of a default is that it should be assumed if possible without violating the consistency, i.e. if it does not contradict the constraints or other assumed defaults. If there are conflicts between two defaults, we should take their relative priorities into account, i.e. if one is defined in a subtype and one in a supertype, we should assume the one from the subtype, since it is the more specific one. Note that the units of assumption or rejection are not the defaults, but their instances. For example, given a default [x: s]¬p(x) and a constraint p(a), only the instance ¬p(a) of the default is blocked, but we are still interested to assume ¬p(x) for other x. A specific feature of our approach is that we use semantical instances of defaults by means of variable assignments, and not syntactical instances by means of substitutions. Because of this, second order circumscription [McC86] is a special case of our approach. Definition 4.5 (Default Instances): Given a model I of S, the valid instances of the defaults specified in s ∈ So are ∆s,I := {hδ, αi | δ ∈ ∆s , α a corresponding assignment, and hI, I[o], αi |= δ}. An intended model should satisfy a maximal set of default instances, taking their priorities into account. Formally, we define a preference relation (a strict partial order) on the models, and then choose the most preferable models. These “most preferable models” are usually known as “minimal models” since defaults are normally used to minimize predicate extensions. For this reason, we will write I1 < I2 to mean that we prefer I1 to I2 . The minimal model approach is quite standard, only an appropriate preference relation has to be found for the object-oriented environment. If there were no priorities between the defaults, we would simply define I1 < I2 iff ∆s,I1 ⊇ ∆s,I2 for all sorts s and “⊃” for at least one (so I1 satisfies more default instances than I2 ). To respect the priorities, we allow the violation of this condition for some sort s if there is a subsort s′ ≺ s where the strict superset condition holds (since the defaults specified there are more specific and thus should have higher priority when determining which of the two models is considered “better”). 9
Definition 4.6 (Preference Relation): For two models I1 and I2 of S, the model I1 is preferable to I2 (I1 < I2 ) iff • The two interpretations differ in their o-cores only. • For each s ∈ So with ∆s,I1 6⊇ ∆s,I2 there is s′ ∈ So , s′ ≺ s with ∆s′ ,I1 ⊃ ∆s′ ,I2 . • There is an s ∈ So with ∆s,I1 6= ∆s,I2 (to make < a strict partial order). So in effect, we look only at the ≺-minimal sorts s where the two models differ in their valid default instances, and require ∆s,I1 ⊃ ∆s,I2 for these sorts. For the comparison of the two models the defaults specified further up in the inheritance hierarchy are not relevant, since they differ already in defaults of higher priority. This means, we could replace the second condition in the preceding definition by • For each s ∈ So : If ∆s′ ,I1 = ∆s′ ,I2 for all s′ ∈ So with s′ ≺ s, then ∆s,I1 ⊇ ∆s,I2 So for each path in the object type hierarchy the following must hold:
sn
si
s1
?
···
···
)
arbitrary
∆s,I1 ⊃ ∆s,I2
∆s,I1 = ∆s,I2
o
This resembles the definition of the preference relation for prioritized circumscription [Lif86], but it is a generalization, since prioritized circumscription cannot handle multiple inheritance. Furthermore, our preference relation respects the locality of objects, because only local differences can be used for minimization: Models are uncomparable if they differ in the global context. Example 4.7: Let us consider the specification of the object SB as given in section 2 and the following Herbrand interpretations (based on the global signature, true facts are marked with “•”): I0 I1 I2 SB.interested in(RISC) • • SB.interested in(AT386) • RISC.os(unix) • • AT386.os(unix) • • ... ... ... ... I0 is not a model, since it does not satisfy the constraint SB.interested in(RISC). 10
The following default instances are satisfied in these models (marked with •): Specified in sort customer
Default ¬interested in(x)
Assignment I 1 I2 hx/RISCi hx/AT386i • computer scientist interested in(x) ∧ x.os(unix) hx/RISC, y/AT386i • ∧ y.os(unix) → interested in(y) . . . • •
Comparing I1 and I2 , we note that each one satisfies a default that the other does not. But the second default has higher priority than the first one, since it is defined lower in the object type hierarchy (it overrides the first one). So we should have I1 < I2 . Formally, customer is the only sort s with ∆s,I1 6⊇ ∆s,I2 (we even have ∆s,I1 ⊂ ∆s,I2 ). But in the subsort computer scientist of customer the model I1 satisfies strictly more default instances: ∆s,I1 ⊃ ∆s,I2 . For the preference relation, this is decisive, so we get I1 < I2 as intended. 2 Lemma 4.8: The relation < on the models of S is a partial order, i.e. transitive and irreflexive. Proof: • “Transitivity:” Let I1 < I2 and I2 < I3 , so we have to show I1 < I3 . Let s ∈ So be given with ∆s,I1 6⊇ ∆s,I3 . This means that ∆s,I1 6⊇ ∆s,I2 or ∆s,I2 6⊆ ∆s,I3 . But since I1 < I2 and I2 < I3 , there is an s′ ∈ So such that ∆s,I1 ⊃ ∆s′ ,I2 or ∆s,I2 ⊃ ∆s′ ,I3 . Choose a minimal s′ which satisfies one of these two conditions. This minimality condition entails that we have “⊇” in the other case. So we can compose “⊃” with “⊇” to get ∆s,I1 ⊃ ∆s′ ,I3 . We finally have to show that there is s ∈ So with ∆s,I1 6= ∆s,I3 , but this follows directly from I1 < I2 and I2 < I3 if one uses a ≺-minimal sort with ∆s,I1 6= ∆s,I2 or ∆s,I2 6= ∆s,I3 . • “Irreflexiveness:” This follows directly from the definition, since the two interpretations must differ in the truth value of some default instance. 2 Now we select the most preferrable models (the minimal models wrt
Semantics of Inheritance in Logical Object Specifications∗ Stefan Brass
Udo W. Lipeck
Institut f¨ ur Informatik, Universit¨at Hannover Lange Laube 22, D-W 3000 Hannover 1, Fed. Rep. Germany e-mail: {sb|ul}@informatik.uni-hannover.dbp.de
Abstract Our goal is to integrate the paradigms of object-oriented structuring and of rule-based specifications for databases. In this paper, we consider hierarchical specifications of objects and object types with attributes defined by logical rules, and we explain their local (single object) semantics as well as their composite (object society) semantics. In order to allow inheritance with exceptions (overriding) even for rules, the defining formulas are interpreted like defaults of different priorities corresponding to levels in the object type hierarchy. Here, minimal model semantics known from default reasoning in artificial intelligence or from database completions can be utilized, but must be modified to respect object-oriented issues, in particular locality. We prove that intended models exist for object and composite specifications under natural conditions, even if general clauses are used as defaults.
1
Introduction
Much has already been said about the relative merits of the object-oriented and the logic paradigm, and about the potential advantages of integrating them both; the reader might compare many of the contributions to the first conference in this series [KNN90]. One of the roots of object-orientation is the concept of a module in a programming language: an encapsulation of data and procedures belonging together. From this perspective it seems fairly obvious that in an object-oriented and at the same time logical language each object should contain a module of a logic program. This means that objects can have derived attributes which are defined by a set of logical rules given by, for instance, Datalog clauses. Another origin of object-orientation is the requirement to reuse code: Software should be designed in a “differential” way — select a module from a library, refine it by adding new functions, and modify it by overriding some old ones. This leads to the famous inheritance hierarchies in object-oriented specifications. This work was partially supported by the CEC under ESPRIT-2 BRA Working Group No. 3023 IS-CORE (Information Systems — COrectness and REusability) ∗
1
Let us now consider how such an inheritance mechanism can be incorporated into logical object specifications. The problem is how to override inherited rules. An obvious syntactical way might be to replace or re-define the affected inherited rules which, however, have to be named explicitly for that purpose. Apart from the inconvenience to remember rule names, such an approach does not allow to specify just a few, maybe conditional, exceptions to inherited rules instead of replacing them completely. There is an alternative semantical approach, and this is the one our proposal is based on: We could as well view the inherited rules as “defaults” which can be overridden by specifying additional information which may partially be contradictory. This kind of non-monotonic reasoning has been studied in artificial intelligence, where in particular the famous “bird and penguins” example comes from; here is an object-oriented variant: Assume a database for the classification of animals which stores their typical characteristics. So in the object type “bird ” (which is a subtype of “animal ”) facts like “characteristic(able to fly)” and “characteristic(feathered )” are specified. Further down in the inheritance hierarchy, there is a subtype “penguin” where we would like to override the property of flying by introducing a formula of the form color (black and white) → ¬characteristic(able to fly) (black-and-white pinguins do not fly; we don’t know what colored penguins can’t do). Note that this rule is a negative clause which is needed to override inherited positive information. Of course, overriding the ability to fly should not change other inherited characteristics like the property of being feathered. Default rules are not new in deductive databases as well, but only a fixed set of rather simple defaults has been used there: negative ground literals or at most hierarchies of such literals for stratified logic programs. Such a form of completion or “closed world assumption” is always needed in deductive databases as long as only positive knowledge is to be given explicitly and negative knowledge is assumed “by default”. We, however, want to use arbitrary disjunctions of arbitrary literals, i.e. general clauses, as defaults. So, the difference to standard completions of deductive databases lies in the ability to use a big class of formulas as defaults and to specify the defaults explicitly, i.e. to have “user-specifiable defaults”. In fact, the AI community has been studying more general forms of default rules for quite a long time ([Rei80], e.g.), as well as inheritance hierarchies ([Tou86], e.g.), but not a composition of both directions. We have suggested in [BL89] an extension of the closed world assumption [Rei78], which was motivated by the database view and allowed the specification of fairly general default rules (“possible assumptions” called there). Properties of general database completions have been investigated in [Bra90]. Although it is usually possible to code defaults in such a way that only negation is used implicitly, such attempts lead to clumsy and artificial formulations (in the example above: “black-and-white penguins are an exception to the rule that birds are flying”). Thus the power of general defaults greatly simplifies the task of knowledge specification. In most of the approaches to deductive object-oriented databases, e.g., [Abi90, Bee90, HS89], inheritance has been applied to attribute or method names (together with their definitions) only, and deduction rules have been introduced over objects, i.e. on top of a set of object modules, but not inside the objects where they would be subject to inheritance. 2
A remarkable exception is the language proposal by [Abi90] who includes rules into objects and discusses inheritance and overriding by examples; he even presumes that “this is perhaps the core of the integration between the logic-programming and object-oriented paradigms”. We are aiming at that core and want to study semantic issues of such kind of inheritance. So, we consider in this paper hierarchical specifications of objects and object types with attributes defined by logical rules, and we explain their local (single object) semantics as well as their composite (object society) semantics. In order to allow inheritance with exceptions (overriding) even for rules, the defining formulas are interpreted as defaults of different priorities corresponding to levels in the object type hierarchy. Here, minimal model semantics can be utilized, but must be modified to respect object-oriented issues, in particular locality. We prove that intended models exist for object and composite specifications under natural conditions, and we show that our semantics has several useful properties. The rest of the paper is structured as follows: To illustrate our scenario, section 2 introduces a simple example of logical object-oriented specification in a concrete, but adhoc syntax. In section 3, the complete object specifications resulting from such description elements are defined formally. Their local objectwise semantics which is determined by the inheritance hierarchy of default rules is explained in section 4, and properties of this semantics are shown in section 5. Section 6 deals with the composition of object specifications to an object society. In section 7, we give a short comparison of our approach with related work.
2
An Example
Let us start with a simple example that should give an impression how our kind of logical object specification might be expressed in an ad-hoc specification language, which specification elements are needed here, and what their intuitive semantics is. We consider a small “computer market” society of customers, some of them being computer scientists, of computers and of operating systems. There is an object type “os type” (operating system type), and there are two objects (“msdos” and “unix”) of that type: type os type end object msdos: os type end object unix: os type end The next object type “computer” introduces two attributes for each object of that type, the operating systems available for that computer (predicate “os”) and its price (predicate “price”). Obviously, price should be a functional attribute which we indicate by “→”. 3
Since the specification of computers refers to another object type (the operating systems), the name of that type must be imported. The intention of import declarations is to make each object specification self-contained so that we are able to give it a local semantics without knowing anything outside this specification. Of course, the imported references must exist when all object specifications of an object society are composed. Data types like “integer” are assumed to be given without further notice. For the computer object called “AT386” we know its price and that it supports two operating systems (whose object names must be imported). The other computer object called “RISC” is a “unix” machine. type computer imports os type attributes os(os type); price(→integer) end object AT386: computer imports msdos: os type; unix: os type known os(msdos); os(unix); price(1500) end object RISC: computer imports unix: os type known os(unix) end The “customer” object type given below introduces an attribute “interested in” about which we can assume as a default that a usual customer is not interested in any specific computer. (This would be the usual default in a relational database storing customers and their interests). Computer scientists, however, who are a special class — a subtype — of customers usually get so enthusiastic, if they are interested in some “unix” computer, that they are interested in every “unix” computer. Since defaults represent only possible knowledge, they may be overridden by more specific knowledge on an object subtype or a concrete object: a customer may be interested in a certain computer or a computer scientist may not be interested in a certain “unix” computer. Please note that an expression like “x.os(. . .)” in a rule refers to the attribute “os” of the object “x”. So each predicate actually has an additional object-valued argument. As 4
it is usual in object-oriented languages, this argument is written as a prefix and may be omitted for the current object “self ”. type customer imports computer attributes interested in(computer) assume [x: computer] ¬interested in(x) end subtype computer scientist of customer imports os type; unix: os type; computer.os(os type) assume [x,y: computer] interested in(x) ∧ x.os(unix) ∧ y.os(unix) → interested in(y) end object SB: computer scientist imports RISC: computer known interested in(RISC) end object UL: computer scientist end What we know about computer scientists like UL comes from combining the defaults of the type and its supertype “customer”: if he is interested in some “unix” computer then he is interested in a computer if and only if it is a “unix” computer: Formally, we have (using general predicate logic, not the specification language which is restricted to clauses): ∃x: computer (interested in(x) ∧ x.os(unix)) → ∀y: computer (y.os(unix) ↔ interested in(y)). For the object SB, who is interested in the RISC computer, we can locally conclude, for instance: RISC.os(unix) → ∀y: computer (y.os(unix) → interested in(y)). Only globally, however, i.e. from composition of object specifications, we get to know that he is indeed interested in all “unix” computers, since “os(unix)” holds for the object RISC: ∀y: computer (y.os(unix) → SB.interested in(y)). 5
In summary, the following types and objects have been specified: The boxes denote objects, ovals object types, solid arrows the instance relation, dashed arrows the import relation and downward lines the subtype relation. -
#
customer
" #
#
-
os type
"
unix
@
@
! @ R @
msdos
@
- AT386
@
!
- computer scientist
@ R @
" 6
RISC
6
3
#
computer
"
!
-
SB
@
@
!
@ R @
UL
6
Object Specifications
In this section, we will define what constitutes an object specification resulting from a description in a specification language like that in the example above. The two main issues that we will consider are inheritance and locality. As indicated in the introduction, a specification consists of rules assigned to the object types and to the objects. Typically, the objects store facts only. To be able to write down such rules we first need syntactic constituents (predicates, variables, constants) in form of a signature. For each object type and for each object, a local signature will be defined. This signature consists of symbols introduced in the current object type, symbols inherited from supertypes, and symbols explicitly imported from other object types. We assume that there is a set D of data types given, e.g. D := {int, string, date} including the usual constants, functions, and predicates of these sorts. Given a set S of ˆ object sorts, we denote S ∪ D by S. Definition 3.1 (Signature): A signature Σ = hS, ≺, P, Oi consists of • S, a finite set of object sorts. • ≺, a strict partial order (transitive and irreflexive) on S, the subsort relation. • P , an S × Sˆ∗ × Sˆ∗ -indexed family of disjoint predicate sets, which are also disjoint from S. If p ∈ Ps0 ,s1 ...sn ,sn+1 ...sm , the predicate p is local to s0 , has arity (argument sorts) s1 . . . sm , and s1 . . . sn are a key of p. • O, an S-indexed family of disjoint object name sets, also being disjoint from S and P . If o ∈ Os , the object o has sort s. 6
In the example of section 2, signatures can be built from the symbols defined or imported in an object or object type, together with all those from its supertypes. The symbols defined in the whole specification also form a signature (the global one). Note that multiple inheritance is possible since the subsort relation can be any strict partial order. We use So to denote the sort so of o together with all supersorts and the object name o itself, i.e. So := {o} ∪ {s ∈ S | so s, o ∈ Oso }. The subsort relation ≺ is extended to So by defining o ≺ s for each s ∈ So ∩ S. Definition 3.2 (Rule): Let Σ = hS, ≺, P, Oi be a signature and so ∈ S. ˆ • A variable declaration is a finite S-indexed family X of variable sets. It is written as an enumeration [x1 : s1 ] . . . [xm : sm ] listing all xi ∈ Xsi (i = 1, . . . , m). • A hΣ, so i-rule ϕ has the form [x1 : s1 ] . . . [xm : sm ] ϕ1 ∨ · · · ∨ ϕn with hΣ, X, so iliterals ϕi , where X is the variable declaration corresponding to [x1 : s1 ] . . . [xm : sm ]. • A hΣ, so , Xi-literal is a hΣ, so , Xi-atom or the negation of such an atom. • A hΣ, so , Xi-atom has the form: - t0 .p(t1 , . . . , tm ), where p ∈ Ps0 ,s1 ...sn ,sn+1 ...sm , and each ti is a hΣ, so , Xi-term of sort s′i with s′i si (i = 0, . . . , m), - p(t1 , . . . , tm ), where ti as above and so s0 , - or a datatype predicate applied to data terms. • A hΣ, so , Xi-term of sort s ∈ Sˆ is - an object name from Os (if s ∈ S), - a variable from Xs , - the special symbol self (if s = so ), - or a datatype constant or term of sort s (if s ∈ D). The rules can equivalently be written as implications with a conjunction of literals in the body and a disjunction of literals in the head. In contrast to other approaches, we do not consider the partition of literals into head and body of a rule as significant. In our view, if such an extralogical information is important, then one should declare it explicitly and not intermixed with the actual logical knowledge. To define the complete local specification of an object o, we must include knowledge about its type and all supertypes in So , but not about imported types S − So or objects O − {o}. That knowledge is represented by rules for which we make a distinction between strictly constraining rules and overridable ones. Therefore, a specification contains two So -indexed families of rule sets, one with the constraints, the other with the defaults. Definition 3.3 (Object Specification): An object specification S = hΣ, o, Φ, ∆i consists of • Σ = hS, ≺, P, Oi, a local signature. • o ∈ O, the name of the specified object. Let so be the sort of o. • Φ, an So -indexed family of sets of hΣ, so i-rules, the “known” rules (or constraints). • ∆, an So -indexed family of hΣ, so i-rules, the “assumed” rules (or defaults). 7
The indexing of rule sets by a partially ordered set of sorts will be crucial for the semantics of the defaults, since it attaches priorities to them. For the constraints, however, the indexing could be neglected. They can equally well be seen as defaults of highest priority. Note that this definition allows the rules in some object to assert things about other objects. This should be avoided by further restrictions, since it violates locality. We will come back to this problem when we try to compose specifications in section 6. where we will define (semantically) “tolerant” object specifications.
4
Local Semantics
Now we have to define the model-theoretic semantics of the specifications introduced in the last section, i.e. their set of intended models. Let a signature Σ = hS, ≺, P, Oi be given. Definition 4.1 (Interpretation): A Σ-interpretation I defines • A set I[s] for each object sort s ∈ S such that s1 ≺ s2 implies I[s1 ] ⊆ I[s2 ] for arbitrary s1 , s2 ∈ S. • A relation I[p](d0 ) ⊆ I[s1 ]×· · ·×I[sm ] satisfying the key dependency (as known from relational database theory) (s1 . . . sn ) → (s1 . . . sm ) for each p ∈ Ps0 ,s1 ...sn ,sn+1 ...sm and each d0 ∈ I[s0 ]. • An element I[o] ∈ I[s] for each object name o ∈ Os , s ∈ S, such that distinct names are interpreted by distinct elements. • The standard interpretation of data types. Definition 4.2 (Reduct, object core): The reduct of a Σ-interpretation I to a subsignature Σ′ , written Σ′ -reduct(I), is the interpretation restricted to the elements of the subsignature. For an object o ∈ O, the o-core of an interpretation I is the interpretation of the predicates for that object only, i.e. the relations I[p](I[o]) for all p ∈ P . Definition 4.3 (Evaluation): Let a Σ-interpretation I and a current object do ∈ I[so ] be given. ˆ • An assignment α defines an element α(x) ∈ I[s] for each variable x ∈ Xs , s ∈ S. • The value hI, do , αi[t] of a hΣ, so , Xi-term t under an assignment α is defined by - hI, do , αi[o] := I[o] for object names o ∈ O, - hI, do , αi[self ] := do , - hI, do , αi[x] := α(x) for variables x ∈ X, - and for datatype constants or terms as usual. • The validity of a hΣ, so , Xi-literal ϕ wrt hI, do , αi is defined as follows: - For ϕ ≡ t0 .p(t1 , . . . , tm ): hI, do , αi |= ϕ iff (hI, do , αi[t1 ], . . . , hI, do , αi[tm ]) ∈ I[p](hI, do , αi[t0 ]). 8
- For ϕ ≡ p(t1 , . . . , tm ): hI, do , αi |= ϕ iff (hI, do , αi[t1 ], . . . , hI, do , αi[tm ]) ∈ I[p](do ). - For datatype predicates as usual. - For ϕ ≡ ¬ψ: hI, do , αi |= ϕ iff hI, do , αi 6|= ψ. • Let ϕ ≡ [x1 : s1 ] . . . [xm : sm ]ϕ1 ∨ · · · ∨ ϕn be a (Σ, so )-rule. Then we define: - hI, do , αi |= ϕ iff there is at least one i ∈ {1, . . . , n} such that hI, do , αi |= ϕi . - hI, do i |= ϕ iff hI, do , αi |= ϕ for all assignments α of the variables x1 , . . . , xm . Let an object specification S = hΣ, o, Φ, ∆i be given in the following definitions. A model of S is an interpretation that satisfies all the constraining rules from Φ: Definition 4.4 (Model): A Σ-interpretation I is a model of S (I |= S) iff hI, I[o]i |= ϕ for each ϕ ∈ Φ. A model does not necessarily respect the defaults, so the next goal is to define the intended models as a subset of all models. The intuitive semantics of a default is that it should be assumed if possible without violating the consistency, i.e. if it does not contradict the constraints or other assumed defaults. If there are conflicts between two defaults, we should take their relative priorities into account, i.e. if one is defined in a subtype and one in a supertype, we should assume the one from the subtype, since it is the more specific one. Note that the units of assumption or rejection are not the defaults, but their instances. For example, given a default [x: s]¬p(x) and a constraint p(a), only the instance ¬p(a) of the default is blocked, but we are still interested to assume ¬p(x) for other x. A specific feature of our approach is that we use semantical instances of defaults by means of variable assignments, and not syntactical instances by means of substitutions. Because of this, second order circumscription [McC86] is a special case of our approach. Definition 4.5 (Default Instances): Given a model I of S, the valid instances of the defaults specified in s ∈ So are ∆s,I := {hδ, αi | δ ∈ ∆s , α a corresponding assignment, and hI, I[o], αi |= δ}. An intended model should satisfy a maximal set of default instances, taking their priorities into account. Formally, we define a preference relation (a strict partial order) on the models, and then choose the most preferable models. These “most preferable models” are usually known as “minimal models” since defaults are normally used to minimize predicate extensions. For this reason, we will write I1 < I2 to mean that we prefer I1 to I2 . The minimal model approach is quite standard, only an appropriate preference relation has to be found for the object-oriented environment. If there were no priorities between the defaults, we would simply define I1 < I2 iff ∆s,I1 ⊇ ∆s,I2 for all sorts s and “⊃” for at least one (so I1 satisfies more default instances than I2 ). To respect the priorities, we allow the violation of this condition for some sort s if there is a subsort s′ ≺ s where the strict superset condition holds (since the defaults specified there are more specific and thus should have higher priority when determining which of the two models is considered “better”). 9
Definition 4.6 (Preference Relation): For two models I1 and I2 of S, the model I1 is preferable to I2 (I1 < I2 ) iff • The two interpretations differ in their o-cores only. • For each s ∈ So with ∆s,I1 6⊇ ∆s,I2 there is s′ ∈ So , s′ ≺ s with ∆s′ ,I1 ⊃ ∆s′ ,I2 . • There is an s ∈ So with ∆s,I1 6= ∆s,I2 (to make < a strict partial order). So in effect, we look only at the ≺-minimal sorts s where the two models differ in their valid default instances, and require ∆s,I1 ⊃ ∆s,I2 for these sorts. For the comparison of the two models the defaults specified further up in the inheritance hierarchy are not relevant, since they differ already in defaults of higher priority. This means, we could replace the second condition in the preceding definition by • For each s ∈ So : If ∆s′ ,I1 = ∆s′ ,I2 for all s′ ∈ So with s′ ≺ s, then ∆s,I1 ⊇ ∆s,I2 So for each path in the object type hierarchy the following must hold:
sn
si
s1
?
···
···
)
arbitrary
∆s,I1 ⊃ ∆s,I2
∆s,I1 = ∆s,I2
o
This resembles the definition of the preference relation for prioritized circumscription [Lif86], but it is a generalization, since prioritized circumscription cannot handle multiple inheritance. Furthermore, our preference relation respects the locality of objects, because only local differences can be used for minimization: Models are uncomparable if they differ in the global context. Example 4.7: Let us consider the specification of the object SB as given in section 2 and the following Herbrand interpretations (based on the global signature, true facts are marked with “•”): I0 I1 I2 SB.interested in(RISC) • • SB.interested in(AT386) • RISC.os(unix) • • AT386.os(unix) • • ... ... ... ... I0 is not a model, since it does not satisfy the constraint SB.interested in(RISC). 10
The following default instances are satisfied in these models (marked with •): Specified in sort customer
Default ¬interested in(x)
Assignment I 1 I2 hx/RISCi hx/AT386i • computer scientist interested in(x) ∧ x.os(unix) hx/RISC, y/AT386i • ∧ y.os(unix) → interested in(y) . . . • •
Comparing I1 and I2 , we note that each one satisfies a default that the other does not. But the second default has higher priority than the first one, since it is defined lower in the object type hierarchy (it overrides the first one). So we should have I1 < I2 . Formally, customer is the only sort s with ∆s,I1 6⊇ ∆s,I2 (we even have ∆s,I1 ⊂ ∆s,I2 ). But in the subsort computer scientist of customer the model I1 satisfies strictly more default instances: ∆s,I1 ⊃ ∆s,I2 . For the preference relation, this is decisive, so we get I1 < I2 as intended. 2 Lemma 4.8: The relation < on the models of S is a partial order, i.e. transitive and irreflexive. Proof: • “Transitivity:” Let I1 < I2 and I2 < I3 , so we have to show I1 < I3 . Let s ∈ So be given with ∆s,I1 6⊇ ∆s,I3 . This means that ∆s,I1 6⊇ ∆s,I2 or ∆s,I2 6⊆ ∆s,I3 . But since I1 < I2 and I2 < I3 , there is an s′ ∈ So such that ∆s,I1 ⊃ ∆s′ ,I2 or ∆s,I2 ⊃ ∆s′ ,I3 . Choose a minimal s′ which satisfies one of these two conditions. This minimality condition entails that we have “⊇” in the other case. So we can compose “⊃” with “⊇” to get ∆s,I1 ⊃ ∆s′ ,I3 . We finally have to show that there is s ∈ So with ∆s,I1 6= ∆s,I3 , but this follows directly from I1 < I2 and I2 < I3 if one uses a ≺-minimal sort with ∆s,I1 6= ∆s,I2 or ∆s,I2 6= ∆s,I3 . • “Irreflexiveness:” This follows directly from the definition, since the two interpretations must differ in the truth value of some default instance. 2 Now we select the most preferrable models (the minimal models wrt
