3.1 Computational workflow

Incremental-DLV2 is built upon a proper integration of the overgrounding-based incremental grounder ${I}^2$ -DLV, presented by Ianni et al. (Reference Ianni, Pacenza and Zangari2020), into DLV2. Coherently with its roots, Incremental-DLV2 fully complies with the declarative nature of ASP; among all the requirements, an important feature is that all means for enabling efficient multi-shot incremental reasoning are mostly transparent to the user. Incremental-DLV2 adapts the traditional ground & solve pipeline that we briefly recalled in Section 2 to the new incremental context. The grounding step of Incremental-DLV2 is based on overgrounding with tailoring; furthermore, in order to reduce the impact of a ground program that grows across steps, the solving phase selectively processes only a smaller, equivalent subset of the current overgrounded program.

Figure 1 provides a high-level picture of the internal workflow of the system. When Incremental-DLV2 is started, it keeps itself alive in a listening state waiting for commands. Commands refer to high-level operations to be executed on demand, as detailed in Section 4. ${I}^2$ -DLV acts as OverGrounder module and enables incrementality in the computation on the grounding side, while the integrated Solver sub-system currently relies on the same non-incremental solving algorithms adopted in DLV2. Differently from DLV2, in Incremental-DLV2, both the grounding and the solving sub-systems are kept alive across the shots; while ${I}^2$ -DLV was already designed to this extent, the Solver module has been modified to remain alive as well. The updates in the solver and the tighter coupling of the two sub-systems pave the way to further steps toward a fully integrated incremental solving.

Fig 1.

Incremental-DLV2 architecture.

Multi-shot reasoning is performed by loading a fixed program $P$ at first and then a set of facts $F_{i}$ for each shot $i$ . According to the techniques described in Section 2, the OverGrounder module maintains across all shots a monotonically growing propositional program $G$ . Such program is updated at each shot $i$ with the new ground rules generated on the basis of facts in $F_i$ that were never seen in previous shots; then, an internal component efficiently manages ad hoc internal data structures, updated from shot to shot, that allow to keep track and select a relevant, yet smaller, portion of $G$ to be passed to the Solver module. On the basis of such “relevant” portion, the Solver module is then able to compute the answer sets of $AS(P \cup F_i)$ for the shot $i$ . Note that “relevant” is here used in the sense of “sufficient to keep equivalence with $P \cup F_i$ .” Eventually, once the answer sets are provided as output, the internal data structures of the Solver module are cleaned up from shot-dependent information, so to be ready for the subsequent evaluations.

Fig 2.

Simplified version of the incremental algorithm IncrInst.

3.2 Implementation details

The evaluation order taking place in the OverGrounder module is carried out by considering direct and indirect dependencies among predicates in $P$ . Connected components in the obtained dependency graph are identified once and for all before at the beginning of the first shot: then, the incremental grounding process takes place on a per component basis, following a chosen order. We report an abstract version of our IncrInst algorithm in Figure 2, where, for the sake of simplicity, we assume the input program $P$ forms a single component.

At shot $i$ , a new overgrounded program $G' = DG \cup {N\!R}$ is obtained from $G$ by iteratively repeating, until fixed point, a Desimpl step, followed by an Instantiate and Simplify step, which we call $\Delta {INST}$ . A set $AF$ of accumulated atoms keeps track of possibly true ground atoms found across shots; the set $N\!R$ keeps track of newly added rules whose heads can be used to build additional ground rules at the current shot, while $DG$ is a “desimplified” version of $G$ .

The Desimplstep properly undoes all simplifications applied on $G$ at previous shots that are no longer valid according to $F_i$ . This step relies on the meta-data collected during the previous simplifications: intuitively, meta-data keep record of the “reasons” that led to simplifications, such as deleted rules and/or literals. As a result of this phase, deleted rules might be reinstated, simplified rules might be lengthened, and new additions to $N\!R$ could be triggered.

The following $\Delta {INST}$ step incrementally processes each rule $r \in P$ , possibly producing new additions to $N\!R$ . The $getInstances$ function generates all the new ground instances $I_r$ of a rule $r$ by finding substitutions for the variables of $r$ obtained by properly combining head atoms of $DG$ and of $N\!R$ .

The instantiation of a rule relies on a version of the classic semi-naïve strategy of Ullman (Reference Ullman1988). The reader may see the work Faber et al. (Reference Faber, Leone and Perri2012) for details about a specialized implementation for ASP. The rules of $P$ are processed according to an order induced by predicate dependencies.

Then we simplify $I_r$ to $I'_r$ . In particular, this step processes rules in $I_r$ to check if some can be simplified or even eliminated (see Section 2), still guaranteeing semantics. On the grounding side, all ground rules in $I_r$ are stored in their complete and non-simplified version along with information (i.e., meta-data) regarding body literals that were simplified and regarding deleted rules, for example, those rules containing a certainly false literal in their body. Then $I'_r$ is added to $N\!R$ .

It must be noted that $DG$ is subject only to additions and desimplifications, while simplifications are allowed only on the newly added rules $N\!R$ . Further details on the tailored overgrounding process can be found in Ianni et al. (Reference Ianni, Pacenza and Zangari2020).

Once these two phases are over, the obtained ground rules are used to update the overgrounded program $G$ ; meta-data related to the occurred simplifications are maintained in order to undo no longer valid simplifications in later shots.

Note that $G$ is cumulatively computed across the shots and kept in memory, ready to be re-adapted and possibly enlarged, yet becoming more generally applicable to a wider class of sets of input facts; this comes at the price of a generally larger memory footprint. Moreover, when fed to the Solver module, the size of $G$ can highly influence performance. In order to mitigate the latter issue, Incremental-DLV2 makes use of the aforementioned meta-data for identifying a smaller yet equivalent ground program, which is in turn given as input to the Solver module in place of the whole $G$ .

Furthermore, to mitigate memory consumption, the system has been endowed with a simple forgetting strategy that, upon request, removes all rules accumulated in $G$ so far, while still keeping atoms stored; this will cause the overgrounded program to be computed from scratch from the next shot on, but allows one to instantly reduce the memory footprint of the system. Other finer-grained forgetting strategies for overgrounded programs are presented in Calimeri et al. (Reference Calimeri, Ianni, Pacenza, Perri, Zangari, Gebser and Sergey2024).

Load. A load tag can be formed in order to request to load a program or a set of facts from a file. The attribute path can be used to specify a string, representing a file path containing what has to be loaded. Multiple load commands can be provided: rules files are accumulated to form a unique program, and similarly, facts are also accumulated. For instance, with the following commands, the system is asked to load four files:

Assuming the first two loaded files contain rules while the latter two contain facts, the system composes a fixed program $P$ consisting of all rule files and stores all loaded facts, which together compose the first shot’s input $F_1$ . Note that the set of rules can be loaded only at the beginning of the system’s activity, while input facts can be loaded at any time.

Run. The <run/> command requests to compute the answer sets of the loaded program together with the collected facts. As a side effect, incremental grounding takes place, thus updating the current overgrounded program $G_P$ .

After a run command is executed, all so far loaded facts are assumed to be no longer true. Future loading of rule files after the first run is discarded, as $P$ is assumed to be fixed; conversely, one expects further loading of facts forming subsequent shots’ inputs.

Forget. Since $G_P$ tends to be continuously enlarged, forgetting can be used to save memory by dropping off parts of the accumulated ground program. Incremental-DLV2 features a form of forgetting, which is accessible either as a command or using program annotations.

With the command , it is possible to request the “forgetting” (i.e., removal) of accumulated atoms or rules along the shots. More in detail, mode can be either r or p to enable the so-called “rule-based forgetting” or “predicate-based forgetting,” respectively (see Calimeri et al. (Reference Calimeri, Ianni, Pacenza, Perri, Zangari, Gebser and Sergey2024)). The rule-based forgetting removes all ground rules composing the so far accumulated overgrounded program $G_P$ , whereas the predicate-based forgetting removes all ground rules and accumulated atoms of all predicates appearing either in rule bodies or heads. Overgrounding is started from scratch at the next shot. Note that the forget command allows to choose in which shot forgetting happens, but one cannot select which parts of $G_P$ must be removed.

Alternatively, forgetting can be managed by adding annotations within $P$ . Annotations consist of meta-data embedded in comments (see Calimeri et al. (Reference Calimeri, Fuscá, Perri and Zangari2017)) and allow to specify which predicates or rules have to be forgotten at each shot. Syntactically, all annotations start with the prefix “ $\%@$ ” and end with a dot (“ $.$ ”). The idea is borrowed from Java and Python annotations, having no direct effect on the code they annotate, yet allowing the programmer to inspect the annotated code at runtime, thus changing the code behavior at will. In order to apply the predicate-based forgetting type after each shot over some specific predicates, the user can include in the loaded logic program an annotation of the following form:

forcing the system to forget all the atoms featuring the predicate p of arity n. To forget more than one predicate, the user can simply specify more than one annotation of this type. Furthermore, an annotation in the form:

can be used in the logic program before a rule to express that all ground instances of such a rule have to be dropped at each shot. The user can annotate more than one rule; each one needs to be preceded by the annotation.

Service commands. Further appropriate service commands allow managing the behavior of the system. The <reset/> command requests to hard reset all internal data structures, including $P$ and $G_P$ , and restarts the computation from scratch, while the <exit/> command requests to close the working session and to stop the system.

The default reasoning task of Incremental-DLV2 is the search for just one answer set; it is possible to compute all the existing answer sets with a dedicated switch (option -n0). Alternatively, the system can perform grounding only and output just the current overgrounded program, which can be piped to a solver module of choice (option ).

Fig 3.

An example of multi-shot reasoning task based on Incremental-DLV2: compute 3-coloring for graphs featuring a structure that changes over time.

We illustrate next how the system works when properly executed for a multi-shot reasoning task; to this aim, we make use of an example over dynamic graphs, that is, graphs whose shape changes over time. Dynamic graphs have practical relevance in many real-world scenarios, for example, communication networks, VLSI design, graphics, assembly planning, IoT, etc. (see Demetrescu et al. (Reference Demetrescu, Finocchi, Italiano, Mehta and Sahni2004); He et al. (Reference He, Tang and Zeh2014); Wang et al. (Reference Wang, Yuan, Ma and Wang2019); Adi et al. (Reference Adi, Sihombing, Siregar, Yanris, Sianturi, Purba, Tamba, Simatupang, Arifuddin, Subairi and Prasetya2021)); for the sake of presentation, we will consider here a simple setting based on the classical NP-hard 3-coloring problem (Lawler (Reference Lawler1976)) in a dynamic setting. Given a graph $G(V,E)$ , the problem is to assign each node $v\in V$ with exactly one color out of a set of $3$ (say, red, green, and blue), so that any pair of adjacent nodes never gets the same color. If the structure of a given graph instance $G$ is specified by means of facts over predicates $node$ and $edge$ , then the following program $P_{3col}$ encodes the problem in ASP:

\begin{align*} r_1 :\ \ \ col(X, red) \ |\ col(X, green) \ |\ col(X, blue)\ :\!\!- \ node(X). \\ r_2 :\ \ \ :\!\!- \ edge(X,Y),\ col(X, C),\ col(Y, C). \end{align*}

Here, $r_1$ is a “guessing” rule, expressing that each node must be assigned with one of the three available colors, whereas $r_2$ is a strong constraint that filters out all candidate solutions that assign two adjacent nodes with the same color. We refer here to an optimization version of the problem, in which some preferences over admissible solutions are given; this can be easily expressed via the following weak constraints (see Calimeri et al. (Reference Calimeri, Faber, Gebser, Ianni, Kaminski, Krennwallner, Leone, Maratea, Ricca and Schaub2020) for details on the linguistic features of ASP):

\begin{align*} r_3 :\ \ \ :\sim \ {\mathtt {not}}\ col(1,red).\ [1@1] \\ r_4 :\ \ \ :\sim \ {\mathtt {not}}\ col(2,green).\ [1@1] \end{align*}

In this case, rules $r_3$ and $r_4$ express preferences for colors to be assigned to nodes $1$ and $2$ : more in detail, color red is preferred for node $1$ , while color green is preferred for node $2$ .

Let us consider the setting in which it is needed to reason on a graph whose structure changes over time, that is, at each shot, nodes and edges can be added or removed.

We show the behavior of the system across three possible shots where input facts change (see Figure 3). Assuming that rules $r_1$ , $r_2$ , $r_3$ , $r_4$ are contained in a file 3-col.asp, the command has issued to Incremental-DLV2 to load the program. Let f1.asp be a file containing the input facts for the first shot:

\begin{equation*} node(1..3).\ edge(1,2).\ edge(2,3).\ edge(1,3). \end{equation*}

By issuing the commands and <run/>, the system finds the unique optimum answer set that assigns nodes $1,2,3$ with colors red, green, and blue, respectively, and internally stores the overgrounded program $G_{3col}$ reported below, in which barred atoms represent occurred simplifications:

At this point, facts in f1.asp are no longer assumed to be true, and the system is ready for a further shot. Suppose that now a further file f2.asp containing the facts for the second shot is loaded (Figure 3, middle column):

\begin{align*} node(1..3).\ edge(1,2).\ edge(1,3).\ edge(2,3).\ \\ node(4..5).\ col(4,red).\ edge(4,5).\ edge(1,5).\ edge(1,4). \end{align*}

two new nodes connected to each other are added and connected also to node $1$ , while coloring for node $4$ is already known to be red. If now another $\lt$ run/ $\gt$ command is issued, thanks to the overgrounding-based instantiation strategy, the system only generates further ground rules due to newly added nodes and edges and adds them to $G_{3col}$ :

Notably, simplifications made at shot 1 remain valid since all facts in shot $1$ are also facts of shot $2$ . Finally, suppose that in the third shot, the system loads a file f3.asp containing the facts (Figure 3, right column):

\begin{align*} node(1..3).\ edge(1,2).\ edge(2,3).\ edge(1,3).\ \\ node(4..5).\ col(4,red).\ edge(1,5).\ edge(4,5). \end{align*}

The input graph is updated by removing the edge between nodes $1$ and $4$ . Now, no new fact results as unseen in previous shots: hence, no additional ground rules are generated, and no grounding effort is needed; the only update in $G_{3col}$ consists of the desimplification of $edge(1,4)$ in rules $r_{17}$ , $r_{18}$ , and $r_{19}$ :

The unique optimum answer set now consists of coloring nodes $1,2,3,4,5$ in red, green, blue, red, green, respectively. It is worth noting that the savings in computational time, obtained by properly reusing ground rules generated at previous shots, occur with no particular assumption made in advance about possible incoming input facts. Moreover, the management of the incremental computation is completely automated and transparent to the user, who is not required to define a priori what is fixed and what might change.

5.1 Benchmarks

We considered a collection of real-world problems that have been already used for testing incremental reasoners. A brief description of each benchmark follows. The full logic programs, instances, and experimental settings can be found at https://dlv.demacs.unical.it/incremental.

5.1.3 Photo-voltaic system (Calimeri et al. (Reference Calimeri, Manna, Mastria, Morelli, Perri and Zangari2021))

We consider here a stream-reasoning scenario in which an intelligent monitoring system (IMS) for a photo-voltaic system (PVS) is used to promptly detect major grid malfunctions. We consider a PVS composed of a grid of $60 \times 60$ solar panels interconnected via cables; each panel continuously produces a certain amount of energy to be transferred to a central energy accumulator directly or via a path between neighbor panels across the grid. The amount of energy produced is tracked and sent to the IMS. An ASP program is repeatedly executed over streamed data readings with the aim of identifying situations to be alerted for and thus prompting the necessity of maintenance interventions. Notably, this domain causes a more intensive computational effort on the grounding side with respect to the solving side as the logic program at hand does not feature disjunction and is stratified.

Fig 4.

Incremental-DLV2 against DLV2: performance in multi-shot contexts.

5.2 Setting

We compared the herein presented Incremental-DLV2 system against the DLV2 system. Both systems were run in single-threaded mode. Experiments have been performed on a NUMA machine equipped with two $2.8$ GHz AMD Opteron $6320$ CPUs, with $16$ cores and $128$ GB of RAM. Differently from Incremental-DLV2, DLV2 is restarted, that is, executed from scratch, at each shot in order to evaluate the given program on the current facts. For each domain, we choose two different measures: we track the total accumulated time and the maximum memory peak per shot. Figure 4 plots the chosen measures against the number of shots for all benchmarks; the $X$ axis diagrams data in the shot execution order.

5.3 Execution times

When observing execution times, a clear advantage is experienced by Incremental-DLV2 over all considered domains.

The Pac-Man benchmark is characterized by the need for computing all distances between all positions ( $30 \times 30$ ) in the game map, which is fixed, and hence Incremental-DLV2 is able to compute them only once at the first shot, which is the most time expensive. At each shot after the first, there is a net gain in grounding times stabilizing at an approximate speedup factor of 4.6; furthermore, given the nature of the available instances, which encode a real game, it turns out that, for a large part of the overgrounded program, the simplifications performed are preserved when moving toward the next shots. Hence, Incremental-DLV2 gains from the low need for desimplifications, while still avoiding to burden the Solver module too much as it is fed with highly simplified versions of the ground program.

In the Content Caching scenario, reasoning is performed on a time window spanning over the last 1000 time ticks. Thus, instances are so that for the first $1000$ shots, the input facts span over a time window of less than $1000$ ticks, and consequently, they are a superset of inputs coming from previous shots; then, from shot $1000$ on, possible input facts do not change anymore. This implies that, basically, from shot to shot the whole overgrounded program is just monotonically enriched with new ground rules, yet keeping the simplifications performed in previous shots, up to the point that nothing new has to be instantiated after shot $1000$ . While Incremental-DLV2 cumulative time performance exhibits a linear growth, the DLV2 behavior worsens as instances become larger. Indeed, early shots require a little computational effort, and thus DLV2 takes advantage of the lack of the multi-shot machinery overhead, although the computing times of the two systems are very close. However, in later shots, the picture overturns: the growth of DLV2 times starts accelerating after a few hundred shots, up to the point that, from shot $1000$ on, as the task to be executed is almost the same across all shots, Incremental-DLV2 significantly outperforms DLV2, as it basically saves the whole grounding time thanks to the overgrounding technique. It is also worth noting that Incremental-DLV2 scales definitely better, as the growth of the execution time is always almost linear; on the other hand, the DLV2 cumulative execution time has a quadratic like trend at the very start and becomes linear only when the effort for requested tasks stabilizes after shot $1000$ , converging to a speedup factor in favor of Incremental-DLV2 of around 1.6.

In the case of the PVS benchmark, both systems show a linear growth in cumulated time; still, Incremental-DLV2 clearly outperforms DLV2, with a speedup factor of slightly less than 2. The corresponding logic program is stratified and features a recursive component that is “activated” at each shot; hence, the hard part of the computation is carried out during the grounding phase, which, also given the nature of the available instances, still remains significant in later shots, differently from the other domains.

5.4 Memory usage

Some additional considerations deserve to be done about memory usage. Indeed, as it is expected because of the incremental grounding strategy herein adopted, the memory footprint is definitely higher for Incremental-DLV2, in all considered domains. However, interestingly, it can be noted that in all cases the memory usage trend shows an asymptotic “saturation” behavior: after a certain number of shots the memory usage basically stays constant; hence, the price to pay in terms of memory footprint is not only counterbalanced by the gain in terms of performance, but it also happens to not “explode.” We also observe that in the Content Caching and PVS benchmarks the memory usage increases along the shots, while it reaches a sort of plateau in the Pac-Man benchmark. Indeed, in this latter domain, a large amount of information, useful in all shots, is inferred only at the first shot and then kept in memory, but with some redundancy. As a result, the memory usage in this benchmark domain is high at the beginning of the shot series, but it stays almost unchanged later. On the other hand, DLV2 makes a good job in generating, from scratch, a compact ground program for each shot. Although the results show a fairly reasonable memory usage, as mentioned before, memory-limiting and rule-forgetting policies added on top of existing algorithms can help in mitigating the memory footprint of Incremental-DLV2, especially in scenarios where memory caps are imposed.

6.1 Theoretical foundations of incremental grounding in ASP

The theoretical foundations and algorithms at the basis of Incremental-DLV2 were laid out by Calimeri et al. (Reference Calimeri, Ianni, Pacenza, Perri and Zangari2019) and Ianni et al. (Reference Ianni, Pacenza and Zangari2020). The two contributions propose, respectively, a notion of embedding and tailored embedding. Embeddings are families of ground programs, which enjoy a number of desired properties. Given $P \cup F$ , an embedding $E$ is such that $AS(P \cup F) = AS(E)$ ; $E$ must be such that it embeds ( $E \vdash r$ ) all $r \in ground(P \cup F)$ .

The $\vdash$ operator is similar to the operator $\models$ that is applied to interpretations and enjoys similar model theoretical properties. Intuitively, given interpretation $I$ and rule $r$ with head $h_r$ and positive body $b_r$ , it is known that $I \models r$ whenever $I \models h_r$ or $I \not \models b_r$ , thus enforcing an implicative dependency between $b_r$ and $h_r$ . A similar implicative dependency is enforced on the structure of ground programs qualified as embeddings: $E \vdash r$ whenever $r \in E$ or whenever, for some atom $b \in b_r$ , $E$ does not embed any rule having $b$ in its head. Embeddings are closed under intersection, and the unique minimal embedding can be computed in a bottom-up fashion by an iterated fixed-point algorithm. An overgrounded program $G$ of $P \cup F$ is such that $G \cup F$ is an embedding of $P \cup F$ .

Ianni et al. (Reference Ianni, Pacenza and Zangari2020) extend the notion of embedding to tailored embeddings. Tailored embeddings are families of ground programs, equivalent to some $P \cup F$ , which allow the possibility of including in the ground program itself a simplified version $r'$ of a rule $r \in ground(P)$ . A tailored embedding is such that $T \Vdash r$ for each $r \in ground(P \cup F)$ . The operator $\Vdash$ takes into account the possibility of simplifications and deletion of rules. The presence of simplified rules might lead to ground programs, which are not comparable under plain set containment; however, tailored embeddings are closed under a generalized notion of containment, and the least tailored embedding can be computed using a bottom-up fixed-point algorithm. Importantly, an overgrounded program with tailoring $G$ obtained by the IncrInst algorithm at shot $i$ with input facts $F_i$ , is such that $G \cup F_i$ is a tailored embedding of $P \cup F_i$ , and thus $AS(G \cup F_i) = AS(P \cup F_i)$ .

It is worth highlighting that embeddings and tailored embeddings can be seen as families of relativized hyperequivalent logic programs in the sense of Truszczynski and Woltran (Reference Truszczynski and Woltran2009). Indeed, given logic programs $P$ and $Q$ , these are said to be hyperequivalent relatively to a finite family of programs $\mathcal{F}$ iff $AS(P \cup F) = AS(Q \cup F)$ for each $F \in \mathcal{F}$ . A member $G$ of a sequence of overgrounded programs is characterized by being equivalent to a program $P$ relative to (part of) a finite set of inputs $F_1, \ldots , F_n$ , similarly to hyperequivalent programs relative to finite sets of inputs. Conditions in which a form of equivalence is preserved under simplifications, possibly changing the simplified program signature w.r.t. the original program, were studied by Saribatur and Woltran (Reference Saribatur and Woltran2023).

6.2 Other ASP systems with incremental features

The ASP system clingo (Gebser et al. (Reference Gebser, Kaminski, Kaufmann and Schaub2019)) represents the main contribution related to multi-shot reasoning in ASP. clingo allows to procedurally control which and how parts of the logic program have to be incremented, updated and taken into account among consecutive shots. This grants designers of logic programs a great flexibility; however, the approach requires specific knowledge about how the system internally holds its computation and about how the domain at hand is structured. It must in fact be noted that the notion of “incrementality” in clingo is intended in a constructive manner as the management of parts of the logic program that can be built in incremental layers. Conversely, in the approach proposed in this paper, the ability of using procedural directives is purposely avoided, in favor of a purely declarative approach. Incrementality is herein intended as an internal process to the ASP system, which works on a fixed input program.

The Stream Reasoning system Ticker of Beck et al. (Reference Beck, Bierbaumer, Dao-tran, Eiter, Hellwagner and Schekotihin2017) represents an explicit effort toward a more general approach to ASP incremental reasoning. Ticker implements the LARS stream-reasoning formal framework of Beck et al. (Reference Beck, Dao-tran and Eiter2018). The input language of LARS allows window operators, which enable reasoning on streams of data under ASP semantics. Ticker implements a fragment of LARS, with no disjunction and no constraints/odd-cycle negation loops, by using back-end incremental truth maintenance techniques.

Among approaches that integrate tightly grounding and solving, it is worth mentioning lazy grounding (see Dal Palù et al. (Reference Dal Palù, Dovier, Pontelli and Rossi2009); Lefèvre et al. (Reference Lefèvre, Béatrix, STéphan and Garcia2017); Bomanson et al. (Reference Bomanson, Janhunen and Weinzierl2019)). Note that overgrounding is essentially orthogonal to lazy grounding techniques, since these latter aim at blending grounding tasks within the solving step for reducing memory consumption; rather, our focus is on making grounding times negligible on repeated evaluations by explicitly allowing the usage of more memory, while still keeping a loose coupling between the two evaluation steps.

6.3 Incrementality in datalog

The issue of incremental reasoning on ASP logic programs is clearly related to the problem of maintaining views expressed in Datalog. In this respect, Motik et al. (Reference Motik, Nenov, Piro and Horrocks2019) proposed the so-called delete/rederive techniques, which aim at updating materialized views. In this approach, no redundancy is allowed, that is, updated views reflect only currently true logical assertions: this differs from the overgrounding idea, which aims to materialize bigger portions of logic programs, which can possibly support true logic assertions. Hu et al. (Reference Hu, Motik and Horrocks2022) extended further the idea, by proposing a general method in which modular parts of a Datalog view can be attached to ad hoc incremental maintenance algorithms. For instance, one can plug in the general framework a special incremental algorithm for updating transitive closure patterns, etc.