{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

jamilthesis

# The idea is to constrain property clause evaluation

This preview shows page 1. Sign up to view the full content.

This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: ion, of a program to capture inheritance in the form of constrained deduction. The idea is to constrain property clause evaluation such that the clauses are only red in an object when the object is legitimately allowed to use the clause. Intuitively, given a program P , for every p-clause in l we replace the descriptor of the clause with a variable, and restrict the instantiation of the variable in a controlled and deterministic way. The idea of inheritability is the key. Recall that for a given program P and a given p-clause Cl 2 l, its inheritability is known. That is the set of objects in P that can inherit Cl is known. Only thing we have to do is restrict the instantiation of the replaced variable to the set of allowed objects. The following de nition formally captures the idea of i-completion. De nition 4.1 (I-completion) Let P = h l l li be an l-closed program. Then its i-completion, denoted Pi = h i i ii, is a minimal program de ned as follows. i =, i = l and i = l. 80 for every p-clause Cl = p m(t1 : : : tk ) 7! t] B 2 l =) (p m(t1 : : : tk ) 7! t]) B) p= ] V [email protected] ] 2 i where V is a distinguished variable not occur=V ring in Cl, and fp= g is a term replacement. =V 2 7! The intention of the i-completion is clear and intuitive. We replace every self-reference in the clause to a variable V and decide evaluation of the clause in an object V in terms of its inheritability. If V is an instance or subclass of the object p where the clause was originally de ned, and V can legitimately inherit mk from p (i.e., V [email protected] ] is true), then the clause evaluation is allowed. As discussed before, this is consistent with respect to the idea of code reuse and our notion of inheritance. The i-completed p-clauses may be viewed as new kind of is-a constrained p-clauses. This is because for every such clause, V [email protected] ] is true only if V :: p holds true. We can now rely solely upon deduction provided we are able to compute the set of i-atoms of the form p [email protected] ] for P. Again, we can show that an i-completed program admits an identical class of canonical models with respect to its original ORLog program, and hence are equivalent. Let us turn to our running example to see how i-completion works. 7! 7! 7! 7! follows where Example 4.1 Consider program P1 in Example 3.2. The i-completion of P1 is as 1i =: 1i (1) (2) (3) (4) (5) := (6) (7) (8) (9) (10) (11) o ]: p ]: q ]: r ]: X ] X : o: Q ]: r : p: r : q: q : o: p : o: r t0 < p]: p t0 > r]: X :: X X ]: X :: Y X : Z Z :: Y: P u0 ] P : o: o m0 ]: o s0 ]: q t0 ]: p s0 ]: p t0 ]: Q v0 ]: ! ! ! ! ! ! ! ! ! 1i (12) V V (13) V (14) V := V (15) V (16) V (17) V (18) V m ! X] V s ! X] v ! g] V [email protected] ]: s ! 5] V [email protected] ]: u ! d] V : o P @u0 ]: s ! 2] V [email protected] ]: t ! a] V [email protected] ]: t ! c] V [email protected] ]: v ! g] V [email protected] ]: ! ! ! ! ! ! ! 2 81 4.3.3 Computing Inheritability of Clauses using r Recall that our goal is to encode ORLog programs into a rst-order language and use a bottom-up evaluator to compute the encoded intended model of the program. Since rst-order bottom-up evaluators are only capable of deductions, we need to provide a means to compute the set of encoded i-atoms so that the evaluator can use them to evaluate the i-completed p-clauses that are encoded. So far, we have only provided a means to compute the locality of p-clauses and to derive the partial order of the is-a hierarchy through l-closure. Finally, by taking the i-completion we accounted for a transformation of clause inheritance into constrained deductions. 1. uses(Object, Object, Name, Arity, Method type) local(Object, Name, Arity, Method type). 2. uses(Source, Object, Name, Arity, Method type) possible(Source, Object, Name, Arity, Method type), :local(Object, Name, Arity, Method type), local(Source, Name, Arity, Method type), Source6=Object. 3. possible(Source, Object, Name, Arity, Method type) parent(Object, Some object), Object6=Some object, uses(Source, Some object, Name, Arity, Method type), :withdraw(Object, Some object, Name, Arity, Method type), :con ict(Source, Object, Some object, Name, Arity, Method type). 4. con ict(Source, Object, Some object, Name, Arity, Method type) parent(Object, Another object), Object6=Another object, uses(Another source, Another object, Name, Arity, Method type), :withdraw(Object, Another object, Name, Arity, Method type), Some object6=Another object, Another source6=Source. Figure 11: Implementation of r using a strati ed predicate logic program P . r Now, to be able to compute inheritability as stipulated in the de nition of the r function (De nition 3.3), we present the following set of encoded rules P in Figure 11. Note that the rules involve negation and are locally strati able 67] since the underlying is-a hierarchy is acyclic by assumption. Observe the dependency relation of predicates in P and in encode( i) as depicted in Figure 12. Intuitively, it is easy to see that the parent relation supplies new tuples to the rules for conflict and possible. r r 82 The rules for uses, possible an...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online