oriâ guaranteed on demand by means of a syntactic restriction check that ensures a finite-domain property. The system, which is already successfully used in ...
An ASP System with Functions, Lists, and Sets Francesco Calimeri, Susanna Cozza, Giovambattista Ianni, and Nicola Leone Department of Mathematics, University of Calabria, I-87036 Rende (CS), Italy {calimeri,cozza,ianni,leone}@mat.unical.it
Abstract. We present DLV-Complex, an extension of the DLV system that features the support for a powerful (possibly recursive) use of functions, list and set terms in the full ASP language with disjunction and negation. Any computable function can be encoded in a rich and fully declarative KRR language, ensuring termination on all programs belonging to the recently introduced class of finitely-ground programs; furthermore, termination can be “a priori” guaranteed on demand by means of a syntactic restriction check that ensures a finite-domain property. The system, which is already successfully used in many universities and research institutes, comes also equipped with a rich library of built-in functions and predicates for the manipulation of complex terms.
1 System Language A term is either a simple term or a complex term. A simple term is either a constant or a variable. A complex term is either a functional, a list or a set term. If t1 . . . tn are terms, then complex terms are defined as follows. • A functional term is defined as f (t1 , . . . , tn ), where f is a function symbol (functor) of arity n. • A list term can be of the two forms: − [t1 , . . . , tn ], where t1 , . . . , tn are terms; − [h|t], where h (the head of the list) is a term, and t (the tail of the list) is a list term. • A set term is defined as: {t1 , . . . , tn }, where {t1 , . . . , tn } do not contain any variable. Some functional terms, referred to as built-in functions, are predefined, and have a fixed meaning. Syntactically, their functors are prefixed by #. Such kind of functional term is supposed to be substituted by the value resulting from the application of the functor to its arguments, according to some predefined semantics. For this reason builtin functions are also referred to as interpreted functions.1 If t1 , . . . , tk are terms, then p(t1 , . . . , tk ) is an atom, where p is a predicate of fixed arity k ≥ 0; by p[i] we denote its i-th argument. Atoms prefixed by # are instances 1
The system herein presented provides a number of interpreted functions, including arithmetic operations and list and set manipulation functions.
E. Erdem, F. Lin, and T. Schaub (Eds.): LPNMR 2009, LNCS 5753, pp. 483–489, 2009. c Springer-Verlag Berlin Heidelberg 2009
484
F. Calimeri et al.
of built-in predicates. Such kind of atoms are evaluated as true or false by means of operations performed on their arguments, according to some predefined semantics.2 A literal l is of the form a or not a, where a is an atom; in the former case l is positive, and in the latter case negative. A rule r is of the form α1 ∨ · · · ∨ αk :β1 , . . . , βn , not βn+1 , . . . , not βm . where m ≥ 0, k ≥ 0; α1 , . . . , αk and β1 , . . . , βm are atoms. We define H(r) = {α1 , . . . , αk } (the head of r) and B(r) = B + (r)∪B − (r) (the body of r), where B + (r) = {β1 , . . . , βn } (the positive body of r) and B − (r) = {not βn+1 , . . . , not βm } (the negative body of r). If H(r) = ∅ then r is a constraint; if B(r) = ∅ and |H(r)| = 1 then r is referred to as a fact. A rule is safe if each variable in that rule also appears in at least one positive literal in the body of that rule. For instance, the rule p(X, f (Y, Z)) :- q(Y ), not s(X). is not safe, because of both X and Z. From now on we assume that all rules are safe and there is no constraint.3 An ASP program is a finite set P of rules. As usual, a program (a rule, a literal) is said to be ground if it contains no variables. A thorough discussion about the semantics, based on the notion of Answer Set proposed in [1], can be found in [2].
2 Knowledge Representation with DLV-Complex The main strength point of DLV-Complex, besides all those shared with DLV [3], is the featured language, that includes a full usage of function symbols and a native support for list and set terms. Function symbols, and other complex terms, allow to aggregate atomic data, manipulate complex data structures and generate new symbols (value invention). This paves the way to a more natural knowledge representation. Example 1. The term notify(delete(F)) in the atom request(S, I, notify (delete(F)), T 0) is a functional term. Other examples of functional terms are father(X) and mother(X) in the atom family trio(X, father(X), mother (X)), or f(g(a)) in the atom p(f(g(a))). Lists can be profitably exploited in order to explicitly model collections of objects where position matters, and repetitions are allowed. Example 2. The term [a,d,a] in the atom palindromic([a,d,a]) is a list term. Other examples of list terms are [jan,feb,mar], or [jan,feb|[mar,apr,may, jun]], or [[jan,31]| [[feb,28],[mar,31],[apr,30],[may,31],[jun, 30]]]. Set terms are used to model collections of data having the usual properties associated with the mathematical notion of set. They satisfy idempotence (i.e., sets have no duplicate elements) and commutativity (i.e., two collections having the same elements but with a different order represent the same set) properties. 2
3
The system herein presented provides some simple built-in predicates, such as the comparative predicates equality, less-than, and greater-than (=, ), list and set predicates like #member, #subset. Under Answer Set semantics, a constraint :- B(r) can be simulated through the introduction of a standard rule fail :- B(r), not fail, where fail is a fresh predicate not occurring elsewhere in the program.
An ASP System with Functions, Lists, and Sets
485
Example 3. The term {john,carl,ann,mary} in the atom seatAt(1,{john,carl, ann, mary}) is a set term. Other examples of set terms are {red,green,blue}, or {[red,5], [blue,3],[green,4]}, or {{red,green},{red,blue},{green, blue}}. It is worth remembering that duplicated elements are ignored, thus the terms {red,green,blue} and {green, red,blue,green} actually represent the same set. In the following we illustrate the usage of DLV-Complex as a tool for knowledge representation and reasoning, by means of some examples.4 Example 4. Suppose that a system administrator wants to model the following security policy about file deletion: ‘A certain subject (a person, an agent,..) S is permitted to delete a file F if at a time T0 she/it sends a request to a target institution I, notifying the intention of deleting F , and there are no explicit request from I to S to retain F in the next ten units of time’. The following rule can be used to naturally express this policy thanks to proper functional terms. permitted(S, delete(F ), T1 ) :- request(S, I, notif y(delete(F )), T0 ), not requestInBetween(I, S, retain(F ), T0 , T1 ), T1 = T0 + 10.
Example 5. We show now how lists can be used to model strings of characters. Let us consider the following facts: word([a, d, a]). word([g, i, b, b, i]). word([a, n, n, a]).
The following rule: palindromic(X) :- word(X), #reverse(X) = X.
allows to easily deduce words that are palindromic by using the interpreted function #reverse for inverting the order of the elements in a list, and the built-in predicate ‘=’ for comparison. The program consisting of the two rules above would have the unique following answer set: {palindromic([a, d, a]), palindromic([a, n, n, a])}.
Example 6. Let us consider the famous “Towers of Hanoi” puzzle [5]. Assume that a possible move is represented by the predicate possible move, featuring three attributes: the first represents the move number, the second the state of the three stacks before applying the current move, and the last the state of the three stacks after the move has been applied. Then, we can encode a possible move from the first stack to the second stack by means of the following rule: possible move(#succ(I), towers([X|S1], S2, S3), towers(S1, [X|S2], S3)) :possible state(I, towers([X|S1], S2, S3)), legalM oveN umber(I), legalStack([X|S2]).
Roughly, the top element of the first stack can be moved on top of the second stack if: (i) the current state for stacks is admissible, i.e. this state can be reached after applying 4
Full encodings for problems presented in Example 6 and Example 7 can be found at [4].
486
F. Calimeri et al.
a sequence of “I” moves(possible state(I,towers([X|S1],S2,S3))); (ii) the number “I” is in the range of allowed move numbers (legalMoveNumber(I)); (iii) the new resulting configuration for the second stack is legal, i.e. there is no larger disc on top of a smaller one (legalStack([X|S2])). It is worth noting the use “`a la Prolog” ([Head|Tail]) for lists, and the role of the interpreted function #succ, whose meaning is straightforward. Example 7. If facts like: sons( someone, {son1 , ..., sonn }) model the association between a parent and her/his sons, one can make the transitive closure and obtain the names of all descendants of someone by means of the following rules: ancestor(A, Ss) :- sons(A, Ss). ancestor(A, #union(Ds, Ss)) :- ancestor(A, Ds), #member(S, Ds), sons(S, Ss).
where the first argument of the predicate “ancestor” represents the name of a person (ancestor) and the second argument represents the set of names of descendants of this person. The first rule says that all sons of A are descendants of A. The second rule says that if Ds are descendants of A, S belongs to the set of descendants Ds, and Ss is the set of all sons of S, then the set resulting from the union of the sets Ds and Ss is also a set of descendants for A. The second rule makes use of the interpreted function #union and the built-in predicate #member, which have intuitive meaning. Example 8. Let us imagine that the administrator of a social network wants to increase the connections between users. In order to do that, (s)he decides to propose a connection to pairs of users that result, from their personal profile, to share more than two interests. If the data about users are given by means of EDB atoms of the form user(id, {interest1 , . . . , interestn }), the following rule would compute the set of common interests between all pairs of users: sharedInterests(U1, U2 , #intersection(S1 , S2 )) :- user(U1 , S1 ), user(U2 , S2 ), U1 = U2 .
where the interpreted function #intersection takes as input two sets and returns their intersection. Then, the predicate selecting all pairs of users sharing more than two interests could be defined as follows: proposeConnection(pair(U1 , U2 )) :- sharedInterests(U1, U2 , S), #card(S) > 2.
Here, the interpreted function #card returns the cardinality of a given set, which is compared to the constant 2 by means of the built-in predicate “>”.
3 Implementation and Usage As previously stated, the system herein presented has been built on top of the stateof-the-art ASP system DLV [3]. The support for complex terms has been achieved by means of a proper rewriting strategy.
An ASP System with Functions, Lists, and Sets
List and Set Library
#import
487
Logic Program
dynamic linking
DLV-Complex Rewriter
Finite Domain Checker
ASP Engine
Answer Set(s)
Fig. 1. System Architecture
Figure 1 shows an overview of the system architecture. At first, the program is processed by a rewriting module, which removes all complex terms and introduces a number of instances of predefined built-in predicates (described below). Since the evaluation of an ASP program with complex terms is not guaranteed to terminate in general [6], the rewritten program is passed to a module (that can be bypassed on demand) that checks the membership to a class that is “a priori” known to be computable, namely the class of finite-domain programs, recently introduced in [2]. Finally, the rewritten program is given as input to DLV, that deals with the built-in predicates introduced in the rewriting phase by means of the framework defined in [7].5 The DLV-Complex core (consisting of the aforementioned modules) can also link, at run-time, a library of list and set manipulation functions and predicates, if required by the original ASP program being evaluated. We briefly illustrate in the following how the rewriting module acts in presence of functional terms. Firstly, any functional term t = f (X1 , . . . , Xn ), appearing in some rule r ∈ P , is replaced by a fresh variable F ; then, one of the following atom is added to B(r): - #f unction pack(f, X1 , . . . , Xn , F ) if t appears in H(r); - #f unction unpack(F, f, X1 , . . . , Xn ) if t appears in B(r). This transformation is applied to the rule r until no functional terms appear in it anymore. The arguments of the #f unction pack/unpack built-ins are: 1. the fresh variable F representing the whole functional term; 2. the function symbol f ; 3. all of the arguments: X1 , . . . , Xn for the original functional term. Therefore, an instance of the #f unction pack built-in predicate is in charge of building a functional term, starting from a functor and its arguments, while an instance of 5
The DLV-EX system, discussed in [8,7], allows the definition of custom built-in atoms in the #p(t1 , . . . , tn ) syntactic form.
488
F. Calimeri et al.
the #f unction unpack built-in predicate unfolds a functional term in order to give values to its arguments. Hence, the former built-in predicate binds the F variable, provided that all other terms are already bound; the latter binds (or checks the values, in case they are already bound) the X1 , . . . , Xn variables according to the binding for the F variable (the whole functional term). Example 9. The rule: p(f (f (X))) :- q(X, g(X, Y )). will be rewritten as follow: p(F1 ) :- #f unction pack(F1 , f, F2 ), #f unction pack(F2 , f, X), q(X, F3 ), #f unction unpack(F3 , g, X, Y ).
Note that rewriting the nested functional term f (f (X)) requires two #f unction pack atoms in the body: (i) for the inner f function having X as argument and (ii) for the outer f function having as argument the fresh variable F2 , representing the inner functional term. List and set terms are treated by means of proper “pack/unpack” built-in predicates, that act analogously to what described above, with some minor adjustments, such as a flag used in order to identify the kind of list term to be managed (comma-separated enumeration or “`a la prolog”). 3.1 Usage DLV-Complex per se is a command-line tool (as usual, for a brief list of command-line options, specify “-help”). In addition to the DLV standard ones (the reader may refer to the official DLV documentation [9]), some options are available in order to modify the behavior of the system in presence of complex terms. A finite-domain syntactic checker is enabled by default. If the user is confident that the program can be grounded in finite time (that is it belongs to the class of finitelyground programs), then she can skip the finite-domain check. This can be done by specifying the command-line option -nofdcheck. Another way that lead to the guarantee of termination is the choice of a maximum allowed nesting level N for functional terms, via the command-line option -MAXNL=. The system comes equipped with a rich library of list and set manipulation functions. This library actually contains the definition of many interpreted functions and predicates; in order to exploit them, the logic program must contain, in the preamble, a line that tells the system to include the library itself. Example 10. Let’s suppose that we have a file named palindromic.dl, containing the program reported in Example 5. Since the program exploits the #reverse interpreted function, we must also add a very first line with the instruction #include. If the palindromic.dl file is placed in the same folder as the DLV-Complex executable (let it be dlv-complex), and the list and set library is placed in the /usr/mylib folder we can invoke the system by the following command line:6 $ dlv-complex palindromic.dl -silent -nofacts -libpath=/usr/mylibs/ 6
We suppose to work on a Linux-like platform. The system behaves analogously on other platforms.
An ASP System with Functions, Lists, and Sets
489
4 Conclusions We have presented the DLV-Complex system, an extension of the DLV system that features the support for functions, list and set terms in the full ASP language with disjunction and negation. DLV-Complex is already successfully used in many universities and research institutes, and it is already exploited for some real-world applications; for instance, in [10] it is used for the computation of minimum cardinality diagnoses, and functional terms are here employed to replace existential quantification. The system, which is free for non-commercial use, is available for download at [4]. The library for list and set terms manipulation is available for free download as well, together with a reference guide, a tutorial and a number of examples. For any further detail about system options and synopsis the reader is referred to such documentation.
References 1. Gelfond, M., Lifschitz, V.: Classical Negation in Logic Programs and Disjunctive Databases. NGC 9, 365–385 (1991) 2. Calimeri, F., Cozza, S., Ianni, G., Leone, N.: Computable Functions in ASP: Theory and Implementation. In: Garcia de la Banda, M., Pontelli, E. (eds.) ICLP 2008. LNCS, vol. 5366, pp. 407–424. Springer, Heidelberg (2008) 3. Leone, N., Pfeifer, G., Faber, W., Eiter, T., Gottlob, G., Perri, S., Scarcello, F.: The DLV System for Knowledge Representation and Reasoning. ACM TOCL 7(3), 499–562 (2006) 4. Calimeri, F., Cozza, S., Ianni, G., Leone, N.: DLV-Complex homepage (since 2008), http://www.mat.unical.it/dlv-complex 5. Buneman, P., Levy, L.S.: The Towers of Hanoi Problem. Information Processing Letters 10(4/5), 243–244 (1980) 6. Dantsin, E., Eiter, T., Gottlob, G., Voronkov, A.: Complexity and Expressive Power of Logic Programming. ACM Computing Surveys 33(3), 374–425 (2001) 7. Calimeri, F., Cozza, S., Ianni, G.: External sources of knowledge and value invention in logic programming. AMAI 50(3-4), 333–361 (2007) 8. Calimeri, F., Ianni, G.: External sources of computation for Answer Set Solvers. In: Baral, C., Greco, G., Leone, N., Terracina, G. (eds.) LPNMR 2005. LNCS (LNAI), vol. 3662, pp. 105–118. Springer, Heidelberg (2005) 9. Faber, W., Pfeifer, G.: DLV homepage (since 1996), http://www.dlvsystem.com/ 10. Friedrich, G., Ivanchenko, V.: Diagnosis from first principles for workflow executions. Tech. Rep., http://proserver3-iwas.uni-klu.ac.at/download area/ Technical-Reports/technical report 2008 02.pdf
