=Paper=
{{Paper
|id=Vol-3078/paper-29
|storemode=property
|title=Probabilistic logic programming in 2P-KT
|pdfUrl=https://ceur-ws.org/Vol-3078/paper-29.pdf
|volume=Vol-3078
|authors=Jason Dellaluce,Roberta Calegari,Giovanni Ciatto
|dblpUrl=https://dblp.org/rec/conf/aiia/DellaluceCC21
}}
==Probabilistic logic programming in 2P-KT==
https://ceur-ws.org/Vol-3078/paper-29.pdf
Probabilistic logic programming in 2P-KT
Jason Dellaluce1 , Roberta Calegari2 and Giovanni Ciatto1
1
Dipartimento di Informatica – Scienza e Ingegneria (DISI), Alma Mater Studiorum—Università di Bologna, Italy
2
Alma Mater Research Institute for Human-Centered Artificial Intelligence, Alma Mater Studiorum—Università di
Bologna, Italy
Abstract
The work introduces an elastic and platform-agnostic approach to probabilistic logic programming aimed
at linking this paradigm with modern mainstream programming platforms, thus widening its usability
and portability (e.g. towards the JVM, Android, Python, and JavaScript platforms). We design our solution
as an extension of the 2P-Kt symbolic AI ecosystem to inherit its multi-platform and multi-paradigm
nature.
Keywords
probabilistic logic programming, symbolic AI, 2P-Kt
1. Introduction
Artificial Intelligence (AI) is progressively conquering the software industry to become one
of the most pivotal fields, with a fast-paced evolution of challenges and requirements that
existing technologies often fail to match. Accordingly, the increasing demand for transparent
and pervasive intelligence is opening new horizons for logic programming (LP) and symbolic
AI approaches [1, 2, 3]. However, logic-based approaches alone are often not suitable to
be integrated with present-day planning and learning workflows, which natively deal with
uncertainty and probabilistic decision-making [4, 5, 6].
Probabilistic logic programming (PLP) [7, 8] is a research field that investigates the combina-
tion of LP with the probability theory. There, theories may contain facts or rules enriched with
probabilities, which may, in turn, be queried by the users to investigate not only which state-
ments are true or not, but also under which probability. To support this behaviour, probabilistic
solvers leverage ad-hoc resolution strategies explicitly taking probabilities into account. This
makes them ideal to deal with uncertainty and the complex phenomena of the physical world.
It is thus unsurprising that Bayesian and data-driven AI, other than cyber physical systems
(CPS), are among the areas which would benefit the most from the development of robust and
interoperable PLP technologies.
State-of-the-art PLP solutions [9, 10] have reached a considerable level of maturity and theo-
retical reach. Not only has exact probabilistic resolution been reified into actual programming
AIxIA 2021 Discussion Papers
" jason.dellaluce@studio.unibo.it (J. Dellaluce); roberta.calegari@unibo.it (R. Calegari); giovanni.ciatto@unibo.it
(G. Ciatto)
~ http://robertacalegari.apice.unibo.it (R. Calegari); https://about.me/gciatto (G. Ciatto)
0000-0003-3794-2942 (R. Calegari); 0000-0002-1841-8996 (G. Ciatto)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
languages, but also approximate resolution, and learning of probabilities from data. However,
existing technologies currently rely upon monolithic runtimes, often targeting single platforms
or having inconvenient constraints and dependencies [11, 12]—limiting their interoperability
and portability with mainstream programming platforms. This follows a general tendency of
logic-based technologies, which are often constructed as technological silos – being so opti-
mised for performance and correctness while being poorly interoperable among each other –
targetting the LP community alone.
To overcome such tendency towards the creation of isolated monoliths, the notion of logic
ecosystem [13] has recently been proposed. There, the authors argue that LP facilities – e.g.
knowledge representation, unification, clauses indexing, resolution, etc. – should be made
independently available to the widest possible audience—there including mainstream developers
and logic programmers, and all major programming platforms. Most notably, LP facilities
should not only be exploitable as stand-alone applications (e.g. Prolog interpreters) but also
(and foremost) as libraries—thus enabling re-use at the mechanism level. In this perspective,
logic ecosystems consist of extensible technological frameworks where single LP facilities can be
incrementally constructed on top of the previous ones, other than used—either individually or
composedly. Notably, the authors in [13] prose 2P-Kt as the technological reification of a logic
ecosystem. Unfortunately, however, PLP is not among the LP facilities currently supported by
2P-Kt.
Accordingly, in this work we propose an extension of the 2P-Kt ecosystem aimed at supporting
PLP via an ad-hoc implementation of the ProbLog language. The proposed implementation
aims at overcoming the interoperability and portability issues of state-of-the-art PLP solutions.
In fact, as part of the 2P-Kt ecosystem, our ProbLog implementation can be compiled/run on
several strategic platforms, other than used as a library in multiple programming languages. Our
solution provides PLP support on top of standard Prolog solvers. Hence, as a side contribution,
we provide insights about how a ProbLog solver can be realised on top of Prolog’s SLD(+NF)
resolution principle.
It is worth highlighting how our current goal is to provide a usable and functioning PLP code
base, initially supporting only the fundamental features, and aiming to be flexible for future
growth. Outperforming existing solutions is not amongst our primary concerns. Conversely,
we aim to open the horizons for wider adoption of LP and PLP, by favouring portability and by
making it easier to exploit from outside the LP realm. In this regard, we describe a number of
examples aimed at demonstrating the usability and portability of our PLP solution on multiple
runtimes and programming platforms.
2. Background
A variety of research contributions exploring the field of PLP exist in the logic programming
literature. Proposals often differ for their semantics or syntaxes, or for the way they perform
probabilistic reasoning [14, 11, 9, 15].
Roughly speaking, semantics are concerned with endowing probabilistic programs with
meaning. Sato’s distribution semantics (DS) [16, 17] is one of the most prominent approaches
for the combination of logic programming and probability theory. There, a probabilistic logic
program is interpreted as a concise description of many possible worlds, and the probabilities
of queries are solved by summing up their probability in each possible world.
Languages adhering to the distribution semantics may in turn differ in how they represent
clauses, and their probabilities. A successful approach in this context is LPAD (Logic Programs
with Annotated Disjunctions), where clauses admit disjunctions of atoms in their heads, and each
atom is labelled with a probability value. In other words, LPAD is a special notation supporting
the definition of non-binary probabilistic distributions over clauses and facts. However, in
practice, probabilistic logic programs may support a certain evidence [18] to be provided via
unannotated fact/rules which are known to be true, even though they may be defined over
some probability distribution.
Finally, concerning probabilistic reasoning, PLP generally supports reasoning tasks, and each
of them has been richly documented in the literature [19]. Broadly speaking, options range
from exact to approximate—the former being more precise and computationally demanding,
while the latter being more affordable at the price of lower precision. In the remainder of this
paper we focus on exact methods only.
Along this line, a common strategy is to rely upon knowledge compilation [20] to make
probabilistic reasoning efficient—i.e., by transforming logic formulæ into simpler (more tractable)
forms. Binary decision diagrams (BDD) [21, 22] and their variants/extensions are commonly
exploited to serve this purpose [23, 24].
2.1. State-of-the-art technologies for PLP
A number of programming languages follow the LPAD approach over the DS, there including
ProbLog and cplint. They both rely on (some variant of) BDD to support probabilistic
reasoning. Within the scope of this paper, we consider them as interesting solutions for PLP as
they come with some actually usable technology. In the reminder of this section, we briefly
analyse ProbLog and cplint from a technological perspective.
ProbLog. ProbLog [9] is a probabilistic programming language providing PLP support on
top of Prolog. We appreciate the simplicity of the language and the high compatibility with
traditional Prolog—hence why we target a ProbLog extension for 2P-Kt. ProbLog, in particular,
leverages upon a number of aspects of Prolog’s operation to attain PLP support. First, it relies
on knowledge compilation of annotated facts into ordinary Prolog clauses. Then, it exploits
Prolog’s backtracking mechanism to enumerate the possible worlds in which a query is true.
These are called ‘explanations’ in PLP’s nomenclature, while they are ordinary solutions in
the eyes of a Prolog solver. Finally, ProbLog attempts to iteratively build a BDD as part of
the resolution process, in order to keep the problem of computing the probability of a query
tractable. The Prolog solvers’ dynamic KB are used as ancillary data stores in the meanwhile.
Once all the possible worlds have been enumerated, the resulting BDD is fully navigated to
efficiently compute the probability of the query.
Currently, the ProbLog project consists of a Python codebase, depending on a number of
native libraries and tools—such as the YAP Prolog technology [25]. Such technological choices
limit the portability of ProbLog outside the scope of the major desktop operative systems (e.g.
Windows, Linux, or Mac OS). Notably, this issue is mitigated by the existence of a publicly-
available Web application letting users experiment ProbLog from their browsers. In any case,
to the best of our understanding of the ProbLog’s documentation and source code, ProbLog is
mainly intended as a stand-alone command-line application and interpreter, and its usage as a
library is not explicitly supported.
cplint. The cplint system (CPLogic INTerpreter) [10] applies knowledge compilation to
logic programs annotated à la CP-Logic [26]. Notably, it compiles probabilistic clauses into
Multivalued Decision Diagrams (MDDs) [27], an extension of BDDs. Thus, differently from
ProbLog, the random variables corresponding to logic clauses can be multi-valued. Furthermore,
cplint’s probabilistic programs support negated atoms.
cplint leverages upon a Prolog meta-interpreter to solve probabilistic queries. Similarly to
ProbLog, it keeps track of the solutions encountered during resolution, while simultaneously
building a MDD aimed at leter being able to draw probabilities.
Currently, the cplint project consists of a Prolog codebase targetting the SWI-Prolog [28]
platform. Such technological choices limit the portability of cplint on platforms for which
SWI-Prolog is not available, or platforms that are poorly interoperable with (SWI-)Prolog—e.g.
Android, the JVM or iOS. Notably, this issue is mitigated by the existence of a publicly-available
Web application letting users experiment cplint from their browsers. In any case, to the best
of our understanding of its documentation and source code, cplint is mainly intended as a
stand-alone command-line application and interpreter, or as a Prolog library.
2.2. Logic Ecosystems and 2P-Kt
The current practice of logic-based technologies (LBT) follows a tendency where software
contributions are constructed as extensions or on top of the Prolog language, often on native
(i.e. based on C or C++) technologies. Such a tendency has pushed the LP community towards a
situation where tools consist of poorly interoperable technological silos, where: (i) logic facilities
(e.g. unification; clauses storage, indexing, or retrieval; resolution, etc.) are not adequately
separated, and can only be exploited by means of Prolog, (ii) usage of logic facilities must
step through a stand-alone application (commonly, either graphical or command-line), as they
are not available “as a library” to other programming platforms (iii) the portability of LBT
technologies is constrained on the platforms the underlying Prolog system supports.
To overcome such issues the 2P-Kt technology has been recently proposed in [13], along
with the notion of logic ecosystem. There 2P-Kt is considered as an ecosystem of loosely
coupled modules, each one dedicated to a single logic facility. Hence, overall, it consists of a
collection of logic facilities, exposed to the developers as multi-platform libraries—and, possibly,
as stand-alone applications as well. There, multi-platform support aims at letting mainstream
programming platforms benefit from the sole logic facilities they need, natively—and without
having to interact with a full fledged Prolog system.
Arguably, multi-platform support is fundamental to let researchers and practitioners from
the many branches of computer science and artificial intelligence benefit from LBT. Along this
line, we believe logic facilities – such as probabilistic resolution – should be exploitable on
mainstream programming platforms and languages – e.g. JVM, Python, JavaScript, etc. – to ease
the exploitation of LP for the niches by which those platforms and languages are used the most.
On the long run, for instance, we hope that bringing LP on Python will ease its hybridisation
with data science, while bringing it on JavaScript will ease its hybridisation with the Web, and
so on.
Accordingly, 2P-Kt currently explicitly targets the Kotlin, Android, JVM, and JavaScript
platforms, while other platforms – such as iOS and Python – are going to be supported soon,
thanks to the multi-platform programming facilities offered by Kotlin1 . Of course, we acknowl-
edge that different languages and platforms may follow different conventions and paradigms.
Hence, multi-platform must not be realised via mere cross-compilation on several platforms,
but rather ad-hoc software layers should be provided to harmonise LP to the target platforms,
at the paradigm level (cf. [29]).
2P-Kt currently focuses on supporting knowledge representation and automatic reasoning
via logic programming. The modular, unopinionated architecture of 2P-Kt is deliberately aimed
at supporting and encouraging extensions towards other sorts of symbolic AI systems than
Prolog—including PLP, which is currently missing. Accordingly in the following, we discuss
how a module for ProbLog can actually be designed and realised to enrich the 2P-Kt ecosystem.
3. Design of Probabilistic Solver Module
Here we discuss how the 2P-Kt ecosystem can be enriched to support PLP. In particular, our
goal is to add two major facilities to the ecosystem, namely: (i) a general-purpose API for
probabilistic resolution, and (ii) a purpose-specific API for ProbLog-like resolution. Of course,
while pursuing this purpose, the underlying technical requirement is to re-use the pre-existing
facilities offered by 2P-Kt as much as possible. This includes terms, clauses, and theories
representation, as well as Prolog’s SLDNF resolution.
Accordingly, as depicted in Fig-
ure 1, PLP support is injected into utils
the ecosystem via multiple self- dsl-core core serialize-core parser-core
contained and inter-dependent mod- dsl-unify unify parser-jvm parser-js
ules, each one representing a con- dsl-theory theory serialize-theory parser-theory
tribution of our proposal. Arrows
bdd dsl-solve solve oop-lib
indicate direct dependencies from Legend
io-lib module implementation
one module to another. Of course, solve-plp
solve-streams solve-classic
root depends on
dependencies are transitive, mean- solve-problog
uses
api only
utility
ing that each module inherits (and
ide-plp ide repl
can therefore exploit) all the facili- Figure 1: Architectural overview of our PLP and ProbLog
ties carried by the other modules it modules, and their role within the 2P-Kt ecosys-
depends upon, either directly or in- tem
directly. Notably, PLP related mod-
ules are: :bdd, :solve-plp, :solve-problog, and :ide-plp.
The :bdd module represents our proposal for the binary decision diagram manipulation
library. This module is purely self-contained, in the sense that it does not rely upon any external
1
https://kotlinlang.org/docs/mpp-supported-platforms.html
facility to support BDD. Rather, it consists of a pure Kotlin solution, which therefore puts no
additional constraint on the platforms targetted by 2P-Kt. It is worth noting that, with such a
choice, we intend to promote the usage of the library as a lean external dependency on other
projects as well.
The :solve-plp module is meant to bundle all the entities and traits that are common to
any potential implementation of solvers for the PLP paradigm. In other words, it is where our
goal (i) is realised. This is a purely abstract module, that only provides API, interfaces and
classes on which multiple PLP solver implementations can rely upon. Notable, this module
depends on 2P-Kt’s :solve module, which provides common abstractions for logic solvers
and fixes their API, in order to keep them interoperable. In other words, we model probabilistic
logic solvers as a direct subset of logic solvers.
The :solve-problog module contains the actual implementation of the PLP solver sup-
porting the ProbLog language. In other words, this is where our goal (ii) is realised. As ProbLog
solvers will be particular cases of probabilistic solvers, the :solve-problog module depends
on the abstractions of :solve-plp and it is compliant to them. The other fundamental (and in-
direct) dependency is the :bdd module, which is used for manipulating binary decision diagrams
during probabilistic logic goal resolution. Additionally, it also depends on :solve-classic—
as ProbLog solvers will exploit ordinary Prolog resolution behind the scenes. Further details
about the inner design and functioning of this module are discussed in the remainder of this
section, and represent the main contribution of this paper.
Finally, the :ide-plp module implements a stand-alone graphical application based on
JavaFX, aimed at letting 2P-Kt users practice with ProbLog via an integrated environment.
3.1. Design Rationale
Figure 3a provides an overview of the overall design of our :solve-problog module. Overall,
the module aims at providing a notion of ProbLog solver as a particular case of logic solvers. As
any other sort of solver in 2P-Kt, ProbLog solvers accept users’ queries as inputs – consisting of
(possibly partially instantiated) logic atoms – and produce a multitude of solutions as outputs—
consisting of variable assignments and probabilities. Notably, solutions are computed against a
ProbLog knowledge base, which, in practice, consists of a Prolog theory with annotated clauses.
To perform probabilistic resolution, each ProbLog solver relies on a Prolog solver behind
the scenes. The Prolog solver expects the probabilistic theory to be compiled into an ordinary
Prolog theory aimed at constructing a BDD as the resolution process proceeds. In this phase,
each probabilistic clause of the form 𝑝::Head :- Body is transformed into and ordinary
Prolog clause of the form prob(Explanation, Head) :- Body2, where Explanation
represents the BDD to be constructed out of the probability 𝑝 and Body , whenever the proba-
bility of some sub-goal Head must be computed. A number of ad-hoc meta-predicates can be
exploited in the clauses’ bodies to serve the purpose of incrementally building a BBD. Under
such assumption, the underlying Prolog solver may answer to probabilistic queries of the form
prolog_query(-Probability, +Goal). More precisely, the prolog_query/2 predicate
is in charge of (i) computing all possible Prolog solutions for Goal and (ii) constructing their
specific BDD, then (iii) merging them into a unique BDD aimed at computing the overall
Probability of Goal.
Figure 2: Architecture of our ProbLog solver (left), with a focus on the KB recompilation step (right).
male(john).
0.80::male(mike).
0.65::female(anna).
0.60::parent(mike, john).
0.95::father(X, Y) :- male(X), parent(X, Y).
Knowledge
Compilation
Engine prob(E, male(john)) :- expl_build(E, 1.0).
prob(E, male(mike)) :- expl_build(E, 0.8).
prob(E, female(anna)) :- expl_build(E, 0.65).
prob(E, parent(mike, john)) :- expl_build(E, 0.6)
prob(E, father(X, Y)) :-
expl_build(E0, 0.95),
prob(E1, male(X)), prob(E2, parent(X,Y)),
expl_and(E, [E0, E1, E2]).
(b) Example of KB recompilation
(a) Architecture and information flow of our
ProbLog solver
To sum up, a ProbLog solver is a bi-directional façade among the user and the underlying
Prolog solver. It takes care of translating probabilistic theories and queries in Prolog form, and
Prolog solutions back into probabilistic form. Given this overview, the design of our PLP solver
is built on top of three interconnected components: (i) a knowledge compilation engine, (ii) a
library of meta-predicates, and (iii) a solver piloting engine. In the remainder of this section,
we delve into the details of these components.
3.1.1. Knowledge Compilation Engine.
Each ProbLog solver of ours is backed by a Prolog solver aimed at computing an explanation
(i.e. a BDD) for each possible probabilistic query. However, the Prolog solver can only deal
with ordinary logic theories consisting of unannotated Horn clauses. Accordingly, knowledge
compilation engine is the architectural component in charge of converting annotated probabilistic
theories provided by the ProbLog users into ordinary Prolog users. It does so by applying a
number of rewriting rules to the probabilistic theory:
[[𝑓 (𝑋¯ ).]] −→ ‘prob(E, 𝑓 (𝑋 ¯ )) :- expl_build(E, 1.0).’
[[𝑝::𝑓 (𝑋 ¯ ).]] −→ ‘prob(E, 𝑓 (𝑋 ¯ )) :- expl_build(E, 𝑝).’
¯ ¯ ¯
[[𝑝::𝑓 (𝑋 ) :- 𝑏1 (𝑋 1 ), . . . , 𝑏𝑛 (𝑋 𝑛 ).]] −→ ‘prob(E, 𝑓 (𝑋 ¯ )) :- expl_build(E0 , 𝑝),
prob(E1 , 𝑏1 (𝑋 ¯ 1 )), . . . , prob(E𝑛 , 𝑏𝑛 (𝑋 ¯ 𝑛 )),
expl_and(E, [E0 , E1 , . . . , E𝑛 ]).’
¯ 𝑚 ) :- ¯𝑏.]]
¯ 1 ), . . . , 𝑝𝑚 ::𝑓𝑚 (𝑋
[[𝑝1 ::𝑓1 (𝑋 −→ ¯ 1 ) :- ¯𝑏.]]. . . . [[𝑝𝑚 ::𝑓𝑚 (𝑋
‘[[𝑝1 ::𝑓1 (𝑋 ¯ 𝑚 ) :- ¯𝑏.]].’
There, the first rule handles the case of unannotated facts (a.k.a. evidence). They are consid-
ered as certain facts—i.e. facts having 1.0 as probability. The second rule handles the case
of annotated facts having a probability 𝑝 ∈ [0, 1] ⊂ R. Finally, the third rule handles the
case of annotated rules, whereas the last rule handles the case of probabilistic clauses having
annotated disjunctions in their heads. Because of space limitations, we here omit other rules
aimed at handling conjunction, negation, or implication in clauses’ bodies. In all such cases,
𝑓, 𝑓1 , . . . , 𝑓𝑚 , 𝑏1 , . . . , 𝑏𝑛 denote logic predicates’ symbols of arbitrary arity, 𝑝, 𝑝1 , . . . , 𝑝𝑚 are
real numbers in the [0, 1] range denoting probability values, 𝑋 ¯,𝑋 ¯ 1, . . . , 𝑋 ¯ 𝑚 denote tuples
¯ 𝑛, 𝑋
of logic terms of arbitrary length, while ¯𝑏 denote a conjunction of logic atoms involving zero,
one, or more atoms.
Figure 3b exemplifies the knowledge compilation engine in action on a simple probabilistic
theory. As the reader may notice, the resulting Prolog theory consists of a number of rules
of the form prob(-Explanation, +Goal), aimed at computing the an Explanation for a
particular Goal. The bodies of such rules may exploit a number of built-in meta-predicates
aimed at iteratively constructing an explanation out of simpler explanations.
3.1.2. Library of Meta-Predicates
A fundamental prerequisite for the knowledge compilation engine to work is that BDD can be
suitably represented in logic, as explanations, at the end of the day, consist of BDD instances.
To address such a need, in our :solve-plp module, we define a whole new class of logic
constants aimed at referencing particular instances of BDD. So BDD instances – which are
in-memory data structures in Kotlin’s object-oriented world – are treated as constants in the
logic realm. In this way, BDD instances can be carried around, constructed, or composed as part
of resolution, and possibly bound to variables such as Explanation or E, E1 , . . . , E𝑛 mentioned
above.
To make it possible to create and compose BDD from a logic program, we introduced a
library of Prolog-compliant meta-predicates, each one implementing a specific task supporting
ProbLog-like inference. Of course, as such meta-predicates operate on data structures that lay
outside the logic realm, they cannot be defined in Prolog. Accordingly, through the generator
mechanism of 2P-Kt (cf. [30]), we are able to implement the behaviour of these meta-predicates
with object-oriented Kotlin code. At the functional level, however, the behaviour of most
relevant meta-predicates can be described as follows:
expl_and(-E, [+E 1 , ..., +E 𝑛 ]) | provided that variables E1 , . . . , E𝑛 are bound to as
many constants representing 𝑛 ≥ 2 BDD, this meta-predicate merges them all into a new
BDD representing their conjunction, and binds a constant to E referencing that BDD
expl_or(-E, [+E 1 , ..., +E 𝑛 ]) | like the above, but for disjunction
expl_not(-E, +E ′ ) | like the above, but for negation
expl_build(-E, +P ) | provided that variable E is bound to a number representing a valid
probability value, this meta-predicate creates a bare new, minimal BDD out of that
probability value, and binds a constant to E referencing that BDD
1 0.6::edge(1,2).
2 0.1::edge(1,3).
3 0.4::edge(2,5).
0.3
4 0.3::edge(2,6). 3 4 0.8
5 0.3::edge(3,4).
0.1
0.4 5
6 0.8::edge(4,5). 0.2
1 0.6
7 0.2::edge(5,6).
8 2 0.3 6
9 path(X,Y) :- edge(X, Y).
10 path(X,Y) :- edge(X, Z),Y \== Z,path(Z, Y).
Figure 4: Example of Probabilistic Graph Modeling: ProbLog syntax (left) and corresponding graph
(right)
The prolog_query(-Probability, +Goal) meta-predicate then closes the loop, acting
as the main entry point for probabilistic resolution in Prolog. The first argument represents
the numeric probability of the goal being queries, and the second argument is the goal itself.
The probability argument can either be an input number or an output variable. If the goal
argument is a non-ground term, its variables are substituted for each solution found by the
solver. Of course, despite the prolog_query/2 meta-predicate simulates a lazy enumeration
of solutions via backtracking, the whole set of solutions must be eagerly computed behind the
scenes, in order to compute probabilities. Hence, queries having an infinite proof tree may lead
to a situation where the solver gets stuck or saturates the available memory even before the
first solution is presented to the user.
3.1.3. Solver Piloting Engine
The last piece needed by our system to fully implement a PLP inference solver is a component
aimed at hiding the presence of an underlying Prolog solver. We call this component the solver
piloting engine.
This component is responsible for accepting LP and PLP queries from clients, properly
configuring the underlying LP solver, piloting it to infer the solutions, extracting the probability
values and presenting the results. As a matter of fact, it represents the presentation layer of our
system. Notably, solver configurations are handled at this level, and the component is capable
of passing both LP and PLP queries to the inner solver on demand.
Also, the solver piloting engine recompiles queries and goals bidirectionally to be compli-
ant with the meta-predicates semantics of our solution. For instance, our solution assumes
that each query is represented via the prob_query/2 predicate. Considering the example
in Figure 4, a query such as path(From, To) would be transformed in prob_query(P,
path(From, To)). Once solutions are found, the solver piloting engine extracts the two terms
P and path(From, To), and presents their values to the clients in the correct format.
4. Multi-platform Support Demonstration
Here we provide a demonstration of our ProbLog module for 2P-Kt. More precisely, we show
how our solution supports: (i) a wide gamma of usage modalities – ranging from issuing ProbLog
(a)
(b)
0.1::edge(1, 3) 0.3::edge(3, 4) 0
0.8::edge(4, 5)
0.6::edge(1, 2)
0.3::edge(2, 6)
0.1::edge(1, 3) 0.4::edge(2, 5)
0.4::edge(2, 5) 0.3::edge(2, 6) 0.2::edge(5, 6)
1
0.3::edge(2, 6)
Figure 5: 2P-Kt PLP IDE (5a) and corresponding BDD built by the solver (5b)
queries via a GUI to usage “as a library” –, and (ii) a number of mainstream programming
platforms and languages.
In particular, our demonstration works by solving a probabilistic query against the trivial
probabilistic logic program from Figure 4 – where a probabilistic graph is modelled in ProbLog –,
enumerating all possible solutions and interpreting them as possible paths and their probabilities.
We perform this action multiple times, and in several ways, each time showing a different usage
modality. Notably, we exemplify the usage ProbLog as a JavaFX-based graphical application,
other than as a Kotlin, Java, Android, Python, and JavaScript library.
Figure 5 shows 2P-Kt’s IDE, tailored on our ProbLog module. The whole demonstration can
be reproduced by downloading the PLP IDE executable (2p-ide-plp-X.Y.Z-redist.jar)
from https://github.com/tuProlog/2p-kt/releases/latest. The IDE accepts ProbLog theories as
input, either from a file or as bare textual input, and it is designed to resemble a simple text editor.
One can issue a query and submit it to the underlying ProbLog solver. Once computed, solutions
to that query are shown in a list view. Also, a tab view enables the inspection of the internal
state of the solver. Figure 5b depicts the BDD used by our ProbLog solver behind the scenes
while computing the probability of solution path(1, 6). Notably, BDD representation is yet
another function of our IDE, attained via an automatically-generated DOT [31] specification.
Figure 6 shows how our ProbLog module can be used “as a library” on multiple programming
platforms and languages, namely Kotlin (for both the JVM and Android platforms), Python,
and JavaScript. The Java language is supported as well, despite not being depicted in the
figure. The similarity among the code snippets is deliberate and aimed at stressing how the
many 2P-Kt ports share a common design and API, despite the slight syntactical differences
characterising the target language. The conceptual flow is analogous: (i) a ClausesParser is
instantiated out of the set of ProbLog predicates (i.e. Prolog’s standard predicates, plus ::/2),
(ii) it is then used to parse the ProbLog program from Figure 4, (iii) the resulting Theory is
used as static KB of a newly instantiated ProbLog Solver, (iv) the query path(From,To) is
1 // Kotlin
2 val clausesParser = ClausesParser.withOperators(PROBLOG_OPERATORS)
3 val probabilisticTheory = clausesParser.parseTheory("⟨theory from fig. 4⟩")
4 val problogSolver = Solver.problog.solverWithDefaultBuiltins(staticKb = probabilisticTheory)
5 val goal = Struct.of("path", Var.of("From"), Var.of("To"))
6 for (solution in problogSolver.solve(goal, SolveOptions.allLazily().probabilistic()))
7 if (solution.isYes)
8 println("yes: ${solution.solvedQuery} with probability ${solution.probability}")
1 # Python
2 probabilisticTheory = parse_theory("⟨theory from fig. 4⟩", PROBLOG_OPERATORS)
3 problogSolver = problog_solver(static_kb=probabilisticTheory)
4 query = struct(’path’, var(’From’), var(’To’))
5 for solution in problogSolver.solve(query, solve_options(lazy=True, probabilistic=True)):
6 if solution.is_yes:
7 print(f"yes: {solution.solved_query} with probability {probability(solution)}")
1 // JavaScript
2 let clausesParser = ClausesParser.Companion.withOperatorSet(PROBLOG_OPERATORS)
3 let scope = Scope.Companion.empty()
4 let probabilisticTheory = clausesParser.parseTheory("⟨theory from fig. 4⟩")
5 let problogSolver = Solver.Companion.problog.solverWithDefaultBuiltinsAndStaticKB(probabilisticTheory)
6 let query = scope.structOf("path", [scope.varOf("From"), scope.varOf("To")])
7 let options = probabilistic(SolveOptions.Companion.allLazily())
8 let si = problogSolver.solveWithOptions(query, options).iterator()
9 while (si.hasNext()) {
10 let solution = si.next();
11 if (solution.isYes)
12 console.log(’yes: ${solution.solvedQuery} with probability ${probability(solution)}’)}
Figure 6: Usage of 2P-Kt’s ProbLog module “as a library”
programmatically constructed, and (v) issued to the Solver, as a probabilistic query. Solutions
are then (vi) enumerated, and, finally, (vii) positive solutions are printed, along with their
probabilities. For the sake of reproducibility, the provided snippets can be executed on all the
supported platforms by cloning the Git repository https://github.com/tuProlog/2pkt-problog
-compatibility-demo, and by following the contained instruction. As the reader may easily
observe, the resulting solutions and probabilities are the same depicted in Figure 5a.
5. Conclusion and Future Works
This paper describes the design and implementation of a ProbLog solver as a module of a logic
ecosystem. The extension pursues the twofold goal of (i) enriching the 2P-Kt logic ecosystem
and technology towards PLP and, in particular, ProbLog, and (ii) bridging PLP and main-stream
programming platforms and languages by letting developers benefit from a library providing
probabilistic reasoning capabilities to their projects.
The proposed solution is still in its infancy, and it is still not suitable to be compared with other
proposals in the field—at least for what concerns performance or feature richness. However,
by working on top of the 2P-Kt ecosystem, our solution inherits large platform support – as
demonstrated in this paper –, thus overcoming the usability and portability constraints that
affect other solutions in this field. In fact, our technology can be deployed on all the platforms
supported by 2P-Kt—which currently include, but are not limited to, the JVM, Android, Python,
and JavaScript. In the long term, we believe such technological openness will play a fundamental
role in bringing the benefits of (P)LP to the general public and letting AI practitioners exploit
(P)LP with minimal effort. In this perspective, our proposal represents a first step in this
direction.
Ultimately, one of the top priorities of this research effort is to leave the door open to future
developments. Our design is purposely abstract, and we endorse the future exploration of
alternative implementation ideas. Among the others, we envision future directions involving:
approximate inference support, more efficient knowledge compilation data structures, or the
exploitation alternative resolution strategies such as the tabled or concurrent ones—other than,
of course, comparative benchmarks aimed at assessing our solutions w.r.t. the state of the art.
Acknowledgments
The project has been supported by the H2020 ERC Project “CompuLaw” (G.A. 833647).
References
[1] R. Calegari, G. Ciatto, V. Mascardi, A. Omicini, Logic-based technologies for multi-agent
systems: A systematic literature review, Autonomous Agents and Multi-Agent Systems
35 (2021) 1:1–1:67. doi:10.1007/s10458-020-09478-3, collection “Current Trends in
Research on Software Agents and Agent-Based Software Development”.
[2] R. Calegari, A. Omicini, G. Sartor, Explainable and ethical AI: A perspective on argumen-
tation and logic programming, in: M. Baldoni, S. Bandini (Eds.), AIxIA 2020 – Advances in
Artificial Intelligence, volume 12414 of Lecture Notes in Computer Science, Springer Nature,
2021, pp. 19–36. doi:10.1007/978-3-030-73065-9\_2.
[3] A. Ortega, J. Fierrez, A. Morales, Z. Wang, T. Ribeiro, Symbolic ai for xai: Evaluating lfit
inductive programming for fair and explainable automatic recruitment, in: IEEE/CVF
Winter Conference on Applications of Computer Vision (WACV), IEEE, 2021, pp. 78–87.
doi:10.1109/WACVW52041.2021.00013.
[4] R. Calegari, G. Ciatto, E. Denti, A. Omicini, Logic-based technologies for intelligent
systems: State of the art and perspectives, Information 11 (2020) 1–29. doi:10.3390/
info11030167, special Issue “10th Anniversary of Information—Emerging Research
Challenges”.
[5] R. Calegari, G. Ciatto, A. Omicini, On the integration of symbolic and sub-symbolic
techniques for XAI: A survey, Intelligenza Artificiale 14 (2020) 7–32. doi:10.3233/IA-1
90036.
[6] C. Perez, The deep learning AI playbook, Lulu.com, 2017.
[7] R. Ng, V. S. Subrahmanian, Probabilistic logic programming, Information and computation
101 (1992) 150–201. doi:10.1016/0890-5401(92)90061-J.
[8] F. Riguzzi, Foundations of Probabilistic Logic Programming, River Publishers, Gistrup,
Denmark, 2018. URL: http://www.riverpublishers.com/book_details.php?book_id=660.
[9] L. De Raedt, A. Kimmig, H. Toivonen, Problog: A probabilistic prolog and its application in
link discovery, in: M. M. Veloso (Ed.), IJCAI 2007, Proceedings of the 20th International Joint
Conference on Artificial Intelligence, Hyderabad, India, January 6-12, 2007, pp. 2462–2467.
URL: http://ijcai.org/Proceedings/07/Papers/396.pdf.
[10] F. Riguzzi, A top down interpreter for LPAD and cp-logic, in: R. Basili, M. T. Pazienza
(Eds.), AI*IA 2007: Artificial Intelligence and Human-Oriented Computing, 10th Congress
of the Italian Association for Artificial Intelligence, Rome, Italy, September 10-13, 2007,
Proceedings, volume 4733 of Lecture Notes in Computer Science, Springer, 2007, pp. 109–120.
doi:10.1007/978-3-540-74782-6\_11.
[11] A. Kimmig, B. Demoen, L. De Raedt, V. S. Costa, R. Rocha, On the implementation of
the probabilistic logic programming language problog, Theory and Practice of Logic
Programming 11 (2011) 235–262. doi:10.1017/S1471068410000566.
[12] F. Niu, C. Zhang, C. Ré, J. Shavlik, Elementary: Large-scale knowledge-base construction
via machine learning and statistical inference, International Journal on Semantic Web and
Information Systems (IJSWIS) 8 (2012) 42–73.
[13] G. Ciatto, R. Calegari, A. Omicini, 2P-Kt: A logic-based ecosystem for symbolic AI,
SoftwareX 16 (2021) 100817:1–7. doi:10.1016/j.softx.2021.100817.
[14] D. Fierens, G. V. den Broeck, J. Renkens, D. S. Shterionov, B. Gutmann, I. Thon, G. Janssens,
L. D. Raedt, Inference and learning in probabilistic logic programs using weighted boolean
formulas, Theory and Practice of Logic Programming 15 (2015) 358–401. doi:10.1017/S1
471068414000076.
[15] F. Riguzzi, T. Swift, The PITA system for logical-probabilistic inference, in: S. H. Muggleton,
H. Watanabe (Eds.), Latest Advances in Inductive Logic Programming, ILP 2011, Late
Breaking Papers, Windsor Great Park, UK, July 31 - August 3, Imperial College Press /
World Scientific, 2011, pp. 79–86. doi:10.1142/9781783265091\_0010.
[16] T. Sato, A statistical learning method for logic programs with distribution semantics, in:
L. Sterling (Ed.), Logic Programming, Proceedings of the Twelfth International Conference
on Logic Programming, Tokyo, Japan, June 13-16, MIT Press, 1995, pp. 715–729.
[17] T. Sato, Y. Kameya, PRISM: A language for symbolic-statistical modeling, in: Proceedings
of the Fifteenth International Joint Conference on Artificial Intelligence, IJCAI 97, Nagoya,
Japan, August 23-29, 2 Volumes, Morgan Kaufmann, 1997, pp. 1330–1339. URL: http:
//ijcai.org/Proceedings/97-2/Papers/078.pdf.
[18] P. Horwich, Probability and evidence, Cambridge University Press, 2016. doi:10.1017/CB
O9781316494219.
[19] L. De Raedt, A. Kimmig, Probabilistic (logic) programming concepts, Machine Learning
100 (2015) 5–47. doi:10.1007/s10994-015-5494-z.
[20] A. Darwiche, P. Marquis, A knowledge compilation map, Journal of Artificial Intelligence
Research 17 (2002) 229–264. doi:10.1613/jair.989.
[21] S. B. Akers, Binary decision diagrams, IEEE Transactions on computers 27 (1978) 509–516.
doi:10.1109/TC.1978.1675141.
[22] A. Lovato, D. Macedonio, F. Spoto, A thread-safe library for binary decision diagrams, in:
D. Giannakopoulou, G. Salaün (Eds.), Software Engineering and Formal Methods - 12th
International Conference, SEFM 2014, Grenoble, France, September 1-5, volume 8702 of
Lecture Notes in Computer Science, Springer, 2014, pp. 35–49. doi:10.1007/978-3-319-
10431-7\_4.
[23] E. Bellodi, F. Riguzzi, Expectation maximization over binary decision diagrams for proba-
bilistic logic programs, Intelligent Data Analysis 17 (2013) 343–363. doi:10.3233/IDA-
130582.
[24] J. Vlasselaer, J. Renkens, G. Van den Broeck, L. De Raedt, Compiling probabilistic logic
programs into sentential decision diagrams, in: Proceedings Workshop on Probabilistic
Logic Programming (PLP), 2014, pp. 1–10.
[25] V. S. Costa, R. Rocha, L. Damas, The YAP prolog system, Theory Pract. Log. Program. 12
(2012) 5–34. doi:10.1017/S1471068411000512.
[26] J. Vennekens, M. Denecker, M. Bruynooghe, Cp-logic: A language of causal probabilistic
events and its relation to logic programming, Theory Pract. Log. Program. 9 (2009) 245–308.
doi:10.1017/S1471068409003767.
[27] A. Thayse, M. Davio, J. Deschamps, Optimization of multivalued decision algorithms,
in: Proceedings of the eighth international symposium on Multiple-valued logic, MVL
1978, Rosemont, Illinois, USA, 1978, IEEE Computer Society Press, 1978, pp. 171–178. URL:
http://dl.acm.org/citation.cfm?id=804202.
[28] J. Wielemaker, T. Schrijvers, M. Triska, T. Lager, Swi-prolog, Theory Pract. Log. Program.
12 (2012) 67–96. doi:10.1017/S1471068411000494.
[29] G. Ciatto, R. Calegari, E. Siboni, E. Denti, A. Omicini, 2P-Kt: logic programming with
objects & functions in Kotlin, in: R. Calegari, G. Ciatto, E. Denti, A. Omicini, G. Sartor (Eds.),
WOA 2020 – 21th Workshop “From Objects to Agents”, volume 2706 of CEUR Workshop
Proceedings, Sun SITE Central Europe, RWTH Aachen University, Aachen, Germany, 2020,
pp. 219–236. URL: http://ceur-ws.org/Vol-2706/paper14.pdf, 21st Workshop “From Objects
to Agents” (WOA 2020), Bologna, Italy, 14–16 September 2020. Proceedings.
[30] G. Ciatto, R. Calegari, A. Omicini, Lazy stream manipulation in Prolog via backtracking:
The case of 2p-kt, in: W. Faber, G. Friedrich, M. Gebser, M. Morak (Eds.), Logics in
Artificial Intelligence, volume 12678 of Lecture Notes in Computer Science, Springer, 2021,
pp. 407–420. doi:10.1007/978-3-030-75775-5\_27, 17th European Conference,
JELIA 2021, Virtual Event, May 17–20, 2021, Proceedings.
[31] E. R. Gansner, S. C. North, An open graph visualization system and its applications to
software engineering, SoftwareE - Practice and Experience 30 (2000) 1203–1233. doi:10.1
002/1097-024X(200009)30:11\%3C1203::AID-SPE338\%3E3.0.CO;2-N.