|Interface class for external Atoms. More...|
dlvhex evaluates Answer Set Programs with external atoms. One important design principle was to provide a mechanism to easily add further external atoms without having to recompile the main application. A plugin is a shared library that provides functions to realise custom external atoms. Furthermore, a plugin can supply rewriting facilities, which may alter the input logic program prior to evaluation.
This Section gives an overview of dlvhex plugins and external atoms.
Formally, an external atom is defined to evaluate to true or false, depending on a number of parameters:
However, it is more intuitive and convenient to think of an external atom not as being boolean, but rather functional: Depending on a given interpretation and a list of input constants, it returns output tuples. For instance, the external atom to import triples from RDF files has this form:
uri stands for a string denoting the RDF-source and
Z are variables that represent an RDF-triple. The function associated with this atom simply returns all RDF-triples from the specified source. Obviously, in this case the interpretation is ignored.
The interface that is used by dlvhex to access a plugin follows very closely these semantics. For each atom, a retrieval function has to be implemented, which receives a query-object and has to return an an answer-object. The query-object carries the input interpretation as well as the ground input parameters of the external atom call, while the answer object is a container for the output tuples of the external atom's function.
Theoretically, it is completely up to the atom function how to process the interpretation together with the input constants, which are basically only names. In practice however, only parts of the interpretation might be needed (if at all). Considering this as well as for efficiency reasons, we created two (in the implementation three, see below) categories of input parameters:
A parameter of type "Constant" is not related to the interpretation at all, like in the previous example of the RDF-atom. A parameter is of type "Predicate" means that all facts in the interpretation with this predicate are necessary for the atom. Let's assume, we have an external atom that calculates the overall price of a number of books given by their ISBN number:
The single input parameter of this atom would be of type "Predicate", meaning that not the constant itself is necessary for the atom's function, but the part of the interpretation with this predicate. So if we have, e.g.,
the atom's function will be called with a "reduced" interpretation:
Specifying the type of input parameters not only helps to single out the relevant part of the interpretation, but also supports dlvhex in calculating the dependencies within a HEX-program.
We wanted to keep the interface between dlvhex and the plugins as lean as possible. Necessary tasks are:
Usual tasks for implementing a plugin interface are at least one of the following. We give the most usual implementation tasks first:
For details about each of these tasks see the respective method documentation, the test plugin in testsuite/TestPlugin.cpp, the internal plugins
It is recommended to start prototyping using ComfortPluginAtom and then later reimplement performance-critical external computations in the PluginAtom interface. (The HEX programs do not change at all, just the implementation of the external atom.)
We provide a toolkit for building plugins based on the GNU Autotools (http://sourceware.org/autobook/) environment. This means that you will need the respective tools installed on your system - which is usually no problem, since they are provided as packages by all major linux distributions. You need packages for libtool, automake, and autoconf. We also provide a dlvhex.m4 script for easier configuration of DLVHEX plugins, see for its usage the dlvhex-stringplugin or the dlvhex-scriptplugin.