Among other characteristics, an intelligent entity – whether an intelligent autonomous agent, or an intelligent assistant – must have the ability to go beyond just following direct instructions while in pursuit of a goal. This is necessary to be able to behave intelligently when the assumptions surrounding the direct instructions are not valid, or there are no direct instructions at all. For example even a seemingly direct instruction of ‘bring me coffee’ to an assistant requires the assistant to figure out what to do if the coffee pot is out of water, or if the coffee machine is broken. The assistant will definitely be referred to as lacking intelligence if he or she were to report to the boss that there is no water in the coffee pot and ask the boss what to do next. On the other hand, an assistant will be considered intelligent if he or she can take a high level request of ‘make travel arrangements for my trip to International AI conference 20XX’ and figure out the lecture times of the boss; take into account airline, hotel and car rental preferences; take into account the budget limitations, etc.; overcome hurdles such as the preferred flight being sold out; and make satisfactory arrangements. This example illustrates one benchmark of intelligence – the level of request an entity can handle.

In Chapter 4 we formulated several knowledge representation and problem solving domains using AnsProlog* and focused on the program development aspect. In this chapter we consider reasoning about actions in a dynamic world and its application to plan verification, simple planning, planning with various kinds of domain constraints, observation assimilation and explanation, and diagnosis. We do a detailed and systematic formulation – in AnsProlog* – of the above issues starting from the simplest reasoning about action scenarios and gradually increasing its expressiveness by adding features such as causal constraints, and parallel execution of actions. We also prove properties of our AnsProlog* formulations using the results in Chapter 3.

Our motivation behind the choice of a detailed formulation of this domain is twofold. (i) Reasoning about actions captures both major issues of this book: knowledge representation and declarative problem solving. To reason about actions we need to formulate the frame problem whose intuitive meaning is that objects in the worlds do not normally change their properties. Formalizing this has been one of the benchmark problems of knowledge representation and reasoning formalisms. We show how AnsProlog* is up to this task. Reasoning about actions also forms the ground work for planning with actions, an important problem solving task. We present AnsProlog encodings of planning such that the answer sets each encode a plan. (ii) Our second motivation is in regard to the demonstration of the usefulness of the results in Chapter 3.

Turing machines

This appendix is based on [Pap94] and it is recommended that the reader refer to that for detailed exposition on Turing machines, and computational complexity.

Intuitively, a deterministic Turing machine (DTM) is an automata bundled with a semi-infinite tape with a cursor to read from and write to. So, like an automata, there is a state and state transitions are based on the current state and what the cursor points to on the tape. But in addition to the state transition, there is an accompanying transition that dictates if the symbol in the tape location pointed to by the cursor should be overwritten and if the cursor should move to the left or right – by one cell – of its current position. Special symbols mark the beginning of the tape (>), the end of the input on the tape (⊔), and the output of the computation (‘halt’, ‘yes’, ‘no’). We now give a formal definition of DTMs.

Definition 151 A DTM is a quadruple M = (S, Σ, δ, s0) where S is a finite set of nonfinal states that includes s0 the initial state, Σ is a finite alphabet of symbols including the special symbols > and ⊔, and δ is a transition function that maps S × Σ to S ∪ {halt, yes, no} × Σ × {←, →, –}

Intuitively, δ is the control (or the program) of the machine that dictates how the machine behaves.

In this chapter we discuss three query answering and answer set computing systems: Smodels, dlv and PROLOG. Both Smodels and dlv are answer set computing systems and allow an input language with features and constructs not in AnsProlog*. While the Smodels system extends AnsProlog⊥ and AnsProlog⊥, ¬, the dlv system extends AnsProlog⊥,or and AnsProlog⊥,or,¬. We describe the syntax and semantics of the input language of Smodels and dlv and present several programs in their syntax. This chapter can be thought of as a quick introduction to programming in Smodels and dlv, not a full-fledged manual. At the time of writing this, both Smodels and dlv were evolving systems and readers are recommended to visit their corresponding web sites for the latest features.

After describing the Smodels and dlv systems with several small example programs, we consider several medium and large size applications and encode them using one or the other. In particular, we consider encoding of combinatorial auctions together with logical preference criteria, planning with durative actions and resources, resource constraint project scheduling, and specification and verification of active databases.

Finally, we give a brief introduction to the PROLOG interpreter and its approach to answering queries with respect to AnsProlog programs. We present conditions for AnsProlog programs and queries for which the PROLOG interpreter is sound and complete. We illustrate these conditions through several examples.

Smodels

The Smodels system is meant for computing the answer sets of AnsProlog⊥ and AnsProlog⊥,¬ programs and allows certain extensions to them.

In this chapter we formulate several knowledge representation and problem solving domains using AnsProlog*. Our focus in this chapter is on program development. We start with three well known problems from the literature of constraint satisfaction, and automated reasoning: placing queens on a chess board, determining who owns the zebra, and finding tile covering in a mutilated chess board. We show several encodings of these problems using AnsProlog*. We then discuss a general methodology for representing constraint satisfaction problems (CSPs) and show how to extend it to dynamic CSPs. We then present encodings of several combinatorial graph problems such as k-colorability, Hamiltonian circuit, and k-clique. After discussing these problem solving examples, we present a general methodology of reasoning with prioritized defaults, and show how reasoning with inheritance hierarchies is a special case of this.

Three well-known problem solving tasks

A well-known methodology for declarative problem solving is the generate and test methodology whereby possible solutions to the problem are generated and non-solutions are eliminated by testing. This is similar to the common way of showing that a problem is in the class NP, where it is shown that after the non-deterministic choice the testing can be done in polynomial time. The ‘generate’ part in an AnsProlog* formulation of a problem solving task is achieved by enumerating the possibilities, and the ‘test’ part is achieved by having constraints that eliminate the possibilities that violate the test conditions. Thus the answer sets of the resulting program correspond to solutions of the given problem.

Earlier in Chapter 3 we discussed several results and properties of AnsProlog* programs that are useful in analyzing and step-by-step building of these programs. In this chapter we consider some broader properties that help answer questions such as: (a) how difficult is it to compute answer sets of various sub-classes of AnsProlog*? (b) how expressive are the various sub-classes of AnsProlog*? (c) does the use of AnsProlog* lead to compact representation or can it be compiled to a more tractable representation? and (d) what is the relationship between AnsProlog* and other knowledge representation formalisms?

The answers to these questions are important in many ways. For example, if we know the complexity of a problem that we want to solve then the answer to (a) will tell us which particular subset of AnsProlog* will be most efficient, and the answer to (b) will tell us the most restricted subset that we can use to represent that problem. With respect to (c) we will discuss results that show that AnsProlog* leads to a compact representation. This clarifies the misconception that since many AnsProlog* classes belong to a higher complexity class, they are not very useful. For specifications where AnsProlog* leads to (exponentially) compact representation the fact that they are computationally harder is canceled out and they become preferable because compact representation means that the programmer has to write less. So the burden is shifted from the programmer to the computer, which is often desirable.

In this chapter we present several small AnsProlog* programs corresponding to several declarative problem solving modules or knowledge representation and reasoning aspects. Although in general we may have intermingling of the declarative problem solving, and the knowledge representation and reasoning aspects, they can be differentiated as follows.

Normally a problem solving task is to find solutions of a problem. A declarative way to do that is to declaratively enumerate the possible solutions and the tests such that the answer sets of the resulting program correspond to the solutions of the problem. The declarative problem solving modules that we consider in this chapter include modules that enforce simple constraints, modules that enumerate interpretations with respect to a set of atoms, modules that uniquely choose from a set of possibilities, modules that encode propositional satisfiability, modules that represent closed first-order queries, modules that check satisfiability of quantified boolean formulas with up to two quantifiers, modules that assign a linear ordering between a set of objects, modules that can represent various aggregations of facts (such as minimization, maximization, sum and average), modules that encode classical disjunction conclusions, modules that encode exclusive-or conclusions, and modules that encode cardinality and weight constraints.

By knowledge representation and reasoning aspects we mean representing particular benchmark aspects of nonmonotonic and common-sense reasoning that we want to be encoded by AnsProlog* programs.

So far in the book we have considered sub-classes of AnsProlog* which have been well-studied in the literature and two additional extensions AnsPrologsm and AnsPrologdlv which are the input language of the answer set computing systems Smodels and dlv. There have been several additional proposals for extending AnsProlog*, which are not that well-studied. Also, there have been many alternative proposals to characterize programs in the syntax of AnsProlog* and its sub-classes. In this chapter we give a brief overview of the above two aspects.

Some of the extensions that we consider are: (i) enriching the rules by allowing not in the head of rules, (ii) allowing nesting in the head and body of rules; (iii) allowing additional operators such as knowledge and belief operators; (iv) enriching the framework by allowing abduction; (v) allowing explicit specification of intent to use domain closure and its impact on the universal query problem; (vi) allowing set constructs; and (vii) allowing specification preferences between rules of a program.

In regard to alternative characterizations of programs in the syntax of AnsProlog* and its sub-classes, we focus mostly on AnsProlog and AnsProlog¬ syntax, and the well-founded semantics. In the process we define notions such as the 3-valued stable models, and stable classes which are related to both the well-founded characterization and the answer sets. We also briefly discuss the framework of argumentation which can be used in defining both answer sets and the well-founded characterization of programs in AnsProlog syntax.