The DLVHEX System for Knowledge Representation: Recent Advances (System Description)

07/29/2016
by   Christoph Redl, et al.
TU Wien
0

The DLVHEX system implements the HEX-semantics, which integrates answer set programming (ASP) with arbitrary external sources. Since its first release ten years ago, significant advancements were achieved. Most importantly, the exploitation of properties of external sources led to efficiency improvements and flexibility enhancements of the language, and technical improvements on the system side increased user's convenience. In this paper, we present the current status of the system and point out the most important recent enhancements over early versions. While existing literature focuses on theoretical aspects and specific components, a bird's eye view of the overall system is missing. In order to promote the system for real-world applications, we further present applications which were already successfully realized on top of DLVHEX. This paper is under consideration for acceptance in Theory and Practice of Logic Programming.

READ FULL TEXT VIEW PDF

Authors

page 1

page 2

page 3

page 4

11/05/2018

The External Interface for Extending WASP

Answer set programming (ASP) is a successful declarative formalism for k...
07/28/2019

Relating Two Dialects of Answer Set Programming

The input language of the answer set solver clingo is based on the defin...
08/02/2018

Inlining External Sources in Answer Set Programs

HEX-programs are an extension of answer set programs (ASP) with external...
08/08/2016

ASP for Minimal Entailment in a Rational Extension of SROEL

In this paper we exploit Answer Set Programming (ASP) for reasoning in a...
03/06/2020

Boosting Answer Set Optimization with Weighted Comparator Networks

Answer set programming (ASP) is a paradigm for modeling knowledge intens...
12/09/2013

An Application of Answer Set Programming to the Field of Second Language Acquisition

This paper explores the contributions of Answer Set Programming (ASP) to...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Answer Set Programming (ASP) is a declarative programming approach which has been gaining popularity for many applications in artificial intelligence and beyond 

[Brewka et al. (2011)]. Features such as the use of variables as a shortcut for all ground instances, aggregates and optimization statements, distinguish ASP from SAT and simplify the process of problem solving in many cases. However, since not all data or computation sources can (easily and effectively) be encoded in an ASP program, extensions of the formalism towards the integration of other formalisms are needed.

To this end, hex-programs extend ASP with arbitrary external sources (which are realized in C++ or Python) by the use of so-called external atoms. Intuitively, the logic program sends information, given by constants and/or predicate extensions, to the external source, which returns output values that are imported into the program. For instance, the external atom might be used to find the synonyms of , e.g. and . Notably, external atoms can be nonmonotonic, introduce new values which are not part of the program (value invention), and can be used in recursive rules. The generality of external sources is in contrast to previous and dedicated formalisms such as DL-programs [Eiter et al. (2004)] or constraint ASP [Ostrowski and Schaub (2012)], which integrate ASP only with a concrete other formalism. hex-programs subsume these other formalisms and also well-known ASP extensions such as aggregates.

However, expressiveness of a formalism alone it not sufficient. Instead, also an efficient and convenient implementation is needed to attract users; recall that also the success of ASP depends considerably on expressive, efficient and easy-to-use systems like clasp [Gebser et al. (2011)]111http://potassco.sourceforge.net, DLV [Leone et al. (2006)]222http://www.dlvsystem.com, and smodels [Simons et al. (2002)]333http://www.tcs.hut.fi/Software/smodels. The hex-semantics was implemented in the dlvhex system [Eiter et al. (2006a)]444http://www.kr.tuwien.ac.at/research/systems/dlvhex on top of gringo and clasp [Gebser et al. (2011)]. The system celebrates its 10th anniversary this year and was released in version 2.5.0 earlier this year. While early versions were mainly intended to be used for experimental purposes, only in the last three years much effort was spent on turning dlvhex into a system for KR tasks which can conveniently be used beyond experimental purposes. To this end, we have overcome former limitations of the system which prevented its application in practice, including former efficiency problems, restrictions of the language, and technical limitations on the system side.

In this paper, we report about this progress. While some (but not all) of the enhancements discussed in the following have already been presented in dedicated works, this was from an algorithmic perspective and with focus on specific subproblems which occur when evaluating a hex-program. In contrast, this paper provides a bird’s eye view of the system from the user’s perspective, which is missing so far.

After briefly recalling hex-programs in Section 2, we present the novelties compared to earlier versions of the system. We group the enhancements in two main sections:

  • Section 3 presents enhancements based on the exploitation of known properties of external sources such as monotonicity or functionality. We first discuss the types of properties supported by the system and show how they are specified (Section 3.1). Afterwards, we give an overview about how they are used within the system. To this end, we present the two main features based on them, namely scalability boosts by advanced learning techniques (Section 3.2) and language flexibility due to reduced syntactic limitations (Section 3.3).

  • Section 4 presents recent extensions towards usability and system features. This includes a novel convenient programming interface for providers of external sources (Section 4.1), the integration of support for popular ASP extensions and interoperability (Section 4.2), and a new dissemination strategy which respects previous user feedback.

Afterwards, we give an overview about existing applications based on hex-programs in Section 5 and discuss how they can benefit from the system improvements. We conclude in Section 6.

2 hex-Programs

hex-programs [Eiter et al. (2005)] are a generalization of (disjunctive) extended logic programs under the answer set semantics [Gelfond and Lifschitz (1991)] with external atoms. Besides ordinary atoms of the form , where is a predicate and is a list of terms (such as strings, integers, symbolic constants, nested function terms), rule bodies may also contain external atoms of the form , where is an external predicate, and each is an input parameter (which can be either a constant or variable term, or a predicate), and and each is an output term.

Syntax. A hex-program (or program) consists of rules of form

(1)

where each is an (ordinary) atom and each  is either an ordinary atom or an external atom, and ; for such a rule let denote its body.

Semantics. An assignment is a consistent set of literals of form or , where is an atom which is said to be true in if , false if , and undefined otherwise. We say that is complete over a program if for all atoms in we have either or .

The semantics of a hex-program is defined via its grounding over a Herbrand universe of constants as usual, where can contain constants which are not in the program and might even be infinite. The value of a ground external atom wrt. an assignment is given by the value of a decidable -ary three-valued oracle function , where and are the lengths of and , respectively555In previous works, oracle functions were two-valued; we come back to this extension [Eiter et al. (2016)] in Section 3.. The oracle function evaluates to true, false or unknown (, or ), where we assume that (i) it evaluates to true or false if is complete over , and (ii) we have whenever and , i.e., evaluations to true or false do not change when the assignment becomes more complete; we call this property knowledge-monotonicity. In practice, one often abstracts from the Boolean view and sees an external predicate with input list as computation of output values , i.e., determining all values such that .

We note that the definition of the oracle function for assignments which are not complete is only for efficiency improvement, as explained in detail in Section 3.2. For user’s convenience and for backwards compatibility, it is also possible to use a two-valued (Boolean) oracle function which is only defined over complete assignments. It is then implicitly assumed to evaluate to unknown for all assignments which are not complete.

For (a set of) ground literals, rules, programs, etc., say , satisfaction wrt. a complete assignment  extends naturally from ASP to hex-programs, by taking external atoms into account. Satisfaction of under is denoted by . In this case we say that is a model of .

An answer set of a hex-program is a model of the FLP-reduct666The FLP-reduct is equivalent to the traditional reduct for ordinary logic programs [Gelfond and Lifschitz (1991)], but more attractive for extensions such as aggregates or external atoms. of wrt. , given by  [Faber et al. (2011)], which is subset-minimal, i.e., there exists no model of s.t. .

Technically, external atoms are realized as plugins of the reasoner using a programming interface. To this end, the provider of an external source basically implements its oracle function.

Example

Consider the program

where selects a node from an externally defined (finite) graph, and and recursively compute the strongly connected component of . To this end, the external atom is used, which is true if is directly reachable from (and false otherwise).

The implementation of may look as follows (API details follow in Section 4.1):

def edge(x):
  graph=((1,2),(1,3),(2,3))      # simplified implementation; real ones may read a DOT file
  for edge in graph:             # search for outgoing edges of node x
    if edge[0]==x.intValue():
      dlvhex.output((edge[1],))  # output edge target

3 Exploiting External Source Properties

External sources were seen as black boxes in earlier versions of dlvhex. It was assumed that the system does not have any information about them, except that there is an oracle function which decides satisfaction of an external atom under a complete assignment. As a consequence, the room for optimizations in the algorithms was limited because the value of an external atom under one assignment did not allow for drawing any conclusions about its behavior under other assignments.

However, in many practical applications the provider of an external source and/or the hex-programmer have additional knowledge about the behavior of the source, for instance, that the source is monotonic, functional, has a limited domain, returns only elements which are smaller than the input (according to some ordering), etc. Knowing such properties allows for implementing more specialized algorithms which are tailored to the particular external sources used in a program. We therefore identified a set of properties that external sources might have, and allow the user to specify the ones which are fulfilled by a concrete external source.

Example

Suppose is true whenever is the string which results from string if the first character is dropped. Then the output is always smaller than the input wrt. string length.

The system exploits these properties automatically, mainly for two purposes: in the learning algorithms for scalability enhancements and in the grounding component for more flexibility of the language due to reduced syntactic limitations; we discuss these two aspects in more detail in Sections 3.2 and 3.3, respectively. In addition, there are several other system components which exploit the properties to further speed up the evaluation, such as skipping various checks if their result is definite due to known behavior of external sources, partitioning a reasoning task into smaller independent tasks, avoiding unnecessary evaluations of external atoms, and drawing deterministic conclusions rather than guessing.

However, as this paper presents the system from user’s perspective, we focus on which properties can be specified, how the user can do that, and give a rough idea of how the system makes use of this information, but we refrain from discussing the involved algorithms in detail. This is in line with the goal of these properties: the user can benefit from the advantages when specifying them, but without the need to care about how the system is going to exploit this information. Instead, the user can generally expect that the more information is available to the system, the more efficient evaluation will be; if the added information does not yield a speedup, it does at least no harm.777 The only property related to potential performance decrease is provision of a three-valued semantics as additional calls of the external source are sometimes counterproductive [Eiter et al. (2016)]

. However, even then the property itself does not harm since it is only exploited by certain (non-default) evaluation heuristics selected via command-line options.

Some of the properties, such as monotonicity, do even lead to a drop of complexity from to for answer set existence checking over ground disjunction-free programs, provided that external sources are polynomial [Faber et al. (2011)].

Furthermore, properties also serve as assertions: if the reasoner observes a behavior of external sources which contradicts the declared properties, appropriate error messages are printed.

3.1 Specifying Properties

The specification of properties is supported in two ways. The first option is to declare them as part of the external source implementation via the external source interface. The second option is to specify them as part of the hex-program using so-called property tags.

Specification via the External Source Interface. Properties are mostly specified via the (C++ or Python) programming interface for external sources. To this end, the procedural code which implements external atoms calls specific setter methods provided by the programming interface to inform the system that the source has certain properties.

Example

The implementation of a hash function which computes for a string its MD5 hash value might call prop.setFunctionality(true) to let dlvhex know that for each there is exactly one . This allows the system, for instance, to conclude that is false without evaluating the external source, if it has already found a value such that is true.

If a property is declared in this way, the external source is meant to always provide a certain behavior, independent of its usage in a certain hex-program, like in case of the computation of a hash value. Another example is , which computes all values which are in the extension of but not in that of wrt. assignment (formally, these are all values such that ). This external atom it is always monotone/antimonotone in the first/second parameter, which can be specified by calling prop.addMonotonicInputPredicate(0) and prop.addAntimonotonicInputPredicate(1) (cf. Example 4.1).

Specification via Property Tags. However, it might also be the case that only a specific usage of an external source in a concrete program has a property. Then the implementer of the external source cannot declare it yet; instead, only the implementer of the hex-program has sufficient knowledge and can declare the property as part of an external atom in the program.

Example

Suppose checks if the sum of integer values s.t.  is true is greater than . It is not monotone in general if negative integers are allowed, but it is monotone if a program uses only positive integers. While the provider of the external source cannot assert the property, the user of the external source in a concrete program, who knows the context, can.

To this end, the hex language and implementation were extended such that external atoms can be followed by property tags of form , where the list of properties is comma-separated. Each property is then a whitespace-separated list of constants, consisting of a property type (first element in the list), and a number of property parameters (remaining elements in the list), whose number depends on the property type and may also have default values. For example, specifies two properties which declare that the external atom is monotonic in and antimonotonic in wrt. their extension in the input assignment. Here, the first property uses the property type monotonic and the property parameter , while the second property uses the property type antimonotonic and the property parameter . Another example is , which declares that the external source is monotonic in all parameters (because it is monotonic in and it is trivially monotonic in constant input parameters because they are independent of the input assignment); the property type is monotonic and no property parameters are explicitly specified, which indicates by default that the source is monotonic in all inputs. Properties declared by tags are understood to hold in addition to those declared via the external source interface (stating conflicting properties is not possible with the currently available ones).

Supported properties. The following list gives an overview about the currently available properties and how to specify them if the property tag language is used (but all of them can be specified both via the external source interface or in property tags). Each property is explained with an example in order to show the property type and the expected property parameters.

  • Functionality:
    The external atom adds integers and and is true for their sum . The source provides exactly one output value for a given input. There are no property parameters.

  • Monotonicity in a parameter:
    The external atom computes the difference of the extensions of and . The source is monotonic in predicate parameter (i.e., if the extension of increases, the output does not shrink), as indicated by the property parameter.

  • Global monotonicity:
    The source computes the set union of the extensions of and . It is monotonic in all parameters (indicated by the default value of the missing property parameter).

  • Antimonotonicity in a parameter:
    The source is antimonotonic in predicate parameter (i.e., if the extension of shrinks, the output does not shrink).

  • Global antimonotonicity:
    The source computes the complement of the extension of wrt. a fixed domain. It is antimonotonic in all parameters.

  • Linearity on atoms:
    We have domain independence on the level of atoms, i.e., the source can be separately evaluated for each input atom s.t. the final result is the union of the results of all evaluations. For instance, the evaluation under assignment , which yields , can be split up into three evaluations under , and , which yield , and , respectively, and their union the result of the evaluation under . There are no property parameters.

  • Linearity on tuples:
    We have domain independence on the level of tuples in the extensions of predicate input parameters, i.e., the source can be separately evaluated for each pair of atoms and

    for all vectors of terms

    s.t. the final result is the union of the results of all evaluations. For instance, the evaluation under , which yields , can be split up into two evaluations under and , which yield and , respectively, and their union in the result of the evaluation under . However, it would not be correct to split further up into and as they would yield the results and , which would put into the final result, which differs from the evaluation under . There are no property parameters.

  • Finite domain:
    Imports the edges of a predefined graph. Both output values can have only finitely many different values. To this end, we specify two properties with type with property parameters that identify the output terms and by index ( and , respectively).

  • Finite domain wrt. the input:
    Only constants which already appear in the -th input (indicated by the first property parameter ; points in this case to the predicate ) may occur as first output term (indicated by the second property parameter ). Informally, the difference between sets represented by predicates and can only contain elements which appear in the set represented by .

  • Finite fiber:
    The source computes the square root of . Each element in the output is only produced by finitely many different inputs (in this case, in fact, only by a single input value). There are no property parameters.

  • Well-ordering wrt. string lengths:
    The source drops the first character of string and returns the result in . The -th output (indicated by the second property parameter ) is no longer than the longest string in the -th input (indicated by the first property parameter ).

  • General well-ordering:
    The external atom decrements a given integer. There is an ordering of all constants such that the -th output (second parameter) is no greater than the -th input (first parameter) wrt. this ordering.

  • Three-valued semantics:
    The external source can be evaluated under partial assignments, i.e., it can handle assignments which do not define all atoms, but may evaluate to undefined () in this case (can be used with any external source if implemented).

Note that properties are only useful if they are exploited by at least one solving technique or algorithm implemented in the reasoner. It is therefore not intended that typical users introduce custom properties, but only tag external atoms with existing ones from the above list. However, for advanced users who contribute to or customize the reasoner itself, the framework supports easy extension of the parser and data structures. Exploiting such a new property in the algorithms might be more sophisticated depending on the particular property and the envisaged goal.

3.2 Scalability Boost

Traditionally, ground hex-programs have been evaluated by replacing each external atom by an ordinary atom and introducing a rule to guess its truth value; the resulting program is evaluated by an ordinary ASP solver to produce model candidates. Each candidate is subsequently checked by testing (i) if the external atom guesses are correct, i.e., if iff for all external atoms , and (ii) if assignment is a subset-minimal model of . If both conditions are satisfied, an answer set has been found. However, this approach did not scale well because there are exponentially many independent guesses in the number of external atoms in the ground program.

Basic approach. To overcome the problem, novel evaluation algorithms based on conflict-driven techniques have been introduced [Eiter et al. (2012)]. As in ordinary ASP solving, the input program is translated to a set of nogoods, i.e., a set of literals which must not be true at the same time. Given this representation, techniques from SAT solving are applied to find an assignment which satisfies all nogoods [Gebser et al. (2012)]. Notably, as the encoding as a set of nogoods is of exponential size due to loop nogoods which avoid cyclic justifications of atoms, those parts are generated only on-the-fly. Moreover, additional nogoods are learned from conflict situations, i.e., violated nogoods which cause the solver to backtrack; this is called conflict-driven nogood learning.

The extension of this algorithm towards the integration of external sources into the learning component works as follows. Whenever an external atom is evaluated under an assignment in the checking part (i), the actual truth value under the assignment becomes evident. Then, regardless of whether the guessed value was correct or not, one can add a nogood which represents that must be true under if or that must be false under if . If the guess was incorrect, the newly learned nogood will trigger backtracking, if the guess was correct, the learned nogood will prevent future wrong guesses.

Example

As above, suppose computes the set difference between the extensions of predicates and and that it is evaluated under with Herbrand universe . Then it can be learned that by adding the nogood , i.e., whenever are true and is false, then must not be false. Conversely, one can learn that by adding nogood .

Experimental results show a significant, up to exponential speedup [Eiter et al. (2014)]. This is explained by the exclusion of up to exponentially many guesses by the learned nogoods.

Exploiting external source properties. The technique was refined by exploiting additional knowledge about external sources in order to keep the learned nogoods small. In the previous example, atoms and in the assignment are in fact irrelevant when deciding whether is true because constants and are independent (similarly for and when deciding ). If this information is available to the system, it can be exploited to shrink nogoods to the relevant part such that the search space is pruned more effectively.

One way to gain the required information is to make use of the properties introduced in Section 3.1. In particular, the independence of and in the previous example can be derived from the property ‘linearity on tuples’. Then the nogood can be reduced to and the nogood to . If monotonicity in is known in addition, then nogood can be further simplified to by dropping because will remain false even if becomes false.

Exploiting three-valued oracle functions. Alternatively or in addition to external source properties, also three-valued oracle functions (cf. Section 2) can be exploited for shrinking learned nogoods to the essential part [Eiter et al. (2016)]. If the truth value is already known and will not change when the assignment becomes more complete, then the set of yet unassigned atoms is irrelevant for the output of the external source. This is exploited for nogood minimization as follows. Whenever a nogood is learned, the system iteratively tries to remove one of the input atoms and evaluate again in order to check if the truth value is still defined. If this is the case, the according atom is not necessary and can be removed from the nogood.

For instance, a proper implementation of a three-valued oracle function in the previous example allows for reducing to because whenever is in the assignment, it is already definite that is false.

Discussion and Extensions. Whether to exploit external source properties, three-valued oracle functions, or both, depends largely on the use case. Depending on the type of external source to be realized, the implementation of a three-valued oracle function might be more challenging than of a Boolean one (implementing an algorithm which decides over partial assignments is in general more difficult than if all information is known). However, it allows for exploiting application-specific knowledge in an optimal way [Eiter et al. (2016)]. In contrast, tagging external sources with properties from a list is easy and can still lead to good efficiency.

3.3 Language Flexibility

External atoms may introduce constants which do not appear in the program (value invention). Obviously, this can in general lead to programs which do not have a finite grounding that has the same answer sets as the original program (which are defined via the full, possibly infinite grounding ). Since this inhibits grounding in general, it is crucial to identify classes of programs for which the existence of such a finite grounding is guaranteed; we call this property finite groundability. Traditionally, strong safety was used, which basically forbids value invention by recursive external atoms (i.e., external atoms whose input possibly depends on its own output wrt. the predicate dependency graph, for a formal definition cf. eist2006). If only non-recursive external atoms introduce new values, termination is guaranteed. However, it turns out that this is only a sufficient but not a necessary criterion, i.e., strong safety is overly restrictive.

Example

The program from Example 2 is not strongly safe because is recursive (output may be input to the same external atom by another application of ) but may introduce values for which do not appear in . However, if one knows that the graph is finite, one can conclude that the recursive introduction of new values will end at some point.

In the example, the criterion may be circumvented by importing the full domain a priori and adding domain predicates, i.e., adding to the body of and another rule to import all nodes. Then does no longer invent values because all possible values for are determined in a non-recursive fashion using . However, this comes at the price of importing the whole graph although only a small set of nodes might be in the strongly connected component of .

Therefore, new safety criteria have been introduced which allow for exploiting both syntactic and semantic conditions to derive finite groundability, where the latter are based on external source properties as introduced in Section 3.1. So-called liberally safe hex-programs are guaranteed to have a finite grounding which can be computed using a novel algorithm [Eiter et al. (2016)].

Example

Let drop the first character of string and return it as . Then is no longer than and – even if used recursively – it is guaranteed that it can generate only finitely many strings because there are only finitely many strings with a length up to the one of .

In addition to the declaration of predefined properties, the generic framework is also extensible such that custom knowledge about external sources can be exploited. To this end, providers may implement safety plugins, which are integrated into the safety check. The safety check itself is fast (at most quadratic in the size of the non-ground program).

The system combines the available information, given by syntactic conditions, specified semantic properties and safety plugins in order to check safety of the program. This does not only allow for writing programs with fewer syntactic restrictions, but the implementation of some applications may be possible in the first place. For instance, in route planning applications, importing the whole map material a priori is practically impossible due to the large amount of data, while a selective import using liberal safety makes the application possible [Eiter et al. (2016)].

In case a program is not safe, the system prints hints such as the rule and the variable for which finiteness during instantiation could not be proven. This information is intended to guide the user when providing more information in order to make the program safe, e.g., by adding properties from Section 3.1 which constrain the values of this variable further. Alternatively, a command-line option allows to disable the safety check altogether, in which case there is no guarantee that the reasoner terminates (putting this burden on the user).

4 Usability and System Features

In this section we present recent work on the system side to improve the user’s convenience. We start with general remarks on the dlvhex software and its dissemination. dlvhex was previously only available in source format (released under GNU LGPL) and only for Linux platforms. This deployment method turned out to be inconvenient for ASP programmers who want to use the system as is without custom modifications, thus we now provide pre-built binaries for all major platforms (Linux-based, OS X and Windows) in addition. We further created an online demo of the system under http://www.kr.tuwien.ac.at/research/systems/dlvhex/demo.php which allows for evaluating hex-programs directly in the browser (the user may specify both the logic program and custom Python-implemented external atoms in two input fields). The demo comes with a small set of examples to demonstrate the main features of the KR formalism. We further provide a manual to support new users of the system [Eiter et al. (2015)].

Next, the following two subsections give an overview of the new Python programming interface and interoperability of the system.

4.1 Python Programming Interface

With earlier versions of the system, users who wanted to integrate custom external sources had to write plugins in C++. While this was natural as the reasoner itself is implemented in C++, it was cumbersome and introduced development overhead even for experienced developers. This is because multiple configuration, source and header files need to be created even when realizing only a small and simple plugin. Also the compilation and linking overhead during development and debugging was considered inconvenient.

As a user-friendly alternative, dlvhex 2.5.0 introduces a plugin API for Python-implemented external sources. A plugin consists of a single file (unless the user explicitly wants to use multiple files), which imports a dedicated dlvhex package and specifies a single method for each external atom. Thanks to higher-level features of Python and modern packages, this usually results in much shorter and simpler code than with C++-implemented plugins. A central register method exports the available external atoms and (optionally) their properties from Section 3.1 to dlvhex.

Example

The following snippet implements for computing the values which are in the extension of but not in that of . It is monotonic in and antimonotonic in .

import dlvhex
def diff(p,q):
  for x in dlvhex.getTrueInputAtoms():         # for all true input atoms
    if x.tuple()[0] == p:                      # is it of form p(c)?
      if dlvhex.isFalse(dlvhex.storeAtom(      # is the corresponding q(c) false?
                          (q, x.tuple()[1]))):
        dlvhex.output((x.tuple()[1], ));       # then c is in the output
def register():
  prop = dlvhex.ExtSourceProperties()          # inform dlvhex about
  prop.addMonotonicInputPredicate(0)           # monotonicity/antimonotonicity
  prop.addAntimonotonicInputPredicate(1)       # in the first/second parameter
  dlvhex.addAtom(”diff”, (dlvhex.PREDICATE, dlvhex.PREDICATE), 1, prop)

On the command-line, the call dlvhex2 --python-plugin=plugin.py prog.hex loads the external atoms defined in plugin.py and then evaluates hex-program prog.hex.

In the system, the Python programming interface is realized as a wrapper of the generic C++ interface as shown in Figure 1, where arcs model both control and data flow. That is, the Python interface uses only the C++ interface but does not communicate with the core reasoning components otherwise. This turns the Python interface in fact into a special C++ plugin. The performance gap between C++ and Python plugins is normally negligible (the update of the Python data structures it in the worst case linear in the number of input atoms), unless the plugin is itself computationally expensive. Wrappers for other languages can be added similarly and can also be implemented externally, i.e., they do not necessarily need to be part of the dlvhex solver.

For a complete API description we refer to http://www.kr.tuwien.ac.at/research/systems/dlvhex/.

Reasoning Component

C++ Programming Interface

C++ Plugins

Python Programming Interface

Python Plugins

dlvhex
Figure 1: Architecture of the Python Programming Interface

4.2 ASP-Core-2 Standard, Extensions and Interoperability

In the course of the organization of the fourth ASP competition, the input language of ASP systems was standardized in the ASP-Core-2 input language format [Calimeri et al. (2013)]. The dlvhex system in its current version supports all features defined in the standard, including function symbols, choice rules, conditional literals, aggregates, and weak constraints. The supported language is therefore a strict superset of the standard.

The system further supports input and output in CSV format to improve interoperability with other systems such as Unix commands or spreadsheet applications. That is, facts may be read from the lines of a CSV file, where the different values are mapped to the arguments of a predicate. After the computation, the extension of a specified predicate may be written in CSV format to allow a seamless further processing by other applications. For instance, consider salary.csv:

joe,smith,2000
sue,johnson,2200

It can be read as facts and (where the first element is the original line number if relevant) using the dlvhex command-line option --csvinput=emp,salary.csv. Conversely, results can be output in CSV format.

5 Applications

We now discuss some applications which were realized on top of hex-programs. In this paper, we focus on applications whose purpose was not to demonstrate hex-programs or to evaluate the reasoner. Instead, the following applications are motivated by real needs and are interesting by themselves, while hex-programs were merely a means for their realization. This witnesses that hex-programs and dlvhex can be fruitfully applied for real-world problems.

We discuss the effects of the described system improvements on the applications. Some quantitative results are included in A. However, since this paper gives an overview of the system and not all of the presented improvements are related to efficiency, not all of the following applications are suited as performance benchmarks. For an extensive empirical evaluation focused on efficiency we refer to efkrs2014-jair and efkr2016-aij.

Hybrid planning. The application comes from the robotics domain and consists of high-level planning and low-level feasibility checking [Erdem et al. (2016)]. High-level plans are sequences of actions towards a goal, while low-level constraints (such as stability issues of robots or intersections of routes) exclude some of the sequences. Thus, not all such plans which are possible from high-level perspective are actually executable. The separation of the two levels is motivated by the observation that the full integration of low-level constraints into the model for high-level planning might blow up the encoding (while it might be feasible in other cases). An implementation of hybrid planning on top of hex-programs was presented, where external atoms are used to perform low-level feasibility checking of high-level plans generated in the program.

Effects of improvements: The application uses hand-crafted custom learning functions which add custom nogoods during evaluation to improve efficiency, cf. Erdem2016a. With the new dlvhex version, three-valued oracle functions can be used instead, which allow for an easier realization of a similar learning behavior. Furthermore, the property tuplelevellinear can be exploited whenever feasibility checks can be split into multiple independent checks (e.g. of independent robots), and relativefinitedomain can be exploited for external atoms used for sensing objects (only objects which appear in the description of the world can be sensed).

Route planning. The combination of route planning with side constraints was realized on top of hex [Eiter et al. (2016)]. An example is planning a tour through multiple locations, where the possibility to get refreshments should be included if the tour is longer than a limit.

Effects of improvements: Since the traditional criterion of strong safety disallows recursive value invention, previous system versions must import the whole map a priori. As this is infeasible for real-world data, the application can in fact only be realized on top of hex by exploiting the improvements from Section 3.3. To this end, finiteness of the map used with liberal safety allows for importing only relevant parts of the map and solving the problem efficiently [Eiter et al. (2016)].

Multi-context Systems. Multi-context systems are a framework for integrating heterogeneous knowledge-bases, called contexts, which are abstractly identified by sets of belief sets [Brewka and Eiter (2007)]. Their integration works via dedicated bridge rules which derive information in one context based on atoms in other contexts. The whole system may become inconsistent although the individual contexts are all consistent. A typical reasoning task is then inconsistency analysis, i.e., the computation of an inconsistency explanation [Eiter et al. (2010)], which was realized on top of hex-programs [Bögl et al. (2010)]. The main idea is to realize contexts as external sources. Then a hex-program can access all contexts, compute candidate explanations, and check them against all contexts. Experimental results, which demonstrate effectiveness of the learning techniques from Section 3.2, can be found in the work by efkrs2014-jair.

Effects of improvements: Already plain learning (general part of Section 3) is highly effective, cf. [Eiter et al. (2014)]. The external atoms are functional, which does however, since their output is -ary, not lead to additional performance improvements, but does at least not harm.

Complaint management. Citizens may raise complaints about issues such as noise or traffic jams as part of e-government. A system was realized on top of dlvhex, which ranks complaints by their severity, such that priorities can be assigned [Zirtiloglu and Yolum (2008)]. While ontologies capture parts of the application, the authors combine them with hex-programs due to the inherent support for nonmonotonic reasoning. This is motivated by the dynamic behavior of complaint management systems, which might need to adopt the ranking if new complaints are added.

Effects of improvements: The encoding makes use of recursive rules over external atoms, thus the evaluation involves nondeterministic guessing. However, as the external atoms use only constant input, they are independent of the assignment are thus trivially monotonic and antimonotonic. In this case, the techniques from Section 3.2 assign the correct truth value permanently after the first evaluation and thus this application is expected to benefit significantly from the improvements.

AI in computer games. Angry-HEX is an AI agent for the computer game Angry Birds888https://www.angrybirds.com [Ianni et al. (2016)] and was developed since 2012 for participation in the AIBirds competition999https://aibirds.org; it was a finalist in 2015. The goal is to shoot birds with a slingshot at pigs located in buildings of wood, stone and ice blocks in order to destroy them. While the game is a strategy and skills game when playing manually, an AI agent can precisely compute the trajectory and the angle and speed in order to hit the desired target. Thus, the main issue is the selection of the best target.

The strategy employed by Angry-HEX is to select the target which maximizes the estimated damage to pigs (primary goal) and to other objects (secondary goal). This is encoded as a

hex-program which guesses possible targets, estimates the damage for each, and uses weak constraints for optimization. However, the estimation of the damage requires physics simulation for deciding, for instance, which objects will fall if others are destroyed. As such a simulation cannot easily be done with rules alone, external atoms are used to interface with a physics simulator. Hence, the low-level simulation is done in external atoms while the high-level strategy is rule-based. The idea of this two-level approach is similar to the hybrid planning domain.

Effects of improvements: The application mainly benefits from the improvements in Section 4. It uses new language features from the ASP-Core-2 standard such as optimization statements. Moreover, until now a significant amount of development time was spent on low-level coding for interfacing physics libraries. The new Python interface is expected to speed up the development of the agent. Finally, the availability of binaries is more important than for other applications since the application needs to be run in an environment provided by the organizers of the competition.

6 Conclusion

The dlvhex system implements hex-programs and was first released ten years ago [Eiter et al. (2006a)]. Over time, it was significantly extended with new algorithms, features, programming interfaces, and user’s resources. While it served mainly as an experimental framework in the beginnings, its advancement towards practical applicability started only in the last three years. We now reached a stable state, where all extensions envisaged for this major release are implemented.

In this paper, we gave a summary of version 2.5.0 and the most important recent enhancements. While literature on theoretical aspects and algorithms is preexisting, this paper focuses on the practical aspects which are relevant when realizing an application on top of hex. After receiving positive feedback from individual users, we believe that informing the users succinctly about the enhancements will push the use not only of the new features but also of the system altogether.

The improvements concern exploitation of known properties of external sources for novel efficient evaluation algorithms and more flexibility of the language, and recent system extensions for improved user’s convenience; the latter include a Python programming interface, additional material and a new dissemination strategy. Real applications, which emerged independently of the research on hex, but were realized on top of dlvhex, confirm the practicability of the approach.

References

  • Bögl et al. (2010) Bögl, M., Eiter, T., Fink, M., and Schüller, P. 2010. The MCS-IE system for explaining inconsistency in multi-context systems. In In JELIA 2010. 356–359.
  • Brewka and Eiter (2007) Brewka, G. and Eiter, T. 2007. Equilibria in Heterogeneous Nonmonotonic Multi-Context Systems. In AAAI. AAAI Press, 385–390.
  • Brewka et al. (2011) Brewka, G., Eiter, T., and Truszczyński, M. 2011. Answer set programming at a glance. Comm. ACM 54, 12, 92–103.
  • Calimeri et al. (2013) Calimeri, F., Faber, W., Gebser, M., Ianni, G., Roland Kaminski, T. K., Leone, N., Ricca, F., and Schaub, T. 2013. ASP-Core-2 Input Language Format.
  • Eiter et al. (2012) Eiter, T., Fink, M., Krennwallner, T., and Redl, C. 2012. Conflict-driven ASP solving with external sources. Theory and Practice of Logic Programming: Special Issue ICLP.
  • Eiter et al. (2016) Eiter, T., Fink, M., Krennwallner, T., and Redl, C. 2016. Domain expansion for asp-programs with external sources. Artif. Intell. 233, 84–121.
  • Eiter et al. (2014) Eiter, T., Fink, M., Krennwallner, T., Redl, C., and Schüller, P. 2014. Efficient HEX-program evaluation based on unfounded sets. Journal of Artificial Intelligence Research 49, 269–321.
  • Eiter et al. (2010) Eiter, T., Fink, M., Schüller, P., and Weinzierl, A. 2010. Finding explanations of inconsistency in Multi-Context Systems. In KR. AAAI Press, 329–339.
  • Eiter et al. (2005) Eiter, T., Ianni, G., Schindlauer, R., and Tompits, H. 2005. A Uniform Integration of Higher-Order Reasoning and External Evaluations in Answer-Set Programming. In IJCAI 2005, 90–96.
  • Eiter et al. (2006a) Eiter, T., Ianni, G., Schindlauer, R., and Tompits, H. 2006a. dlvhex: A Prover for Semantic-Web Reasoning under the Answer-Set Semantics. In the ICLP’06 Workshop on Applications of Logic Programming in the Semantic Web and Semantic Web Services (ALPSWS2006). CEUR WS, 33–39.
  • Eiter et al. (2006b) Eiter, T., Ianni, G., Schindlauer, R., and Tompits, H. 2006b. Effective Integration of Declarative Rules with External Evaluations for Semantic-Web Reasoning. In ESWC 2006, 273–287.
  • Eiter et al. (2016) Eiter, T., Kaminski, T., Redl, C., and Weinzierl, A. 2016. Exploiting partial assignments for efficient evaluation of answer set programs with external source access. In IJCAI 2016, To appear.
  • Eiter et al. (2004) Eiter, T., Lukasiewicz, T., Schindlauer, R., and Tompits, H. 2004. Combining Answer Set Programming with Description Logics for the Semantic Web. In KR 2004, D. Dubois, C. Welty, and M.-A. Williams, Eds. AAAI Press, 141–151.
  • Eiter et al. (2015) Eiter, T., Mehuljic, M., Redl, C., and Schüller, P. 2015. User guide: dlvhex 2.x. Tech. Rep. INFSYS RR-1843-15-05, Vienna University of Technology, Institute for Information Systems. September.
  • Erdem et al. (2016) Erdem, E., Patoglu, V., and Schüller, P. 2016. A Systematic Analysis of Levels of Integration between High-Level Task Planning and Low-Level Feasibility Checks. AI Communications, IOS Press.
  • Faber et al. (2011) Faber, W., Leone, N., and Pfeifer, G. 2011. Semantics and complexity of recursive aggregates in answer set programming. Artif. Intell. 175, 1, 278–298.
  • Gebser et al. (2011) Gebser, M., Kaufmann, B., Kaminski, R., Ostrowski, M., Schaub, T., and Schneider, M. 2011. Potassco: The Potsdam Answer Set Solving Collection. AI Commun. 24, 2, 107–124.
  • Gebser et al. (2012) Gebser, M., Kaufmann, B., and Schaub, T. 2012. Conflict-driven answer set solving: From theory to practice. Artif. Intell. 187–188, 52–89.
  • Gelfond and Lifschitz (1991) Gelfond, M. and Lifschitz, V. 1991. Classical Negation in Logic Programs and Disjunctive Databases. New Generation Computing 9, 3–4, 365–386.
  • Ianni et al. (2016) Ianni, G., Calimeri, F., Germano, S., Humenberger, A., Redl, C., Stepanova, D., Tucci, A., and Wimmer, A. 2016. Angry-HEX: an artificial player for angry birds based on declarative knowledge bases. IEEE Transactions on Computational Intelligence and AI in Games.
  • Leone et al. (2006) Leone, N., Pfeifer, G., Faber, W., Eiter, T., Gottlob, G., Perri, S., and Scarcello, F. 2006. The DLV system for knowledge representation and reasoning. ACM Trans. Comput. Log. 7(3), 499–562.
  • Ostrowski and Schaub (2012) Ostrowski, M. and Schaub, T. 2012. ASP modulo CSP: the clingcon system. CoRR abs/1210.2287.
  • Simons et al. (2002) Simons, P., Niemelä, I., and Soininen, T. 2002. Extending and Implementing the Stable Model Semantics. Artificial Intelligence 138, 181–234.
  • Zirtiloglu and Yolum (2008) Zirtiloglu, H. and Yolum, P. 2008. Ranking semantic information for e-government: complaints management. In OBI 2008, Karlsruhe, Germany, October 27, 2008, pages 5:1–5:7.

Appendix A Selected Benchmark Results

In this appendix we discuss the performance effects of the presented system improvements on the applications from Section 5 in more detail. To this end, we include selected numerical results where experimental evaluation using benchmarks is appropriate.

However, we recall that this paper does not only focus on efficiency improvements, but rather presents the current status of the system and application areas as a whole. Thus, while all presented applications benefit from some of the improvements (cf. Section 5), not all of them are suited to be used as performance benchmarks. Instead, the properties presented in Section 3 are also exploited for reducing syntactic limitations, and the improvements presented in Section 4 concern usability of the system (i.e., ease its usage and the implementation of plugins). For an extensive evaluation solely focused on efficiency improvements we thus refer to efkrs2014-jair and efkr2016-aij.

Hybrid planning. Erdem2016a considered two application domains from the robotics area. In the housekeeping domain, multiple autonomous robots should tidy up a house within a given time limit by putting items to their places. Low-level feasibility checks concern the time limit and physical limitations of the robots. In the robotic manipulation domain, two robots arrange elongated payloads, where payloads may only be moved by both robots together. Feasibility checks concern the avoiding of collisions of robots and payloads.

Table 1 is an extraction from Table 5 by Erdem2016a, containing the results which are in this context the most important ones. The authors used instances for each domain and present the average runtime needed to find the first feasible plan (first) resp. a maximum of feasible plans (max10k). They compare multiple possibilities for implementing low-level feasibility checks, but in context of this paper only the two extreme cases are relevant, namely learning over complete interpretations (Repl by Erdem2016a) and learning over partial interpretations (Int by Erdem2016a). It appears that the latter is significantly faster in both domains.

Housekeeping Robotic Manipulation
learning method first max10k first max10k
complete interpretations
partial interpretations
Table 1: Hybrid planning, results in secs

Using the new version of dlvhex, the application would benefits from the possibility to provide three-valued oracle functions. While the developers had to hand-craft custom learning functions, which is a cumbersome task, the definition of a three-valued oracle function usually much more natural but allows for similar learning effects.

Route planning. In this benchmark we consider route planning of a single person who wants to visit multiple locations. If and only if the tour is longer than the given limit of cost units, the person wants to get refreshments. The external source allows only for computing shortest paths between two two locations. Thus, it cannot solve the task completely and there needs to be interaction with the hex-program.

The sequence in which the locations are visited is guessed non-deterministically in the logic program. While the direct connections between two locations are of minimum length by definition of the external atom, the length of the overall tour is only optimal wrt. the chosen sequence of locations, but other sequences might lead to a shorter overall tour. However, we have the constraint that for visiting locations there should be at most changes. Due to this constraint not all instances have a solution. The underlying map material is the public transport system of Vienna. The instance size is the number of locations . For each instance size we generated instances by randomly drawing locations to visit.

An implementation based on a full import of the map, i.e., without exploiting the finiteness property, yields only timeouts even for instances of the smallest size; we do not not explicitly shown in the table since there are only timeouts anyway. Table 2 shows the results if the finiteness property and liberal safety are exploited. It shows for each instance size the averages of the wall clock times, the grounding times, the solving times, the percentage of instances for which a solution was found within the time limit, the average path length (costs) of the instances with solutions, the average number of necessary changes, and the percentage of instances with solutions which include getting refreshments. One can observe that for the considered instances with to locations (which is realistic wrt. what is feasible within one day), the runtime is manageable.

# exploiting liberal safety based on finiteness property
wall clock ground solve solution (%) length changes refreshm. (%)
1 (50) 2.40   (0) 1.71   (0) 0.54   (0) 100.00 0.00 0.00 0.00
2 (50) 7.82   (0) 5.00   (0) 2.42   (0) 90.00 82.64 2.24 0.00
3 (50) 16.44   (0) 9.46   (0) 5.81   (0) 76.00 152.21 3.92 0.00
4 (50) 36.60   (0) 16.69   (0) 16.90   (0) 52.00 213.00 5.31 3.85
5 (50) 102.71   (0) 26.63   (0) 69.26   (0) 52.00 281.27 7.58 11.54
6 (50) 284.69 (38) 236.43 (38) 45.56   (0) 16.00 368.12 9.00 100.00
7 (50) — (50) — (50) 0.00   (0) 0.00 NaN NaN NaN
Table 2: Route Planning benchmark, results in secs; timeout (“—”) is 300 secs