Robert Kowalski and Fariba Sadri. Imperial College ...... Gordon, E. and Logan, B., Game Over: You have been beaten by a GRUE, In Challenges in Game ...
Teleo-Reactive Abductive Logic Programs Robert Kowalski and Fariba Sadri Imperial College London, {rak, fs}@doc.ic.ac.uk Abstract. Teleo-reactive (TR) programs are a variety of production systems with a destructively updated database that represents the current state of the environment. They combine proactive behaviour, which is goal-oriented, with reactive behaviour, which is sensitive to the changing environment. They can take advantage of situations in which the environment opportunistically solves the system’s goals, recover gracefully when the environment destroys solutions of its goals, and abort durative actions when higher priority goals need more urgent attention. In this paper, we present an abductive logic programming (ALP) representation of TR programs, following the example of our ALP representation of the logic-based production system language LPS. The operational semantics of the representation employs a destructively updated database, which represents the current state of the environment, and avoids the frame problem of explicitly reasoning about the persistence of facts that are not affected by the updates. The model-theoretic semantics of the representation is defined by associating a logic program with the TR program, the sequence of observations and actions, and the succession of database states. In the semantics, the task is to generate actions so that all of the program’s goals are true in a minimal model of this associated logic program.
Keywords: teleo-reactive programs, abductive logic programming, production systems, LPS.
1 Introduction Tele-reactive (TR) programs were introduced by Nils Nilsson in a technical report in 1992 [14] and an article [15] published in 1994. In [16], a TR program is characterized as “an agent control program that robustly directs the agent towards a goal in a manner that continuously takes into account the agent’s changing perceptions of the environment.” These characteristics have contributed to a growing interest in TR programs in recent years. For example: Coffey and Clark [3] propose a BDI-style agent architecture that uses teleo-reactive plans in its plan library. Marinovic et al [13] use TR programs to represent workflows and policies in pervasive healthcare. Gordon and Logan [4] use TR programs to program game agents. Gubisch et al [5] use an architecture based on TR programs for mobile robot control and apply it to soccer robots. Broda and Hogger [23] present a systematic procedure for constructing TR programs. TR programs are written and executed like ordered production rules:
K1 a1 …… Ki ai ….
Km am The list is checked from the top, and the first rule whose conditions Ki are satisfied fires, and its action ai is executed. In effect, the conditions Ki of the i-th rule implicitly include the negations of all of the conditions of the previous i-1 rules. Actions ai are atomic formulae, representing a primitive action, an invocation of another TR program, or a recursive invocation of the same program with different parameters. As we argue elsewhere [7, 24], rules in production systems have the syntax of logical formulae, but do not have a logical semantics. One of the main goals of this paper is to show how to translate TR programs into logical form, in such a way that the operational semantics of TR programs is sound with respect to a modeltheoretic semantics. One of the biggest challenges of the translation is to do justice to the fact that actions can be durative, in the sense that they are executed continuously, as long as their corresponding condition remains the highest true condition in the list. When the highest true condition changes the action also changes accordingly. In a hierarchy of TR programs, in which one program calls another, the conditions of all the programs in the hierarchy are checked continuously. The action that is executed is the one associated with the highest true condition in the “highest program in the stack of called programs”. In many cases, the program is associated with an explicit goal, which is the first condition K1 in the list, and the associated action a1 is nil. A program has the regression property if whenever the action ai of a rule Ki ai is executed then an earlier condition Kj (j M operate(T) operate(T) operate(T ) operate(T ) operate(T)
water-level(W, T) high < W pump(T) water-level(W, T) low < W pump-active(T ) pump(T) water-level(W, T) high W low Water(T) water-level(W, T) high W ¬ pump-active(T)
Notice that the condition high W of the third rule for operate(T) is redundant and can be deleted. Moreover, the defined durative action operate(T) can be compiled away, replacing it by its definition, giving the program: mine-pump(T) methane-level(M, T) critical M alarm(T) mine-pump(T) methane-level (M, T) critical > M water-level (W, T) high < W pump(T) mine-pump(T) methane-level (M, T) critical > M water-level (W, T) low < W pump-active T pump(T) mine-pump(T) methane-level (M, T) critical > M water-level (W, T) high W low Water mine-pump(T) methane-level (M, T) critical > M water-level (W, T) high W ¬ pump-active(T) Notice that in the translation of a rule Ki+1 ai+1, the corresponding condition of the LTR clause contains the explicit negations of all the conditions of the higher-level rules K1 a1 … Ki ai. This syntactic redundancy can be avoided in the LTR syntax by employing a similar convention to that employed in the TR syntax or by using a special operator like the “cut” in Prolog. The inefficiency of re-evaluating these conditions in the operational semantics can be avoided, as it is in the TR operational semantics, in the Prolog implementation of cut, or by means of tabling [21]. The operational semantics of LTR is based on the operational semantics of ALPA, similarly to the way in which the operational semantics of LPS is based on that of ALPA. It also mimics the operational semantics of TR programs. It is illustrated by the following example, in which critical, high and low are 100, 20 and 10, respectively. time1 time2 time3 time4 time5 time6 time7 time8 time9 time10
7
methane-level 66 77 88 99 99 100 110 104 98 98
water-level 18 20 20.0001 20.00001 15 12 18 19 19 15
pump-active no no no yes yes yes no no no no
alarm no no no no no yes yes yes no no
pump no no yes yes yes no no no no no
Here the primitive actions alarm and pump are durative actions, which are turned on automatically when their conditions hold, and turned off when their conditions do not hold. For example, at time6, the conditions for pump fail to hold, and the pump is turned off, when the conditions of the higher priority rule for sounding the alarm hold. The declarative semantics of such a LTR program, consisting of an integrity constraint and a locally stratified program P can be understood naturally in ALPA [8] terms: The task is to generate a set of ground actions such that the integrity constraint, in this case observed(T) mine-pump(T), is true in the perfect model of P Obs , where Obs is the set of all ground facts representing the input observations, including ground facts of the form observed(t) for every time t that an observation is made. Notice that this semantics does not depend upon the nature or even the sequencing of time points. In theory, the set of time points could be uncountably large, represented for example by the set of positive real numbers. Such a semantics would be appropriate for hardware implementations using analogue electronic circuits, as suggested by Nilsson [15]. Notice also that primitive actions are assumed to take place at the same time T as the conditions that trigger the actions. This is an idealization, which simplifies the theory, like the assumption of friction-less motion in the laws of physics. 3.2 TR and LTR programs with an internal database. The simple semantics above is inadequate for TR-programs that employ a destructively updated database as a representation of the current state of the environment. For such programs it is necessary to define the semantics relative to a sequence of discrete database states. Consider, for example, Nilsson’s tower-building example with towers represented as lists S, using LISP notation, where car(S) is the top block on the sub-tower cdr(S) [16]: make-tower(S); S is a list of blocks, {tower(S) → nil ordered(S) → unpile(car(S)) null(cdr(S)) → move-to-table(car(S)) tower(cdr(S))→move(car(S), cadr(S)) true → make-tower(cdr(S)) } move-to-table(X); X is a block, {on(X,table) → nil holding(Y) → putdown(Y, table)) clear(X) → pickup(X) true → unpile(X) }
8
move(X, Y); X and Y are blocks, {on(X,Y) → nil holding(X)clear(Y) → putdown(X,Y) holding(X) → putdown(Z, table)) clear(X) clear(Y) → pickup(X) clear(Y) → unpile(X) true → unpile(Y) } unpile(X); X is a block, {clear(X) → nil on(Y,X) → move-to-table(Y) }
The TR-program in this example manages a small deductive database, which records the current location of blocks and whether the robot is holding a block. When a primitive action, such as putdown is executed, its effects are sensed and the facts affected by the action are updated in the database. Facts that are not affected are not updated, so frame axioms are unnecessary. Nilsson allows for the possibility that primitive actions might affect the database directly, but he does not explain how the effects of such internal actions are specified. In LPS we use an explicit event theory Ev without frame axioms for this purpose. We also use an event theory in LTR. Like the event theory in LPS, the event theory Ev in LTR specifies how externally observed events and internally generated actions update the extensional predicates of the database. Ev also specifies how the database is updated when facts involving the extensional predicates are observed. In addition to extensional predicates, defined by ground atomic facts, the deductive database can contain intensional predicates, defined by “perceptual rules”, which “create increasingly abstract predicates from simpler ones”. In Nilsson’s towerbuilding example, these rules have logic programming form. Here is the translation of these rules into a locally stratified logic program, with an explicit time parameter, using the Prolog convention that [H|S] represents a list with first element H, followed by list S: tower([Block|S], T) ordered([Block|S], T) X on(X, Block, T) ordered([Block1, Block2|S], T) ordered([Block2|S],T) on(Block1, Block2, T) ordered([Block], T) on(Block, table, T) clear(Block, T) X on(X, Block, T) holding(Block, T) Nilsson describes a computational architecture in which such rules are executed forwards, to add new facts to the database, using a truth maintenance system to delete derived facts when the extensional facts that support them are deleted. Our declarative and operational semantics are neutral with respect to whether the definitions of the intensional predicates are executed forwards or backward. If they are executed backwards, Prolog-style, then truth maintenance is unnecessary. Here is the translation of make-tower1. The translation of the other programs is similar: make-tower(S, T) tower(S, T) make-tower([Block|S], T) tower([Block|S], T) ordered([Block|S], T) unpile(Block, T) make-tower([Block], T) tower([Block], T) ordered([Block], T) move-to-table(Block, T) make-tower([Block1, Block2|S], T) tower([Block1, Block2|S], T) ordered([Block1, Block2|S], T) tower([Block2|S], T) move(Block1, Block2, T) 1
The conditions null(S) and ¬null([Block2|S]), respectively, in the 3rd and 4th clauses are unnecessary because they are implied by the list data structure.
9
make-tower([Block|S], T) tower([Block|S]), T) ordered([Block|S], T) null(S, T) tower(S, T) make-tower(S, T)
Arguably, the semantics of the top-level goal of the TR program is ambiguous. Given the problem of building a specific tower, say [a, b, c], is the goal a (one-off) achievement goal, to make the tower and then terminate? Or is it a (perpetual) maintenance goal, to make the tower and rebuild it if and when the environment interferes with it? In LTR, the different kinds of goals can be accommodated by means of a single integrity constraint: required-tower(Tower, T) make-tower(Tower, T) where required-tower is an extensional predicate, instances of which are updated by using an event theory Ev, which contains such clauses as: initiates(request-tower(Tower, T), required-tower(Tower)) terminates(cancel-tower(Tower, T), required-tower(Tower)) Using the event theory, an observation of an external event request-tower(tower, t) adds the fact required-tower(tower) to the database, and an observation of an external event cancel-tower(tower, t) deletes the fact required-tower(tower) from the database. In general, the declarative semantics of TR programs with a destructively updated database is an extension of the semantics of TR programs without a database. Informally speaking, given an initial database and sequence of sensed observations, the task is to generate a set of ground actions such that all the integrity constraints are true in the perfect model determined by the program, observations, actions and associated sequence of database states. More precisely and more formally: Given the representation of a TR program as a locally stratified logic program P and a set IC of one or more integrity constraints with explicit time, a time-stamped representation DB0 of the initial state of the database, a set I of definitions of intensional predicates with explicit representation of time, a sequence Obs0, …, Obsi, … of sets of time-stamped input observations, and an event theory Ev, the task is to generate a sequence of time-stamped ground actions a0, …, ai,… with an associated sequence DB1, … , DBi, … of time-stamped extensional databases, such that all the integrity constraints IC are true in the perfect model of P I Obs {a0, …, ai,…} DB, where Obs = Obs0 … Obsi … and DB = DB0 … DBi … . It is possible to show that a TR style of operational semantics, using destructive database updates, is sound with respect to this semantics, using an argument similar to that for showing the soundness of the operational semantics of LPS [10].
10
4 Alternative ALP Representations of TR programs We argued above that the semantics of the top-level goal of a TR program is ambiguous. Here we will see that if the top-level goal is intended as a maintenance goal, then it is often natural to represent the program in ALP form as a set of conditional integrity constraints. For example, the compiled version of the minepump example can be represented simply by three integrity constraints: methane-level(M, T) critical M alarm(T) methane-level (M, T) critical > M water-level (W, T) high < W pump(T) methane-level (M, T) critical > M water-level (W, T) low < W pump-active T pump(T) In this case the logic program P defines only the auxiliary inequality predicate The semantics of subsection 3.1 for TR programs with an internal database still applies, but without the need for additional observations of the form observed(t): The task is to generate a set of ground actions such that the integrity constraints IC are all true in the perfect model of P Obs , where Obs is the set of all ground facts representing the input observations. In some versions of ALP [8] conditionals can occur in the conditions of logic programs. Thus we can write, for example: mine-pump(T)[methane-level(M, T) critical M alarm(T)] [methane-level (M, T) critical > M operate(T)] operate(T) [water-level (W, T) high < W pump(T)] [water-level (W, T) low < W pump-active (T) pump(T)] This (conditional) version is equivalent to the first version in subsection 3.1, in which mine-pump and operate are defined by normal logic programs. More generally: Theorem: given that
(A B) (C D) (A B) (C D) (¬A ¬C) C ¬A (equivalently A ¬C).
Note that the assumption C ¬A holds for all LTR programs. Proof: We use the fact that (P Q) (¬P Q) (¬P (P Q)). (A B) (C D) (¬A (A B)) (¬C (C D)) (¬A ¬C) (¬A C D) (A B ¬C) (A B C D) Note that (¬A C D) ↔ (C D) because C ¬A. We need to show (A B ¬C) (A B C D) A B.
11
(A B ¬C) A B because A ¬C, and (A B C D) false because C ¬A.
But
Both ways of representing TR programs as logic programs can also be written as equivalences. For example: mine-pump(T) [methane-level(M, T) critical M alarm(T)] [methane-level (M, T) critical > M operate(T)] operate(T)
[water-level (W, T) high < W pump(T)] [water-level (W, T) low < W pump-active T pump(T)]
This is because perfect models2 of logic programs are minimal models, and because the if-and-only-if form of a definition is true in a minimal model if and only if the ifhalf of the definition is true in the model. The equivalence of different representations makes it easier to reason about TR programs in ALP form.
5 Reasoning about LTR Programs The following example is based on the example in [6]. Theorem: Let max-in and min-out be the maximum rate that water enters the mine, and the minimum rate that the pump removes water from the mine, respectively. Let water-in(In, T) and water-out(Out, T) express that the water enters the mine at rate In at time T and leaves the mine at rate Out at time T, respectively. Assume that: 1) In, T [water-in(In, T) In ≤ max-in and max-in ≤ min-out] Assume also that the primitive action pump satisfies the property: 2) M, T, W, Out [methane-level(M, T) critical > M water-level (W, T) low < W water-out(Out, T) pump(T) min-out ≤ Out] Then the defined action mine-pump satisfies the property:
M, W, In, Out, T [methane-level(M, T) critical > M water-level (W, T) high < W water-in(In, T) water-out(Out, T) mine-pump(T) In ≤ Out]
Note that the perfect model semantics for programs of the form G (A B) can be defined in terms of normal programs of the form G ¬A G A B. 2
12
Proof: Assume that at some given time t, methane-level(m, t) critical > m water-level (w, t) high < w water-in(in, t) water-out(out, t) mine-pump(t).
3)
It is necessary to show that in ≤ out. But assumptions (1) and (3) imply in ≤ max-in ≤ min-out. Therefore it suffices to show min-out ≤ out. This follows from assumptions (2) and (3) provided we can show pump(t) and low < w. pump(t) follows from assumption (1), the second condition methane-level (M, T) critical > M operate(T) of mine-pump T, and the definition of operate(T). low < w follows from low < high and high < w. The proof can be pictured as a tree, with the conclusion at the top and assumptions at the bottom:
6 Knowledge Representation with LTR Programs We have shown above that LTR gives a model-theoretic semantics to TR programs, which facilitates proving TR program properties. In this section, we show that TR programs suggest a non-recursive programming style, which can also be used in LTR and ALPA more generally. We illustrate this with a path-finding example. However, the example also shows that TR programs are restricted to deterministic programs, whereas the corresponding path-finding program written in ALPA is naturally non-
13
deterministic. Consider the following recursive logic program for path-finding with time represented explicitly: go-to(X, T, T) at(X, T) go-to(X, T1, T2) ¬at(X, T1) at(Y, T1) towards(Y, Z, X) move(Y, Z, T1, T) go-to(X, T, T2) Here go-to(X, T1, T2) represents the “macro-action” of going to X from time T1 to time T2. The predicate towards(Y, Z, X) non-deterministically identifies a place Z that is next to Y and in the direction from Y towards X. There could be several alternative such places Z. So an agent would need to choose between them, perhaps by planning ahead to find a path that ends in X, and then moving along that path to get to X. TR programs suggest a non-recursive way of writing a similar logic program: go-to(X, T) at(X, T) go-to(X, T) ¬ at(X, T) at(Y, T) towards(Y, Z, X) move(Y, Z, T) or in the conditional representation go-to(X, T) [¬ at(X, T) at(Y, T) towards(Y, Z, X) move(Y, Z, T)] The variable Z, which does not occur in the conclusion go-to(X, T) of the clause, is existentially quantified in the conditions of the clause. Both of these non-recursive formalisations need to be augmented with an integrity constraint such as required-destination(Place, T) go-to(Place, T), where requireddestination is an extensional predicated updated by observations of events, say, request-destination and cancel-destination. This is similar to the predicate requiredtower and the events request-tower and cancel-tower, in the case of the tower building example, earlier. It is not possible to represent the non-recursive logic program directly as a TR program. Suppose we try to represent it as: go-to(X) {at(X) nil, at(Y) towards(Y, Z, X) move(Y, Z)} Then what is the implicit quantification of the variable Z? Is it that the agent should move to every place Z that is towards X from Y? Or does it mean that the agent should non-deterministically find one such place Z and move towards it? The alternative representation: go-to(X) {at(X) nil, at(Y) towards(Y, Z, X) move(Y, Z)} is not allowed in the syntax of TR programs, and is not catered for in the operational semantics of TR programs.
14
Notice that the non-recursive style can also be used for the tower-building program. Here is the top-level of a non-recursive LTR program: make-tower(S, T) tower(S, T) make-tower([Block|S], T) tower([Block|S], T) ordered([Block|S], T) unpile(Block, T) make-tower([Block], T) tower([Block], T) ordered([Block], T) move-to-table(Block, T) make-tower(S, T) tower(S, T) ordered(S, T) append(S1, [B1, B2|S2], S) ordered([B2|S2], T) on(B1, B2, T) move(B1, B2, T) make-tower(S, T) tower(S, T) ordered(S, T) append(S1, [B], S) ¬ ordered([B], T) move-to-table(B, T) The condition append(S1, [B1, B2|S2], S) splits S into a tower [B2|S2] that has already been built and the part that remains to be built. In the next section we describe LPS, with a view towards embedding both LTR and LPS in a more expressive and more powerful ALPA framework with a destructively updated database.
7 The Logic-Based Production System and Agent Language LPS LPS [9, 10] combines logic programs and production systems in a logical framework based on ALP. The relationship between LPS and ALP is analogous to the relationship between LTR and ALP. Both TR programs and LPS employ a destructively updated database and a syntax without time, but can be given a model-theoretic semantics by translating them into ALPA with an explicit representation of time. In both cases, the semantics is defined relative to the time-stamped sequence of observations, actions and database states. TR programs and LPS differ in their ontologies for actions. In TR programs, actions are executed duratively, for as long as their associated conditions continue to hold. The effects of actions, like the level of water in a mine or a robot’s location, are sensed as observations, rather than derived by means of an event theory. These effects can vary continuously as a function of the durations of actions, as in the case of pumping, which affects the level of water, and moving forwards, which affects the robot’s location. In LPS, actions are discrete events, which transform one state of the world (or the database) into another. The effects of actions and other events are defined, as in the situation calculus [20] and event calculus [11], by an event theory, which specifies the extensional predicates that are initiated or terminated by events, and the preconditions
15
that must hold for actions to be possible. LPS uses the event theory (but without frame axioms) to update the database. Perhaps the biggest difference between TR programs and LPS is that LPS allows definitions of sequences of database state transitions. For example, the recursive definition of the macro-action go-to in the previous section could be written in LPS in the form: go-to(X) at(X) go-to(X) ¬ at(X) : at(Y) : towards(Y, Z, X) : move(Y, Z) : go-to(X) The meaning of the sequential connective : is given by the translation into ALP, which we have already seen in the last section: go-to(X, T, T) at(X, T) go-to(X, T1, T2) ¬at(X, T1) at(Y, T1) towards(Y, Z, X) move(Y, Z, T1, T) go-to(X, T, T2). The action move(Y, Z, T1, T) transforms the database state at time T1 to the next state at time T. The event theory updates the database by deleting the old location at(Y) and adding the new location at(Z). Database transitions in LPS are similar to transactions in Transaction Logic [1]. In both cases, transactions are alternating sequences of queries and actions. An action can be an atomic action, which directly updates the external environment and/or the internal database, or a macro-action, which is the name of a transaction. In this respect, LPS is also similar to Golog [20]. However, like Golog and unlike Transaction Logic, transactions in LPS are not atomic and cannot be rolled back, although this is a feature that could be added to LPS. The top-level of an LPS program consists of reactive rules, which are like condition-action rules in production systems and like event-condition-action rules in active database systems. However in LPS, reactive rules have the semantics of integrity constraints in ALP, and their conclusions can be transactions (or equivalently, macro-actions). The structure of an LPS program can be pictured roughly like this:
16
Given their compatible syntax and operational and declarative semantics, LTR and LPS can be combined in a unified language inheriting the benefits of the separate languages. One way of combining them is to embed LTR programs in LPS programs. For example, here is the definition, translated into ALP, of a macro-action that calls the teleo-reactive program make-tower to construct a tower and terminate when the tower is completed: achieve-tower (S, T, T) tower(S, T) achieve-tower (S, T1, T2) ¬ tower(S, T1) make-tower(S, T1) achieve-tower(S, T1+1, T2) Similarly the teleo-reactive LTR program go-to of the last section can be embedded in an LPS macro-action definition: get-to(X, T, T) at(X, T) get-to(X, T1, T2) ¬at(X, T1) go-to(X, T1) get-to(X, T1+1, T2) to move towards a place, and terminate when reaching it. In both the case of achievetower and the case of get-to, the goal is achieved “teleo-reactively”, taking advantage of any favourable changes in the environment and recovering gracefully from any unfavourable changes.
17
8 Conclusions: ALPA as a Unifying Framework The translations of LPS and TR programs into ALPA illustrate the broader potential of ALPA to unify different knowledge representation formalisms. The contribution of LPS is that it shows how to give a model-theoretic semantics to programs that maintain a destructively updated database. But this contribution can be generalised to any representation in ALPA that similarly maintains such a database. Complex event recognition and processing (CEP) [12] is another programming paradigm that could benefit from such a treatment. In the same way that macroactions can be defined in terms of queries and actions, complex events can be defined in terms of conditions and simpler events. Conditions can be evaluated either by querying sensory inputs or by querying the database. Atomic events can be recognised by input observations. Here are two examples from [22], written in ALP form: shoplift (Item, T1, T2) shelf-reading(Item, T1) exit-reading(Item, T2) ¬ (check-out-reading(Item, T) T1 T T T2 ) T2 – T1 < 12 hours overdose(Person, antibiotics, T1, T2) ingest(Person, Medicine1, Dosage1, T1) ingest(Person, Medicine2, Dosage2, T2) antibiotics(Medicine1) antibiotics(Medicine2) Dosage1+Dosage2 >1000 T2 – T1 < 4 hours The first identifies the occurrence of a complex event of shoplifting when an item that was on shelf is removed from the store without being checked out. The second identifies a complex event of overdosing when a person has taken more than 1000 units of antibiotics in less than 4 hours in two doses. Notice that, to specify such complex events, we need to be able to represent temporal constraints on the times that conditions hold and events are observed. However, with the ability to represent such constraints, it is easy to specify a partial ordering among the conditions and events that make up a complex event. Notice also that the ALPA framework allows not only defining (and thus identifying) complex events, but also reacting to them (via ALPA integrity constraints) with transactions. Investigating complex event processing further is part of our future work. Other topics we plan to consider in the future include formalisation and proof of other properties of LTR programs, such as “progress” towards achieving goals, and formal characterisations of how an LTR agent “recovers” and “re-plans” after environmental interference, without the need for explicit inclusion of such features in the representation. We have a prototype implementation of LPS, which is sufficiently general that it can run programs written in LTR. Exploring the scalability of the implementation for more substantial examples is also part of future work.
18
Afterword. It is a pleasure to dedicate this paper to Marek, whose friendship and intellectual inspiration have been a great support over many years. Acknowledgments. Many thanks to Keith Clark for awakening our interest in TR programs, and to Clive Spencer and Alan Westwood from Logic Programming Associates for many useful discussions and for their work on the prototype implementation of LPS and its application to LTR. Thanks also to the anonymous referees.
References 1. 2. 3.
4. 5.
6.
7.
Bonner and M. Kifer.: Transaction logic programming. In Warren D. S., (ed.), Logic Programming: Proc. of the 10th International Conf., 257-279 (1993) Brooks, R.A., Intelligence Without Representation, Artificial Intelligence 47, 139-159 (1991) Coffey, S., and Clark, K. L., A Hybrid, Teleo-Reactive Architecture for Robot Control, In Proceedings of the Second International Workshop on Multi-Agent Robotic Systems (MARS-06) (2006) Gordon, E. and Logan, B., Game Over: You have been beaten by a GRUE, In Challenges in Game Artificial Intelligence: AAAI Workshop (2004) Gerhard Gubisch, Gerald Steinbauer, Martin Weiglhofer and Franz Wotawa A., TeleoReactive Architecture for Fast, Reactive and Robust Control of Mobile Robots, In IEA/AIE 2008 Wroclaw, Poland, Lecture Notes in Computer Science, Volume 5027, 541550 (2008) Hayes, I.J., Towards Reasoning About Teleo-reactive Programs for Robust Real-time Systems, In Proceedings of the 2008 RISE/EFTS Joint International Workshop on Software Engineering for Resilient Systems (SERENE), 87-94 (2008) Kowalski, R.: Computational Logic and Human Thinking: How to be Artificially Intelligent, Cambridge University Press (2011)
8.
Kowalski, R. and Sadri, F.: From Logic Programming Towards Multi-agent Systems, Annals of Mathematics and Artificial Intelligence, Volume 25, 391-419 (1999) 9. Kowalski, R. and Sadri, F.: An Agent Language with Destructive Assignment and ModelTheoretic Semantics, In Dix J., Leite J., Governatori G., Jamroga W. (eds.), Proc. of the 11th International Workshop on Computational Logic in Multi-Agent Systems (CLIMA), 200-218 (2010) 10. Kowalski, R. and Sadri, F.: Abductive Logic Programming Agents with Destructive Databases, Annals of Mathematics and Artificial Intelligence, Volume 62, Issue 1, 129158 (2011) 11. Kowalski, R. and Sergot, M.: A Logic-based Calculus of Events. In New Generation Computing, Vol. 4, No.1, 67-95 (1986). Also in The Language of Time: A Reader (eds. Inderjeet Mani, J. Pustejovsky, and R. Gaizauskas) Oxford University Press (2005) 12. Luckham, D.: The Power of Events - An Introduction to Complex Event Processing in Distributed Enterprise Systems, Addison-Wesley (2002) 13. Marinovic, S., Twidle, K., Dulay, N., Teleo-reactive Workflows for Pervasive Healthcare, First IEEE PerCom Workshop on Pervasive Healthcare (2010) 14. Nilsson, N., Toward Agent Programs with Circuit Semantics, Technical Report STANCS-92-1412, Stanford University Computer Science Department (1992)
19
15. Nilsson, N.J., Teleo-reactive Programs for Agent Control, Journal of Artificial Intelligence Research cs.AI/9401, 139-158, January (1994) 16. Nilsson, N.J., Teleo-reactive Programs and the Triple-tower Architecture, Electronic Transactions on Artificial Intelligence, Vol. 5, Section B, 99-110 (2001) 17. Przynusinski, T., On the Declarative and Procedural Semantics, Journal of Automated Reasoning 5: 167-295 (1989) 18. Przymusinski, T.: On the Declarative and Procedural Semantics of Stratified Deductive Databases. In J. Minker, editor, Foundations of Deductive Databases and Logic Programming, Morgan-Kaufman, Los Altos, CA, 193–216 (1988) 19. Rao, A. S., Georgeff, M. P.: BDI Agents: From Theory to Practice, International
Conference on Multiagent Systems - ICMAS , 312-319 (1995) 20. Reiter, R.: Knowledge in Action. MIT Press (2001) 21. Sagonas, K. F., Swift,T., Warren, D. S.: XSB as an Efficient Deductive Database Engine, Sigmod Record , vol. 23, no. 2, 442-453 (1994) 22. Wu, E., Diao, Y., Rizvi, S.: High-Performance Complex Event Processing Over Streams, SIGMOD, Chicago, Illinois, USA, 407-418 (2006) 23. Broda, K., Hogger, C.J.: Designing and Simulating Individual Teleo-Reactive Agents, Poster Proceedings, 27th German Conference on Artificial Intelligence (2004) 24. Kowalski, R., and Sadri, F.: Integrating Logic Programming and Production Systems in Abductive Logic Programming Agents, In Web Reasoning and Rule Systems (eds. A. Polleres and T. Swift) Springer, LNCS 5837 (2009) 25. van Emden, M. and Kowalski, R.: The Semantics of Predicate Logic as a Programming Language, in JACM, Vol. 23, No. 4, 733-742 (1976)
Appendix Brief Introduction to Logic Programming Logic programs are collections of sentences in the logical form of conditionals: if conditions then conclusion, also written conclusion conditions. Such conditionals (also called clauses) combine a conclusion, which is an atomic formula, with conditions, which are a conjunction of atomic formulas or negations of atomic formulas. A clause without negative conditions is called a definite clause. The number of conditions in a clause can be zero, in which case the clause is written without the implication sign , simply as conclusion. If the number of conditions is not zero, then the clause is also sometimes called a rule. All variables in a clause are implicitly universally quantified with scope the clause. Clauses with no variables are called ground clauses. Ground clauses with zero conditions are also called facts.
20
Logic programs can be viewed as definitions of the predicates occurring in the conclusions of clauses. These definitions are used to solve goal clauses, which are existentially quantified conjunctions of atomic formulas or negations of atomic formulas. A definite goal clause is a goal clause without negative conditions. Both definite clauses and definite goal clauses are also called Horn clauses. The use of logic programs to solve goals can be viewed in both programming and database terms. Viewed in programming terms, logic programs compute values of the existentially quantified variables in goal clauses. Viewed in database terms, they derive answers to goal clauses, viewed as database queries. Given a logic program L, to solve a goal clause G, it is necessary to find a variablefree (i.e. ground) instance G‘ of G such that G‘ holds with respect to L. In the case of a definite clause program L, there are two equivalent semantic notions of what it means for a sentence S to hold with respect to L: L logically entails S, i.e. S is true in all models of L. S is true in the unique minimal model of L. The minimal model semantics has a number of advantages, which are detailed for example in [7]. The minimal model [25] of a definite clause program L is equivalent to the set of all facts that can be derived from L by repeatedly applying the two inference rules of instantiation and modus ponens, until no new facts can be derived. Instantiation replaces all occurrences of a variable in a clause by a ground term constructed from the constants and function symbols of the language. Modus ponens derives the conclusion of a clause conclusion conditions from the conditions given as facts. In the case of non-Horn clauses that are locally stratified [18], the minimal model semantics has a natural generalisation to perfect models. For simplicity, consider the case of a ground clause program L with two strata, determined by partitioning the set of all ground atoms A of the language into two disjoint sets (or strata) A0 and A1. L is locally stratified if L is the union L0 L1 of two disjoint sets of clauses: L0 consists of clauses whose conclusion and positive conditions belong to A0, and that have no negative conditions. L1 is the set of all the clauses in L whose conclusion belongs to A1, whose positive conditions belong to A0 A1, and whose negative conditions have atoms in A0. Thus no clause in L contains a negative condition in A1. The perfect model of L is the union M0 M1 of two minimal models: M0 is the minimal model of the definite clause program L0. M1 is the minimal model of the definite clause program L1’ obtained from L1 by evaluating in M0 both the positive and negative conditions of clauses in L1 whose atoms are in A0. i.e. L1’ contains a clause of the form conclusion conditions1 iff L1 contains a clause of the form conclusion conditions1 and conditions2, where the atoms in conditions1 are all in A1, the atoms in conditions2 are all in A2, and the conditions2 are all true in M0.
21
This definition can be generalised in three ways: 1) from ground logic programs to programs containing variables, by adding universal instantiation; 2) to an unbounded number of strata: 0, 1, …. and 3) from conditions that are negative atoms at lower strata to conditions that are arbitrary formulas in the vocabulary of lower strata.
22
