DLV-EE and DLV-IoT
for Data-Intensive, Distributed and IoT Applications

The DLV-EE system is a framework based on Answer Set Programming (ASP) for performing declarative-based reasoning tasks over data-intensive, distributed applications. It is based on the DLV2 system, and features interoperability means for dealing with Big-Data over modern, industry-level, databases (both relational and NoSQL). The framework emerges from the integration of different versions of DLV2 exploiting all most recent and advanced features, and, moreover, interact with Big Data systems and external database systems (both relational and NoSQL).

The DLV-IoT system is an ASP system compatible with “mobile” technologies for enabling advanced reasoning capabilities on smart/IoT devices. It works on Android and Raspberry systems and can natively execute logic programs as long as the input is small and the complexity of the logic programs is not high. To this end it performs an estimation of the computational workload, thus deciding whether it can be reasonably executed locally; if this is not the case, it interacts with DLV-EE via the REST services.

Use Case: an Android App for planning touristic itineraries

NavTour is an Android App created for allowing the user to generate scheduled tourist itineraries by exploiting DLVNavigator, a web service, based on DLV-EE (which has been endowed with additional features) that can automatically generate scheduled tourist, itineraries.

For the generation of a scheduled tourist itinerary (we call it a tour), a proper ASP program has been implemented. The ASP program is composed by two layers; we report next some details. The first layer basically consists of the following rules:

n(1..14).
n_category(C,N) :- category(C), #count{ID: poi(ID,_,_,_,_,_,_, C,_,_)} = N.
{n_chosen_category(C, N) : n(N), N <= X, n_category(C, X)} = 1 :- category(C).
node(ID,C,DT) :- start(ID), poi(ID,_,_,_,_,DT,_,C,_,_).
node(ID,C,DT) :- poi(ID,_,_,_,_,DT,_,C,_,P), n_chosen_category(C,N).
:~ category(CODE), #count{ID: node(ID,CODE,_)} = X, partition(CODE,Y), X < Y, Z = Y - X. [Z@2]
:~ poi(ID,_,_,_,_,DT,_,C,_,P), node(ID,C,DT). [P@1]

The facts in Rule 1 specify how many POIs a user can visit in a tour, at most. Rule 2 defines the extension of predicate n category, collecting the number of existing POIs for each category. Choice Rule 3 guesses, for each category, a number of POIs to visit that does not exceed a given maximum (specified by Rule 1). Predicate node is the output predicate that collects the candidate POIs of the final tour. A starting POI is specified in input and will be part of the tour (see Rule 4); subsequent POIs will be chosen by considering the same choosen category (see Rule 5). The first Weak Constraint (Rule 6) ensures that the chosen nodes respects, as much as possible, the user preference summarized by predicate partition, where the first attribute represents a category and the second attribute is a preference value containing the number of nodes that a user would like to visit for that category. In such a way, the Weak Constraint states that the number of nodes of the tour, preferably, should match the value of the partition. The second Weak Constraint (Rule 7), specify to minimize, with lower priority, the cost for visiting the POIs.

The second layer consists of following ASP rules:

slot(X,IN,OUT) :- start(X), node(X,_,DT), poi(X,IN,_,_, _,_,_,_,_,_), OUT=IN+DT, budget(B), OUT
slot(Y,IN,OUT) :- slot(X,_,OUTP), inPath(X,Y,TT,_), node(Y,_,DT), budget(B), IN=OUTP+TT, OUT=IN+DT, OUT

The answers sets of this program represent the final tour for the user via predicate slot. The attributes of the predicate represent, respectively, the place (node) to visit, the entry time and the exit time. Rule 1 states that, for a given node of the candidate POIs, get the entry time and the exit time of the place being careful to not exceed the temporal budget of the user. Rule 2 is a recursive rule that builds the tour by considering subsequent entry/exit time and the available time budget. The predicate inPath of the rule is determined using a variant of the well known Hamiltonian Path problem ASP encoding, that, in our case, is used to minimize the distance between single locations.

Here some screenshots regarding the Android App called NavTour.