PreprintPDF Available

A Table-Based Representation for Probabilistic Logic: Preliminary Results

Authors:

Abstract

We present Probabilistic Decision Model and Notation (pDMN), a probabilistic extension of Decision Model and Notation (DMN). DMN is a modeling notation for deterministic decision logic, which intends to be user-friendly and low in complexity. pDMN extends DMN with probabilistic reasoning, predicates, functions, quantification, and a new hit policy. At the same time, it aims to retain DMN's user-friendliness to allow its usage by domain experts without the help of IT staff. pDMN models can be unambiguously translated into ProbLog programs to answer user queries. ProbLog is a probabilistic extension of Prolog flexibly enough to model and reason over any pDMN model.
arXiv:2110.01909v1 [cs.AI] 5 Oct 2021
A Table-Based Representation for Probabilistic Logic: Preliminary Results
Simon Vandevelde,1,3 Victor Verreet, 2,3 Luc De Raedt, 2,3 Joost Vennekens 1,3
1KU Leuven, De Nayer Campus, Dept. of Computer Science, J.-P.-De Nayerlaan 5, 2860 Sint-Katelijne-Waver, Belgium
2KU Leuven, Dept. of Computer Science, Celestijnenlaan 200, 3001 Heverlee, Belgium
3Leuven.AI - KU Leuven Institute for AI, B-3000, Leuven, Belgium
s.vandevelde@kuleuven.be, victor.verreet@kuleuven.be, luc.deraedt@kuleuven.be, joost.vennekens@kuleuven.be
Abstract
We present Probabilistic Decision Model and Notation
(pDMN), a probabilistic extension of Decision Model and
Notation (DMN). DMN is a modeling notation for determin-
istic decision logic, which intends to be user-friendly and
low in complexity. pDMN extends DMN with probabilistic
reasoning, predicates, functions, quantification, and a new
hit policy. At the same time, it aims to retain DMN’s user-
friendliness to allow its usage by domain experts without the
help of IT staff. pDMN models can be unambigiously trans-
lated into ProbLog programs to answer user queries. ProbLog
is a probabilistic extension of Prolog flexible enough to model
and reason over any pDMN model.
Introduction
ProbLog (De Raedt, Kimmig, and Toivonen 2007) is a pow-
erful modeling tool that combines logical reasoning with
probabilities. It supports many inference tasks, such as
marginal and conditional probability calculations, allowing
it to be used for problems such as Bayesian reasoning and
inference in social networks (Gutmann, Thon, and De Raedt
2011). However, ProbLog rules are often difficult to inter-
pret for domain experts with no familiarity with Probabilis-
tic Logic Programming (PLP).
The Decision Model and Notation standard (DMN)
(Object Management Group 2019) is a user-friendly nota-
tion for decision logic, published by the Object Management
Group (OMG). The goal of DMN is to be readable and us-
able by all parties involved in the decision process (business
people, IT experts, ...), as well as being executable. Cur-
rently, it only allows the modelling of deterministic decision
processes.
In this paper, we present a preliminary version of Prob-
abilistic Decision Model and Notation (pDMN): a DMN-
like notation for probabilistic logic that aims to combine
DMN’s intuitive notation with ProbLog’s powerful proba-
bilistic reasoning capabilities. Our goal is to close the gap
between ProbLog experts and domain experts, by lowering
the threshold to understand and interpret probabilistic mod-
els, and to possibly allow domain experts to create the mod-
els themselves. This work is similar in spirit to our earlier
Copyright © 2021, Association for the Advancement of Artificial
Intelligence (www.aaai.org). All rights reserved.
work on cDMN (Aerts, Vandevelde, and Vennekens 2020),
that extended DMN with constraint programming.
The contributions of this paper are as follows:
1. the pDMN notation for probabilistic programming, which
aims to be user-friendly;
2. the translation principles of pDMN into ProbLog;
3. an implementation of a ProbLog-based solver for pDMN.
This paper is structured as follows. First, we go over the
DMN and ProbLog concepts necessary for this work. We
then introduce our pDMN syntax, and elaborate on how it
differs from standard DMN. We also present the translation
principles of pDMN into ProbLog, and very briefly go over
our implementation of a pDMN solver. Afterwards, we show
a full pDMN implementation of a well-known example, to
show pDMN in action. Finally, we conclude our preliminary
work, and lay out the future work ahead.
Decision Model and Notation
In DMN, all logic is represented by decision tables. An ex-
ample is shown in Fig. 1. In such a table, the value of the
“output” variable(s) (in lighter blue) is defined by the value
of the “input” variable(s) (in darker green). All variables in
DMN are either booleans (0-ary predicates), or constants (0-
ary functions). Each row of a table represents a decision rule.
A row is applicable if its input values match the actual val-
ues of the input variables. For example, if BMI = 22, the
second row of the first table is applicable.
The table’s hit policy, as denoted in the top-left corner,
further defines the behavior of the table. In U(nique) tables,
only one row may be applicable for a set of input values.
In A(ny) tables, multiple rows can be applicable, but they
must all agree on the output value(s) they assign. Lastly, in
F(irst) tables, the topmost applicable row is always selected.
Besides these so-called single hit policies there are also mul-
tiple hit policies, which are out of the scope of this paper.
A variable which is an output in one table can be an in-
put in another table. In this way, decisions can be chained
together. For instance, starting from BMI = 22, we can first
decide that BMILevel = Normal and then use the second ta-
ble to decide that Healthy = Yes.
Another component in DMN, besides the decision tables,
is the Decision Requirements Diagram (DRD). This is a
BMILevel
U BMI BMILevel
1<18.5Underweight
2[18.5..25] Normal
3>25 Overweight
Healthy
U BMILevel Healthy
1 Normal Yes
2 Overweight, Underweight No
Figure 1: Example DMN tables
graph that gives an overview of the structure of a DMN
model. However, as this paper focuses in first instance on
the decision tables, we will not discuss the DRD further.
Probabilistic Logic Programming
ProbLog is a probabilistic extension of Prolog. A ProbLog
program consists of a set of probabilistic facts and a set of
Prolog rules. Probabilistic facts are of the form Pf:: f, with
Pf[0,1] a probability and fan atom. The atom fis true
or false with probability Pfand 1Pfrespectively. Rules
are written as h:b1, b2,...,bnwhere the atom his called
the head and biare the body atoms. The head of a rule may
never occur in a probabilistic fact. Whenever all the atoms
in the body of a rule are true, the head atom is true as well.
A rule can also be annotated with a probability, but this is
syntactic sugar for adding a unique atom to the body which
is true with the annotated probability. Symbolically, the rule
Pr:: h:b1, b2, . . . , bn(1)
is translated into
h:b1, b2,...,bn, frand Pr:: fr(2)
with fra newly created atom. ProbLog also allows anno-
tated disjunctions (ADs), written as
P1:: f1;P2:: f2;...;Pn:: fn(3)
with PiPi1. An AD denotes a probabilistic choice
where every atom fiis selected to be true with probabil-
ity Pi, but at most one atom in the AD can be selected. If
PiPi<1it is possible that none are true.
An interpretation is a truth value assignment to every atom
occurring in the program. A model of the program is an in-
terpretation that satisfies every rule and follows the closed
world assumption. The closed world assumption states that
an atom can only be true in a model whenever it can be de-
rived through at least one rule. The probability of any model
Mof the program is the product of the probabilities of the
facts in the model. The probability of an atom qis the sum
of the probabilities of the models in which that atom is true.
Hence,
P(q) = X
M|=q
Y
fM
P(f)(4)
where the sum runs over all models Min which qis true
and the product runs over all the probabilistic facts fin the
model M. The probability P(f)is the user given value Pfif
fis true in the model M, and 1Pfotherwise. An example
of a ProbLog program is given in Example 1.
Example 1. Consider the program
0.8 :: a. c :a.
0.3 :: b(1); 0.5 :: b(2); 0.2 :: b(3). c :b(1).(5)
where we are interested in the probability of c. This
program has 6 models, {a, b(1), c},{a, b(2), c},
{a, b(3), c},{not(a), b(1), c},{not(a), b(2),not(c)}
and {not(a), b(3),not(c)}, where cis only true in the first 4
models. Therefore, the probability of cis
P(c) = 0.8·0.3 + 0.8·0.5 + 0.8·0.2 + 0.2·0.3 = 0.86 (6)
pDMN: Syntax
We now elaborate on the syntax of pDMN, our DMN exten-
sion for probabilistic logic programming. In pDMN, there
are three types of tables: glossary tables, decision tables, and
the query table.
Glossary
Variables in pDMN, in contrast to standard DMN, are
typed n-ary functions and predicates. In order to cor-
rectly identify these variables and their arguments, pDMN
introduces three glossary tables in which these should
be declared: the Type table, the Predicate table and the
Function table. These glossary tables contain the re-
quired meta-information to correctly interpret the pDMN
model. This is analogous to the approach used in
cDMN (Aerts, Vandevelde, and Vennekens 2020).
The Type table declares the types used in a pDMN model,
together with their domain of elements. For example, the
Type table in Fig. 2 declares a type Person, which consists
of two elements, ann and bob, and a type Vaccine, which
consists of the elements a,band n(one).
The Predicate table declares n-ary predicates. There is no
fixed naming syntax for predicates; the arguments of a pred-
icate are those types that appear in its description, and the
remaining string is considered the predicate’s name. For ex-
ample, in the glossary of Fig. 2, Person is infected represents
a unary predicate is infected, which denotes for every Per-
son (i.e., ann and bob) whether they are infected. Similarly,
Person contacted Person is a binary predicate contacted that
denotes contact between people.
The Function table declares n-ary functions. Analogously
to predicates, the function’s name contains its arguments. In
contrast to predicates, however, functions map their argu-
ments to the type listed in the Type column of the glossary
table, instead of to a boolean. For example, vaccine of Per-
son denotes the Vaccine for each Person, i.e., it maps every
person (ann and bob) to a vaccine (a, b, n).
Decision Tables
pDMN extends standard DMN decision tables with three
new concepts: probabilities, the new Ch(oice) hit policy, and
Type
Name Elements
Person ann, bob
Vaccine a, b, n
Function
Name Type
vaccine of Person Vaccine
Predicate
Name
Person is infected
Person contacted Person
Figure 2: Example of a pDMN glossary
quantification. We will briefly touch on each concept, and
show an example. Firstly, pDMN allows probabilities in the
cells of an output column. For example, the h1 and h2 tables
shown in Fig. 3a respectively define a probability of 0.5and
0.6to flip a coin on its head. Note that we use Yes and No to
represent true and false for predicates. In a table containing
probabilities, the output values (such as Yes) are not listed
in the rules directly, but rather in a separate row above the
rules, which contains only output values. If the conditions of
a rule are met, the probability of the output variable taking
on a specific value is equal to the value that is listed below
this output value in that particular row.
The second new concept is the Ch(oice) hit policy, which
denotes that the output values for the output variable are mu-
tually exclusive (i.e., only one can be assigned to the vari-
able). This is demonstrated in the table in Fig. 3b, which
states in its first row that an ordinary die has an equal 1/6
chance for any die value, and in its second row that a biased
die has a higher chance of resulting in six. However, because
of the Choice hit policy, the die can never e.g. be assigned
both “one” and “two” at the same time. If, for instance, the
table had the Unique hit policy, it would be possible to have
an outcome in which the die has multiple face values at once.
The third and final addition in pDMN is quantification.
For example, the Vaccine table shown in Fig. 3c expresses
that “For every Person X, there is a chance of 36% that they
have received vaccine a, a 63% chance on vaccine b, and a
1% chance of being unvaccinated.” The Xhere represents a
quantification variable of type Person. Similarly, the Infec-
tion table expresses that every person Xwho had contact
with an infected person Ycould now also be infected, de-
pending on their vaccine’s performance, or lack thereof.
Query
The Query table is the third type of table present in a pDMN
model, and is used to denote which symbols’ probability
should be calculated. Querying the probability of a predi-
cate is done by adding it to the query table, either with spe-
cific elements of a type or with a quantification variable. To
query a function, the table should contain a cell of the form
func name(arg) = val . Here too, it is allowed to write
down a specific element of a type or a quantification vari-
able. Examples of query tables are shown in Fig. 4. The ta-
ble in Fig. 4a verifies the probability of flipping two heads
and some heads with coins. Fig. 4b demonstrates querying
predicates with a specific variable value (bob), or a quantifi-
cation variable (X). In the latter case, the probability of the
predicate is calculated for every element of the type Person.
Lastly, Fig. 4c, in which we want to know the probability
that a die lands on a six, shows the querying syntax for func-
tions.
Translating pDMN to ProbLog
To practically use pDMN models, we translate them into
ProbLog. We will now go over the general translation prin-
ciples. Intuitively, every row of a U-table represents a rule in
ProbLog, with the input variables forming the body, and the
output variable forming the head. If there are multiple out-
put variables present, a rule is created for each of them. For
example, the heads table in Fig. 3a translates to the ProbLog
rules shown in (7). Note that the rows in which the output
was No are not translated, as these do not need to be explic-
itly formulated in ProbLog due to the closed world assump-
tion.
twoHeads :heads1 ,heads2 .
someHeads :heads1 ,heads2 .
someHeads :heads1 ,not(heads2 ).
someHeads :not(heads1 ),heads2 .
(7)
If the output rows of a table contain probabilities, these
are added to their respective ProbLog rules or facts. E.g., the
h1 table in Fig. 3a translates to the fact 0.5 :: heads1 .
As explained before, DMN also provides the F(irst) hit
policy. Consider again the heads table in Fig. 3a, except we
now consider it as an F-table. To translate the first hit be-
haviour to ProbLog, for any row in the table we need to
add the negation of all the previous rows to the body of
the translation. To do this, dummy variables are introduced,
representing whether a row has fired or not. The resulting
ProbLog translation for this example is shown in (8), where
r1 ,r2 and r3 represent the dummy variables.
r1 :heads1 ,heads2 .
r2 :heads1 ,not(heads2 ).
r3 :not(heads1 ),heads2 .
twoHeads :r1.
someHeads :r1.
someHeads :r2,not(r1 ).
someHeads :r3,not(r1 ),not(r2 ).
(8)
Tables with the newly introduced Ch(oice) hit policy are
translated into ProbLog’s annotated disjunctions. For exam-
ple, the table shown in Fig. 3b assigns a value to the 0-ary die
value function. In ProbLog, n-ary functions are represented
by an (n+ 1)-ary predicate, resulting in the unary die value
h1
U heads1
Yes
1 0.5
h2
U heads2
Yes
1 0.6
heads
U heads1 heads2 twoHeads someHeads
1 Yes Yes Yes Yes
2 Yes No No Yes
3 No Yes No Yes
4 No No No No
(a) Example pDMN implementation describing two coinflips.
Throwing Dice
Ch biased die value
one two three four five six
1 No 1/6 1/6 1/6 1/6 1/6 1/6
2 Yes 0.1 0.1 0.1 0.1 0.1 0.5
(b) Example of a pDMN table with the “Choice” hit policy.
Vaccine
Ch vaccine of X
a b n
1 0.36 0.63 0.01
Infection
U X contacted Y Y is infected vaccine of X X is infected
Yes
1 Yes Yes n 0.8
2 Yes Yes a 0.1
3 Yes Yes b 0.2
(c) Snippet of a pDMN model implementing infections with vaccination.
Figure 3: Snippets of various pDMN examples.
Query
twoHeads
someHeads
(a)
Query
vaccine of bob
X is infected
(b)
Query
die value = six
(c)
Figure 4: Example Query tables.
predicate:
1/6 :: die value (one ); ...; 1/6 :: die value (six )
:not(biased ).
1/5 :: die value (one ); ...; 1/2 :: die value (six )
:biased.
(9)
Types declared in the Type table in pDMN are repre-
sented by unary predicates in ProbLog, as the latter is not
a typed language. Additionally, the contents of the Elements
column are translated into facts. E.g., Person, as shown in
the Type table in Fig. 2, translates to the facts person(ann)
and person(bob). When translating a decision table con-
taining quantification, the type of the quantification vari-
able(s) is derived from the glossary, and an atom is added
to the ProbLog rule for each variable to denote its type.
For example, the pDMN model in Fig. 3c translates to the
ProbLog code shown in (10). Consider e.g. the Infection ta-
ble: it contains two quantification variables, Xand Y, both
of type Person. As such, this is denoted in the ProbLog
rules by adding two atoms to their bodies, person(X)and
person(Y), to represent the types of the variables.
person(ann).person(bob).
vaccine(a).vaccine(b).vaccine(n)
0.36 :: vaccine(X, a); 0.63 :: vaccine(X, b);
0.01 :: vaccine(X, n) :person(X).
0.8 :: infected (X) :vaccine(X, n),infected (Y),
contacted (X, Y ),person(X),person(Y).
0.1 :: infected (X) :vaccine(X, a),infected (Y),
contacted (X, Y ),person(X),person(Y).
0.2 :: infected (X) :vaccine(X, b),infected (Y),
contacted (X, Y ),person(X),person(Y).
(10)
The Query table is represented in ProbLog by query state-
ments. For every cell of the table, a new query statement is
added. For example, the three query tables shown in Fig. 4
translate to the following ProbLog statements:
query(twoH eads).
query(someHeads).
query(vaccine of P erson(bob)).
query(person is inf ected(X)).
query(die value(six)).
(11)
If no Query table is present in a pDMN model, it is as-
sumed that the probabilities of all symbols of the model
should be queried. In such a case, a ProbLog query rule is
generated for every entry in the Predicate and Function glos-
sary tables.
Implementation
To automatically translate pDMN models to ProbLog and
execute them, the translation principles described earlier
have been implemented in a solver1. This solver is largely
based on the solver which we created in earlier work for
cDMN (Aerts, Vandevelde, and Vennekens 2020), due to the
similar nature of the notations. The input for the solver is a
pDMN model in the form of a .xslx spreadsheet. Con-
cretely, the solver works in three steps.
First, it interprets all glossary tables in the spreadsheet,
beginning with the Type table. For every entry, the solver
creates internal Type objects, necessary to interpret the ar-
guments used in the Predicate and Function tables. The
solver then evaluates every decision table one-by-one, us-
ing a lex/yacc parser to parse every cell and transform
them into a pDMN expression. For example, an expres-
sion of the form “vaccine of bob” is translated into vac-
cine of person(bob)”.
Next, all decision tables, are converted into ProbLog rules
in the manner described earlier. At the same time, the Query
table is parsed and converted into ProbLog query statements.
Lastly, the generated specification is executed using
ProbLog’s Python API, after which the queried probabili-
ties are shown. In this way, the pDMN execution process
consists of a closed pipeline between pDMN modelling and
ProbLog execution.
The pDMN solver is available as a Python package, and
can be downloaded from its PyPi repository2.
Full example
In the previous sections, every example only consisted of
limited snippets of pDMN models. To give a view of what
a complete pDMN model looks like, this section shows a
concrete implementation of the well-known Earthquake ex-
ample. In this example, a house alarm can be triggered by a
burglary,by an earthquake of a certain intensity (heavy, mild
or none), or by a combination of the two. Both the burglary
and the intensities of the earthquake have a probability asso-
ciated with them. If the alarm rings, the neighbours John and
Mary both could either call the home owner, or they could
1https://gitlab.com/EAVISE/cdmn/pdmn
2https://pypi.org/project/pdmn
dismiss the alarm as incorrect and ignore it. We now want to
find out the probabilities of either neighbour calling.
The pDMN model for this example is shown in Fig. 5,
and consists of the glossary tables, five decision tables and
a query table. In the glossary tables, we first introduce two
types, Person and Intensity, which respectively represent the
neighbours and the earthquake intensities. In the Predicate
table, we declare four predicates: the 0-ary predicates bur-
glary,alarm and anycalls, and the unary predicate Person
calls. To denote the intensity of the earthquake, we make
use of the 0-ary function earthquake, which will thus either
be heavy,mild, or none.
Of the five decision tables, two are straightforwardly used
to set the probabilities of a burglary and the earthquake in-
tensities. As these concepts do not depend on anything, their
decision tables contain no input columns. The Alarm table
contains a rule for every possible combination of burglary
and earthquake to represent the probability of the alarm trig-
gering. Note that it does not contain a rule in which neither a
burglary or an earthquake take place, as the alarm will never
trigger in such a situation, thus allowing us to leave out that
rule. The fourth decision table, named Calls, expresses that
every person Xhas a certain probability to call the home
owner, depending on whether the alarm rings. Finally, the
last decision table defines anycalls = Yes whenever any per-
son Xcalls.
To find the probability of each neighbour calling sep-
arately, and the probability of either of them calling, the
Query table is added to the model in order to finish it. Trans-
lating this model to ProbLog using the pDMN solver results
in the following code:
%facts
intensity(heavy).intensity (mild ).intensity (none).
person(john).person(mary ).
%Burglary
0.7 :: burglary.
%Earthquake
0.01 :: earthquake(heavy); 0.19 :: earthquake(mild );
0.8 :: earthquake(none).
%Alarm
0.9 :: alarm :burglary,earthquake(heavy).
0.85 :: alarm :burglary,earthquake(mild ).
0.8 :: alarm :burglary,earthquake(none ).
0.1 :: alarm :not(burglary),earthquake(mild ).
0.3 :: alarm :not(burglary),earthquake(heavy).
%Calls
0.8 :: person calls (X) :alarm ,person(X).
0.1 :: person calls (X) :not(alarm ),person(X).
%anycalls
anycalls :person calls (X).
query(person calls (X)).
query(anycalls).
We can also use the pDMN solver to execute the example,
Type
Name Elements
Person john, mary
Intensity heavy, mild, none
Predicate
Name
burglary
alarm
Person calls
anycalls
Function
Name Type
earthquake Intensity
Burglary
U burglary
Yes
1 0.7
Earthquake
Ch earthquake
heavy mild none
1 0.01 0.19 0.8
Calls
U alarm X calls
Yes
1 Yes 0.8
2 No 0.1
Alarm
U burglary earthquake alarm
Yes
1 Yes heavy 0.9
2 Yes mild 0.85
3 Yes none 0.8
4 No mild 0.1
5 No heavy 0.3
anycalls
U X calls anycalls
1 Yes Yes
Query
X calls
anycalls
Figure 5: Full pDMN model for the Earthquake example
by running ProbLog directly. This results in the following
output:
>>> pdmn Examples.xslx −x −n ”Earthquake”
{person calls(mary): 0.501765, person calls(john): 0.501765,
anycalls: 0.6319415}
Conclusion
This paper presents a preliminary version of pDMN, a no-
tation for Probabilistic Logic Programming based on the
DMN standard, which aims to combine ProbLog’s ex-
pressiveness together with DMN’s readability and user-
friendliness. It extends DMN with probabilities, predicates,
quantification, and a new hit policy to represent annotated
disjunctions. We lay out the general translation principles
of converting pDMN into ProbLog code, allowing for the
execution of the pDMN models. These principles have also
been implemented in an automatic conversion tool, which is
available for general use. In future work, we plan on further
extending the notation (e.g., with support for more hit poli-
cies), formalizing the complete pDMN semantics, extending
the DRD to support probabilities and making a user-friendly
interface for the system.
Acknowledgements
This research received funding from the Flemish Govern-
ment under the “Onderzoeksprogramma Artifici¨ele Intelli-
gentie (AI) Vlaanderen” programme.
References
Aerts, B.; Vandevelde, S.; and Vennekens, J. 2020. Tack-
ling the DMN challenges with cDMN: A tight integration of
DMN and constraint reasoning. volume abs/2005.09998 of
Proceedings of RuleML+RR 2020, 23–38. Springer Interna-
tional Publishing. ISBN 978-3-030-57977-7.
De Raedt, L.; Kimmig, A.; and Toivonen, H. 2007. ProbLog:
A Probabilistic Prolog and Its Application in Link Discov-
ery. In IJCAI, volume 7, 2462–2467. Hyderabad.
Gutmann, B.; Thon, I.; and De Raedt, L. 2011. Learning
the Parameters of Probabilistic Logic Programs from Inter-
pretations. In Gunopulos, D.; Hofmann, T.; Malerba, D.;
and Vazirgiannis, M., eds., Machine Learning and Knowl-
edge Discovery in Databases, 581–596. Berlin, Heidelberg:
Springer Berlin Heidelberg. ISBN 978-3-642-23780-5.
Object Management Group. 2019. Decision model and no-
tation. URL http://www.omg.org/spec/DMN/.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
This paper describes an extension to the Decision Model and Notation (DMN) standard, called cDMN. DMN is a user-friendly, table-based notation for decision logic. cDMN aims to enlarge the expressivity of DMN in order to solve more complex problems, while retaining DMN’s goal of being readable by domain experts. We test cDMN by solving the most complex challenges posted on the DM Community website. We compare our own cDMN solutions to the solutions that have been submitted to the website and find that our approach is competitive, both in readability and compactness. Moreover, cDMN is able to solve more challenges than any other approach.
Conference Paper
Full-text available
ProbLog is a recently introduced probabilistic extension of the logic programming language Prolog, in which facts can be annotated with the probability that they hold. The advantage of this probabilistic language is that it naturally expresses a generative process over interpretations using a declarative model. Interpretations are relational descriptions or possible worlds. This paper introduces a novel parameter estimation algorithm LFI-ProbLog for learning ProbLog programs from partial interpretations. The algorithm is essentially a Soft-EM algorithm. It constructs a propositional logic formula for each interpretation that is used to estimate the marginals of the probabilistic parameters. The LFI-ProbLog algorithm has been experimentally evaluated on a number of data sets that justifies the approach and shows its effectiveness.
Conference Paper
We introduce ProbLog, a probabilistic extension of Prolog. A ProbLog program defines a distribution over logic programs by specifying for each clause the probability that it belongs to a randomly sam- pled program, and these probabilities are mutually independent. The semantics of ProbLog is then de- fined by the success probability of a query, which corresponds to the probability that the query suc- ceeds in a randomly sampled program. The key contribution of this paper is the introduction of an effective solver for computing success probabili- ties. It essentially combines SLD-resolution with methods for computing the probability of Boolean formulae. Our implementation further employs an approximation algorithm that combines iterative deepening with binary decision diagrams. We re- port on experiments in the context of discovering links in real biological networks, a demonstration of the practical usefulness of the approach.