Actions as Prolog Programs Marcus V. Tolentino,
Paulo E. Santos, Flavio S. C. da Silva, University of Sao Paulo Laboratory of Integrated Systems Sao Paulo, SP, Brazil fmarcus,santos,
[email protected] [email protected]
Abstract As an extention of the TRASYS approach to reasoning about actions, this work presents a new step in the direction to the transposition of the gap between action formalisms and their real execution inside planning environments. We try to clarify some points of the former paper by presenting a re-structured overview of the Transaction Logic formalism and proposing some modifications to the action model which will allow the use of non-atomic formulae in the world model. Aiming an efficient method for executing action specifications, we present how could these specifications be rendered into a PROLOG program.
1. Introduction In the last years, the number of papers related to the formal description of planning systems has increased significantly. There are strong justifications for this approach, for instance it provides the means to establish the system’s formal semantic so that we can better understand the system’s intrinsic computations, limitations and complexity. In planning, the main difficulty to execute formal specifications is the existence of a gap between action formalisms and real planners. Most of these formalisms are useful to action specification and world modeling. On the other hand, a planner implementation must not only consider the real world uncertainties but also deals with complex computations like search strategies, heuristics, domain modeling and user interfaces. Aiming the transposition of this gap, a recent paper proposed an action model named TRASYS (Transaction Logic Action System) [11]. Originally, inspired in the possible worlds formalism [10], in its corrections presented in Supported by grant from the CNPq.
Marcio Rillo
[4, 12] and in the Transaction Logic (TR) formalism [2, 3, 1], TRASYS endeavours to bridge the gap between a formal action model and its real execution inside planning environments. In fact, being part of a more ambitious project which aims an ex ante implementation of a planner underlied on TR, the action model presented in [11] was a step in this direction. Strongly underlied on TR, this action system enables a clear and declarative analysis of the update phenomena commonly found in the process of reasoning about actions and change. This work is an extention of the original TRASYS proposal. Firstly, we try to clarify some points of the former paper by presenting a re-structured overview of the TR formalism. We also propose some modifications to the action model which will allow the use of non-atomic formulae in the world model. Then, we present how could an action specification in TR be rendered into a PROLOG program.
2. Background on Transaction Logic Programming TR is a formalism basically applicable to the study of problems related to the update phenomena. In planning this kind of problem is very common, since the execution of actions in real environments could be modeled by suitable updates applied to a set of logic formulae. Generally, considering a TR programming system, its interaction with the user should be similar to logic languages like PROLOG or relational database systems. The user would build rules which describe transactions, ask for the execution of a certain transaction and the system would answer presenting solutions to the transaction or updating the database. An important difference between TR and PROLOG is that updates in PROLOG are not logical, if a user performs a database update and afterwards, for some reason, the execution fails, the database is not rolled back to its original state.
2.1. Syntax The TR syntax is similar to classical first order logic, except the fact that it has an additional binary operator, , called serial conjunction, which give us an appropriate way to combine transactions executing them sequentially. For instance, the expression a b denotes a serial conjunction which is composed of transaction a followed by transaction b, informally this expression means: “First execute transaction a, and then execute transaction b”. Dual to this operator is the serial disjuntion, , defined by the following equivalence relation :a :b $ :(b a). Using the same representation presented in [7], transaction formulae are defined as follows: 1. An atomic formula is an expression of the form p(t1; :::; tn), where p is a predicate symbol, and t1; :::; tn are function terms as in first-order-logic. 2. If and are transaction formulae, then so are the following expressions:
^ , _ , , , and : . (8X) and (9X) , where X is a variable.
2.4. Model Theory
2.2. Serial-Horn Transaction Logic Program TR also has a more restrictive serial-Horn version which allows the user to program transactions using rule definitions. The TRASYS action system [11] uses this TR subset as the action specification language. We will also use this TR subset and action model to specify and execute actions. A serial-Horn TR program consists of two parts: the transaction base, which is a finite set P of serial-Horn rules specifying the user defined transactions, and the database, which is a set D of first order logic formulae, where the transaction base can insert and remove formulae. SerialHorn rules are expressions of the form:
p(X1 ; X2 ; :::; Xn)
identifier, i, Od (i) is a set of first order formulae which represents the truths about the database state. Depending on the application domain, different kinds of state data oracles can be used. Different from the approach presented in [11], we will not use the relational oracle, since it limits the state identifier to ground atomic formulae. As could be seen in section 3, in our approach the world model can also be represented by non-atomic classical Horn rules. Hence we decided to use the classical Horn oracle, where a state identifier is represented by a set of classical Horn rules, D, and Od (D) is D augmented with the least Herbrand model of D. The application domain also dictates the kind of transactions which causes only one database update called elementary update or elementary state transition. This kind of transition is specified outside TR through the transition oracle, Ot , which is a function that maps pairs of states to sets of variable free atomic formulae. In this work the atomic formulae b:ins and b:del represent, respectively, elementary state transitions which insert and delete a formula b from the database, i.e., ins(b) 2 Ot(D; D + fbg) e del(b) 2 Ot(D; D ? fbg)1.
(1)
where p(X1 ; X2 ; :::; Xn), (n 0), is an atomic formula and is a serial conjuntion of the form a1 a2 ::: ak , (k 0). A procedural interpretation of rule 1 is the following: “to execute transaction p(X1 ; X2; :::; Xn) is sufficient to execute transaction ”. As in Horn clauses, the symbol p in rule 1 is the name of the transaction, the arguments X1 ; X2 ; :::; Xn are the input paramenters, and is the transaction definition. 2.3. Database States and Elementary Updates The TR semantics of a database state is defined by a special mechanism called state data oracle, Od . To each state
The TR semantics is built on the concept of sequence of database states named paths. Like the modal logic semantics, a structure consists of a set of states and each state represents a database. However, the truths in TR are not defined on arcs between database states, but on paths. Definition: (Path structure) [2] Let L be a language having a state data oracle, Od , and a state transition oracle, Ot. A path of length k on L is a finite and arbitrary sequence of state identifiers, hD1 ; :::; Dki, where k 1. The set of all paths in L is called Paths(L). A path structure M on L is the triple hU; If ; Ipath i, where:
U is a set called domain of M ; If is an interpretation of function symbols occurring in L;
Ipath
is a mapping from every path in Paths(L) to a semantic structure in Struct(U; If ). The set Struct(U; If ) is the set of all classical first order structures on L of the form hU; If ; Ip i, where Ip is the mapping that interprets the predicate symbols P as a relation in U ; U and If are interpreted in the same way as in M .
Definition: (Model) A path structure (M ) is a model of a TR formula , written M j= , iff M; j= for every path . 1 The operators
+ and ? denote, respectively, set union and difference.
Definition: (Executional Entailment) Let P be a transaction base, D an inicial database, a transaction formula and D0 ; :::; Dn a sequence of database states. Then P; D0; :::; Dn j= is true iff M; hD0 ; ::Dni j= for every model, M , of P . For any transaction base P , any sequence of database states D0 ; :::; Dn, and any transaction formulae and , the following statements are true:
If P; D ; :::; Dn j= and P; D ; :::; Dn j= then P; D ; :::; Dn j= ^ . If P; D ; :::; Di j= and P; Di ; :::; Dn j= then P; D ; :::; Dn j= . If is in P , and P; D ; :::; Dn j= then P; D ; :::; Dn j= . If 2 Ot (D ; D ) then P; D ; D j= . If 2 Od (D ) then P; D j= where is a first 0
0
0
0
0
0
0
0
1
0
0
1
0
order formula.
3. Actions in the TRASYS Framework The basic idea of the TRASYS approach is to determine the effects of an action which invokes elementary updates applied in a world state described as a set D of positive literals. The TR execution deduction, which underlies TRASYS action execution, updates this set in such a way that the final state D0 is consistent with the action post-conditions. However, defining a world state composed only of atoms is very restrictive. The TRASYS formalization lacks in its definition the possibility of expressing the world state also with non-atomic formulae. Although, we must be carefull when opening this possibility, since actions could update these formulae generating inconsistencies in the world model. With this in mind, we borrowed from Lifschitz the notion of essentialnnon-essential formulae [8], and used this concept to define the soundness of TRASYS action operators. Therefore, in our alternative TRASYS approach, considering L a language of the TR serial-Horn version, an instance of an action system is the triple:
= hD; K; hA; R; Sii
2.5. Proof Theory As was previously mentioned, TRASYS uses the serialHorn TR subset to build action specifications. To understand the way these formal specifications are executed we will present a short description of the TR inference system. In TR an inference is successful if and only if it finds an execution path to the transaction , i.e., a sequence of database states D0 ; ; Dn in such a way that P; D0; ; Dn j= . The inference system is composed of one axiom and three inference rules: Axiom: P; D ` (). Inference Rules: In rules 1-3 bellow, is a substitution, a is an atomic formula and rest is a serial conjunction. 1. Defining transactions: if b is a rule from P , b `(9)( rest) and a unify with the m.g.u , then P;D P;D`(9)(a rest)
2. Querying the database: if a and rest share no variP;D`(9)rest ables and Od (D) j=c a, then P;D `(9)(a rest)
3. Performing elementary updates: if a and rest share no variables and a 2 Ot(D1 ; D2 ), then
P;D2 `(9)rest P;D1 `(9)(a rest)
The executional deduction must obey the following conditions:
1. the initial sequent has the form P; D0 ` (), for some database D0 ; 2. the final sequent has the form some database D;
P; D ` (9) , for
3. each sequent is obtained from the previous sequent by one of the inference rules.
where
D L consists of a world model, is a set of classical Horn rules such that each atomic rule , 2 D, is considered essential, and the others are considered non-essentials.
K L represents the domain knowledge, is a set of classical Horn rules;
A L is the action operators, is a set of positive literals;
R; S L are action operators descriptions, are sets of serial-Horn rules.
An action operator description is a set of serial-Horn rules represented as follows:
prec1 effects1 pos1 prec2 effects2 pos2 :::::: precn effectsn posn where 2 A; the pre-conditions preci , the action effects effectsi and the post-conditions posi are serial conjunctions or the invocation of other transactions. Using this representation, the option for a specific rule will depend on the context defined by pre-condition preci . Consequently, it is possible to define actions which effects depend on the context they are executed. In this representation, nothing prevents the user from omitting the transactions preci , effectsi or posi in the rules definition. There
are circumstances that these omissions are opportune, e.g., when it is necessary to represent an action where the satisfaction of a pre-condition implies no updates in the database. The followingexpressions represent the execution entailment of an action rule:
P; D0 ; ; Di j= preci P; Di ; ; Dl j= effectsi P; Dl ; ; Dn j= posi Using an approach similar to [8], now it is time to define under which conditions the action system can be considered sound. Let D0 be the initial world state, D be any other world state. If an action is a partial function f from states to states and f(D) is defined, then we say that f is applicable in the state D, and f(D) is the result of the action. A world model D is satisfied in a state D if every element of D is satisfied in D. We assume that an action fa is associated with each action operator , 2 A. An action operator description is sound relative to f , if for every state D such that the pre-condition preci is satisfied in D,
f is applicable in D; every essential sentence which is satisfied in D and is
not removed by effectsi is satisfied in f(D);
non-essential sentences are never removed from D; every non-essential sentence inserted in D by effectsi is satisfied in all states of the world; the action post-condition posi is satisfied in f(D);
is sound if
D is satisfied in the initial state D ; every sentence in D which is not essential is satisfied 0
0
0
in all states of the world;
every action operator description is sound relative to f .
To illustrate the previous definitions we will analyse an example similar to the one presented in [10]. The following figure represents a domain where a robot executes actions in a household environment by moving objects from place to place. The atom on(X; Y ) determines the object positions (it means: object X is on object Y ). Therefore, world model is represented by the following initial database state:
9 8 on(ball; tpshelf) on(tv; book) = < on(book; btmshelf) ; D = : on(box; duct) rounded(ball) 0
The displacement of the objects must be in accordance with some constraints, e.g., the air ducts can not be blocked,
the television could be damaged if the robot puts an object on its top, and it is not possible to put an object on a rounded one. These constrains represent the domain of knowledge and is represented by the following set K of classical Horn rules:
9 8 blocked(D) on(X; D) = < K = : damage(tv) on(X; tv) stuffy(room) blocked(duct) ;
In this action system the set A = fmove(X; Y )g represents the action operators, and the action operator descriptions are represented by the set R [ S which has the following serial Horn rules:
move(X; Y ) prec(X; Y )
effect mv(X; Y ) posc(X; Y ) move(X; Y ) on(X; Y ) prec(X; Y ) clear(X)
chkClearFloor(Y ) :rounded(Y ) chkClearFloor(floor) chkClearFloor(X) clear(X) clear(X) :on(Y; X) clear(X) del(on(Y; X))
on(Z; W) Z Y X Z
clear(Y ) clear(Z) ins(on(Y; Z)) effect mv(X; Y ) on(X; Z)
del(on(X; Z)) ins(on(X; Y )) posc(X; Y ) on(X; Y )
:damage(tv) :stuffy(room) posc(X; Y ) damage(tv)
on(X; tv) move(X; floor) posc(X; Y ) stuffy(room)
on(X; duct) move(X; floor)
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
We could note in this action specification that the action clear(X) has two distinct roles: verify if an object X does not have any other on its top (rule 6); move an object Y to another place if Y is on X , (rule 7). The action postconditions (rule 10 and 11) prevent the occurrence of objects damaging the television or blocking the air duct. The executional deduction of a transaction
? ? move(ball; floor) could be summarized as follows: P; D0 ` prec(ball; floor)
}|
z
{
effect mv(ball; floor)
posc(ball; | {z floor)}
if P; D0 ` clear(ball) chkClearFloor(floor)
:rounded(floor)
.. .
.. .
.. .
.. .
if P; D0 ` effect mv(ball; floor) if P; D0 ` on(ball; tpshelf)
del(on(ball; tpshelf)) ins(on(ball; floor)) D }| { z ? f on(ball; tpshelf) g if P; D | {z +fon(ball; floor)g} ` 1
0
posc(ball; floor)
D2
if P; D2 ` on(ball; floor) :damage(tv)
z
}|
{
this transaction fails
:stuffy(room)
if P; D2 ` stuffy(room) on(box; duct)
move(box; floor) .. .
.. .
if P; D2 ? fon(box; duct)g + fon(box; floor)g ` ( ) Due to the limited space, we decided to omit some steps of the executional deduction process. We tried to illustrate in this example one interesting characteristc of our action model which is the capability to represent alternative effects for actions applied in one context. The reader could observe that the action move has three post-conditions: check if the object was moved from one place to another; certify if the television is not damaged and the duct is not blocked. Therefore, the satisfaction of one specific post-condition will depend on what happened during the action effects. We can observe in this example that in the sixth sequent, when the action postcondition posc(ball; floor) is invoked, though the query on(ball; floor) is satisfied in the database state D2 , the duct is blocked. Hence, this post-condition fails and the other post-conditioninvokes an action to move the object from the duct.
4. From TRASYS specifications to PROLOG Programs As was mentioned in section 1, our final goal, which will be topic to forthcoming papers, is to build a planner with TR
as a specification and implementation language. Firstly, being an extension of first order logic, the most natural way to execute TR formalizations is rendering them into PROLOG code. Thus, equivalence between PROLOG and TR programs must be proved. Several definitions of equivalence between logic programs can be found in [6, 9, 5], but we are here interested in a constructive proof. In fact, this proof is a translation algorithm from serial-Horn programs to PROLOG code. According to [5], given an extension L of the SLDresolution that builds in a set A of axioms, it is shown that there is a transformation on logic programs such that: i)There is a refutation from a program P and a goal G according to L iff there is an SLD-refutation from the transformed program (P) and G; ii) (P) and P [ A are equivalent w.r.t. correct answer substitution criteria [6, 5]. Clearly, looking at its proof theory, TR is an extension of the SLD-resolution. As could be seen in section 2, the TR resolution improves the SLD-resolution with two more inference rules. Hence, the proof of TR and PROLOG equivalence will be based on a mapping of one language into the other with preserved arity. This issue is stated in the following theorem: Theorem (TR and PROLOG equivalence): Let us first define a program P as being P [ where P ; LP are respectively a logic program and a database state written in the logic language LP . Let P 0 be a PROLOG program, G a goal and P a TR program that is a finite extension of P 0. P [ G and P 0 [ G are equivalents if there is a mapping from P to P 0. Proof: Firstly, we know that a serial-Horn transaction rule may have in its tail the invocation of other rules, queries or elementary state transitions. Moreover, syntactically, serial-Horn rules are similar to PROLOG rules, except the serial logical connective . Therefore, we use an algorithm which recursively analyses the contents of the serial-Horn rules while rendering them into PROLOG rules. Let P be a serial-Horn program consisted of k serial-Horn rules, then a mapping from each k-th rule in P to a PROLOG rule could be summarized as the following algorithm: 1. let be the k-th rule head and is k-th rule tail, i.e., a serial conjunction; 2. if is nil, then is in PROLOG syntax; 3. otherwise, for each b in do as follows:
the ’s are translated to the classical conjunction operator “;”;
if b is a query to the TR database, it is translated
to the predicate query(b);
otherwise b remains the same;
In our approach, each database formula is encapsulated in the PROLOG database structure db( ). By this way, during execution time, when a query transaction b is invocated, the predicate query(b) will search for formula b inside the database structures db( ). We know that, semantically, the TR elementary state transitions ins and del are different from the PROLOG predicates assert and retract. Therefore, after translating the TR program to PROLOG code, we must emulate the TR way of rolling back accomplished updates to execute this code. Hung [7] presented a solution to this problem which is centered on never removing formulae from the database. Instead, he used delete tags to mark them as deleted. The insert tag and delete tag of a formula are defined by ip( ) and dp( ), respectively. Therefore, the transactions ins and del could be defined by the following PROLOG rules: onbktk(X). onbktk(X) :- call(X), !, fail. insp(X) :- assert(X), onbktk(retract(X)). delp(X) :- retract(X), !, onbktk(assert(X)). delp(X). ins(X) :- not(db(ip(X))), insp(db(ip(X))), !. ins(X) :- db(ip(X)), delp(db(dp(X))). del(X) :- db(ip(X)), ins(db(dp(X))).
5. Results and Open Issues Based in the proof of the equivalence theorem between serial-Horn programs and PROLOG programs, our group has been developing the first TRASYS environment and compiler prototype. This prototype was used as an important tool through which the user can dinamically build and execute action specifications. The modifications to the TRASYS approach suggested in this work are consequence of some problems we have faced during the specification and execution of domain examples inside this environment. As extentions to this work, we are nowadays searching for a suitable formal representation for plans in the TR framework. We also intend to add to our formalism the possibility of dealing with inconsistencies in the world model.
References [1] M. C. A.J. Bonner, M. Kifer. Database programming in transaction logic. In C. A. Ohori and D. Shasha, editors, Proceedings of the International Workshop on Database Programming Languages, pages 309–337, Feb 1994. [2] M. K. A.J. Bonner. Transaction logic programming. In Intl. Conference on Logic Programming (ICLP), Jun 1993. [3] M. K. A.J. Bonner. An overview of transaction logic. Theoretical Computer Science, 133:205–265, Out 1994. [4] J. H. G. Brewka. How to do things with worlds: On formalizing actions and plans. Journal of Logic and Computation, 3:517–532, 1993.
[5] C. K. Hung. Equivalent logic programs and the semantics of meta interpreters. Technical Report 154, Department of Computer Science The University of Western Ontario, 1986. [6] C. K. Hung. Equivalent logic programs. J. Logic Programming, 8:187–199, 1990. [7] S. Hung. Implementation and performance of transaction logic in prolog. Master’s thesis, University of Toronto, 1996. [8] V. Lifschitz. On the semantics of strips. In M. Georgeff and L. L. A, editors, Proc. 1986 Workshop Reasoning about Actions and Plans, pages 1–9, 1987. [9] M. J. Maher. Equivalences of logic programs. Lecture Notes in Computer Science, 225:410–424, 1986. [10] D. M.L.Ginsberg. Reasoning about action i: A possible worlds approach. Journal of Artificial Intelligence, 35:165– 195, 1988. [11] M. Tolentino. On the formalization of actions using transaction logic. In Proceedings of the ECAI-96. Workshop on Cross-fertilization in Planning, Aug 96. Budapeste. [12] M. Winslett. Reasoning about action using possible models approach. In M. Kaufmann, editor, Proceedings of the 7th American National Conference on Artificial intelligence (AAAI-88), pages 89–93, 1988.
