1 Introduction
The ACLP framework and system is an attempt to address the problem of providing a highlevel declarative programming (or modeling) enviroment for problems of Artificial Intelligence which at the same time has an acceptable computational performance. Its key elements are (i) the support of abduction as a central inference of the system, to facilitate a highlevel of expressivity for problem representation, and (ii) the use of constraint solving to enhance the efficiency of the computational process of abductive inference as this is applied on the highlevel representation of the problem at hand.
It has been argued in [Denecker & Kakas2000] that declarative problem solving, where the proplem representation contains information about properties that hold true in the problem domain rather than information on methods of how we would solve the problem, and abduction are closely related to each other. In an (ideal) declarative setting problem solving consists of filling in missing information from the theory that represents the problem. In other words, the solution consists of an extension of the basic description of the problem so that the problem task (or goal) is satisfied in this extended description. This process of extending the theory is called abduction. For example, in a logical setting, abduction as a problem solving method, assumes that the general data structure for the solution to a problem (or solution carrier) is at the predicate level and hence a solution is described in the same terms and level as the problem itself.
Indeed, abduction allows a highlevel representation of problems close to their natural specification suitable for addressing a variety of problems in AI, such as diagnosis, planning and scheduling, natural language understanding, assimilation of sensor data and user modeling. The main advantage of using abduction to solve these problems is the highlevel representation or modeling environment that it offers. This in turn provides a high degree of modularity and flexibility which is useful for applications with complex and changing requirements. But although the utility of abduction for formulating such problems in AI is well proven there has been little work (see though [Menzies1996]) to address the question of whether these abductive formulations can form the basis for computationally effective solutions to realistic problems.
ACLP tries to address this problem by a nontrivial integration of constraint solving within the abductive process. The general pattern of computation in ACLP consists of a cooperative interleaving between hypotheses and constraint generation, via abductive inference, with constraint satisfaction of the generated constraints. Abductive reasoning provides an incremental reduction of the highlevel problem representation and goals to abductive hypotheses together with lowerlevel constraints whose form is problem independent. The integration of abductive reasoning with constraint solving in ACLP is cooperative, in the sense that the constraint solver not only solves the final constraint store generated by the abductive reduction but also affects dynamically this abductive search for a solution. It enables abductive reductions to be pruned early by setting new suitable constraints on the abducible assumptions into the constraint store, provided that this remains satisfiable. During the ACLP computation there is a nontrivial interaction between (i) reduction of goals and consistency checking of abducible assumptions, (ii) setting new constraints in the constraint store of reduction and (iii) generating further abductive hypotheses.
2 General Information
Currently, the ACLP system is implemented as a metainterpreter on top of the CLP language of ECLiPSe. As such the system is relatively compact comprising about 500 lines of code. It is based on the abductive proof procedure developed in [Kakas & Michael1995] (which in turn follows a series of proof procedures [Eshghi & Kowalski1989], [Kakas & Mancarella1990a], [Kakas & Mancarella1990b]) and uses the CLP constraint solver of ECLiPSe to handle constraints over finite domains (integer and atomic elements). The architecture of the system is quite general and can be implemented in a similar way with other constraint solvers.
The ACLP system runs on any platform on which ECLiPSe runs. This
includes all major platforms.
It can be obtained, together with information on how to use it,
from the following web address: http://www.cs.ucy.ac.cy/aclp/.
ACLP programs (see section 3 below) are loaded
into ECLiPSe together with the ACLP system file, aclp.pl,
and executed
by calling the toplevel ECLiPSe query:
aclpsolve(+Goal, +Initialhypothesis, ?outputvariable).
The outputvariable returns a list of abducible hypotheses, with their
domain variables constrained according to the dynamic constraints that were
generated through the unfolding of the “relevant” part, with
respect to the Goal, of the
program and the integrity constraints.
A subsequent step of labelling on these
variables is needed to give a ground solution of our query, +Goal.
Various constraint predicates of ECLiPSe can be used at this stage
e.g. min_max/2 or minimize/2 to find an optimal
ground solution. If we are not interested in such further optimization
we can use the simpler queries:
aclpsolve(+Goal)
aclpsolve(+Goal, +Initialhypothesis).
The initialhypothesis variable is a list of ground abducible facts which we want the system to take as given when constructing a solution. It is used when we have partial information about the solution that we are looking for. (If no such information is known then this is given as the empty list.) Its typical use is when we want to recompute the solution to a goal under some new requirements by adapting the old solution as for example in the case of rescheduling. The old solution (or part of this) will then form the initialhypothesis.
3 Applying the System
The ACLP system is a programming environment on top of the ECLiPSe language. An ACLP program is an abductive theory consisting of a triple where:

is a finite set of userdefined ECLiPSe clauses,

is a set of declarations of abducibles predicates in the form of ECLiPSe facts as: ,

is a set of integrity constraints written as ECLiPSe rules of the form: where:

at least one of the goals has an abducible predicate, and

the rest of the goals can be either positive or negative literals on userdefined predicates or constraint predicates of ECLiPSe.

The (lowerlevel) problem independent CLP constraint predicates that can be used in the body of a program rule or an integrity constraint can be (i) arithmetic constraint predicates (over the integers) or (ii) logical contraint predicates. The constraint predicates on finite domain variables of ECLiPSe that are supported by the current ACLP implementation are:
 T1##T2 :

the value of variable T1 is not equal to that of variable T2.
 T1#=T2 :

the value of variable T1 is equal to that of variable T2.
 T1#<T2 :

the value of variable T1 is less than that of variable T2.
 T1#<=T2:

the value of variable T1 is less or equal to that of variable T2.
 T1#>T2 :

the value of variable T1 is greater than that of variable T2.
 T1#>=T2:

the value of variable T1 is greater or equal to that of variable T2.
The equality and inequality constraints are also supported over other nonarithmetic userdefined finite domains. The system also has a term equality constraint, T1##=T2 , where the terms and can contain variables one level deep inside a function sympol. In addition, ACLP supports logical constraints such as conjunction, #, and disjunction, #. These simple constraints can be combined to build complex logical constraint expressions. During the ACLP computation constraints maybe negated and their negation is set in the current constraint store. This negation of the constraints is the usual mathematical negation, e.g. the negation of the aritmetic constraint T1#<T2 is T1#>=T2. The negation of the logical constraint # is #.
An ACLP program, , can contain negation as failure literals in and . Negation as failure is handled through abduction simply as another type of abducible in the theory. All occurences of in the program are replaced by which is treated as an abducible with the canonical integrity constraint In the current implementation it is necessary for the user to specify explicitly both the fact that is abducible by adding a statement in the program as well as adding the above canonical constraint in the program. The semantics of negation as failure is that of (partial) Stable Models in the program and Generalised (partial) Stable Models when we consider the whole abductive theory with its integrity constraints . The details of the abductive semantics for ACLP programs and the particular treatment of NAF can be found in [Kakas, Michael, & Mourlas2000].
As an example, the ACLP program below is an implementation of the basic axioms (of persistence) of the Event Calculus [Kowalski & Sergot1986] suitable for abductive planning. The program consists of the following clauses:
holds_at(P,E) : initially(P,T), not clipped(T,E,P). holds_at(P,E) : initiates(P,A), time(T), T #< E, act(T,A), not clipped(T,E,P).
together with the auxiliary definitions:
between(A,B,C) : A #<B, B#<C. time(T) : maximum_time(Max), T :: 1..Max.
The abducible predicates in are the action predicate and the NAF predicate declared by the following clauses:
abducible_predicate(act/2). abducible_predicate(not_clipped/3).
The integrity constraints in contain the negation as failure constraint as the clause:
ic : not_clipped(T,E,P), terminates(P,A1), act(C,A2), A1 ##= A2, between(T,C,E).
and contraints that encode the preconditions of actions written as clauses of the general form:
ic : act(T,A), not preconditions(A,T).
In a specific planning domain, e.g. the trucks domain, this will be extended with clauses for the and predicates in , for example:
initiates(in(Obj,Truck), load_truck(Obj,Truck,Loc)). terminates(at(Obj,Loc), load_truck(Obj,Truck,Loc)).
and the definitions, again in , of the preconditions of the specific actions in the domain, for example:
preconditions(load_truck(Obj,Truck,Loc),T): holds_at(at(Obj,Loc),T), holds_at(at(Truck,Loc),T).
The initial state is defined by a set of facts of the form , e.g.
3.1 Methodology
ACLP has been applied to several different types of abductive problems such as planning, aircrew scheduling, optical music recognition, analysis of software requirements and intelligent information integration (see below section3.2). Although most of these applications are not of ”industrial scale” they indicate some methodological guidelines that can be followed when using ACLP. As ACLP is a general development framework with no specific application domain these guidelines can only be themselves of a general nature.
The central advantage of an abductive approach is the highlevel declarative representation that it allows. This means that the development of the program can be done incrementally starting first with a ”pure” declarative representation based on a simple model of the problem and gradually refine this model to reflect more and more particular domain knowledge of the problem at hand. A central first decision to be taken is the choice of abducibles for the problem. These play the important role of the solution carriers or answers to the problem goals. Each problem has its own abducible answer predicates (c.f. the usual answer holder of a logical variable in LP and CLP ) which means that we can describe directly in our theory (the ACLP program) the desired properties of the solution.
An important methodological step is the distinction between strict validity requirements on the solution of our problem, which are separated in the integrity constraints of the ACLP theory, and the basic model of our problem which is described in the program of the ACLP theory. A good such separation means that we can then incrementally refine this basic model to improve the quality of the solution without affecting its validity (which is always ensured by the integrity constraints in ). As we refine our representation we include more domain specific information, exploiting any natural structures of the problem at hand, that can help to improve the computation of the solution.
At a final step of refinement of the problem representation we can develop the model in order to control the choice of abducible in the abductive reduction of the problem goals. This choice can be implemented to follow either some heuristics, priorities, or algorithm for optimality, to control both the computational efficiency and the quality of the solutions. We can then experiment with different design alternatives adopting different strategies to study how this would affect the quality of the solutions. In large scale problems the user can also experiment with different orders in which the integrity constraints are satisfied. Generally, the heuristic of trying first more specific integrity constraints gives better results.
An importnat characteristic of an ACLP representation of a problem is the flexibility it offers under new or dynamically changing requirements. Once we have one complete representation of the problem we can easily experiment with different requirements on the solution, by changing the integrity constraints which specialize the general model to the needs and preferences of a particular case. This can be done in a modular way by affecting only the integrity constraints to reflect the new requirements.
3.2 Users and Useability
ACLP is a highlevel knowledge representation environment which supports directly abduction. Its use requires some basic knowledge of logic programming, constraint logic programming [J.Jaffar & M.J.Maher1998] and abductive logic programming [Kakas, Kowalski, & Toni1998]. As it is implemented on top of ECLiPSe knowledge of this particular CLP language can help. In some cases it is also useful to understand some of the basic search heuristics that ACLP and ECLiPSe underneath use in their computation (see below in section 4). Details of how to use it with examples can be found at the web page of ACLP at: http://www.cs.ucy.ac.cy/aclp/.
The ACLP framework as a declarative problem solving paradigm can be used to address several different types of problems. Its developers have applied it initially to the problems of scheduling and planning [Kakas & Mourlas1997, Kakas, Michael, & Mourlas1998] to test its computional effectiveness and its flexibility in problem representation. Also it has been used in an industrial application of crewschedulling [Kakas & Michael1999]. Other groups have used ACLP for (i) optical music recognition [Ferrand, Leite, & Cardoso1999] where ACLP was used to implement a system that can handle recognition under incomplete information, and (ii) resolving inconsistencies in software requirements [Russo et al.1999] where (a simplified form of) ACLP was used to identify the causes of inconsistency and suggest changes that can restore consistency of the specification. Also the intelligent information integration work of [Bressan & Goh.1997] although it does not use ACLP in its implementation its approach to information integration is based on an ACLP representation.
Currently, we are considering two new applications of ACLP. One is that of the development of an information integration mediator for integrating information suitable for electronic commerce applications. The other application area concerns the further development of the problem of planning with emphasis on (i) the study of a systematic way to exploit domain specific information, and (ii) the problem of planning under incomplete information about the initial state of the problem.
We also mention that ACLP programs can be generated automatically from example data using a machine learning technique called
abductive concept learning. For details of this method and a related system see http://wwwlia.deis.unibo.it/Software/ACL/.4 Evaluating the System
At this initial stage of the development of the ACLP system the main aim of its evaluation is to understand the cost of the extra highlevel expressivity layer that it gives (over for example CLP approaches) in comparison with the advantages of modularity that this may provide. The ACLP system has thus been evaluated mainly in two different directions: (i) computational efficiency, particularly in comparison with the underlying CLP language of ECLiPSe on which it is implemented, and (ii) flexibility under changes of the problem specification. The overall evaluation of an application under ACLP is a combination of these two factors together with the quality of the generated solutions under some optimization criteria when such criteria apply.
For example, the aircrew scheduling application in [Kakas & Michael1999] produced solutions (for the small sized company of Cyprus Airways) that were judged to be of good quality, comparable to manually generated solutions by experts of many years on the particular problem, while at the same time it provided a flexible platform on which the company^{1}^{1}1 Unfortunately, the company has decided not to use the system for reasons that relate more to their policy of adopting a global solution to the full computerization of their operation with direct compatibility between their different systems. could easily experiment with changes in policy and preferences. Also the rescheduling module of the system was judged to be of highvalue both as a tool for adjusting the initially generated solution and for handling unexpected changes on the day of operation.
The computational effectiveness of the ACLP system depends on two factors: (a) the effectiveness of the reduction of the highlevel ACLP representation to lowerlevel finite domain constraints and (b) the effeciency of the underlying constraint solver in propagating (or solving) these constraints. In fact, these two factors are interrelated as in many cases the reduction in (a) depends on the completeness of the propagation in (b). For some problems where these are not strongly related e.g. in the case of jobshop sheduling we can see that in comparison with (b) the overhead for the reduction in (a) is small. Information on these evaluation experimenents can be found at the ACLP web pages. Further results of comparison on problems where factors (a) and (b) are loosesly coupled can be found in the recent work of [Pelov, Mot, & Bruynooghe2000] where experiments with various types of systems, including ACLP, on the constraint satisfaction problems of the Nqueens and graph colouring have been perfomed.
Another, but limited, comparison that we have carried out in order to test the effectiveness of the current ACLP implementation was a comparison with the use of Constraint Handling Rules (CHRs) [Fruhwirth1998] on the same problems of jobshop scheduling. On the whole the ACLP system was at least as effecient as CHR. It should be noted though that these comparions were carried out before recent developments on CHRs.
In problems where the search space of the reduction of the highlevel specification depends strongly on the fast detection that the contraint store of finite domain constraints is becoming unsatisfiable, the overall computational efficiency of ACLP can be sensitive to the particular way of modeling the problem and the amount of specific domain knowledge it contains pertaining to the computation aspects of the problem. Such a problem is that of planning. As an example, table 1 shows the execution time (on a SUN Ultra1 with 64Mb RAM) and the number of moves required for an indicative set of blocks world planning problems. The representation of the problem that was used was purely declarative with the exception that the towers of the final state were to be build in a horizontal fashion from the bottom up. The number of available positions on the table was restricted to be one third of the total number of blocks in order to make the problems more computationally demanding. These times are comparable with the execution times of solving such problems directly in ECLiPSe as reported in [ElKholy & Richards1996].
Performance Measurements  
Blocks  time (in secs)  # of moves 
15  3.7  23 
24  15.19  34 
33  40.69  49 
42  69.5  58 
51  325.97  74 
60  345.52  87 
69  662.15  101 
The flexibility of the ACLP system as a knowledge representation framework is tested by examining how easy it is for a given ACLP representation to be adapted under changes in the requirements of the original problem. There are two factors to measure here: (1) the programming effort required to adapt an existing solution to the new problem, and (2) the computational robustness of the system under such changes. Experiments in the domains of jobshop scheduling, aircrew scheduling and planning show that the extra programming effort in ACLP is considerably smaller than the corresponding effort when the problem is represented directly in ECLiPSe. In many cases, the effort required in ACLP is simply the addition of some new integrity constraints written directly from the declarative specification of the new requirements. The same experiments show that on the whole the computational performance of ACLP remains within the same order of magnitute under changes which affect the problem only locally in one part, e.g. extra requirements on the moves allowed for a particular ”small” subset of blocks in the problem of blocks world planning.
Another feature of the flexibility of ACLP is the ability to use it to recompute the solution for a given goal, under some new information about the particular instance of the problem, so that the new solution remains ”close” to the old solution, e.g. it contains a minimal number of changes from the old solution. Experiments to test this feature have been performed on the problems of jobshop and aircrew scheduling. Table 2 shows an example of the results. For each one of these problems a new requirement of some resource unavailability was added (shown below in the first column). The rescheduling results are shown in the third column of the table, which gives the time together with the number of changes needed on the existing solution in order to satisfy the new requirements. The fourth column displays the analogous information for the control experiment of reexecuting the goal with the extra requirement represented in the program but now without any initial solution.
Performance & Quality Measurements  

Problem  Initial Solution  Rescheduling  ReExecution 
# tasks  Resource Availability  /  /  
25 tasks  
unavailable in period (0,20)  0.23  0.27/4  0.23/21 
50 tasks  
unavailable in period (20,30)  0.71  1.94/14  0.74/40 
75 tasks  
unavailable in period (0,16)  1.03  1.25/5  1.81/25 
100 tasks  
unavailable in period (20,35)  1.61  1.95/1  1.67/47 
4.1 Future Development
ACLP is a general purpose declarative programming framework. Hence its evaluation must combine different aspects of its performance. At this initial stage the emphasis in the development of the first prototype was on its declarativeness together with an acceptable computational performance.
The search that ACLP performs in constructing a solution needs further study for improvement. Currently, the system employs a few simple heuristics to help in its search. As ACLP is parametric on the underlying finite domain constraint solver improvements on its performance will improve the ACLP performance. More important though, is the interaction between the abductive reduction and the satisfaction of the finite domain constaints that it generates. This is the major aspect of the search space of ACLP. Hence one way to improve the ACLP search is to develop further the interface between the abductive reduction and the constraint solver so that the propagation of the domain constraints varies according to some heuristic criteria on the point of the search space where the request to the constraint solver is made.
In particular, while the abductive process is reducing the highlevel goal and integrity constraints there are choice points where we can either introduce a new abducible hypothesis in the solution or instead backtrack higher up in the search space. In many cases, this decision can be made to depend on the satisfaction of some of the lowerlevel domain constraints that are generated by the abductive reduction. We can then evaluate the significance of their satisfaction (currently the system adopts a very simple form of evaluation) and depending on this guide the search to introduce or not a new hypotheses in the solution. This has to be combined with the general heuristic of abductive search of prefering to reuse hypotheses and delay the specialisation of (nonground) hypotheses or the generation of new ones. In developing though a better search for ACLP it maybe necessary to restrict our attention to separate classes of problems e.g. to develop separately an ACLP planner from an ACLP system for diagnosis.
These considerations of improving the general purpose search strategy of the system is an important next stage of development. On the other hand, it is clear that the general improvement of efficiency that can be achieved is limited as we are aiming to use the system for computational hard problems. Hence another line of development is to provide more facilities for problem specific information to be incorporated in the representation of the problem whose exploitation can improve the performance of the system on the particular problem at hand. This problem specific information could include information to directly control the search of the system on the particular problem in the same spirit of recent developments for controlling models in constraint programming [Hentenryck1999].
References
 [Bressan & Goh.1997] Bressan, S., and Goh., C. 1997. Semantic integration of disparate information sources over the internet using constraints. In Constraint Programming Workshop on Constraints and the Internet.
 [Denecker & Kakas2000] Denecker, M., and Kakas, A. C. 2000. Abductive logic programming: Editorial forward. Journal of Logic Programming: Special Issue of Abductive Logic Programming.
 [ElKholy & Richards1996] ElKholy, A., and Richards, B. 1996. Temporal and resource reasoning in planning: the parcplan approach. In Proceedings of ECAI96.
 [Eshghi & Kowalski1989] Eshghi, K., and Kowalski, R. 1989. Abduction compared with Negation by Failure. In Proceedings of the 6th International Conference on Logic Programming.
 [Ferrand, Leite, & Cardoso1999] Ferrand, M.; Leite, J.; and Cardoso, A. 1999. Improving optical music recognition by means of abductive constraint logic programming. In Proceedings of EPIA’99, number 1695 in LNAI, 342–356.
 [Fruhwirth1998] Fruhwirth, T. 1998. Theory and practice of constraint handling rules. Journal of Logic Programming: Special Issue on Constraint Logic Programming 37(13).
 [Hentenryck1999] Hentenryck, P. V. 1999. Optimization Programming Language. MIT Press.
 [J.Jaffar & M.J.Maher1998] J.Jaffar, and M.J.Maher. 1998. Constraint logic programming: A survey. In Gabbay, D.; Hogger, C.; and Robinson, J., eds., Handbook of Logic in AI and Logic Programming, volume 5. Oxford University Press. 591–696.
 [Kakas & Mancarella1990a] Kakas, A., and Mancarella, P. 1990a. Database updates through abduction. In D. McLeod, R. S.D., and Schek, H., eds., Proceedings of the 16th International Conference on Very Large Databases, VLDB90, 650–661. Morgan Kaufmann.
 [Kakas & Mancarella1990b] Kakas, A., and Mancarella, P. 1990b. On the relation between truth maintenance and abduction. In Proceedings of the 2nd Pacific Rim International Conference on Artificial Intelligence.
 [Kakas & Michael1995] Kakas, A., and Michael, A. 1995. Integrating abductive and constraint logic programming. In Procedings of the 12th International Conference on Logic Programming, ICLP95.
 [Kakas & Michael1999] Kakas, A., and Michael, A. 1999. Aircrew scheduling through abduction. In Proceedings of IEA/AIE99, 600–612.
 [Kakas & Mourlas1997] Kakas, A., and Mourlas, C. 1997. Aclp: Flexible solutions to complex problems. In Proceedings of Logic Programming and Nonmonotonic Reasoning, LPNMR97.
 [Kakas, Kowalski, & Toni1998] Kakas, A.; Kowalski, R.; and Toni, F. 1998. The role of abduction in logic programming. In Gabbay, D.; Hogger, C.; and Robinson, J., eds., Handbook of Logic in AI and Logic Programming, volume 5. Oxford University Press. 235–324.
 [Kakas, Michael, & Mourlas1998] Kakas, A.; Michael, A.; and Mourlas, C. 1998. Aclp: a case for nonmonotonic reasoning. In Proceedings of NMR98, 46–56.
 [Kakas, Michael, & Mourlas2000] Kakas, A.; Michael, A.; and Mourlas, C. 2000. Aclp: Abductive constraint logic programming. Journal of Logic Programming: Special Issue of Abductive Logic Programming.
 [Kowalski & Sergot1986] Kowalski, R., and Sergot, M. 1986. A logicbased calculus of events. Journal of New Generation Computing 4.
 [Menzies1996] Menzies, T. 1996. Applications of abduction: Knowledgelevel modeling. Journal of Human Computer Studies.
 [Pelov, Mot, & Bruynooghe2000] Pelov, N.; Mot, E. D.; and Bruynooghe, M. 2000. A comparison of logic programming approaches for representation and solving of constraint satisfaction problems. In Proceedings of NMR2000: special session on Abduction.
 [Russo et al.1999] Russo, A.; Miller, R.; Nuseibeh, B.; and Kramer, J. 1999. An abductive approach for handling inconsistencies in scr specifications. Technical report, Imperial College.
Comments
There are no comments yet.