Data and Processes: Can we Marry Them . . . and Make the Marriage Last?

Data and Processes: Can we Marry Them . . .and Make the Marriage Last?

Diego Calvanese

Research Centre for Knowledge and Data (KRDB)Free University of Bozen-Bolzano, Italy

..

KRDB1

INRIA Saclay Paris – 18/3/2016

Dichotomy Analysis Marriage Strengthening Conclusions

Diego Calvanese (FUB) Foundations of Data-Aware Process Analysis INRIA Saclay Paris – 18/3/2016 (1/52)


Outline

1 Data and processes: a dichotomy

2 Analysing data and processes

3 Marrying data and processes

4 Strengthening the marriage

5 Conclusions



Processes and data

The information assets of an organization are constituted by data andprocesses:

Data are the main information source about the history of the domain ofinterest, and about the relevant aspects of the current state of affairs.

A (business) process consists of a set of activities that are performed incoordination in an organizational and technical environment [Weske 2007].

Activities change the real world: The corresponding updates arereflected into the organizational information system(s).

Data trigger decision-making, which in turn determines the next stepsto be taken in the process.



Our starting point

Marrying processes and data is a must if we

really want to understand the functioning of

complex systems in the real world.







5 ConclusionsDiego Calvanese (FUB) Foundations of Data-Aware Process Analysis INRIA Saclay Paris – 18/3/2016 (5/52)


Experts’ dichotomy

Survey by Forrester [Karel, Richardson, and Moore 2009]: lack of interactionbetween data and process experts:

Business process management professionals: think that data aresubsidiary to processes, and neglect importance of data quality.

Data management experts: claim that data are the main driver of theorganizational processes, and only focus on data quality.

Forrester: 83 out of 100 . . . no interaction at all between these two groups!

This isolation propagates to languages and tools, which never properlyaccount for the process-data connection.



One side: conventional data modeling

Focus: relevant entities, relations, static constraints

Supplier ManufacturingProcurement/Supplier

Sales

Customer PO Line Item

Work OrderMaterial PO

*

*

spawns0..1

Material

But. . . how do data evolve?Where can we find the “state” of a purchase order?



The other side: conventional process modeling

Focus: control flow of activities in response to events

But. . . how do activities update data?What is the impact of canceling an order?



IT integration: Spaghetti!

Manage Cancelation

ShipAssembleManageMaterial POs

DecomposeCustomer PO

Activities

Process

Data

Activities

Process

Data

Activities

Process

Data

Activities

Process

Data

Activities

Process

Data

Customers Suppliers&CataloguesCustomer POs Work Orders Material POs

IT integration: system is difficult to manage, understand, evolve.



Too late to reconstruct the missing pieces

Where is our data?

part is in the DBs,part is hidden in the process execution engine.

Where are the relevant business rules, and how are they modeled?

At the DB level? Which DB? How to import the process data?(Also) in the business model? How to import data from the DBs?

DataProcess

Supplier ManufacturingProcurement/Supplier

Sales

Customer PO Line Item

Work OrderMaterial PO

*

*

spawns0..1

Determine cancelation

penaltyNotify penalty

Material

Process Engine

Process State

Business rulesFor each work order W For each material PO M in W if M has been shipped add returnCost(M) to penalty



Data and processes in AI

Artificial Intelligence, traditionally has given important contributions to bothsettings:

Data: knowledge bases, conceptual models, ontologies, ontology-baseddata access and integration, inconsistency-tolerant semantics, . . .

Processes: reasoning about actions, temporal/dynamic logics,situation/event calculus, temporal reasoning, planning, verification,synthesis, . . .

Why is there still isolation?

To attack the complexity – Divide et impera!



Data and processes in BPM

Need for conceptual integration recognized by the (business) process modelingcommunity as well.

Data-process integration is crucial to assess the value of processes andevaluate KPIs [Meyer, Smirnov, and Weske 2011].

Data-process integration is crucial to aggregate all relevant information,and to suitably inject business rules into the system [Dumas 2011].

Process and data are just two sides of the same coin [Reichert 2012].



Overcoming the dichotomy

Strong need for:

suitable modeling formalisms supporting the integrated management ofprocesses and data;

methodologies for the design of systems based on such formalisms;

systems and tools that implement these languages and methodologies.

This, in turn requires a foundational approach to tackle important issues.1 Provide a clear understanding of (data-aware) process models w.r.t.

semantic properties, andcomputational properties.

2 Enable static analysis of such formalisms.









Analysis in DB theory

In DB theory, data-related analysis is well-established:

intensional reasoning over queries: containment, equivalence

database dependencies: axiomatization, satisfaction, implication, . . .

semantic and conceptual data models

reasoning over views

· · ·



Business process analysis

In BPM, process model analysis is considered the second most influentialtopic in the last decade (after process modeling languages) [Aalst 2012].

Basic assumption: control-flow is captured by a (possibly infinite-state)propositional labeled transition system:

Labels represent the process tasks/activities.

Concurrency is represented by interleaving.

Transition system usually not represented explicitly, but is implicitly“folded” into a Petri net.

However:

Data has been abstracted away.

Emphasis has been on the control-flow dimension:; sophisticated techniques for absence of deadlocks, boundedness,soundness, or domain-dependent properties expressed in LTL or CTL.



Verification of complex system behaviour

Automated analysis of aformal model of the system

against a property of interest,considering all possible system behaviors.



Verification via model checking

Verification of software and hardware systems via model checking.[2007 Turing Award: Clarke, Emerson, Sifakis]

Dynamic properties of interest are formulated in a temporal logic (LTL,CTL, µ-calculus, . . . ).

The transition system mathematically capturing the dynamics of thesystem of interest is (implicitly or explicitly) represented.

The temporal logic formulas are checked (i.e., evaluated) over thetransition system.

Model checking technology applicable only over a finite transition system.



Analysis of data-aware processes

The presence of data complicates analysis significantly:

States must be modeled relationally rather than propositionally.

The resulting transition system is typically infinite state.

Query languages for analysis need to combine two dimensions:

A temporal dimension to query the process execution flow.A first-order dimension to query the data present in the relational structures.

; We need first-order variants of temporal logics.

Model checking data-aware processes becomes immediately undecidable!









Marrying data and processes

How can we marry data and processes, mediating between:

the expressiveness of the language for temporal properties, and

the form of the data-aware processes,

in such a way that

1 we are able to capture notable, real-world scenarios, but

2 analysis stays decidable, and possibly efficient.



Business entities/artifacts

Data-centric paradigm for process modeling.

First: elicitation of relevant business entities that are evolved withingiven organizational boundaries.

Then: definition of the lifecycle of such entities, and how tasks triggerthe progression within the lifecycle.

Information model Lifecycle Artifact

Is an active research area, with concrete languages (e.g., IBM GSM, OMGCMMN).

Cf. EU project ACSI (2010–2013). a i S C Diego Calvanese (FUB) Foundations of Data-Aware Process Analysis INRIA Saclay Paris – 18/3/2016 (22/52)


Concrete models for artifacts

Key questions:

How and where to store data maintained by the information model?

How to specify the lifecycle of an artifact?

At which level of abstraction?

Some concrete information models:

Relational database (with nested records).

Knowledge base, e.g., expressed in some ontology language.

Some concrete lifecycle models:Finite-state machines. State = phase; events trigger transitions.

Implemented in the Siena prototype by IBM.

Guard-Stage-Milestone lifecycles, based on declarative(event-condition-action)-like rules.

Implemented in the Barcelona prototype by IBM.

Proclets (interacting Petri nets).Emphasise many-to-many relationships between artifacts.



Data-Centric Dynamic Systems (DCDS)

Abstract model underlying variants of artifact-centric systems.

Semantically equivalent to the most expressive models for business processsystems (e.g., GSM).

Data Process Data+Process

Data Layer: Relational databases / ontologies

Data schema, specifying constraints on the allowed statesData instance: state of the DCDS

Process Layer: key elements are

Atomic actionsCondition-action-rules for application of actionsService calls: communication with external environment, new data!



Deterministic vs. non-deterministic services

DCDSs admit two different semantics for service-execution:

Deterministic services semantics

Along a run, when the same service is called again with the same arguments, itreturns the same result as in the previous call.

Are used to model an environment whose behavior is completely determined bythe parameters.Example: temperature, given the location and the date and time

Non-deterministic services semantics

Along a run, when the same service is called again with the same arguments, itmay return a different value than in the previous call.

Are used to model:

an environment whose behavior is determined by parameters that areoutside the control of the system;input of external users, whose choices depend on external factors.

Example: current temperature, given the locationDiego Calvanese (FUB) Foundations of Data-Aware Process Analysis INRIA Saclay Paris – 18/3/2016 (25/52)


An example: Hotels and price conversion

Data Layer: Info about hotels and room prices

Cur = 〈UserCurrency〉 CH = 〈Hotel ,Currency〉 PEntry = 〈Hotel ,Price,Date〉

Process Layer/1

User selection of a currency.

Process: true 7−→ ChooseCur()

Service call for currency selection: uInputCurr()

Models user input with non-deterministic behavior.

ChooseCur() :

{Cur(c) del{Cur(c)}true add{Cur(uInputCurr())}

}



An example: Hotels and price conversion

Data Layer: Info about hotels and room prices

Cur = 〈UserCurrency〉 CH = 〈Hotel ,Currency〉 PEntry = 〈Hotel ,Price,Date〉

Process Layer/2

Price conversion for a hotel.

Process: Cur(c) ∧ CH(h, ch) ∧ ch 6= c 7−→ ApplyConv(h, c)

Service call for currency selection: conv(price, from, to, date)

Models historical conversion with deterministic behavior.

ApplyConv(h, c) : PEntry(h, p, d) del{PEntry(h, p, d)}PEntry(h, p, d) ∧ CH(h, cold) ∧ Cur(c) add{PEntry(h,conv(p, cold , c, d), d)}

CH(h, cold) del{CH(h, cold)}, add{CH(h, c)}



Run of the system

HC

h1 eurh2 eur

PEntry

h1 95 apr-25h1 80 sep-18h2 80 sep-18

HC

h1 eurh2 eur

PEntry

h1 95 apr-25h1 80 sep-18h2 80 sep-18

Cur

usd

HC

h1 usdh2 eur

PEntry

h1 115 apr-25h1 95 sep-18h2 80 sep-18

Cur

usd

HC

h1 usdh2 usd

PEntry

h1 115 apr-25h1 95 sep-18h2 95 sep-18

Cur

usd

ChooseCur(): uInputCurr() =

?

usd

ApplyConv(h1,usd):conv(95,eur,usd,apr-25) = ?115conv(80,eur,usd,sep-18) = ?95

ChooseCur()

ApplyConv(h2,usd)

ChooseCur()

ApplyConv(h2,usd)conv(80,eur,usd,sep-18) = 95



Semantics via transition systems

Semantics of a DCDS S is given in terms of a transition system ΥS :

Each state of ΥS has an associated DB over a common schema.

The initial state is associated to the initial DB of the DCDS.

s0

s1

s3

s4

s6

s7

Note: ΥS is in general infinite state:

Infinite branching, due to the results of service calls.

Infinite runs, since infinitely many DBs may occur along a run.

Associated to the states we have DBs of unbounded size.Diego Calvanese (FUB) Foundations of Data-Aware Process Analysis INRIA Saclay Paris – 18/3/2016 (28/52)


Verification for DCDSs

We are interested in the verification of temporal properties over ΥS .

Idea to overcome infiniteness:

1 Devise a finite-state transition system ΘS that is a faithful abstractionof ΥS independent of the formula to verify.

2 Reduce the verification problem ΥS |= Φ to the verification of ΘS |= Φ.

Problem: Verification of DCDSs is undecidable even for propositionalreachability properties.; We need to pose restrictions on DCDSs.

We could draw inspiration from chase termination for tgds in data exchange,and specifically from weak-acyclicity.



Restrictions on DCDSs

Run-bounded DCDS

Runs cannot accumulate more than a fixed number of different values.

Transition system is still infinite-state due to infinite branching.

This is a semantic condition, whose checking is undecidable.; Sufficient syntactic condition: Weak-acyclicity.

Run-boundedness is very restrictive for DCDSs with nondeterministicservices.

State-bounded DCDS

States cannot contain more than a fixed number of different values.

Relaxation of run-boundedness.

Infinite runs are possible.

This is a semantic condition, whose checking is undecidable.; Sufficient syntactic condition: e.g., GR-acyclicity.



Verification formalisms for DCDSs

Boundedness is not sufficient for decidability.We introduce two extensions of the modal µ-calculus µL / LTL with restrictedforms of first order quantification.

History-Preserving quantification: µLA / LTL-FOA

FO quantification ranges over current active domain only.

Examples:LTL-FOA : ∀x.live(x) ∧ Customer(x)→ F Gold(x)

µLA : ∀x.live(x) ∧ Customer(x)→ µZ.Gold(x) ∨ [−]Z

Persistence-Preserving quantification: µLP / LTL-FOP

FO quantification ranges over persisting individuals only.

Examples:LTL-FOP : ∀x.live(x) ∧ Gold(x)→ G Gold(x)

µLP : ∀x.live(x) ∧ Gold(x)→ νZ.Gold(x) ∧ live(x) ∧ [−]Z

LTL

µL

µLFO/LTL-FO

µLA/LTL-FOA

µLP /LTL-FOP



Towards decidability

We need to tame the two sources of infinity inDCDSs:

infinite branching, due to external input;

infinite runs, i.e., runs visiting infinitelymany DBs.

P(a) P(a)

P(b)

. . .

. . .

. . .

. . .

To prove decidability of model checking for a specific restriction and a specificverification formalism:

We use bisimulation as a tool.

We show that restricted DCDSs have a finite-state bisimilar transitionsystem.



Bisimulation between transition systems

States sA and sB of transition systems A and B are bisimilar if:1 sA and sB are isomorphic;2 If there exists a state sA1 of A such that sA ⇒A sA1 , then there exists a

state sB1 of B such that sB ⇒B sB1 , and sA1 and sB1 are bisimilar;3 The other direction!

A and B are bisimilar, if their initial states are bisimilar.

A BsA sB

sA1 sB1

sB2sA2

µL invariance property of bisimulation:

Bisimilar transition systems satisfy the same set of µL properties.



Adapting the notion of bisimulation

History PreservingBisimulation Invariant Languages

Persistence PreservingBisimulation Invariant Languages

Bisimulation Invariant Languages

L

CTL

µL

LP

µLP

LA

µLA

µLFOP

rop

ositio

na

lT

emp

ora

lL

og

icsF

irstO

rder

Tem

po

ral

Lo

gics



Decidability of µL extensions for run-bounded systems

Theorem

Verification of µLA over run-bounded DCDSs is decidable and can be reducedto model checking of propositional µ-calculus over a finite transition system.

Idea: use isomorphic types instead ofactual values.

Remember: runs are bounded!

...

...

...

...

. . .

A-bisimilar

non A-bisimilar



Decidability of µL extensions for state-bounded systems

Theorem

Verification of µLP over state-bounded DCDSs is decidable and can be reducedto model checking of propositional µ-calculus over a finite transition system.

Steps:

1 Prune infinite branching (isomorphic types).2 Finite abstraction along the runs:

µLP looses track of previous values that do notexist anymore.New values can be replaced with old, non-persistingones.This eventually leads to recycle the old valueswithout generating new ones.

......

......

......

......

...

...

...

. . .

P-bisimilar

non P-bisimilar



What about LTL-FO?

For verification of LTL-FO over DCDSs, analogous decidability results hold:

Theorem

Verification of LTL-FOA over run-bounded DCDSs, andLTL-FOP over state-bounded DCDSs

are decidable and can be reduced to model checking of propositional LTL over afinite transition system.

Moreover:

Theorem

Verification of LTL-FOA over state-bounded DCDSs is undecidable.

Intuition: LTL-FOA can arbitrarily quantify over the infinitely many valuesencountered during a single run, and start comparing them.

Proof is based on a reduction from satisfiability of LTL with freeze quantifiersover infinite data words.



And verification of µLA over state-bounded DCDSs?

Well-known

Propositional LTL can be expressed in µL, i.e., the propositional µ-calculus.

Folklore “theorem” (see, e.g., [Okamoto 2010])

This correspondence carries over to the FO-variants, i.e., LTL-FO can beexpressed in µLFO.

Note: This, together with the undecidability of LTL-FOA verification overstate-bounded DCDSs, would imply that also:

Verification of µLA over state-bounded DCDSs is undecidable.



Verification of µLFO over state-bounded DCDSs

Instead, the following positive result holds:

Theorem

Verification of µLFO (and hence µLA) over state-bounded DCDSs is decidable.

Relies on the fact that DCDSs generate transition systems that are generic:Intuitively, if a state s has a successor state s′ with fresh values ~v, then ithas also all successor states that are obtained from s′ by varying in allpossible ways the fresh values ~v.This is a consequence of the fact that the progression mechanism isdefined by means of a logical specification.

Lemma

For generic TSs (with infinite domain), persistence-preserving bisimilarityand bisimilarity (and hence history-preserving bisimilarity) coincide.

For TSs of state-bounded DCDSs, we can devise finite state abstractionsthat are faithful for µLFO formulas (although such abstractions maydepend on the formula).



Results on decidability of verification for DCDSs

Un

rest

rict

edD

CD

Ss

(Tu

rin

gco

mp

lete

)

Sta

te-b

ou

nd

edD

CD

Ss

Ru

n-b

ou

nd

edD

CD

Ss

Fin

ite-

sta

teD

CD

Ss

GR+-acyclic DCDSs

GR-acyclic DCDSs

Weakly-acyclic DCDSsfor det. services

Finite-range DCDSs

Unrestricted State-bounded Run-bounded Finite-state

LTL-FO / µLFO U U / N ? / N D

LTL-FOA / µLA U U / N D D

LTL-FOP / µLP U D D D

LTL / µL U D D D

D: decidable U: undecidable N: decidable, but no finite abstraction









Semantically-Governed Artifact Systems (SASs)

The data layer in an artifact system might be very complex, and difficult tointeract with.

Hence we can resort to ontology-based technology and ontology-based dataaccess techniques to support users:

We install “on top” of an artifact system an ontology, capturing thedomain of interest at a higher level of abstraction.

We connect the ontology to the underlying artifact system via declarativemappings.

Such a setting gives rise to a very rich and still largely unexplored framework, inwhich we have various choices for:

the language used to express the ontology;

the form of the mappings, and the language used to express them;

the assumptions we make about the dynamics of the system;

the kind of analysis tasks we want to perfom.



Semantically-Governed Artifact Systems (SASs)

Artifacts System conceptual schema (TBox) composed of semantic constraintsthat define the “data boundaries” of the artifact system.

TBox



Semantic layer and snapshots

Actual data are concretely maintained at the artifact layer.Snapshot: database instances of artifacts.

Da

Db

Dc

Artifact System Snapshot

TBox

...



Mappings

Each snapshot is conceptualized in the ontology as instance data.Mappings define how to obtain the virtual ABox from the source data.

Da

Db

Dc


Mappings

TBox

ABox1

...



Action execution to evolve the system

The system evolves due to actions/process executed over the artifact layer,invoking external services to inject new data.

Da

Db

Dc


D'a

D'b

D'c


Mappings Mappings

Semantic Layer Snapshot

TBox

ABox1

TBox


ABox2

Transition... ...



Understanding the evolution

Semantic layer used to understand the evolution at the conceptual level,by posing queries over the ontology.

Da

Db

Dc


D'a

D'b

D'c


Mappings Mappings


TBox

ABox1

TBox


ABox2

Transition... ...

... ...

queries



Semantic Governance

Semantic layer used to regulate the execution of actions at the artifact layer byrejecting actions that lead to violations of constraints in the ontology.

Da

Db

Dc


D'a

D'b

D'c


Mappings Mappings


TBox

ABox1


...

ABox2

TBox

Transition



Temporal Verification over Semantic Layer

Temporal properties expressed as:

queries over the ontology combined with

temporal operators to talk about the dynamics of the system.

System evolves at the Artifact Layer.

Rewriting of temporal properties

The temporal part is maintained unaltered, because thesystem evolves at the Artifact Layer.

Faithful transformation of a temporal property overSemantic Layer:

1 Rewriting of ontology queries to compile away the TBox.2 Unfolding of temporal property wrt mappings to obtain a

corresponding temporal property over the Artifact Layer.

D

A

T

M

Q0 = rew(Q, T )

Q

unfold(Q0,M)

Hence, verification of temporal properties expressed over the ontology isreduced to verification of temporal properties over the artifacts.



Decidability of Verification over SASs

We obtain that the verification of (restricted first-order) temporal properties isdecidable, provided the transition system at the Artifact Layer satisfies suitableboundedness conditions.

Results

The following are decidable, and can be reduced to model checking ofpropositional LTL/mu-calculus over a finite transition system:

Verification of LTL-FOA/µLA properties over run-bounded SASs withdeterministic services.

Verification of LTL-FOP /µLP properties over state-bounded SASs (bothwith deterministic and with non-deterministic services).









Additional, ongoing, and future work

Dealing with state-boundedness:

relaxation of syntactic restrictionsboundedness “by design”

Further developments of the semantically enriched setting:

More sophisticated treatment of inconsistency w.r.t. the ontology[C., Kharlamov, et al. 2013; C., Montali, and Santoso 2015].Handling of contextual information [C., Ceylan, et al. 2014].Allow the system to evolve also at the semantic layer, and propagate theupdates to the artifact layer.

Enriching of the data model with ordered data types [C., Delzanno, and

Montali 2015].

Investigate how to deal with the exponential explosion w.r.t. the data.

Implementation of the approach on the top of a relational database[C., Montali, Patrizi, et al. 2015]. We aim at using state-of-the-artfinite-state model checkers.

Other reasoning services, e.g., composition, adversarial synthesis[C., De Giacomo, et al. 2013].



Acknowledgements

Thanks to my friends and colleagues with whom this work was carried out!

Babak Bagheri Hariri (graduated in Bolzano)

Giuseppe De Giacomo (Sapienza University of Rome)

Alin Deutsch (University of California San Diego)

Marco Montali (Bolzano)

Fabio Patrizi (Bolzano)

Ario Santoso (PhD student in Bolzano, graduating soon)



Thank you for your attention!


References References

References I

[1] Mathias Weske. Business Process Management: Concepts, Languages,Architectures. Springer, 2007. isbn: 9783540735212.

[2] Rob Karel, Clay Richardson, and Connie Moore. Warning: Don’t AssumeYour Business Processes Use Master Data – Synchronize Your BusinessProcess And Master Data Strategies. Report. Forrester, Sept. 2009.

[3] Andreas Meyer, Sergey Smirnov, and Mathias Weske. Data in BusinessProcesses. Tech. rep. 50. Available online athttp://opus.kobv.de/ubp/volltexte/2011/5304/.Hasso-Plattner-Institut for IT Systems Engineering, Universitat Potsdam,2011.

[4] Marlon Dumas. “On the Convergence of Data and Process Engineering”.In: Proc. 15th Int. Conf. of the Advances in Databases and InformationSystems (ADBIS). Vol. 6909. Lecture Notes in Computer Science.Springer, 2011, pp. 19–26. doi: 10.1007/978-3-642-23737-9_2.


http://opus.kobv.de/ubp/volltexte/2011/5304/

http://dx.doi.org/10.1007/978-3-642-23737-9_2


References II

[5] Manfred Reichert. “Process and Data: Two Sides of the Same Coin?” In:Proc. of the On the Move Confederated Int. Conf. (OTM 2012).Vol. 7565. Lecture Notes in Computer Science. Springer, 2012, pp. 2–19.doi: 10.1007/978-3-642-33606-5_2.

[6] Wil M. P. van der Aalst. “A Decade of Business Process ManagementConferences: Personal Reflections on a Developing Discipline”. In: Proc.of the 10th Int. Conf. on Business Process Management (BPM).Vol. 7481. Lecture Notes in Computer Science. Springer, 2012, pp. 1–16.

[7] Keishi Okamoto. “Comparing Expressiveness of First-Order Modalµ-calculus and First-Order CTL*”. In: RIMS Kokyuroku 1708 (2010),pp. 1–14.

[8] Diego C., Evgeny Kharlamov, et al. “Verification of Inconsistency-AwareKnowledge and Action Bases”. In: Proc. of the 23rd Int. Joint Conf. onArtificial Intelligence (IJCAI). 2013.

[9] Diego C., Marco Montali, and Ario Santoso. “Verification of GeneralizedInconsistency-Aware Knowledge and Action Bases”. In: Proc. of the 24thInt. Joint Conf. on Artificial Intelligence (IJCAI). 2015.


http://dx.doi.org/10.1007/978-3-642-33606-5_2


References III

[10] Diego C., Ismail Ilkan Ceylan, et al. “Verification of Context-SensitiveKnowledge and Action Bases”. In: Proc. of the 14th Eur. Conf. onLogics in Artificial Intelligence (JELIA). Vol. 8761. Lecture Notes inComputer Science. Springer, 2014, pp. 514–528.

[11] Diego C., Giorgio Delzanno, and Marco Montali. “Verification ofRelational Multiagent Systems with Data Types”. In: Proc. of the 29thAAAI Conf. on Artificial Intelligence (AAAI). AAAI Press, 2015,pp. 2031–2037. isbn: 9781577356981.

[12] Diego C., Marco Montali, Fabio Patrizi, et al. “ImplementingData-Centric Dynamic Systems over a Relational DBMS”. In: Proc. ofthe 9th Alberto Mendelzon Int. Workshop on Foundations of DataManagement (AMW). 2015.

[13] Diego C., Giuseppe De Giacomo, et al. “Verification and Synthesis inDescription Logic Based Dynamic Systems”. In: Proc. of the 7th Int.Conf. on Web Reasoning and Rule Systems (RR). Vol. 7994. LectureNotes in Computer Science. Springer, 2013, pp. 50–64.
