=Paper=
{{Paper
|id=Vol-2678/paper7
|storemode=property
|title=Operationalizing Declarative and Procedural Knowledge: a Benchmark on Logic Programming Petri Nets (LPPNs)
|pdfUrl=https://ceur-ws.org/Vol-2678/paper7.pdf
|volume=Vol-2678
|authors=Giovanni Sileno
|dblpUrl=https://dblp.org/rec/conf/iclp/Sileno20
}}
==Operationalizing Declarative and Procedural Knowledge: a Benchmark on Logic Programming Petri Nets (LPPNs)==
https://ceur-ws.org/Vol-2678/paper7.pdf
Operationalizing Declarative and Procedural
Knowledge: a Benchmark on Logic
Programming Petri Nets (LPPNs)
Giovanni Sileno1
1
Informatics Institute, University of Amsterdam, the Netherlands
g.sileno@uva.nl
Abstract. Modelling, specifying and reasoning about complex systems
requires to process in an integrated fashion declarative and procedural
aspects of the target domain. The paper reports on an experiment con-
ducted with a propositional version of Logic Programming Petri Nets
(LPPNs), a notation extending Petri Nets with logic programming con-
structs. Two semantics are presented: a denotational semantics that fully
maps the notation to ASP via Event Calculus; and a hybrid operational
semantics that process separately the causal mechanisms via Petri nets,
and the constraints associated to objects and to events via Answer Set
Programming (ASP). These two alternative specifications enable an em-
pirical evaluation in terms of computational efficiency. Experimental re-
sults show that the hybrid semantics is more efficient w.r.t. sequences,
whereas the two semantics follows the same behaviour w.r.t. branchings
(although the denotational one performs better in absolute terms).
Keywords: Reasoning, Model-execution, Discrete simulation, Causal mecha-
nisms, Constraints, Answer Set Programming, Petri Nets
1 Introduction
A proper treatment of cases or scenarios is based on two requirements: on the one
hand, to capture and adequately process the symbolic entities used to represent
the target system: instances, classes, interrelationships forming a local ontology
relevant to the domain in focus; on the other hand, to reproduce—by means of
elements modelling causal mechanisms, processes, courses of actions, etc.—the
same dynamics exhibited by the target system.
Consider for example this case: “While John was walking his dog, the dog ate
Paul’s flowers.” This event description is not sufficient for entailing that John
is responsible to pay Paul for what happened, as typically this is concluded on
the basis of norms as “The owner of an animal has to pay for the damages it
produces.’ ’. However, even this addition lacks crucial connections between the
*
Copyright c 2020 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
2 Logic Programming Petri Nets: a Benchmark
conceptual domain of the case and the one of the norm, like “dogs are animals”,
“eating an object destroys the object”, “destruction is damage”, etc.
These various elements exhibit two perspectives on knowledge: a declarative
perceptive, concerning objects (physical, mental, institutional) and their logical
relationships—both reified as symbols—; and a procedural perceptive, concern-
ing patterns of events/actions, mechanisms, or processes (involving objects) (cf.
reactive/declarative dichotomy in [10]). Formal logic is the prototypical domain
concerned with the first perspective, just as process modeling focuses on the
second. Unfortunately, methodologies associated with one of the two aspects
generally have a limited treatment of the other component, and they require
specific mediating machinery to deal with. For instance, if you want to make a
certain outcome impossible in a procedural model you need to add conditions
that disable all transitions that might produce that outcome. If you want to
represent a transition in a declarative way, a typical approach is to consider
snapshots of the arrangements holding before and after the transition, usually
labeled with a sort of timestamp. This is the principle behind situation calculus
[15, 20], event calculus [11, 21], and fluent calculus [24]: using appropriate ax-
ioms, you can create and reason about the logical dependencies between these
snapshots in a way such that they are compatible to the causal relationships
between the moments they refer to.
Rather than trying to project one dimension on the other, an alternative
tradition in AI and logic proposes to consider causality as a primitive notion. This
approach is for instance behind the idea of all Action languages [6]. Even when
the dichotomy is made clear, however, operationalizations of these languages
often result in compiling action programs to logic programs [5, 4], returning to
‘snapshot-handling’ solutions.
The motivation behind this work stems from the hypothesis that leaving
process analysis to procedural descriptions should be in principle a better choice:
procedural components can directly map to native computational mechanisms,
that can be used not only to re-present, but also re-create the process object,
transforming the question from what the referent should be (characteristic of
logic), to what it is (characteristic of simulation and more in general of model-
execution).
The paper reports therefore on a simple benchmark experiment with an hy-
brid notation (that is, including procedural and declarative knowledge compo-
nents), called Logic Programming Petri Nets (LPPNs).1 Section § 2 will introduce
the motivation and an informal semantics of LPPNs. Section § 3 will present a
formalisation of a propositional version of LPPN. Section § 4 will present an
hybrid operational semantics and a denotational semantics based on ASP pro-
grams with Event Calculus. Section § 5 will present the results of a first empirical
experiment. Discussion and a note on further developments end the paper.
1
A prototype of a LPPN interpreter is available on http://github.com/s1l3n0/
pypneu, together with the code run for conducting the experiment.
Logic Programming Petri Nets: a Benchmark 3
E
t1 t1 t1
p1 p3 p1 p3 p1 p3
p2 p2 p2
(a) not enabled transition, (b) enabled transition and (c) the transition has fired
before firing firing
Fig. 1: Example of a Petri net and of its execution (but also of a LPPN procedural
component when labels are propositions).
2 Logic Programming Petri Nets
Logic Programming Petri Nets (LPPNs) are a visual notation first introduced in
[22] as an common representational ground where to align representations of law
(norms), of implementations of law (regulatory services in the form of business
processes), and of action (behavioural scripts ascribed to social participants).
It has been used for a wide class of models (business processes embedded with
normative positions, representation of scenarios issued from narratives, agent
scripts, deontic paradoxes, etc. [22]). The notation builds upon the intuition that
places and transitions mirror the common-sense distinction between objects and
events (e.g. [2]), roughly reflecting the use of noun/verb categories in language
[9]: the procedural components captured by Petri nets can be used to model
transient aspects of the system in focus; the declarative components captured by
logic programming construct can be used to model steady state aspects, i.e. those
on which the transient is irrelevant or does not make sense (e.g. terminological
constraints). In this section we will informally describe the bases motivating
their integration.
2.1 From Petri Nets to LPPNs
Petri nets are a simple, yet effective computational modelling representation
featuring an intuitive visualisation (see Fig. 1). They consist in directed, bipartite
graphs with two types of nodes: places (visually represented with circles) and
transitions (with boxes). A place can be connected only to transitions and vice-
versa. One or more tokens (dots) can reside in each place. The execution of Petri
nets is also named “token game”: transitions fire by consuming tokens from their
input places and producing tokens in their output places.2
Despite their widespread use in computer science, electronics, business pro-
cess modelling and biology, Petri nets are generally considered not to be enough
expressive for reasoning purposes: in their simplest form, tokens are indistinct,
2
For an overview on the general properties of Petri nets see e.g. [18].
4 Logic Programming Petri Nets: a Benchmark
p9
p7 E t3 p10
AND IMPLIES t2 E p11
p4 p6
p8 t4
p5
(a) (b)
Fig. 2: Examples of LPPN declarative components: (a) defined on places by means
of lp-nodes (the example corresponds to the Prolog/ASP code: p6 :- p4, p5.
p5.); (b) defined on transitions, by means of lt-nodes, instantaneously propagat-
ing the firing where possible (the IMPLIES label is here left implicit).
and do not transport any data. Nevertheless, it is a common practice for mod-
ellers to introduce labels to set up a correspondence between the modelling enti-
ties and the modelled entities. This practice enables them to read the results of
a model execution in reference to the modelled system. In other words, an ade-
quate labelling is still functional to the use of a Petri net for modelling purposes,
although it is not a requirement for the execution in itself. Further interaction
is possible if these labels are processed according to an additional formalism, as
for instance it occurs with Coloured Petri Nets (CPNs) [8] (for many aspects
a descendant of Predicate/Transition nets [7]). If their expressiveness and wide
application provide reasons for its adoption, CPNs also introduce many details
which are unimportant in a case modelling setting (e.g. expressions on arcs);
more importantly, they still lack the ability of specifying and processing declara-
tive bindings, necessary, for instance, to model terminological relationships. This
brings us to the idea of LPPN.
Whereas Petri nets essentially specify procedural mechanisms, Logic Pro-
gramming Petri Nets (LPPNs) extend those (a) with literals as labels, attached
on places and transitions; (b) with nodes specifying (logic-programming based)
declarative bindings on places and on transitions. For simplicity, this paper will
focus only on propositional labelling. Under this constraint, the execution of
the LPPN procedural component is the same as Condition/Event nets, Petri
nets whose places do not contain more than one token (Fig. 1). Logic operator
nodes might apply on places (lp-nodes) or on transitions (lt-nodes). An example
of a sub-net with lp-nodes (small black squares) is given in Fig. 2a; these are
used to create logic compositions of places (via operators as NEG, AND, OR, etc).
or to specify logic inter-dependencies (via the logic conditional IMPLIES). Simi-
larly, transitions may be connected declaratively via lt-nodes (black circles), as
in Fig. 2b; these connections may be interpreted as channels enabling instanta-
neous propagation of firing. In this case, it is not relevant to introduce operators
as AND, for the interleaving semantics, only one source transition may fire per
step. Operationally, the declarative components are treated integrating the stable
Logic Programming Petri Nets: a Benchmark 5
e2 e1 IMPLIES
c1 c2 c5
c4 c3
e3
Fig. 3: Example of LPPN with procedural and declarative components.
model semantics used in answer set programming (ASP) [14]. This was a natural
choice because process execution exhibits a prototypical ‘forward’ nature, and
ASP solvers can be interpreted as providing forward chaining.3
Running example Let us consider the LPPN in Fig. 3. Here, for simplicity, we
will conflate the names of the transition/places with their labels (equivalent to
a unique name assumption); in the general case these should be made different
as there might be multiple nodes with the same label. The proposed net spec-
ifies causal mechanisms, declarative constraints. There is only one token in c1,
enabling the transitions associated to e1 and e2. The following execution paths
are possible: (1) e2 fires, consuming the token in c1, e3 fires, consuming the
token c4 and producing a token in c3; (2, 3) e3 fires, and then one of e1 or e2
fires; (4) e1 fires, consuming the token in c1; the firing propagates to e3; the
source firing of e1 also produces a token in c2; the existence of c2 is a sufficient
condition for immediately reifying c5.
3 Formalization
This section presents a simplified version of the LPPN notation considering only
a propositional labeling. We start from the definition of propositional literals
derived from ASP [14], accounting for strong and default negation.
Definition 1 (Literal and Extended literals). Given a set of propositional
atoms A, the set of literals L = L+ ∪ L− consists of positive literals (atoms)
L+ = A, negative literals (negated atoms) L− = {−a | a ∈ A}, where ‘−’ stands
for strong negation.4 The set of extended literals L∗ = L ∪ Lnot consists of
3
Both SLD/SLDNF resolution (Prolog) and DPLL (ASP) are based on backward
chaining. In DPLL, however, all variables are grounded, and all intermediate atoms
generated in the search are collected in stable models; without defining any goal, all
the worlds that are implied by the input knowledge are returned as output. From
an external perspective, this is the same result we would associate with forward
chaining. The intuition that there is a relation between ASP and forward chaining
is confirmed e.g. in ASPeRiX [13].
4
Strong negation is used to reify an explicitly false situation (e.g. “It does not rain”).
6 Logic Programming Petri Nets: a Benchmark
literals and default negation literals Lnot = {not l| l ∈ L}, where ‘not’ stands
for default negation.5
We denote the basic topology of a Petri net as a procedural net.
Definition 2 (Procedural net). A procedural net is a bipartite directed
graph connecting two finite sets of nodes, called places and transitions. It can
be written as N = hP, T, Ei, where P = {p1 , . . . , pn } is the set of place nodes;
T = {t1 , . . . , tm } is the set of transition nodes; E = E + ∪ E − is the set of arcs
connecting them: E + from transitions to places, E − from places to transitions.
LPPNs consists of three components: a procedural net specifying causal rela-
tionships, and two declarative nets specifying respectively logical dependencies
at the level of objects or ongoing events (on places), and on impulse events (on
transitions). Furthermore, propositional LPPNs exhibit a boolean marking on
places (like condition/event nets).
Definition 3 (Propositional Logic Programming Petri Net). A proposi-
tional Logic Programming Petri Net LPPN prop is a Petri Net whose places and
transitions are labeled with literals, enriched with declarative nets of places and
of transitions. It is defined by the following components:
– hP, T, PE i is a procedural net; PE stands for procedural edges;
– CP : P → L∗ and CT : T → L are labeling functions, associating literals
respectively to places and to transitions;
– OP = {¬, −, ∧, ∨, →, ↔, . . .} is a set of logic operators.
– LP and LT are sets of logic operator nodes respectively for places ( lp-nodes)
and for transitions ( lt-nodes).
– CLP : LP → OP maps each lp-node to a logic operator; similarly, CLT :
LT → OP does the same for lt-nodes.
−
– DE LP = DE + LP ∪ DE LP is the set of arcs connecting lp-nodes to places;
−
similarly, DE LT = DE + LT ∪ DE LT for lt-nodes and transitions.
6
– M : P → {0, 1} returns the marking of a place, i.e. whether the place con-
tains (1) or does not contain (0) a token.
Note that if LP ∪ LT = ∅, we have a strictly procedural LPPN prop , i.e. a
standard binary Petri net. If T = ∅, we have a strictly declarative LPPN prop ,
that can be directly mapped to an ASP program. For simplicity, we overlook
in this document the syntaxic constraints on the network topology which are
inherited from ASP.
4 Semantics
This section will present two semantics for LPPNs: a hybrid operational seman-
tics and a denotational semantics, based on ASP and event calculus.
5
Default negation is used to reify a situation in which something cannot be re-
trieved/inferred (e.g. ‘It is unknown whether it rains or not’).
6
Note that DE − LT ⊆ (T ∪ P ) × LT , i.e. these edges go from transitions and places
(modeling contextual conditions) to lt-nodes.
Logic Programming Petri Nets: a Benchmark 7
4.1 Hybrid operational semantics
The execution cycle of a LPPN consists of four steps:
1. given a “source” marking M , the bindings of the declarative net of places
entail a “ground” marking M ∗ ;
2. an enabled transition is selected to pre-fire, determining a “source” transition-
event e;
3. the bindings of the declarative net of transitions entail all propagations of
this event, obtaining a set of transition-events, also denoted as the “ground”
event-marking E ∗ ;
4. all transition-events are fired, producing and consuming the relative tokens.
The steps (1) and (3) are processed in distinct moments and programs by an
ASP solver: the declarative nets of places (1) or of transitions (3) are translated
as rules, tokens (1) or source transition-events (3) are reified as facts. The ASP
solver takes as input the resulting program and, if satisfiable, it provides as
output respectively one or more ground marking (1) or one or more sets of
transition-events to be fired (3). The steps (2) and (4) make clear the distinction
the external firings (the “source” transition-event selected at execution level)
from the internal firing, immediately propagated (the “ground” transition-events
triggered by the declarative net of transitions). The following definitions provides
a formalisation of these concepts.
Definition 4 (Enabled transition). A transition t is enabled in a ground
marking M ∗ if a token is available for each input places:
Enabled (t) ≡ ∀pi ∈ •t, M ∗ (p) = 1
Similarly to what marking is for places, we consider an event-marking for tran-
sitions E : T → {0, 1}. E(t) = 1 if the transition t produces a transition-event
e. Each step s has a “source” event-marking E.
Definition 5 (Pre-firing). An enabled transition t pre-fires (implicitly, at a
step s) if it is selected to produce a transition-event:
∀t ∈ Enabled (T ) : t pre-fires ≡ E(t) = 1
Applying an interleaving semantics for the pre-firing, the interpreter selects only
one transition to pre-fire per step; for any other t0 , E(t0 ) = 0.
Definition 6 (Firing). An enabled transition t fires (implicitly, at a step s) by
propagation consuming a token from each input place, and producing a token in
each output place:
∀t ∈ Enabled (T ) : t fires ≡
E (t) = 1 ↔ ∀pi ∈ •t : M 0 (pi ) = 0 ∧ ∀po ∈ t• : M 0 (po ) = 1
∗
8 Logic Programming Petri Nets: a Benchmark
4.2 Denotational semantics
One of the possibilities to validate a formal language is to map it into another
formal language, i.e. to provide a denotational semantics. The declarative com-
ponent of a LPPN, by design, can be directly rewritten as ASP code. As we
are already halfway down the path, we can translate the remaining procedural
component into ASP.
Event Calculus axioms A well-known solution to treat change in logic pro-
gramming is event calculus (EC) [11, 21]. The simple version of EC is already
satisfactory for our purposes. A modification of the original axioms is however
necessary to deal with the locality brought by places and transitions:
holdsAt(F, P, N) :-
initially(F, P), not clipped(0, F, P, N),
fluent(F), place(P), time(N).
holdsAt(F, P, N2) :-
firesAt(T, N1), N1 < N2,
initiates(T, F, P, N1), not clipped(N1, F, P, N2),
place(P), transition(T), fluent(F), time(N1), time(N2).
clipped(N1, F, P, N2) :-
firesAt(T, N), N1 <= N, N < N2,
terminates(T, F, P, N),
place(P), transition(T), fluent(F), time(N1), time(N2), time(N).
Interleaved semantics axioms The interleaved semantics can be translated
into the following rules:
i. all enabled transitions may or may not pre-fire;
ii. pre-firing is transformed to firing;
iii. at least one enabled transition must pre-fire per step, i.e. it is impossible
that no transition fire if there are enabled transitions;
iv. at maximum one transition can pre-fire per step.
In ASP code:
{prefiresAt(T, N)} :- % (i)
enabled(T, N), transition(T), time(N).
firesAt(T, N) :- prefiresAt(T, N). % (ii)
someTransitionPrefiresAt(N) :- % (iii)
prefiresAt(T, N), transition(T), time(N).
:- not someTransitionPrefiresAt(N), enabled(T, N), transition(T), time(N).
:- prefiresAt(T1, N), prefiresAt(T2, N), T1 != T2, % (iv)
transition(T1), transition(T2), time(N).
Logic Programming Petri Nets: a Benchmark 9
Transformation of a LPPN to an ASP program The mapping of a given
LPPN to an equivalent ASP program includes the previous axioms and the
output of the following steps:
i. for each place p, with label CP (p)
(a) type it as place,
(b) specify its initial state,
(c) for each place with more than one output, write down that you cannot
consume more than the only available token.
ii. for each transition t, with label CT (t)
(a) type it as transition,
(b) define the conditions for which it is enabled,
(c) for each output place, define how to create tokens in the output places,
(d) for each input place, define how to consume tokens in the output places.
iii. for each lp-node lp,
(a) specify the logic constraint to be applied between inputs and outputs.
iv. for each lt-node lt,
(a) write down the logic dependencies between transitions allowing the prop-
agation.
As a concrete example, we apply these actions on some of the components of the
LPPN in Fig. 3:
fluent(filled).
%%% p1, associated to c1
place(c1). % 1.a
initially(filled, c1). % 1.b
:- 2{terminates(e2, filled, c1, N); terminates(e1, filled, c1, N)}. % 1.c
%%% t1, associated to e1
transition(e1). % 2.a
enabled(e1, N) :- holdsAt(filled, c1, N). % 2.b
terminates(e1, filled, c1, N) :- firesAt(e1, N). % 2.c
initiates(e1, filled, c2, N) :- firesAt(e1, N). % 2.d
%% lp1
holdsAt(filled, c5, N) :- holdsAt(filled, c2, N). % 3.a
%% lt1
firesAt(e3, N) :- firesAt(e1, N), enabled(e3, N). % 4.a
Execution With the transformation steps given above, valid LPPNs can be trans-
formed into ASP programs. In particular, for the axioms presented here, these
programs can be solved the ASP engine clingo [3], also available online at:
https://potassco.org/clingo/run/. Setting a temporal range (with the in-
struction “time(0..n).”) the output answer sets represent all possible execu-
tions path after at most n steps.
10 Logic Programming Petri Nets: a Benchmark
Fig. 4: Average execution times (ms) in linear and logarithmic scales over 10 ex-
ecutions of serial and forking configurations of propositional LPPNs of different
depths, performed following alternatively the hybrid operational semantics, via
brute force execution and backtracking (BF+BT); and the denotational seman-
tics, via event calculus (EC). Data is on Table 1.
5 Results
The proposal presented above has been used for developing a prototype Python
application for specifying, executing and analyzing LPPNs7 ; it exploits clingo
[3], as this provide runtime interfaces enabling a direct control of the solver
instance without regrounding the program at each cycle. This enabled us to
perform some direct evaluation of any given LPPN input.
When we process the input LPPN by means of the denotational semantics,
the input is transformed to an ASP program, and the solver intervenes fully
to provide the possible execution paths. Instead, when we refer to the hybrid
operational semantics, the solver intervenes only partially in the execution cycle,
to entail the constraints implied by the declarative components of the net; the
rest of the computational burden is on the module responsible for the Petri net
execution. In this context, one might ask if we can observe some performances
between these two alternative modes of analysis/execution.
7
Available at http://github.com/s1l3n0/pypneu.
Logic Programming Petri Nets: a Benchmark 11
depth of composition of minimal structures
serial 1 11 21 31 41
EC 0.1 ± 0.0 2.1 ± 0.1 13.5 ± 1.8 58.0 ± 8.2 154.2 ± 8.6
BF+BT 0.2 ± 0.0 1.3 ± 0.1 2.9 ± 0.2 5.1 ± 0.6 8.6 ± 0.9
51 61 71 81 91
EC 352.4 ± 9.9 754.4 ± 15.2 1285.3 ± 29.3 2200.6 ± 30.1 3499.0 ± 33.9
BF+BT 11.0 ± 0.2 14.7 ± 0.2 19.4 ± 1.1 23.4 ± 0.8 29.3 ± 3.1
forking 1 2 3 4 5
EC 0.1 ± 0.0 0.2 ± 0.0 0.6 ± 0.0 1.5 ± 0.1 5.3 ± 1.3
BF+BT 0.4 ± 0.0 0.7 ± 0.0 1.9 ± 0.1 5.0 ± 0.3 15.5 ± 1.2
6 7 8 9 10
EC 19.6 ± 3.5 68.5 ± 8.2 272.6 ± 20.4 1151.3 ± 83.7 5033.8 ± 291.7
BF+BT 55.3 ± 7.7 213.1 ± 36.0 920.9 ± 112.1 4834.5 ± 537.9 29529.9 ± 1665.4
Table 1: Average execution time (ms) over 10 executions of different config-
urations of propositional LPPNs, performed following alternatively the hybrid
operational semantics, via brute force execution and backtracking (BF+BT); and
the denotational semantics, via event calculus (EC).
At the moment, we have only evaluated a propositional version of LPPN, and
a limited series of structures, namely compositions of minimal serial elements
(a transition with an input and output places) or minimal forking elements
(a place with two output transitions). In order to implement the procedural
component of the operational semantics, the current Petri Net analysis module
builds upon a simple brute force (BF) execution algorithm, and depth-first search
with backtracking (BT) to cover all the possible execution paths.
Table 1 summarises the performances of 10 executions of different network
configurations.8 Results are also illustrated on Fig. 4. The data essentially con-
firms our hypothesis: the analysis based on the operational semantics (BF+BT)
clearly outperforms and scales excellently for the serial configurations, while that
based on the denotational semantics (EC) scales poorly in this configuration. For
the forking configurations, BF+BT is evidently slower in absolute terms. Intu-
itively this is due to the efficient search and pruning capabilities of ASP. Unlike
clingo, the Python code of the Petri net executor/analyzer is not optimised; on
the contrary, for many aspects this represents a lower-bound on the possible im-
plementation choices. Nevertheless, if we consider execution times in logarithmic
scale, we observe that the two methods are essentially comparable in terms of
tractability.
6 Conclusion
The paper presents an empirical experiment with LPPNs, a logic programming-
based extension to Petri Nets. LPPNs were introduced with a practical goal
8
The tests were run on a MacBook Pro (2018) provided with a 2.2 GHz 6-core pro-
cessor Intel Code i7 and 16Gb RAM DDR4.
12 Logic Programming Petri Nets: a Benchmark
in mind: a visual modelling notation relatively simple for non-experts, that
could handle explicit declarative knowledge, and that could model causation
and other procedural aspects [22]. It was inspired by the point made in [10]
on the widespread confusion in cognitive science and computational disciplines
around the notion of rules (namely between declarative and reactive rules). Pre-
vious contributions [22, 23] highlighted the potential use of LPPNs in normative
modelling tasks in combination with business process modelling, thus potentially
facilitating cross-fertilization between theoretical to practical settings.
Here the focus has been put on its computational properties, showing that
maintaining the two levels separated can bring better performances. The declar-
ative dimension allows to treat at higher abstraction phenomena for which there
is a viable specification at outcome level. The procedural dimension works better
for processes that can be directly executed.
Future developments concern the extension of this work to a wider range of
experiments, first considering mixed networks (of declarative, procedural com-
ponents) with mixed configurations (serial compositions, forks, joins, etc.) and
then passing to the extended LPPN notation accounting for predicates. The
actual impact on real models should be evaluated as well: scenarios describing
cases have very few forks, they rather function as orchestrated (i.e. directed
from the scenario) scripts (procedural models distributed amongst actors). Con-
sequently, applications that require the use of scenarios (e.g. for interpretation,
model-based diagnosis, conformance checking, etc.) may take advantage of the
hybrid operational semantics. The computational improvement may be further
extended considering existing proposals in the literature. For instance, execution
algorithms alternative to brute execution [16, 19]; or decomposition techniques,
for instance in single-entry-single-exit (SESE) components [17], that open up
the possibility of concurrent execution.
Further, these results should be confronted with existing techniques for han-
dling temporal reasoning and causality, e.g. the already cited Action languages
[6], related works (e.g. F2LP [12]) and applications (CCalc, Coala, Cplus2ASP);
optimized versions of Event Calculus (e.g. [1]); applications based on LTL, CTL
and related formalisms.
References
1. Artikis, A., Sergot, M., Paliouras, G.: An Event Calculus for Event Recognition.
IEEE Transactions on Knowledge and Data Engineering 27(4), 895–908 (2015)
2. Breuker, J., Hoekstra, R.: Core concepts of law: taking common-sense seriously.
Proc. of Formal Ontologies in Information (2004)
3. Eiter, T., Faber, W., Fink, M., Woltran, S.: A user’s guide to gringo, clasp, clingo,
and iclingo. Annals of Mathematics and Artificial Intelligence 51(2-4), 123–165
(2008)
4. Ferraris, P., Lee, J.: Representing first-order causal theories by logic programs.
Theory and Practice of Logic Programming 12(03), 383–412 (may 2012)
5. Gebser, M., Grote, T., Schaub, T.: Coala: A compiler from action languages to
ASP. Lecture Notes in Computer Science (including subseries Lecture Notes in
Logic Programming Petri Nets: a Benchmark 13
Artificial Intelligence and Lecture Notes in Bioinformatics) 6341 LNAI, 360–364
(2010)
6. Gelfond, M., Lifschitz, V.: Action languages. Electronic Transactions on AI (1998)
7. Genrich, H.J.: Predicate/Transition Nets. In: Proceedings Advances in Petri nets
1986. pp. 207–247 (1987)
8. Jensen, K.: Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical
Use. Springer-Verlag, London, UK (1996)
9. Kemmerer, D., Eggleston, A.: Nouns and verbs in the brain: Implications of lin-
guistic typology for cognitive neuroscience. Lingua 120(12), 2686–2690 (2010)
10. Kowalski, R., Sadri, F.: Integrating logic programming and production systems
in abductive logic programming agents. Web Reasoning and Rule Systems LNCS
5837, 1–23 (2009)
11. Kowalski, R., Sergot, M.: A logic based calculus of events. New Generation Com-
puting 4(June 1975), 67–95 (1986)
12. Lee, J., Palla, R.: System f2lp - computing answer sets of first-order formulas.
Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial
Intelligence and Lecture Notes in Bioinformatics) 5753 LNAI, 515–521 (2009)
13. Lefevre, C., Nicolas, P.: A First Order Forward Chaining for Answer Set Comput-
ing. LPNMR 2009 LNCS 5753, 196–208 (2009)
14. Lifschitz, V.: What Is Answer Set Programming? Proceedings of the AAAI Con-
ference on Artificial Intelligence (2008)
15. McCarthy, J., Hayes, P.J.: Some philosophical problems from the standpoint of
artificial intelligence. In: Machine Intelligence, pp. 1–51. Edimburgh University
Press (1969)
16. Moreno, R.P., Salcedo, J.L.V.: Performance evaluation of petri nets execution al-
gorithms. Conference Proceedings - IEEE International Conference on Systems,
Man and Cybernetics pp. 1400–1407 (2007)
17. Munoz-Gama, J., Carmona, J., Van Der Aalst, W.M.P.: Single-Entry Single-Exit
decomposed conformance checking. Information Systems 46, 102–122 (2014)
18. Murata, T.: Petri nets: Properties, analysis and applications. Proceedings of the
IEEE 77(4) (1989)
19. Piedrafita, R., Villarroel, J.L.: Performance evaluation of petri nets centralized
implementation. The execution time controller. Discrete Event Dynamic Systems:
Theory and Applications 21(2), 139–169 (2011)
20. Reiter, R.: Knowledge in action: logical foundations for specifying and implement-
ing dynamical systems. MIT Press (2001)
21. Shanahan, M.: The event calculus explained. Artificial Intelligence Today pp. 409–
430 (1999)
22. Sileno, G.: Aligning Law and Action. Ph.D. thesis, University of Amsterdam (2016)
23. Sileno, G., Boer, A., van Engers, T.: A Petri net-based notation for normative mod-
eling: evaluation on deontic paradoxes. In: Workshop on MIning and REasoning
with Legal texts (MIREL2017) in conjunction with ICAIL2017 (2017)
24. Thielscher, M.: From situation calculus to fluent calculus: State update axioms as
a solution to the inferential frame problem. Artificial Intelligence 111(1-2), 277–299
(1999)