Available via license: CC BY 4.0

Content may be subject to copyright.

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, quantiﬁcation, 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 ﬂexible 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 difﬁcult 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 Artiﬁcial

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 brieﬂy 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 deﬁned 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 ﬁrst table is applicable.

The table’s hit policy, as denoted in the top-left corner,

further deﬁnes 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 ﬁrst

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 ﬁrst 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 1−Pfrespectively. 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 PiPi≤1. 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 satisﬁes 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

f∈M

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 1−Pfotherwise. 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 ﬁrst 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

ﬁxed 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

quantiﬁcation. We will brieﬂy 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 deﬁne a probability of 0.5and

0.6to ﬂip 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 speciﬁc 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 ﬁrst 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 ﬁnal addition in pDMN is quantiﬁcation.

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

quantiﬁcation 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-

ciﬁc elements of a type or with a quantiﬁcation 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 speciﬁc element of a type or a quantiﬁcation vari-

able. Examples of query tables are shown in Fig. 4. The ta-

ble in Fig. 4a veriﬁes the probability of ﬂipping two heads

and some heads with coins. Fig. 4b demonstrates querying

predicates with a speciﬁc variable value (bob), or a quantiﬁ-

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 ﬁrst 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 ﬁred 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 coinﬂips.

Throwing Dice

Ch biased die value

one two three four ﬁve 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 quantiﬁcation, the type of the quantiﬁcation 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 quantiﬁcation 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 speciﬁcation 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

ﬁnd out the probabilities of either neighbour calling.

The pDMN model for this example is shown in Fig. 5,

and consists of the glossary tables, ﬁve decision tables and

a query table. In the glossary tables, we ﬁrst 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 ﬁve 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 deﬁnes anycalls = Yes whenever any per-

son Xcalls.

To ﬁnd 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 ﬁnish 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,

quantiﬁcation, 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 Artiﬁci¨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/.