Answer set programming and plan generation.
The idea of answer set programming is to represent a given computational problem by a logic program whose answer sets correspond to solutions, and then use an answer set solver, such as SMODELS or DLV, to find an answer set for this program. Applications of this method to planning are related to the line of research on the frame problem that started with the invention of formal nonmonotonic reasoning in 1980.
Introduction
Kautz and Selman [19] proposed to approach the problem of plan generation
by reducing it to the problem of nding a satisfying interpretation for a set
of propositional formulas. This method, known as satisability planning,
is used now in several planners. 1 In this paper we discuss a related idea,
due to Subrahmanian and Zaniolo [36]: reducing a planning problem to the
problem of nding an answer set (\stable model") for a logic program. The
advantage of this \answer set programming" approach to planning is that the
representation of properties of actions is easier when logic programs are used
instead of axiomatizations in classical logic, in view of the nonmonotonic
character of negation as failure. Two best known answer set solvers (systems
for computing answer sets) available today are smodels 2 and dlv 3 . The
results of computational experiments that use smodels for planning are
reported in [4, 30].
for the latest system of this
kind created by the inventors of satisability planning.http://www.tcs.hut.fi/Software/smodels/ .http://www.dbai.tuwien.ac.at/proj/dlv/ .
In this paper, based on earlier reports [22, 23], applications of answer set
programming to planning are discussed from the perspective of the research
on the frame problem and nonmonotonic reasoning done in AI since 1980.
Specically, we relate them to the line of work that started with the invention
of default logic [33]|the nonmonotonic formalism that turned out to
be particularly closely related to logic programming [2, 26, 10]. After the
publication of the \Yale Shooting Scenario" [14] it was widely believed that
the solution to the frame problem outlined in [33] was inadequate. Several
alternatives have been proposed [18, 20, 34, 15, 21, 29, 8]. It turned out,
however, that the approach of [33] is completely satisfactory if the rest of
the default theory is set up correctly [37]. It is, in fact, very general, as
discussed in Section 5.2 below. We will see that descriptions of actions in
the style of [33, 37] can be used as a basis for planning using answer set
solvers.
In the next section, we review the concept of an answer set as dened
in [9, 10, 25] and its relation to default logic. Then we describe some of the
computational possibilities of answer set solvers (Section
the answer set programming method [27, 30] by applying it to a graph-theoretic
search problem (Section 4). In Section 5 we turn to the use of
answer set solvers for plan generation. Section 6 describes the relation of
this work to other research on actions and planning.
Answer Sets
2.1 Logic Programs
We begin with a set of propositional symbols, called atoms. A literal is an
expression of the form A or :A, where A is an atom. (We call the
\classical negation," to distinguish it from the symbol not used for negation
as failure.) A rule element is an expression of the form L or not L, where L
is a literal. A rule is an ordered pair
Head Body (1)
where Head and Body are nite sets of rule elements. A rule (1) is a constraint
disjunctive if the cardinality of Head is greater
than 1. If
and
then we write (1) as
(2)
We will drop in (2) if the body of the rule is empty
A program is a set of rules.
These denitions dier from the traditional description of the syntax of
logic programs in several ways. First, our rules are propositional: atoms are
not assumed to be formed from predicate symbols, constants and variables.
An input le given to an answer set solver does usually contain \schematic
rules" with variables, but such a schematic rule is treated as an abbreviation
for the set of rules obtained from it by grounding. The result of grounding
is a propositional object, just like a set of clauses that would be given as
input to a satisability solver.
On the other hand, in some ways (2) is more general than rules found in
traditional logic programs. Each L i may contain the classical negation symbol
traditional logic programs use only one kind of negation|negation
as failure. The head of (2) may contain several rule elements, or it can be
traditionally, the head of a rule is a single atom. The negation as
failure symbol is allowed to occur in the head of a rule, and not only in
the body as in traditional logic programming. We will see later that the
additional expressivity given by these syntactic features is indeed useful.
2.2 Denition of an Answer Set
The notion of an answer set is dened rst for programs that do not contain
negation as failure (l = k and in every rule (2) of the program). Let
be such a program, and let X be a consistent set of literals. We say that
X is closed under  if, for every rule (1) in , Head \ X
Body  X. We say that X is an answer set for  if X is minimal among
the sets closed under  (relative to set inclusion).
For instance, the program
has two answer sets:
If we add the constraint
to (3), we will get a program whose only answer set is the rst of sets (4).
On the other hand, if we add the rule
to (3), we will get a program whose only answer set is fp; :q; :rg.
To extend the denition of an answer set to programs with negation as
failure, take an arbitrary program , and let X be a consistent set of literals.
The reduct  X of  relative to X is the set of rules
for all rules (2) in  such that X contains all the literals L
does not contain any of Lm+1 . Thus  X is a program without
negation as failure. We say that X is an answer set for  if X is an answer
set for  X .
Consider, for instance, the program
not q ;
q not r ;
r not s ;
and let X be fp; rg. The reduct of (5) relative to this set consists of two
rules:
Since X is an answer set for this reduct, it is an answer set for (5). It is
easy to check that program (5) has no other answer sets.
This example illustrates the original motivation for the denition of an
answer set|providing a declarative semantics for negation as failure as implemented
in existing Prolog systems. Given program (5), a Prolog system
will respond yes to a query if and only if that query is p or r, that is to say,
if and only if the query belongs to the answer set for (5). In this sense, the
role of answer sets is similar to the role of the concept of completion [3],
which provides an alternative explanation for the behavior of Prolog (p and
r are entailed by the program's completion).
2.3 Comparison with Default Logic
Let  be a program such that the head of every rule of  is a single literal:
We can transform  into a (propositional) default theory in the sense of [33]
by turning each rule (6) into the default
There is a simple correspondence between the answer sets for  and the
extensions for this default theory DT : if X is an answer set for  then the
deductive closure of X is a consistent extension for DT ; conversely, every
consistent extension for DT is the deductive closure of an answer set for .
For instance, the default theory corresponding to program (5) is
r
The only extension for this default theory is the deductive closure of the
program's answer set fp; rg.
Under this correspondence, a rule without negation as failure is represented
by a default without justications, that is to say, by an inference
rule. A fact|a rule with the empty body|corresponds to a default that
has neither prerequisites nor justications, that is, an axiom. The normal
is the counterpart of the rule
q p; not :q: (8)
Logic programs as dened above are more general than defaults in that
their rules may have several elements in the head, and these elements may
include negation as failure. On the other hand, defaults are more general in
that they may contain arbitrary propositional formulas, not just literals or
conjunctions of literals.
In this connection, it is interesting to note that one of the technical issues
related to the \Yale Shooting" controversy is whether the eects of actions
should be described by axioms, such as
loaded
or by inference rules, such as
loaded
According to [37], formulation (10) is a better choice. In the language of
logic programs (10) would be written as
:alive(result(shoot (s))) loaded (s):
Formula (9), on the other hand, does not correspond to any rule in the
sense of logic programming. Paradoxically, limitations of the language of
logic programs play a positive role in this case by eliminating some of the
\bad" representational choices that are available when properties of actions
are described in default logic.
2.4 Generating and Eliminating Answer Sets
From the perspective of answer set programming, two kinds of rules play a
special role: those that generate multiple answer sets and those that can be
used to eliminate some of the answer sets of a program.
One way to write a program with many answer sets is to use the disjunctive
rules
for several atoms A. A program that consists of n rules of this form has 2 n
answer sets. For instance, the program
has 4 answer sets:
As observed in [5], rule (11) can be equivalently replaced in any program
by two nondisjunctive rules
A not :A ;
:A not A :
In the notation of default logic, these rules can be written as
A
Alternatively, a program with many answer sets can be formed using
rules of the form
not L (12)
where L is a literal. This rule has two answer sets: fLg and ;. A program
that consists of n rules of form (12) has 2 n answer sets|all subsets of the
set of literals occurring in the rules. For instance, the answer sets for the
program
q; not q (13)
are the 4 subsets of fp; qg.
The rules that can be used to eliminate \undesirable" answer sets are
constraints|rules with the empty head. We saw in Section 2.2 that appending
the constraint q to program (3) eliminates one of its two answer
sets (4). The eect of adding a constraint to a program is always mono-
tonic: the collection of answer sets of the extended program is a part of the
collection of answer sets of the original program.
More precisely, we say that a set X of literals violates a constraint
if be the program obtained
from a program  by adding constraint (14). Then a set X of literals is an
answer set for  0 i
X is an answer for , and
X does not violate constraint (14).
For instance, the second of the answer sets (4) for program (3) violates the
constraint q, and the rst doesn't; accordingly, adding this constraint
to (3) eliminates the second of the program's answer sets.
To see how rules of both kinds|those that generate answer sets and
those that eliminate them|can work together, consider the following translation
from propositional theories to logic programs. Let be a set of
clauses, and let  be the program consisting of
rules (11) for all atoms A occurring in , and
the constraints L clauses L 1 _    _ L n in .
(By L we denote the literal complementary to L.) The answer sets for
are in a 1{1 correspondence with the truth assignments satisfying , every
truth assignment being represented by the set of literals to which it assigns
the value true.
3 Answer Set Solvers
System dlv computes answer sets for nite programs without negation as
failure in the heads of rules (l = k in every rule (2) of the program). For
instance, given the input le
-r :- p.
it will return the answer sets for program (3). Given the input le
p :- not q.
q :- not r.
r :- not s.
it will return the answer set for program (5).
System smodels requires additionally that its input program contain no
disjunctive rules. This limitation is mitigated by two circumstances.
First, the input language of smodels allows us to express any \exclusive
disjunctive rule," that is, a disjunctive rule
accompanied by the constraints
This combination is represented as
Second, smodels allows us to represent the important disjunctive combination
(12) in the head of a rule by enclosing L in braces:
f L g.
A list of rules of the form
can be conveniently represented in an smodels input le by one line
For instance, rules (13) can be written simply as
{p,q}.
Both dlv and smodels allow the user to specify large programs in a
compact fashion, using rules with schematic variables and other abbrevia-
tions. Both systems employ sophisticated grounding algorithms that work
fast and simplify the program in the process of grounding.
joined(X,Y) :- edge(X,Y).
joined(X,Y) :- edge(Y,X).
:- in(X), in(Y), X!=Y, not joined(X,Y),
vertex(X), vertex(Y).
hide.
show in(X).

Figure

1: Search for a large clique.
4 Answer Set Programming
The idea of answer set programming is to represent a given computational
problem by a program whose answer sets correspond to solutions, and then
use an answer set solver to nd a solution.
As an example, we will show how this method can be used to nd a large
clique, that is, a subset V of the vertices of a given graph such that
every two vertices in V are joined by an edge, and
the cardinality of V is not less than a given constant j.

Figure

1 shows an smodels input le that can be used to nd a large
clique or to determine that it does not exist. This le is supposed to be
accompanied by a le that describes the graph and species the value of j,
such as the one shown in Figure 2.
The possible values of the variables X, Y in Figure 1 are restricted by
the \domain predicates" vertex and edge. In case of the graph described
in

Figure

2, the predicate vertex holds for the numerals and the
const j=3.
vertex(0.5).
edge(0,1). edge(1,2). edge(2,0). edge(3,4).
edge(4,5). edge(5,3). edge(4,0). edge(2,5).

Figure

2: A test for the clique program.
predicate edge holds for 8 pairs of vertices Accordingly,
the expression
at the beginning of Figure 1 (\the set of atoms in(X) for all X such that
vertex(X)") has the same meaning as
{in(0), in(1), in(2), in(3), in(4), in(5)} .
The last expression can be understood as an abbreviation for a set of rules of
form (12), as discussed in Section 3. The answer sets for this set of rules are
arbitrary sets formed from these 6 atoms. Symbol j at the beginning of the
rule restricts the answer sets to those whose cardinality is at least j. This
is an instance of the \cardinality" construct available in smodels [31]. It
allows the user to bound, from below and from above, the number of atoms
of a certain form that are included in the answer set. lower bound is
placed to the left of the expression in braces, as in this example; an upper
bound would be placed to the right.)
The main parts of the program in Figure 1 are the two labeled GENERATE
and TEST. The former denes a large collection of answer sets|\potential
solutions." The latter consists of the constraints that \weed out" the answer
sets that do not correspond to solutions. As discussed above, a potential
solution is any subset of the vertices whose cardinality is at least j; the
constraints eliminate the subsets that are not cliques. This is similar to the
use of generating and eliminating rules in Section 2.4.
The part labeled DEFINE contains the denition of the auxiliary predicate
joined. The part labeled DISPLAY tells smodels which elements of the
answer set should be included in the output: it instructs the system to \hide"
all literals other than those that encode the clique. In case of the problem
shown in Figure 2, the part of the answer set displayed by smodels is
The discussion of this example in terms of generating a set of potential
solutions and testing its elements illustrates the declarative meaning of the
program, but it should not be understood as a description of what is actually
happening during the operation of an answer set solver. System smodels
does not process the program shown above by producing answer sets for
the GENERATE part and checking whether they satisfy the constraints in the
TEST part, just as a reasonable satisability solver does not search for a
model of a given set of clauses by generating all possible truth assignments
and checking for each of them whether the clauses are satised. The search
procedures employed in systems smodels and dlv use sophisticated search
strategies somewhat similar to those used in e-cient satisability solvers.
Answer set programming has found applications to several practically
important computational problems [30, 35, 16]. One of these problems is
planning.
5 Planning
5.1 Example
The code in Figures 3{5 allows us to use smodels to solve planning problems
in the blocks world. We imagine that blocks are moved by a robot with
several grippers, so that a few blocks can be moved simultaneously. However,
the robot is unable to move a block onto a block that is being moved at the
same time. As usual in blocks world planning, we assume that a block can
be moved only if there are no blocks on top of it.
There are three domain predicates in this example: time, block and
location; a location is a block or the table. The constant lasttime is an
upper bound on the lengths of the plans to be considered. (To nd the
shortest plan, one can use the minimize feature of smodels which is not
discussed in this paper.)
The GENERATE section denes a potential solution to be an arbitrary set of
move actions executed prior to lasttime such that, for every T, the number
of actions executed at time T does not exceed the number of grippers.
The rules labeled DEFINE describe the sequence of states corresponding
to the execution of a given potential plan. Each sequence of states is represented
by a complete set of on literals. The DEFINE rules in Figure 5 specify
the positive literals describing the initial positions of all blocks. The rst
two DEFINE rules in Figure 3 specify the positive literals describing the po-
time(0.lasttime).
location(B) :- block(B).
location(table).
time(T), T<lasttime.
% effect of moving a block
block(B), location(L), time(T), T<lasttime.
:- on(B,L,T), not -on(B,L,T+1),
location(L), block(B), time(T), T<lasttime.
% uniqueness of location
block(B), location(L), location(L1), time(T).

Figure

3: Planning in the blocks world, Part 1.
% two blocks cannot be on top of the same block
block(B), time(T).
% a block can't be moved unless it is clear
block(B), block(B1), location(L), time(T), T<lasttime.
% a block can't be moved onto a block that is being moved also
block(B), block(B1), location(L), time(T), T<lasttime.
hide.
show move(B,L,T).

Figure

4: Planning in the blocks world, Part 2
const grippers=2.
const lasttime=3.
block(1.6).
Initial state: Goal:
on(1,2,0).
on(2,table,0).
on(3,4,0).
on(4,table,0).
on(5,6,0).
on(6,table,0).
:- not on(3,2,lasttime).
:- not on(2,1,lasttime).
:- not on(1,table,lasttime).
:- not on(6,5,lasttime).
:- not on(5,4,lasttime).
:- not on(4,table,lasttime).

Figure

5: A test for the planning program.
sitions of all blocks at time T+1 in terms of their positions at time T. The
uniqueness of location rule species the negative on literals to be included
in an answer set in terms of the positive on literals in this answer set.
Note that the second DEFINE rule in Figure 3 is the smodels representation
of the normal default
|if it is consistent to assume that at time t+1 block b is at the same location
where it was at time t then it is indeed at that location (see Section 2.3).
This default is interesting to compare with the solution to the frame problem
proposed by Reiter in 1980:
[33, Section 1.1.4]. If we take relation R to be on, and the tuple of arguments
x to be b; l , this expression will turn into
The only dierence between defaults (15) and (16) is that the rst describes
change in terms of the passage of time (t becomes t + 1), and the latter in
terms of state transitions (s becomes f(b; l; s)).
Consider now the three constraints labeled TEST in Figure 4. The role of
the rst constraint is to prohibit, indirectly, the actions that would create
physically impossible congurations of blocks, such as moving two blocks
onto the same block b. The other two constraints express the robot's
limitations mentioned at the beginning of this section.
Adding these constraints to the program eliminates the answer sets corresponding
to the sequences of actions that are not executable in the given
initial state. When we further extend the program by adding the TEST section
of Figure 5, we eliminate, in addition, the sequences of actions that do
not lead to the goal state. The answer sets for the program are now in a
1{1 correspondence with solutions of the given planning problem.
The DISPLAY section instructs smodels to \hide" all literals except
for those that begin with move. The part of the answer set displayed by
smodels is the list of actions included in the plan:
Stable Model: move(3,table,0) move(1,table,0) move(5,4,1)
True
Duration: 0.340
5.2 Discussion
The description of the blocks world domain in Figures 3 and 4 is more
sophisticated, in several ways, than the shooting example [14] that seemed
so di-cult to formalize in 1987. First, this version of the blocks world
includes the concurrent execution of actions.
Second, some eects of moving a block are described here indirectly. In
the shooting domain, the eects of all actions are specied explicitly: we are
told how the action load aects the
uent loaded , and how the action shoot
aects the
uent alive. The description of the blocks world given above
is dierent. When block 1, located on top of block 2, is moved onto the
table, this action aects two
uents: on(1; table) becomes true, and on(1; 2)
becomes false. The rst of these two eects is described explicitly by the
rst DEFINE rule in Figure 3, but the description of the second eect is
indirect: the uniqueness of location rule allows us to conclude that block 2
is not on top of block 1 anymore from the fact that block 2 is now on the
table. The ramication problem|the problem of describing indirect eects
of actions|is not addressed in the classical action representation formalisms
STRIPS [7] and ADL [32].
Finally, the executability of actions is described in this example indirectly
as well. As discussed above, the impossibility of moving two blocks b 1 , b 2
onto the same block b is implicit in our description of the blocks world:
executing that action would have created a conguration of blocks that is
prohibited by one of the constraints in Figure 4. In STRIPS and ADL,
the executability of an action has to be described explicitly, by listing the
action's preconditions. The usual description of the blocks world asserts,
for instance, that moving one block on top of another is not executable if
the target location is not clear. This description is not applicable, however,
when several blocks can be moved simultaneously: in the initial state shown
in

Figure

5, block 1 can be moved onto block 4 if block 3 is moved at the
same time. Fortunately, when the answer set approach to describing actions
is adopted, specifying action preconditions explicitly is unnecessary.
The usefulness of indirect descriptions of action domains for applications
of AI was demonstrated in a recent report [38] on modelling the Reaction
Control System (RCS) of the Space Shuttle. The system consists of several
fuel tanks, oxidizer tanks, helium tanks, maneuvering jets, pipes, valves,
and other components. How is the behavior of the RCS aected by
ipping
one of its switches? According to [38], this action has only one direct eect,
which is trivial: changing the position of a switch causes the switch to be
in the new position. But there is also a postulate asserting that, if a valve
is functional, it is not stuck closed, and the switch controlling it is in the
open (or closed) position then the valve is open (or closed). These two facts
together tell us that, under certain conditions,
ipping a switch indirectly
aects the corresponding valve. Furthermore, if a helium talk has correct
pressure, there is an open path to a propulsion tank, and there are no paths
to a leak, then the propulsion tank has correct pressure also. Using this
postulate we can conclude that, under certain conditions,
ipping a switch
aects pressure in a propulsion tank, and so on. This multi-level approach
to describing the eects of actions leads to a well-structured and easy to
understand formal description of the operation of the RCS. The answer set
programming approach handles such multi-leveled descriptions quite easily.
6 Relation to Action Languages and Satisability
Planning
Some of the recent work on representing properties of actions is formulated
in terms of \high-level" action languages [12], such as A [11] and C [13].
Descriptions of actions in these languages are more concise than logic programming
representations. For example, the counterparts of the rst two
DEFINE rules from Figure 3 in language C are
move(b; l) causes on(b; l)
and
inertial on(b; l):
The design of language C is based on the system of causal logic proposed
in [28].
For a large class of action descriptions in C, an equivalent translation
into logic programming notation is dened in [24]. The possibility of such a
translation further illustrates the expressive power of the action representation
method used in this paper.
As noted in the introduction, the answer set programming approach to
planning is related to satisability planning. There is, in fact, a formal connection
between the two methods. If a program without classical negation
is \positive-order-consistent," or \tight," then its answer sets can be characterized
by a collection of propositional formulas [6]|the formulas obtained
by applying the completion process [3] to the program. The translations
from language C described in [24] happen to produce tight programs. Describing
a planning problem by a program like this, then translating the
program into propositional logic, and, nally, invoking a satisability solver
to nd a plan is a form of satisability planning that can be viewed also as
\answer set programming without answer set solvers" [1]. This is essentially
how planning is performed by the Causal Calculator. 4
7 Conclusion
In answer set programming, solutions to a combinatorial search problem
are represented by answer sets. Plan generation in the domains that involve
actions with indirect eects are a promising application area for this
programming method.
Systems smodels and dlv allow us to solve some nontrivial planning
problems even in the absence of domain-specic control information. For
larger problems, however, such information becomes a necessity. The possibility
of encoding domain-specic control knowledge so that it can be used
by an answer set solver is crucial for progress in this area, just as the possibility
of using control knowledge by propositional solvers is crucial for further
progress in satisability planning [17]. This is a topic for future work.

Acknowledgements

Useful comments on preliminary versions of this paper have been provided
by Maurice Bruynooghe, Marc Denecker, Esra Erdem, Selim Erdogan, Paolo
Ferraris, Michael Gelfond, Joohyung Lee, Nicola Leone, Victor Marek, Norman
McCain, Ilkka Niemela, Aarati Parmar, Teodor Przymusinski, Miros law
Truszczynski and Hudson Turner. This work was partially supported by the
National Science Foundation under grant IIS-9732744.



--R

Fages' theorem and answer set programming.
Minimalism subsumes default
Negation as failure.
Encoding planning problems in non-monotonic logic programs
Transformations of logic programs related to causality and planning.

STRIPS: A new approach to the application of theorem proving to problem solving.
Autoepistemic logic and formalization of common-sense reasoning
The stable model semantics for logic programming.
Logic programs with classical negation.
Representing action and change by logic programs.
Action languages.
An action language based on causal explanation: Preliminary report.
Nonmonotonic logic and temporal projection.
Simple causal minimizations for temporal persistence and projection.
Using logic programs with stable model semantics to solve deadlock and reachability problems for 1-safe Petri nets
Control knowledge in planning: bene
The logic of persistence.
Planning as satis
Pointwise circumscription: Preliminary report.
Formal theories of action (preliminary report).
Action languages
Answer set planning.
Representing transition systems by logic programs.
Answer sets in general nonmonotonic reasoning (preliminary report).
Victor Marek and Miros law Truszczy
Victor Marek and Miros law Truszczy
Causal theories of action and change.
The anomalous extension problem in default reasoning.
Ilkka Niemel
Ilkka Niemel
ADL: Exploring the middle ground between STRIPS and the situation calculus.
A logic for default reasoning.
Chronological ignorance: Time
Timo Soininen and Ilkka Niemel
Relating stable models and AI planning domains.
Representing actions in logic programs and default theories: a situation calculus approach.
An application of action theory to the space shuttle.
--TR
Nonmonotonic logic and temporal projection
The anomalous extension problem in default reasoning
Autoepistemic logic and formalization of commonsense reasoning: preliminary report
Logic programs with classical negation
ADL
Planning as satisfiability
An action language based on causal explanation
Control knowledge in planning
Answer set planning
Extending and implementing the stable model semantics
Logic programs with stable model semantics as a constraint programming paradigm
Developing a Declarative Rule Language for Applications in Product Configuration
An Application of Action Theory to the Space Shuttle
Representing Transition Systems by Logic Programs
Transformations of Logic Programs Related to Causality and Planning
Using Logic Programs with Stable Model Semantics to Solve Deadlock and Reachability Problems for 1-Safe Petri Nets
Encoding Planning Problems in Nonmonotonic Logic Programs

--CTR
Esra Erdem , Vladimir Lifschitz, Tight logic programs, Theory and Practice of Logic Programming, v.3 n.4, p.499-518, July
M. De Vos , D. Vermeir, Extending Answer Sets for Logic Programming Agents, Annals of Mathematics and Artificial Intelligence, v.42 n.1-3, p.103-139, September 2004
Enrico Giunchiglia , Joohyung Lee , Vladimir Lifschitz , Norman McCain , Hudson Turner, Nonmonotonic causal theories, Artificial Intelligence, v.153 n.1-2, p.49-104, March 2004
Josefina Sierra-Santibez, Heuristic planning: a declarative approach based on strategies for action selection, Artificial Intelligence, v.153 n.1-2, p.307-337, March 2004
Chiaki Sakama, Induction from answer sets in nonmonotonic logic programs, ACM Transactions on Computational Logic (TOCL), v.6 n.2, p.203-231, April 2005
Ernest Davis , Leora Morgenstern, Introduction: progress in formal commonsense reasoning, Artificial Intelligence, v.153 n.1-2, p.1-12, March 2004
Thomas Eiter , Axel Polleres, Towards automated integration of guess and check programs in answer set programming: a meta-interpreter and applications, Theory and Practice of Logic Programming, v.6 n.1-2, p.23-60, January 2006

Davy Van Nieuwenborgh , Dirk Vermeir, Preferred answer sets for ordered logic programs, Theory and Practice of Logic Programming, v.6 n.1-2, p.107-167, January 2006
Tran Cao Son , Chitta Baral , Nam Tran , Sheila Mcilraith, Domain-dependent knowledge in answer set planning, ACM Transactions on Computational Logic (TOCL), v.7 n.4, p.613-657, October 2006
Pascal Hitzler , Matthias Wendt, A uniform approach to logic programming semantics, Theory and Practice of Logic Programming, v.5 n.1-2, p.93-121, January 2005
Marcello Balduccini , Enrico Pontelli , Omar Elkhatib , Hung Le, Issues in parallel execution of non-monotonic reasoning systems, Parallel Computing, v.31 n.6, p.608-647, June 2005
Chiaki Sakama , Katsumi Inoue, An abductive framework for computing knowledge base updates, Theory and Practice of Logic Programming, v.3 n.6, p.671-715, November
Nicola Leone , Gerald Pfeifer , Wolfgang Faber , Thomas Eiter , Georg Gottlob , Simona Perri , Francesco Scarcello, The DLV system for knowledge representation and reasoning, ACM Transactions on Computational Logic (TOCL), v.7 n.3, p.499-562, July 2006
Logic programming and knowledge representation-the A-prolog perspective, Artificial Intelligence, v.138 n.1-2, p.3-38, June 2002
answer sets;default logic;planning;frame problem;logic programming