1 Introduction
Answer Set Programming (ASP; [14]) offers a rich knowledge representation language along with powerful solving technology. Moreover, it has seen over the recent years several extensions for probabilistic reasoning, among them [11], ProbLog [16], and Plog [3].
In this work, we present an extension of the ASP system clingo, called plingo, that features various probabilistic reasoning modes. Plingo is centered on , a probabilistic extension of ASP based upon a weight scheme from Markov Logic [17]. has already proven to be useful in several settings [12, 1] and it serves us also as a middleground formalism connecting to other probabilistic approaches. We rely on translations from ProbLog and Plog to [11, 13], respectively, to capture these approaches as well. In fact, has already been implemented in the system lpmln2asp [10] by mapping based reasoning into reasoning modes in clingo (viz. optimization and enumeration of stable models). As such, plingo can be seen as a reimplementation of lpmln2asp that is well integrated with clingo by using its multishot and theory reasoning functionalities.
In more detail, the language of plingo constitutes a subset of
restricting the form of weight rules while being extended with ASP’s regular weak constraints. This restriction allows us to partition logic programs into two independent parts: A
hard part generating optimal stable models and a softpart determining the probabilities of these optimal stable models. Arguably, this separation yields a simpler semantics that leads in turn to an easier way of modeling probabilistic logic programs. Nonetheless, it turns out that this variant is still general enough to capture full
. Moreover, plingo allows us to capture such probabilistic programs within the input language of clingo. The idea is to describe the hard part in terms of normal rules and weak constraints at priority levels different from , and the soft part via weak constraints at priority level .^{1}^{1}1This fits well with the semantics of clingo, where higher priority levels are more important. On top of this, plingo offers three alternative frontends, for , Plog, and ProbLog, featuring dedicated language constructs that are in turn translated into the format described above. As regards solving, plingo follows the approach of lpmln2asp of reducing probabilistic reasoning to clingo’s regular optimization and enumeration modes. In addition, plingo features an approximation method that calculates probabilities using only the most probable stable models for an input parameter . This is accomplished by an improved implementation of answer set enumeration in the order of optimality [15]. We empirically evaluate plingo’s performance by contrasting it to original implementations of , ProbLog and Plog.2 Background
A logic program is a set of propositional formulas. A logic program with weak constraints is a set where is a logic program and is a set of weak constraints of the form where is a formula, is a real number, and is a nonnegative integer. For the definition of the stable models of a logic program, possibly with weak constraints, we refer the reader to [7, 4]. We denote by the set of stable models of a logic program .
We next review the definition of [11]. An program is a finite set of weighted formulas where is a propositional formula and is either a real number (in which case, the weighted formula is called soft) or for denoting the infinite weight (in which case, the weighted formula is called hard). If is an program, by and we denote the set of soft and hard formulas of , respectively. For any program and any set of atoms, denotes the set of usual (unweighted) formulas obtained from by dropping the weights, and denotes the set of in such that . Given an program , denotes the set of soft stable models The total weight of , written , is defined as . The weight of an interpretation and its probability are defined, respectively, as
An interpretation is called a probabilistic stable model of if . Besides this standard definition, we consider also an alternative definition for from [11], where soft stable models must satisfy all hard formulas of . In this case, we have that denotes the set , while the weight of an interpretation and its probability are defined, respectively, as
The set may be empty if there is no soft stable model that satisfies all hard formulas of , in which case is not defined. On the other hand, if is not empty, then for every interpretation the values of and are the same (cf. Proposition 2 from [11]).
3 and the language of plingo
programs are based on programs under the alternative semantics. On the one () hand, they are a subset of programs where the soft formulas are socalled soft integrity constraints of the form , for some propositional formula . This restriction is interesting because it allows us to provide a definition of the semantics that is arguably very simple and intuitive. Interestingly, the translations from ProbLog and Plog ([11, 13]) fall into this fragment of . Recall that in ASP, integrity constraints of the form do not affect the generation of stable models, but they can only eliminate some of the stable models generated by the rest of the program. In , integrity soft constraints parallel that role, since they do not affect the generation of soft stable models, but they can only affect the probabilistic weights of the soft stable models generated by the rest of the program. More precisely, it holds that the soft models of an program remain the same if we delete from all its soft integrity constraints. This observation leads us to the following proposition.
Proposition 1
If is an program such that contains only soft integrity constraints, then .
This allows us to leave aside the notion of soft stable models and simply replace in and the set by . From this perspective, an program of this restricted form has two separated parts: , that generates stable models; and , that determines the weights of the stable models, from which their probabilities can be calculated.
On the other () hand, extends with regular ASP’s weak constraints. This is a natural extension, that moreover allows us to capture the whole language.
With this, we can define the syntax and semantics of programs. Formally, an program is a set of hard rules, soft integrity constraints, and weak constraints, denoted respectively by , and . By we denote the optimal stable models of . Then, the weight and the probability of an interpretation , written and , are the same as and , but replacing the set by :
Note that, as before, may be empty, in which case is not defined.
We can capture by programs using a translation that is based on the translation lpmln2wc from [13]. Given an program , by we denote the program that contains the hard formulas , the soft formulas , and the weak constraints . The hard rules generate the soft stable models of , the weak constraints select those which satisfy most of the hard rules of , while the soft rules attach the right weight to each of them, without interfering in their generation. To represent the alternative semantics, we consider another program that contains the same soft rules and weak constraints as , but whose hard rules are joined with . The former formulas enforce that hard formulas of must be satisfied, while the latter are the same as in , but only for the soft formulas of .
Proposition 2
Let be an program. For every interpretation it holds that and coincide; and and coincide.
As noted in [10], this kind of translations can be troublesome when applied to logic programs with variables in the input language of clingo. This is the case of the frontend in plingo, where the rules at the input can be seen as safe implications where is a disjunction and a conjunction of firstorder atoms. It is not easy to see how can we apply the previous translations in such a way that the resulting soft formulas and weak constraints belong to the input language of clingo, in particular since the result has to safisfy clingo’s safety conditions. To overcome this issue, we can use the negative version of the previous translations, based on the translation lpmln2wc from [13], with the following soft rules , and weak constraints where occurs always under one negation. In this case, when has the form , the formula can be simply written as , and this formulation can be easily incorporated into clingo. This version is justified by the following result, that is closely related to Corollary 1 from [13].
Proposition 3
Given an program , let be the set of rules . For every interpretation it holds that and coincide.
We can move on now to the implementation of in plingo. The main idea of the system is to keep the input language of clingo, and reinterpret weak constraints at priority level as soft integrity constraints that are not considered to determine the optimal stable models, but instead are used to determine the weights of them, from which their probabilities are calculated. For propositional formulas, this boils down to interpreting the union of a set of propositional formulas with a set of weak constraints as the program that contains the hard rules , the soft integrity constraints , and the weak constraints . For programs in the input language of plingo (or of clingo, that is the same) we can in fact provide a general definition that relies on the definitions used for clingo ([5]), and that therefore covers its whole language. We define a plingo program as a logic program in the language of clingo, and we let denote the optimal models of without considering weak constraints at level , and denote the cost of the interpretation at priority level , according to the definitions of [5]. Then, the weight of an interpretation and its probability are defined as:
4 Frontends
In this section we illustrate the frontends of plingo with examples, and show in each case what is the result of the translation to the core language of plingo.
4.1
Listing 1 shows the birds example from [11] using the frontend of plingo. To start with, there is some general knowledge about birds: both resident birds and migratory birds are birds, and a bird cannot be both resident and migratory. This is represented by the hard rules in Lines 11, that are written as common clingo rules. Additionally, from one source we have the fact that jo is a resident bird, while from another we have that jo is a migratory bird. For some reason, we hold the first source to be more trustworthy than the second. This information is represented by the soft rules in Lines 1 and 1, where the weights are expressed by the (integer) arguments of their &weight/1 atoms in the body. The first soft rule corresponds to the weighted formula , and the second to . Under both the standard and the alternative semantics, this program has three probabilistic stable models: , , and , whose probabilities are , , and , respectively. They can be computed by plingo, running the command plingo mode=lpmln birds.plp for the standard semantics, and using the option mode=lpmlnalt for the alternative semantics.
Plingo translates programs using the negative versions of the translations and from the previous section. Considering first the alternative semantics, the normal rules remain the same, while the soft rules are translated as shown in Listing 2. According to the negative version of , the soft formula becomes the hard formula and the soft formula . In plingo, the first is written as the choice rule in Line 1, and the second as the weak constraint at level of Line 2. The translation of the other soft fact is similar. Considering now the standard semantics, the first rule of Listing 1 becomes the choice rule {bird(X)} : resident(X) together with the weak constraint :~ not bird(X), resident(X).[1@1,X]. The second rule is translated similarly. The third one becomes simply :~ resident(X), migratory(X). [1@1,X], since the additional choice rule is a tautology and can be skipped. Observe that both weak constraints use the variable X in the expression [1@1,X]. This ensures that stable models obtain a weight of 1 for every ground instantiation of the corresponding body that they satisfy.
4.2 ProbLog
We illustrate the frontend for ProbLog with an example where we toss two biased coins whose probability of turning up heads is . We would like to know what is the probability of the first coin turning heads, given some evidence against the case that both coins turn heads. The representation in plingo is shown in Listing 3. The first rule represents the toss of the coins. Its ground instantiation leads to two socalled probabilistic facts, one for each coin, whose associated probabilities are specified by the &problog/1 atom in the body. The argument of &problog/1 atoms is a string that contains either a float number or an expression, e.g., . Since the argument is a probability, the string must either contain or evaluate to a real number between and . The next line poses the query about the probability of the first coin turning heads, using the theory atom &query/1, whose unique argument is an atom. Finally, Lines 3 and 3 add the available evidence, using the theory atom &evidence/2, whose arguments are an atom and a truth value (true or false). In ProbLog, the probabilistic facts alone lead to four possible worlds: with probability , and with probability each, and with probability . The last possible world is eliminated by the evidence, and we are left with three possible worlds. Then, the probability of heads(1) is the result of dividing the probability of by the sum of the probabilities of the three possible worlds, i.e., . This is the result that we obtain running the command plingo mode=problog coins.plp.
Plingo translates ProbLog programs combining the translation from [10] to with the translation from Section 3. The result in this case is shown in Listing 4. In the propositional case, the probabilistic ProbLog fact is translated to the weighted fact , where ,^{2}^{2}2See the explanation in footnote 3 about this usage of logarithms. that in becomes the hard formula together with the soft integrity constraint . The translation for the other probabilistic fact is similar. In plingo, for C=1..2, the hard formula is written as the choice rule of Line 4, and the soft one is written as a weak constraint at level in the next line, after simplifying away the double negation, where @f(X) is an external function that returns the logarithm of X/(1X). Going back to the original program, the &query/1 atom is stored by the system to determine what reasoning task to solve, the normal rule in Line 3 is kept as it is, and the &evidence/1 atom is translated to the integrity constraint of Line 4, that excludes the possibility of both coins turning heads.
4.3 Plog
We illustrate the Plog frontend with a simplified version of the dice example from [3], where there are two dice of six faces. The first dice is fair, while the second one is biased to roll half of the times. We roll both dice, and observe that the first rolls a . We would like to know what is the probability of the second dice rolling another . The representation in plingo using the Plog frontend is shown in Listing 5. Given that the original language Plog is sorted, a representation in that language would contain the sorts and , and the attribute . In plingo there are no attributes, and the sorts are represented by normal atoms, like in the first two lines of Listing 5. Then, for example, to assert that the result of rolling dice d2 is 6, in Plog one would write an assignment roll(d2)=6 stating that the attribute roll(d2) has the value 6, while in plingo one would use a normal atom of the form roll(d2,6). Going back to the encoding, Line 5 contains a random selection rule that describes the experiments of rolling every dice D. Each of these experiments selects at random one of the scores of the dice, unless this value is fixed by a deliberate action of the form &do(A), that does not occur in our example. Line 5 contains a probabilistic atom stating that the probability of dice d2 rolling a 6 is . By the principle of indifference, embodied in the semantics of Plog, the probability of the other faces of d2 is , while the probability of each face of d1 is . Line 5 represents the observation of the first dice rolling a , and the last line states the query about the probability of the second dice rolling another . Running the command plingo mode=plog dice.plp, we obtain that this probability is, as expected, . If we replace the query by &query(roll(d1,1)), then we obtain a probability of , and not of , because the observation in Line 5 is only consistent with the first dice rolling a .
Plingo translates Plog programs combining the translation from [10] to with the translation from the previous section. Given the input file dice.plp, plingo copies the normal rules of Lines 55, translates the rules specific to Plog into the Listing 6, stores internally the information about the &query atom, and adds the general metaencoding of Listing 7. In Listing 6, Line 6 defines for every dice D one random experiment, identified by the term roll(D), that may select for the attribute roll(D) one possible score X. The atoms defined that way are fed to the first rule of the metaencoding to choose exactly one of those assigments, represented in this case by an special predicate h/1, that is made equivalent to the predicate roll/2 in Lines 66 of Listing 7. Those lines are the interface between the specific input program and the general metaencoding. They allow the latter to refer to the atoms of the former using the predicate h/1. Next, Line 6 of Listing 6 defines the probability of the second dice rolling a 6 in the experiment identified by the term roll(d2). This is used in Line 7 of the metaencoding, where @f1(P) returns the logarithm of P,^{3}^{3}3With this representation, the weights do not stand for probabilities, but for the logarithm of the probabilities. Then, the cost of a stable model at level represents the sum of the logarithms of the relevant probabilities and, by exponentiating that value, the probabilistic weight of a stable model becomes the product of the corresponding probabilities. to add that weight whenever the following conditions hold: the attribute A has the value V, this value has not been fixed by a deliberate action, and some probabilistic atom gives the probability P. If there is no such probabilistic atom, then the rule of Line 7 derives that the assignment chosen in the experiment E receives the default probability, calculated in Lines 77 following the principle of indifference mentioned above, where @f2(Y) returns the logarithm of 1Y, and @f3(M) returns the logarithm of 1/M. The idea of this calculation is as follows. For some experiment E, the number Y accounts for the sum of the probabilities of the probabilistic atoms related to E, and M is the number of outcomes of the experiment E for which there are no probabilistic atoms. Then, the probability of each outcome of the experiment E for which there is no probabilistic atom is (1Y)*(1/M). Instead of multiplying those probabilities 1Y and 1/M, the encoding adds their logarithms^{4}^{4}4See footnote 3., and it does so in two steps: one in each of the last two weak constraints. Finally, the observation fact generated in Line 6 of Listing 6 is handled by Lines 77 of Listing 7, and the possible deliberate actions, represented by atoms of the form do(A), are handled in Line 7 of the metaencoding.
5 The system plingo
The implementation of plingo is based on clingo and its Python API (v5.5, [9]). The system architecture is described in Figure 1. The input is a logic program written in some probabilistic language: , , ProbLog or Plog. For , the input language (orange element of Figure 1) is the same as the input language of clingo, except for the fact that the weights of the weak constraints can be strings representing real numbers. For the other languages, the system uses the corresponding frontends, that translate the input logic programs (yellow elements of Figure 1) to the input language of plingo using the Transformer module, as illustrated by the examples of section 4. Among other things, this involves converting the theory atoms (preceeded by ‘&’) to normal atoms. The only exception to this are &query atoms, that are eliminated from the program and stored internally. For Plog, the frontend also appends the meta encoding (Listing 7) to the translation of the input program.
Plingo can be used to solve two reasoning tasks: MAP inference and marginal inference. MAP inference is the task of finding a most probable stable model of a probabilistic logic program. Following the approach of [10], in plingo this task is reduced to finding one optimal stable model of the input program using clingo’s builtin optimization methods. The only changes that have to be made concern handling the strings that may occur as weights of the weak constraints, and switching the sign of those weights, since otherwise clingo would compute the least probable stable models. Regarding marginal inference, it can be either applied in general, or with respect to a query. In the first case, the task is to find all stable models and their probabilities. In the second case, the task is to find the probability of some query atom, that is defined as the sum of the probabilities of the stable models that contain that atom. The implementation for both cases is the same. First, plingo enumerates all optimal stable models of the input program excluding the weak constraints at level . Afterwards, those optimal stable models are passed, together with their cost at level , to the Probability module, that calculates the required probabilities.
In addition to this exact method (represented by the blue arrows in Figure 1), plingo implements an approximation method (purple arrows in Figure 1) based on the approach presented in [15]. The idea is to simplify the solving process by computing just a subset of the stable models, and using this smaller set to approximate the actual probabilities. Formally, in the definitions of and , this implies replacing the set by one of its subsets. In the implementation, the modularity of this change is reflected by the fact that the Probability module is agnostic to whether the stable models that it receives as input are all or just some subset of them. For marginal inference in general, this smaller subset consists of stable models with the highest possible probability, given some positive integer that is part of the input. To compute this subset, the Solver module of plingo uses a new implementation for the task of answer set enumeration in the order of optimality (ASEO) presented in [15].^{5}^{5}5The implementation of the method for clingo in general is available at https://github.com/potassco/clingo/tree/master/examples/clingo/optenum. Given some positive integer , the implementation first computes the stable models of the smallest cost, then, among the remaining stable models, computes the ones of the smallest cost, and so on until stable models (if they exist) have been computed. For marginal inference with respect to a query, the smaller subset consists of stable models containing the query of the highest possible probability, and another stable models without the query of the highest possible probability. In this case, the algorithm for ASEO is set to compute stable models. But once it has computed stable models that contain the query, or stable models that do not contain the query, whichever happens first, it adds a constraint enforcing that the remaining stable models fall into the opposite case.
6 Experiments
In this section, we experimentally evaluate plingo and compare it to native implementations of , ProbLog and Plog.^{6}^{6}6Available, respectively, at https://github.com/azreasoners/lpmln, https://github.com/MLKULeuven/problog, and https://github.com/iensen/plog2.0. For , we evaluate the system lpmln2asp ([10]), that is the basis for our implementation of plingo. For ProbLog, we consider the problog system version 2.1 ([8]), that implements various methods for probabilistic reasoning. In the experiments, we use one of those methods, that is designed specifically to answer probabilistic queries. It converts the input program to a weighted Boolean formula and then applies a knowledge compilation method for weighted model counting. For Plog, we evaluate two implementations, that we call plognaive and plogdco ([2]). While the former works like plingo and lpmln2asp by enumerating stable models, the latter implements a different algorithm that builds a computation tree specific to the input query. All benchmarks were run on an Intel Xeon E52650v4 under Debian GNU/Linux 10, with a memory limit of 24 GB, and a timeout of 1200 seconds per instance.
We have performed three experiments. In the first one, our goal is to evaluate the performance of the exact and the approximation methods of plingo and compare it to the performance of all the other systems on the same domain. In particular, we want to analyze how much faster is the approximation method than the exact one, and how accurate are the probabilities that it returns. In the second experiment, our goal is to compare plingo with the implementations of Plog on domains that are specific to this language. Finally, the goal of the third experiment is to compare plingo and lpmln2asp on the task of MAP inference. In this case, both implementations are very similar and boil down to a single call to clingo. We would like to evaluate if in this situation there is any difference in performance between both systems.
In the first experiment, we compare all systems on the task of marginal inference with respect to a query in a probabilistic Grid domain from [19], that appeared in a slightly different form in [8]. We have chosen this domain because it can be easily and similarly represented in all these probabilistic languages, which is required if we want to compare all systems at the same time. In this domain there is a grid of size , where each node passes information to the nodes and if is not faulty, and each node in the grid can be faulty with probability . The task poses the following question: what is the probability that node receives information from node ? To answer this, we run exact marginal inference with all systems, and approximate marginal inference with plingo for different values of : , , …, and . The results are shown in Figure 2. On the left side there is a cactus plot representing how many instances where solved within a given runtime. The dashed lines represent the runtimes of the approximate marginal inference of plingo for and . Among the exact implementations, the system problog is the clear winner. In this case, its specific algorithm for answering queries is much faster than the other exact systems that either have to enumerate all stable models or, in the case of plogdco, may have to explore its whole solution tree. The runtimes among the rest of the exact systems are comparable, but plingo is a bit faster than the others. For the approximation method, on the right side of Figure 2, for every value of and every instance, there is a dot whose coordinates represent the probability calculated by the approximation method and the true probability (calculated by problog). This is complemented by Table 1, that shows the average absolute error and the maximal absolute error for each value of in , where the absolute error for some instance and some in is defined as the absolute value of the difference between the calculated probability and the true probability for that instance, multiplied by . We can see that, as the value of increases, the performance of the approximation method deteriorates, while the quality of the approximated probabilities increases. A good compromise is found for , where the runtime is better than problog, and the average error is below .
k  

Avg. Error  
Max. Error 
In the second experiment, we compare the performance of the exact method of plingo using the Plog frontend with the two native implementations of that language, on tasks of marginal inference with respect to a query in three different domains: NASA, Blocks and Squirrel. The NASA domain ([2]) involves logical and probabilistic reasoning about the faults of a control system. For this domain there are only three instances. All of them are solved by plingo in about a second, while plognaive takes between and seconds, and plogdco between and seconds. The Blocks domain ([19]) starts with a grid and a set of blocks, and asks what is the probability that two locations are still connected after the blocks have been randomly placed on the grid. In the experiments we use a single map of locations and vary between and . The results are shown in Figure 3, where we can see a similar pattern as in the NASA domain: plingo and plognaive solve all instances in just a few seconds, while plogdco needs much more time for the bigger instances. The Squirrel domain ([2, 3]) is an example of Bayesian learning, where the task is to update the probability of a squirrel finding some food in a patch after failing to find it on consecutive days. In the experiments we vary the number of days between and . The results are shown in figure 3. Now plognaive is slower and can solve only instances up to days, while plingo and plogdco can solve instances up to days. To interpret the results, recall that the underlying algorithms of plognaive and plingo are very similar. Hence, we conjecture that the better performance of plingo is due to details of the implementation. On the other hand, plogdco uses a completely different algorithm. According to the authors ([2]), this algorithm should be faster than plognaive when the value of the query can be determined from a partial assignment of the atoms of the program. This may be what is happening in the Squirrel domain, where it is on par with plingo, while it does not seem to be the case for the other domains.
In the third experiment, we compare the performance of the exact method of plingo using the frontend with the system lpmln2asp on tasks of MAP inference in two domains: Alzheimer and Smokers. The goal in the Alzheimer domain ([16]) is to determine the probability that two edges are connected in a directed probabilistic graph based on a realworld biological dataset of Alzheimer genes ([18]).^{7}^{7}7We thank Gerda Janssens for providing us the instances. The data consists of a directed probabilistic graph with 11530 edges and 5220 nodes. In the experiments we select different subgraphs of this larger graph, varying the number of nodes from to . The results are shown in Figure 4, where we observe that for the smaller and bigger instances the performance of plingo and lpmln2asp is quite similar, while in the middle there are some instances that lpmln2asp can solve within the time limit while plingo cannot. The Smokers domain involves probabilistic reasoning about a network of friends. Originally it was presented in [6], but we use a slightly simplified version from [10]. In the experiments we vary the number of friends in the network. In Figure 4, we can observe that for the smaller instances the performance of plingo and lpmln2asp is similar, but for larger instances plingo is faster. Given that the underlying algorithms of plingo and lpmln2asp are similar, we expected them to have a similar performance. Looking at the results, we have no specific explanation for the differences in some instances of the Alzheimer domain, and we conjecture that they are due to the usual variations in solver performance. With respect to the Smokers domain, the worse performance of lpmln2asp seems to be due to the usage of an external parser that increases a lot the preprocessing time for the bigger instances.
7 Conclusion
We have presented plingo, an extension of the ASP system clingo with various probabilistic reasoning modes. Although based on , it also supports Plog and ProbLog. While the basic syntax of plingo is the same as the one of clingo, its semantics relies on reinterpreting the cost of a stable model at priority level as a measure of its probability. Solving exploits the relation between most probable stable models and optimal stable models [13]; it relies on clingo’s optimization and enumeration modes, as well as an approximation method based on answer set enumeration in the order of optimality [15]. Our empirical evaluation has shown that plingo is at eye height with other ASPbased probabilistic systems, except for ProbLog that relies on wellfounded semantics. Notably, the approximation method produced low runtimes and low error rates (below ). Plingo is freely available at https://github.com/potassco/plingo.
References
 [1] Ahmadi, N., Lee, J., Papotti, P., Saeed, M.: Explainable fact checking with probabilistic answer set programming. In: Liakata, M., Vlachos, A. (eds.) Proceedings of the 2019 Truth and Trust Online Conference (2019)
 [2] Balaii, E.: Investigating and extending Plog. Ph.D. thesis, Texas Tech University (2017)
 [3] Baral, C., Gelfond, M., Rushton, J.: Probabilistic reasoning with answer sets. Theory and Practice of Logic Programming 9(1), 57–144 (2009)
 [4] Buccafurri, F., Leone, N., Rullo, P.: Enhancing disjunctive datalog by constraints. IEEE Transactions on Knowledge and Data Engineering 12(5), 845–860 (2000)
 [5] Calimeri, F., Faber, W., Gebser, M., Ianni, G., Kaminski, R., Krennwallner, T., Leone, N., Ricca, F., Schaub, T.: ASPCore2: Input language format. Available at https://www.mat.unical.it/aspcomp2013/ASPStandardization (2012)
 [6] Domingos, P., Kok, S., Lowd, D., Poon, H., Richardson, M., Singla, P.: Probabilistic Inductive Logic Programming  Theory and Applications, Lecture Notes in Computer Science, vol. 4911. SpringerVerlag (2008)

[7]
Ferraris, P.: Answer sets for propositional theories. In: Baral, C., Greco, G., Leone, N., Terracina, G. (eds.) Proceedings of the Eighth International Conference on Logic Programming and Nonmonotonic Reasoning (LPNMR’05). Lecture Notes in Artificial Intelligence, vol. 3662, pp. 119–131. SpringerVerlag (2005)
 [8] Fierens, D., den Broeck, G.V., Renkens, J., Shterionov, D., Gutmann, B., Thon, I., Janssens, G., Raedt, L.D.: Inference and learning in probabilistic logic programs using weighted boolean formulas. Theory and Practice of Logic Programming 15(3), 385–401 (2015)
 [9] Gebser, M., Kaminski, R., Kaufmann, B., Ostrowski, M., Schaub, T., Wanko, P.: Theory solving made easy with clingo 5. In: Carro, M., King, A. (eds.) Technical Communications of the Thirtysecond International Conference on Logic Programming (ICLP’16). OpenAccess Series in Informatics (OASIcs), vol. 52, pp. 2:1–2:15. Schloss Dagstuhl–LeibnizZentrum fuer Informatik (2016)
 [10] Lee, J., Talsania, S., Wang, Y.: Computing LPMLN using ASP and MLN solvers. Theory and Practice of Logic Programming 17(56), 942–960 (2017)
 [11] Lee, J., Wang, Y.: Weighted rules under the stable model semantics. In: C. Baral, J. Delgrande, F.W. (ed.) Proceedings of the Fifteenth International Conference on Principles of Knowledge Representation and Reasoning. pp. 145–154. AAAI/MIT Press (2016)
 [12] Lee, J., Wang, Y.: Weight learning in a probabilistic extension of answer set programs. In: Proceedings of the 16th International Conference on Principles of Knowledge Representation and Reasoning. pp. 22–31 (2018)
 [13] Lee, J., Yang, Z.: LPMLN, weak constraints and Plog. In: Proceedings of the 31st AAAI Conference on Artificial Intelligence. pp. 1170–1177 (2017)
 [14] Lifschitz, V.: Answer set programming and plan generation. Artificial Intelligence 138(12), 39–54 (2002)
 [15] Pajunen, J., Janhunen, T.: Solution enumeration by optimality in answer set programming. Theory and Practice of Logic Programming 21(1), 750–767 (2021)
 [16] Raedt, L.D., Kimmig, A., Toivonen, H.: ProbLog: A probabilistic prolog and its applications in link discovery. In: Proceedings of the Twentysecond National Conference on Artificial Intelligence (AAAI’07). pp. 2468–2473. AAAI Press (2007)

[17]
Richardson, M., Domingos, P.: Markov logic networks. Machine Learning
62(12), 107–136 (2006)  [18] Shterionov, D.: Design and Development of Probabilistic Inference Pipelines. Ph.D. thesis, KU Leuven (2015)
 [19] Zhu, W.: Plog: Its algorithms and applications. Ph.D. thesis, Texas Tech University (2012)