Nested HEX-Programs

Answer-Set Programming (ASP) is an established declarative programming paradigm. However, classical ASP lacks subprogram calls as in procedural programming, and access to external computations (like remote procedure calls) in general. The feature is …

Authors: Thomas Eiter, Thomas Krennwallner, Christoph Redl

Nested HEX-Pr ograms ? Thomas Eiter, Thomas Krennwallner, and Christoph Redl Institut f ¨ ur Informationssysteme, T echnische Univ ersit ¨ at W ien Fa voritenstraße 9-11, A-1040 V ienna, Austria { eiter,tkren,redl } @kr.tuwien.ac.at Abstract. Answer-Set Programming (ASP) is an established declarativ e programming paradigm. How- ev er , classical ASP lacks subprogram calls as in procedural programming, and access to external computations (like remote procedure calls) in general. The feature is desired for increasing modularity and—assuming proper access in place—(meta-)reasoning ov er subprogram results. While HE X -programs extend classical ASP with e xternal source access, the y do not support calls of (sub-)programs upfront. W e present nested H E X -pro grams , which e xtend H E X -programs to serve the desired feature, in a user- friendly manner . Notably , the answer sets of called sub-programs can be individually accessed. This is particularly useful for applications that need to reason over answer sets like belief set merging, user-defined aggre gate functions, or preferences of answer sets. 1 Introduction Answer-Set Programming, based on [ 8 ], has been established as an important declarativ e programming formalism [ 3 ]. Howe ver , a shortcoming of classical ASP is the lack of means for modular programming, i.e., dividing programs into se veral interacting components. Even though reasoners such as DLV , C L A S P , and D LV H E X allow to partition programs into se veral files, they are still vie wed as a single monolithic sets of rules. On top of that, passing input to selected (sub-)programs is not possible upfront. In procedural programming, the idea of calling subprograms and processing their output is in permanent use. Also in functional programming such modularity is popular . This helps reducing dev elopment time (e.g., by using third-party libraries), the length of source code, and, last but not least, makes code human- readable. Reading, understanding, and debugging a typical size application written in a monolithic program is cumbersome. Modular extensions of ASP hav e been considered [ 9 , 5 ] with the aim of building an ov erall answer set from program modules; ho we ver , multiple results of subprograms (as typical for ASP) are respected, and no reasoning about such results is supported. XASP [ 11 ] is an S M O D E L S interface for XSB-Prolog. This system is related to our work, b ut in this scenario the meta-reasoner is Prolog and thus different from the semantics of its subprograms, which are under stable model semantics. The subprograms are monolithic programs and cannot make further calls. This is insufficient for some applications, e.g., for the MELD belief set mer ging system, which require hierarchical nesting of arbitrary depth. Adding such nesting to av ailable approaches is not easily possible and requires to adapt systems similar to our approach. H E X -programs [ 6 ] extend ASP with higher -order atoms, which allow the use of predicate v ariables, and external atoms, through which external sources of computation can be accessed. But H E X -programs do not support modularity and meta-reasoning directly . In this context, modularity means the encapsulation of subprograms which interact through well-defined interfaces only , and meta-reasoning requires reasoning ov er sets of answer sets. Moreover , in H E X -programs external sources are realized as procedural C++ functions. Therefore, as soon as external sources are queried, we lea ve the declarati ve formalism. Howe ver , the generic notion of e xternal atom, which f acilitates a bidirectional data flo w between the logic program and an external source (vie wed as abstract Boolean function), can be utilized to provide these features. T o this end, we present nested H E X -pr ograms , which support (possibly parameterized) subpr ogram calls . It is the nature of nested hex-programs to hav e multiple H E X -programs which reason over the answer sets of each indi vidual subprogram. This can be done in a user-friendly w ay and enables the user to write purely declarative applications consisting of multiple interacting modules. Notably , call results and answer ? This research has been supported by the Austrian Science Fund (FWF) project P20840 and P20841, and by the V ienna Science and T echnology Fund (WWTF) project ICT 08-020. sets are objects that can be accessed by identifiers and processed in the calling program. Thus, different from [ 9 , 5 ] and related formalisms, this enables (meta)-r easoning about the set of answer sets of a program. In contrast to [ 11 ], both the calling and the called program are in the same formalism. In particular , the calling program has also a multi-model semantics. As an important difference to [ 1 ], nested H E X -programs do not require extending the syntax and semantics of the underlying formalism, which is the H E X -semantics. The integration is, instead, by defining some external atoms (which is already possible in ordinary H E X - programs), making the approach simple and user-friendly for many applications. Furthermore, as nested H E X -programs are based on H E X -programs, they additionally provide access to e xternal sources other than logic programs. This makes nested H E X -programs a po werful formalism, which has been implemented using the D L V H E X reasoner for H E X -programs; applications like belief set merging [ 10 ] show its potential and usefulness. 2 H E X -Programs W e briefly recall H E X -programs, which have been introduced in [ 6 ] as a generalization of (disjunctiv e) extended logic programs under the answer set semantics [ 8 ]; for more details and background, we refer to [6]. A H E X -program consists of rules of the form a 1 ∨ · · · ∨ a n ← b 1 , . . . , b m , not b m +1 , . . . , not b n , where each a i is a classical literal, i.e., an atom p ( t 1 , . . . , t l ) or a negated atom ¬ p ( t 1 , . . . , t l ) , and each b j is either a classical literal or an e xternal atom, and not is negation by failure (under stable semantics). An external atom is of the form & g [ q 1 , . . . , q k ]( t 1 , . . . , t l ) , where g is an external predicate name, the q i are predicate names or constants, and the t j are terms. Informally , the semantics of an external g is gi ven by a k + l + 1 -ary Boolean oracle function f & g . The external atom is true relativ e to an interpretation I and a grounding substitution θ iff f & g ( I , q 1 , . . . , q k , t 1 θ , . . . , t l θ ) = 1 . V ia such atoms, arbitrary (computable) functions can be included. E.g., built-in functions can be realized via external atoms, or library functions such as string manipulations, sorting routines, etc. As external sources need not be on the same machine, knowledge access across the W eb is possible, e.g., belief set import. Strictly , [ 6 ] omits classical ne gation ¬ but the extension is routine; furthermore, [ 6 ] also allo ws terms for the q i and variables for predicate names, which we do not consider . Example 1. Suppose an external knowledge base consists of an RDF file located on the web at http:/ / .../ data.rdf . Using an external atom & r df [ < url > ]( X , Y , Z ) , we may access all RDF triples ( s, p, o ) at the URL specified with < ur l > . T o form belief sets of pairs that drop the third argument from RDF triples, we may use the rule bel ( X , Y ) ← & r df [ http:/ / .../ data.rdf ]( X , Y , Z ) . The semantics of H E X -program is giv en via answer sets, which are sets of ground literals closed under the rules that satisfy a stability condition as in [8]; we refer to [6] for technical details. The abov e program has a single answer set which consists of all literal bel ( c 1 , c 2 ) such some RDF triple ( c 1 , c 2 , c 3 ) occurs at the respectiv e URL. W e use the D L V H E X system from http:/ / www .kr .tuwien.ac.at/ research/ systems/ dlvhex/ as a back end. D LV H E X implements (a fragment of) H E X -programs. It provides a plugin mechanism for external atoms. Besides library atoms, the user can defined her own atoms, where for e valuation a C++ routine must be pro vided. 3 Nested H E X -Programs Limitations of ASP . As a simple example demonstrating the limits of ordinary ASP , assume a program computing the shortest paths between two (fixed) nodes in a connected graph. The answer sets of this program then correspond to the shortest paths. Suppose we are just interested in the number of such paths. In a procedural setting, this is easily computed: if a function returns all these paths in an array , linked list, or similar data structure, then counting its elements is trivial. Main H E X - program D LV H E X Answer Sets Subprograms External Atoms Answer Set Cache Fig. 1: System Architecture of Nestex H E X (data flow 99K , control flo w → ) In ASP , the solution is non-tri vial if the gi ven program must not be modified (e.g., if it is provided by a third party); above, we must count the answer sets. Thus, we need to reason on sets of answer sets, which is infeasible inside the program. Means to call the program at hand and reason about the results of this “callee” ( subpr ogram ) in the “calling pr ogram” ( host pr ogram ) would be useful. Aiming at a logical counterpart to procedural function calls, we define a framew ork which allo ws to input facts to the subprogram prior to its ex ecution. Host and subprograms are decoupled and interact merely by relational input and output v alues. T o realize this mechanism, we exploit external atoms, leading to nested H E X -programs. Architectur e . Nested H E X -programs are realized as a plugin for the reasoner D L V H E X , 1 which consists of a set of external atoms and an answer cache for the results of subprograms (see Fig. 1). T echnically , the implementation is part of the belief set mer ging system MELD, which is an application on top of a nested H E X -programs core. This core can be used independently from the rest of the system. When a subprogram call (corresponding to the e v aluation of a special e xternal atom) is encountered in the host program, the plugin creates another instance of the reasoner to ev aluate the subprogram. Its result is then stored in the answer cache and identified with a unique handle , which can later be used to reference the result and access its components (e.g., predicate names, literals, arguments) via other special external atoms. There are two possible sources for the called subprogram: (1) either it is dir ectly embedded in the host program, or (2) it is stor ed in a separate file . In (1) , the rules of the subprogram must be represented within the host program. T o this end, they are encoded as string constants. An embedded program must not be confused with a subset of the rules of the host program. Even though it is syntactically part of it, it is logically separated to allo w independent ev aluation. In (2) merely the path to the location of the e xternal program in the file system is giv en. Compared to embedded subprograms, code can be reused without the need to copy , which is clearly adv antageous when the subprogram changes. W e no w present concrete external atoms & c al lhex n , & c al lhexfile n , & answersets , & pr e dic ates , and & ar guments . External Atoms f or Subprogram Handling . W e start with two families of external atoms & c al lhex n [ P , p 1 , . . . , p n ]( H ) and & c al lhexfile n [ FN , p 1 , . . . , p n ]( H ) that allo w to ex ecute a subprogram gi ven by a string P respecti vely in a file FN ; here n is an integer specifying the number of predicate names p i , 1 ≤ i ≤ n , used to define the input facts. When ev aluating such an external atom relati ve to an interpretation I , the system adds all facts p i ( a 1 , . . . , a m i ) ← ov er p i (with arity m i ) that are true in I to the specified program, creates another instance of the reasoner to e valuate it, and returns a symbolic handle H as result. For con venience, we do not write n in & c al lhex n and & c al lhexfile n as it is understood from the usage. Example 2. In the following program, we use two predicates p 1 and p 2 to define the input to the subpro- gram sub . hex ( n = 2) , i.e., all atoms over these predicates are added to the subprogram prior to e v aluation. The call deriv es a handle H as result. p 1 ( x, y ) ← p 2 ( a ) ← p 2 ( b ) ← hand le ( H ) ← & c al lhexfile [ sub . hex , p 1 , p 2 ]( H ) A handle is a unique integer representing a certain cache entry . In the implementation, handles are con- secuti ve numbers starting with 0 . Hence in the example the unique answer set of the program is { hand le (0) } (neglecting facts). 1 http:/ / www .kr .tuwien.ac.at/ research/ systems/ dlvhex/ meld.html Formally , given an interpretation I , f & c al lhexfile n ( I , file , p 1 , . . . , p n , h ) = 1 iff h is the handle to the result of the program in file file , extended by the facts over predicates p 1 , . . . , p n that are true in I . The formal notion and use of & c al lhex n to call embedded subprograms is analogous to & c al lhexfile n . Example 3. Consider the following program: h 1 ( H ) ← & c al lhexfile [ sub . hex ]( H ) h 2 ( H ) ← & c al lhexfile [ sub . hex ]( H ) h 3 ( H ) ← & c al lhex [ a ← . b ← . ]( H ) The rules execute the program sub . hex and the embedded program P e = { a ← , b ←} . No facts will be added in this example. The single answer set is { h 1 (0) , h 2 (0) , h 3 (1) } resp. { h 1 (1) , h 2 (1) , h 3 (0) } depending on the order in which the subprograms are ex ecuted (which is irrele vant). While h 1 ( X ) and h 2 ( X ) will ha ve the same value for X , h 3 ( Y ) will be such that Y 6 = X . Our implementation realizes that the result of the program in sub . hex is referred to twice b ut ex ecutes it only once; P e is (possibly) dif ferent from sub . hex and thus ev aluated separately . Now we w ant to determine how many (and subsequently which) answer sets it has. For this purpose, we define external atom & answersets [ PH ]( AH ) which maps handles PH to call results to sets of respecti ve answer set handles. Formally , for an interpretation I , f & answersets ( I , h P , h A ) = 1 iff h A is a handle to an answer set of the program with program handle h P . Example 4. The program ash ( PH , AH ) ← & c al lhex [ a ∨ b ← . ]( PH ) , & answersets [ PH ]( AH ) calls the embedded subprogram P e = { a ∨ b ← . } and retrie ves pairs ( PH , P A ) of handles to its answer sets. & c al lhex returns a handle P H = 0 to the result of P e , which is passed to & answersets . This atom returns a set of answer set handles ( 0 and 1 , as P e has two answer sets, viz. { a } and { b } ). The ov erall program has thus the single answer set { ash (0 , 0) , ash (0 , 1) } . As for each program the answer set handles start with 0 , only a pair of program and answer set handles uniquely identifies an answer set. W e now are ready to solv e our example of counting shortest paths from abo ve. Example 5. Suppose paths . hex is the search program and encodes each shortest path in a separate answer set. Consider the following program: as ( AH ) ← & c al lhexfile [ paths . hex ]( PH ) , & answersets [ PH ]( AH ) numb er ( D ) ← as ( C ) , D = C + 1 , not as ( D ) The second rule computes the first free handle D ; the latter coincides with the number of answer sets of paths . hex (assuming that some path between the nodes exists). At this point we still treat answer sets of subprograms as black boxes. W e now define an e xternal atom to inv estigate them. Giv en an interpretation I , f & pr edic ates ( I , h P , h A , p, a ) = 1 iff p occurs as an a -ary predicate in the answer set identified by h P and h A . Intuiti vely , the external atom maps pairs of program and answer set handles to the predicates names with their associated arities occurring in the accourding answer set. Example 6. W e illustrate the usage of & pr e dic ates with the following program: pr e ds ( P , A ) ← & c al lhex [ node ( a ) . node ( b ) . edge ( a , b ) . ]( PH ) , & answersets [ PH ]( AH ) , & pr e dic ates [ PH , AH ]( P, A ) It extracts all predicates (and their arities) occurring in the answer of the embedded program P e , which specifies a graph. The single answer set is { pr e ds ( no de , 1) , pr e ds ( e dge , 2) } as the single answer set of P e has atoms with predicate no de (unary) and e dge (binary). The final step to gather all information from the answer of a subprogram is to extract the literals and their parameter s occurring in a certain answer set. This can be done with external atom & ar guments , which is best demonstrated with an example. Example 7. Consider the following program: h ( PH , AH ) ← & c al lhex [ node ( a ) . node ( b ) . node ( c ) . edge ( a , b ) . edge ( c , a ) . ]( PH ) , & answersets [ PH ]( AH ) e dge ( W , V ) ← h ( PH , AH ) , & ar guments [ PH , AH , edge ]( I , 0 , V ) , & ar guments [ PH , AH , edge ]( I , 1 , W ) no de ( V ) ← h ( PH , AH ) , & ar guments [ PH , AH , node ]( I , 0 , V ) It extracts the directed graph gi ven by the embedded subprogram P e and rev erses all edges; the single answer set is { h (0 , 0) , no de ( a ) , no de ( b ) , no de ( c ) , e dge ( b, a ) , e dge ( a, c ) } . Indeed, P e has a single answer set, identified by P H = 0 , AH = 0 ; via & ar guments we can access in the second resp. third rule the facts ov er e dge resp. no de in it, which are identified by a unique literal id I ; the second output term of & ar guments is the argument position, and the third the actual value at this position. If the predicates of a subprogram were unknown, we can determine them using & pr e dic ates . T o check the sign of a literal, the external atom & ar guments [ P H, AH , P r ed ]( I , s, Sign ) supports argument s . When s = 0 , & ar guments will match the sign of the I -th positive literal ov er predicate Pr e d into Sign , and when s = 1 it will match the corresponding classically negated atom. 4 A pplications MELD . The MELD system [ 10 ] deals with mer ging multiple collections of belief sets . Roughly , a belief set is a set of classical ground literals. Practical examples of belief sets include e xplanations in abduction problems, encodings of decision diagrams, and relational data. The merging strategy is defined by tree- shaped mer ging plans , whose lea ves are the collections of belief sets to be mer ged, and whose inner nodes are mer ging oper ators (pro vided by the user). The structure is akin to syntax trees of terms. The automatic e v aluation of tree-shaped mer ging plans is based on nested H E X -programs; it proceeds bottom-up, where ev ery step requires inspection of the subresults, i.e., accessing the answer sets of subpro- grams. Note that for nesting of ASP-programs with arbitrary (finite) depth, XASP [11] is not appropriate. Aggregate Functions . Nested programs can also emulate aggre gate functions [ 7 ] (e.g., sum, count, max) where the (user-defined) host program computes the function giv en the result of a subprogram. This can be generalized to aggreg ates ov er multiple answer sets of the subprogram; e.g., to answer set counting, or to find the minimum/maximum of some predicate o ver all answer sets (which may be exploited for global optimization). Generalized Quantifiers . Nested H E X -programs make the implementation of bra ve and cautious reasoning for query answering tasks very easy , even if the backend reasoner only supports answer set enumeration. Furthermore, extended and user-defined types of query answers (cf. [ 5 ]) are definable in a very user-friendly way , e.g., majority decisions (at least half of the answer sets support a query), or minimum and/or maximum number based decisions (qualified number restrictions). Prefer ences . Answer sets as accessible objects can be easily compared wrt. user-defined preference rules, and used for filtering as well as ranking results (cf. [ 4 ]): a host program selects appropriate candidates produced by a subprogram, using preference rules. The latter can be elegantly implemented as ordinary integrity constraints (for filtering), or as rules (possibly inv olving further external calls) to derive a rank. A popular application are online shops, where the past consumer behavior is frequently used to filter or sort search results. Doing the search via an ASP program which deliv ers the matches in answer sets, a host program can reason about them and act as a filter or ranking algorithm. 5 Conclusion T o overcome limitations of classical ASP regarding subprograms and reasoning about their possible out- comes, we briefly presented nested H E X -pr ogr ams , which realize subprogram calls via special external atoms of H E X -programs; besides modularity , a plus for readability and program reusability , they allo w for reasoning ov er multiple answer sets (of subprograms). An prototype implementation on top of D L V H E X is av ailable. Related to this is the work on macros in [2], which allow to call macros in logic programs. The possibility to access answer sets in a host program, in combination with access to other external computations, makes nested H E X -programs a powerful tool for a number of applications. In particular, libraries and user-defined functions can be incorporated into programs easily . As an interesting aspect is that dynamic program assembly (using a suitable string library) and execution are possible, which other approaches to modular ASP programming do not offer . Exploring this remains for future work. References 1. Analyti, A., Antoniou, G., Dam ´ asio, C.V .: Mweb: a principled framew ork for modular web rule bases and its semantics. A CM T rans. Comput. Logic 12(2), 17:1–17:46 (2011) 2. Baral, C., Dzifcak, J., T akahashi, H.: Macros, macro calls and use of ensembles in modular answer set programming. In: ICLP’06, pp. 376–390. (2006) 3. Brewka, G., Eiter , T ., T ruszczy ´ nski, M.: Answer set programming at a glance. Commun. A CM (2011), to appear 4. Delgrande, J.P ., Schaub, T ., T ompits, H., W ang, K.: A classification and surve y of preference handling approaches in nonmonotonic reasoning. Comp. Intell. 20(2), 308–334 (2004) 5. Eiter , T ., Gottlob, G., V eith, H.: Modular Logic Programming and Generalized Quantifiers. In: LPNMR’97, pp. 290–309. (1997) 6. Eiter , T ., Ianni, G., Schindlauer , R., T ompits, H.: A uniform integration of higher-order reasoning and external ev aluations in ASP. In: IJCAI’05, pp. 90-96. (2005) 7. Faber , W ., Leone, N., Pfeifer , G.: Semantics and complexity of recursive aggregates in answer set programming. Artif. Intell. 175(1), 278–298 (2011) 8. Gelfond, M., Lifschitz, V .: Classical negation in logic programs and deducti ve databases. New Generat. Comput. 9, 365–385 (1991) 9. Janhunen, T ., Oikarinen, E., T ompits, H., W oltran, S.: Modularity aspects of disjunctive stable models. J. Artif. Intell. Res. 35, 813–857 (2009) 10. Redl, C., Eiter , T ., Krennwallner , T .: Declarative belief set merging using mer ging plans. In: P ADL ’11, pp. 99–114. (2011) 11. Swift, T ., W arren, D.S.: XSB: Extending Prolog with T abled Logic Programming. CoRR abs/1012.5123 (2010), to appear in Theory Pract. Logic Program.

Original Paper

Loading high-quality paper...

Comments & Academic Discussion

Loading comments...

Leave a Comment