Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
A Challenging, though Necessary, Marriage
Marco Montali
Free University of Bozen-Bolzano
..
KRDB
1
Data and Processes:
PRE...
Our Starting Point
Marrying processes and data is a must if we
want to really understand how complex dynamic
systems opera...
Complex Systems Lifecycle
picture by Wil van der Aalst
Formal Verification
Automated analysis
of a formal model of the system
against a property of interest,
considering all poss...
Our Thesis
Knowledge representation and 

computational logics 



can become a swiss-army knife to



understand data-awa...
Warning!
Towards this goal, I believe we have to:
• foster cross-fertilization with related fields
such as database theory,...
Practice
PracticeBPMN
Declare
UML YAWL
AUML
FCL
GSM
ORM
CMMN
ACM
Bloom
JADE
Dedalus
E-R
OWL
EPC
JASON
BPEL
SQL
SBVR
+ methodologies
Theory
Theory
Theoremeorem
Theorem
Theorem
Theorem
Theorem
Theorem
Theorem
Theorem
TheoremTheorem
Theorem
Our Approach
1. Develop formal models for data-aware dynamic systems
2. Show that they can capture concrete modeling langu...
Outline: 3 Acts
1. Loneliness
2. Marriage
3. Hate and love ? ?
Loneliness
Act 1
The Three Pillars of Complex Systems
System
ProcessesData Resources
In AI and CS, we know a lot about each pillar!
Information Assets
• Data: the main information source about the history
of the domain of interest and the relevant aspect...
State of the Art
• Traditional isolation between processes and data
• Why? To attack the complexity (divide et impera)
• A...
Application Domains
Data Process
Business
Process
Management
• Information system • Activities + events
• Control-flow
cons...
Loneliness in BPM
Data/Process Fragmentation
• A business process consists of a set of activities that
are performed in coordination in an o...
Experts Dichotomy
• BPM professionals: think that data are subsidiary to
processes, and neglect the importance of data qua...
Conventional Data Modeling
Focus: revelant entities, relations, static constraints
Supplier ManufacturingProcurement/Suppl...
Conventional Process Modeling
Focus: control-flow of activities in response to events
But… how do activities update data?
W...
Do you like Spaghetti?
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
Activities
Process
Data
A...
The Need of Conceptual Integration
• [Meyer et al, 2011]: data-process integration
crucial to assess the value of processe...
Business Entities/Artifacts
Data-centric paradigm for process modeling
• First: elicitation of relevant business entities ...
Loneliness in 

Social Commitments
Social Commitments
Semantics for agent interaction that abstracts
away from the internal agent implementation
• [Castelfra...
Conditional Commitments
• When condition ɸ holds, the debtor agent
becomes committed towards the creditor
agent to make co...
Literature Example
• Contract between Bob (seller) and Alice (customer):
• Actions available to agents:
CC(bob,alice,item_...
Literature Example
• Contract between Bob (seller) and Alice (customer):
• Actions available to agents:
CC(bob,alice,item_...
Reality
• Multiple customers, sellers, items

—> Many-to-many business relations established
as instances of the same cont...
From the Literature to Reality
(At least) two fixes required [Montali et al, 2014]:
1. Agent actions/messages must carry an...
Formal Verification
The Conventional, Propositional Case
Process control-flow
Agent behaviors/protocols
(Un)desired property
(Un)desired property
Finite-state
transition
system
Propositional
temporal formula|=
Formal Verification
The Conventional, ...
(Un)desired property
Finite-state
transition
system
Propositional
temporal formula|=
Verification
via model checking
2007 T...
Marriage
Act 2
Process+Data
Data-aware agent behaviors/protocols
(Un)desired property
Formal Verification
The Data-Aware Case
(Un)desired property
First-order
temporal formula|=
Process+Data
Data-aware agent behaviors/protocols
Formal Verification
T...
(Un)desired property
Infinite-state, relational
transition system
First-order
temporal formula|=
?
Process+Data
Data-aware ...
Why FO Temporal Logics
• To inspect data: FO queries
• To capture system dynamics: temporal
modalities
• To track the evol...
Problem Dimensions
Data
component
Relational
DB
Description
logic KB
OBDA system Inconsistency
tolerant KB
…
Process
compo...
Declarative Distributed Computing
Distributed, data-centric computing 

with extensions of Datalog
• Pushed the renaissanc...
Declarative Distributed Systems
(DDS)
We consider fixed,
connected graphs
input
transport
state
D2C
program
Declarative Distributed Systems
(DDS)
D2C Programs
• Datalog programs extended with
• non-determinism: choice construct 

[Saccà and Zaniolo, 1990]
• time: prev...
Node Reactive Behavior
Whenever a node receives (a set of) incoming
messages, it performs a transition:
1. Incoming messag...
Execution Semantics
Relational transition systems with node-indexed databases



Successors constructed considering all po...
Sources of Infinity
…
………
Sources of Infinity
…
………
Infinite-branching 

due to external input
Sources of Infinity
…
………
Runs visiting infinitely many DBs 

due to usage of external input
Pure Declarative Semantics
• Runs of closed DDS can be simulated using standard
ASP solvers
• D2C programs are compiled in...
Classes
synchronous
global clock
asynchronous ordered
interleaving semantics
closed
no input
finite-state 

transition syst...
Classes
synchronous
global clock
asynchronous ordered
interleaving semantics
closed
no input
finite-state
transition system...
Example
Construction of a rooted spanning tree of the
network
• State schema: keeps neighbors and parent
• Transport schem...
Example
• When multiple neighbors request to join, pick one
as a parent if you don’t already have one:
parent(P) if choice...
Another Example
Warehouse manager
Seller
Customer
newItem(Barcode,Type)
available(Barcode,Type)
askAv(Type)
reply(yes/no)
...
Another Example
available(B,T) if chkWare@self,

newItem(B,T).
Warehouse manager
Seller
Customer
newItem(Barcode,Type)
ava...
Another Example
inCat(T) if available(_,T).
reply@C(yes) if askAv@C(T),

inCat(T).
reply@C(no) if askAv@C(T),

not inCat(T...
Domain-specific properties: CTL-FO or LTL-FO
with active domain quantification
• Maintain:
• Broadcast:
Generic properties: ...
Hate and Love
Act 3
No injection of data from the external world:
• system inherently finite-state
• FO: just a nice “surface syntax”
• “direct...
Still, convergence is PSPACE-hard,
without any assumption on the
network topology:
1. Elect a leader
2. Construct a tree r...
Interactive DDS:
the Hard Case
A node is computing machine
with a finite-state control process
and an unbounded memory. 

S...
Interactive DDS:
the Hard Case
A node is computing machine
with a finite-state control process
and an unbounded memory. 

S...
Size-Boundedness
Intuition: put a pre-defined bound on the DB size
• Extensively studied over the last years - cf. ACSI
pro...
Does Size-Boundedness Help?
Interactive DDS, linear-time case
input
bounded
state/transport bounded
N/Y Y/N Y/Y
N
converge...
Reasons for Undecidability
(State Unbounded)
Simulation of a 2-counter Minsky machine
• Single node with 2 unary relations...
Reasons for Undecidability
(State/Transport/Input Bounded)
• Take a DDS with:
• a single node
• two unary, 1-bounded relat...
FO-LTL with
Persistent Quantification
• Intuition: control the ability of the logic to quantify
across snapshots
• Only obj...
Size-Boundedness to the Rescue
Interactive DDS, linear-time case 

with persistent quantification
input
bounded
state/trans...
DDS Key Properties
DDS (and other similar data-aware dynamic
systems) enjoy two key properties: they are…
• Markovian: Nex...
Pruning Infinite-Branching
• Consider a system snapshot and its node DBs
• Input is bounded —> only boundedly many
isomorph...
Example
• Input: single unary relation, 1-bounded
• Current state: two objects
a,b
a
b
c
de
Example
• Input: single unary relation, 1-bounded
• Current state: two objects
a,b
a
b
c
Compacting Infinite Runs
• Key observation: due to persistent quantification, the
logic is unable to distinguish local fresh...
Compacting Infinite Runs
• [Calvanese et al, 2013]: if the system is size-
bounded, the recycling technique reaches a
point...
Recap
Prune Recycle
Recap
• Input: interactive DDS whose node DBs are all size-
bounded
• Construct the abstract transition system that works ...
Conclusion
Marriage between processes and data
is challenging, though necessary
• Size-boundedness is a robust condition t...
Current and Future Work
• Implementations, leveraging the long-standing
literature in data management and formal verificati...
Acknowledgments
All coauthors of this research, 

in particular 



Diego Calvanese

Giuseppe De Giacomo 

Alin Deutsch

J...
Acknowledgments
AI*IA 



The AI*IA “2015 Somalvico Award” Committee
The external supporters of my nomination:

Wil van de...
Acknowledgments
Paola Mello 

Diego Calvanese

The AI group @ DISI-UNIBO

The KRDB Group @ UNIBZ

My colleagues in 

Ferra...
Acknowledgments
My
(unbounded)
family
AIxIA2015 - Marco Somalvico Award 2015 - Montali - Data and Processes: a Challenging, though Necessary, Marriage
Upcoming SlideShare
Loading in …5
×

AIxIA2015 - Marco Somalvico Award 2015 - Montali - Data and Processes: a Challenging, though Necessary, Marriage

192 views

Published on

Invited talk on "Data and Processes: a Challenging, though Necessary, Marriage" at the 14th Italian Conference on Artificial Intelligence (#AI4), related to the "Marco Somalvico 2015 Award".

  • Be the first to comment

  • Be the first to like this

AIxIA2015 - Marco Somalvico Award 2015 - Montali - Data and Processes: a Challenging, though Necessary, Marriage

  1. 1. A Challenging, though Necessary, Marriage Marco Montali Free University of Bozen-Bolzano .. KRDB 1 Data and Processes: PREMIO AI*IA “MARCO SOMALVICO” 2015
  2. 2. Our Starting Point Marrying processes and data is a must if we want to really understand how complex dynamic systems operate Dynamic systems of interest: • business processes • multiagent systems • distributed systems
  3. 3. Complex Systems Lifecycle picture by Wil van der Aalst
  4. 4. Formal Verification Automated analysis of a formal model of the system against a property of interest, considering all possible system behaviors picture by Wil van der Aalst
  5. 5. Our Thesis Knowledge representation and 
 computational logics 
 
 can become a swiss-army knife to
 
 understand data-aware dynamic systems, and 
 provide automated reasoning and verification capabilities along their entire lifecycle
  6. 6. Warning! Towards this goal, I believe we have to: • foster cross-fertilization with related fields such as database theory, formal methods, business process management, information systems • systematically classify the sources of undecidability and complexity, so as to attack them when developing concrete tools • continuously validate how foundational results relate to practice
  7. 7. Practice
  8. 8. PracticeBPMN Declare UML YAWL AUML FCL GSM ORM CMMN ACM Bloom JADE Dedalus E-R OWL EPC JASON BPEL SQL SBVR + methodologies
  9. 9. Theory
  10. 10. Theory Theoremeorem Theorem Theorem Theorem Theorem Theorem Theorem Theorem TheoremTheorem Theorem
  11. 11. Our Approach 1. Develop formal models for data-aware dynamic systems 2. Show that they can capture concrete modeling languages 3. Outline a map of (un)decidability and complexity 4. Find robust conditions for decidability/tractability 5. Bring them back into practice 6. Implement proof-of-concept prototypes
  12. 12. Outline: 3 Acts 1. Loneliness 2. Marriage 3. Hate and love ? ?
  13. 13. Loneliness Act 1
  14. 14. The Three Pillars of Complex Systems System ProcessesData Resources In AI and CS, we know a lot about each pillar!
  15. 15. Information Assets • Data: the main information source about the history of the domain of interest and the relevant aspects of the current state of affairs • Processes: how work is carried out in the domain of interest, leading to evolve data • Resources: humans and devices responsible for the execution of work units within a process We focus on the first two aspects!
  16. 16. State of the Art • Traditional isolation between processes and data • Why? To attack the complexity (divide et impera) • AI has greatly contributed to these two aspects • Data: knowledge bases, conceptual models, ontologies, ontology-based data access and integration, inconsistency-tolerant semantics, … • Processes: reasoning about actions, temporal/ dynamic logics, situation/event calculus, temporal reasoning, planning, verification, synthesis, …
  17. 17. Application Domains Data Process Business Process Management • Information system • Activities + events • Control-flow constraints • External inputs Multiagent Systems • Knowledge of agents • Institutional knowledge • Speech acts • Creation of new objects • Interaction protocols Distributed Systems • Facts maintained by the system nodes • Exchanged messages • Application-level inputs • Node computations
  18. 18. Loneliness in BPM
  19. 19. Data/Process Fragmentation • A business process consists of a set of activities that are performed in coordination in an organizational and technical environment [Weske, 2007] • Activities change the real world • The corresponding updates are reflected into the organizational information system(s) • Data trigger decision-making, which in turn determines the next steps to be taken in the process • Survey by Forrester [Karel et al, 2009]: lack of interaction between data and process experts
  20. 20. Experts Dichotomy • BPM professionals: think that data are subsidiary to processes, and neglect the importance of data quality • Master data managers: claim that data are the main driver for the company’s existence, and they only focus on data quality • Forrester: in 83/100 companies, no interaction at all between these two groups • This isolation propagates to languages and tools, which never properly account for the process-data connection
  21. 21. Conventional Data Modeling Focus: revelant entities, relations, static constraints Supplier ManufacturingProcurement/Supplier Sales Customer PO Line Item Work OrderMaterial PO * * spawns 0..1 Material But… how do data evolve? Where can we find the “state” of a purchase order?
  22. 22. 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?
  23. 23. Do you like Spaghetti? Manage Cancelation ShipAssemble Manage Material POs Decompose Customer 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: difficult to manage, understand, evolve
  24. 24. The Need of Conceptual Integration • [Meyer et al, 2011]: data-process integration crucial to assess the value of processes and evaluate KPIs • [Dumas, 2011]: data-process integration crucial to aggregate all relevant information, and to suitably inject business rules into the system • [Reichert, 2012]: “Process and data are just two sides of the same coin”
  25. 25. Business Entities/Artifacts Data-centric paradigm for process modeling • First: elicitation of relevant business entities that are evolved within given organizational boundaries • Then: definition of the lifecycle of such entities, and how tasks trigger the progression within the lifecycle • Active research area, with concrete languages (e.g., IBM GSM, OMG CMMN) • Cf. EU project ACSI (completed)
  26. 26. Loneliness in 
 Social Commitments
  27. 27. Social Commitments Semantics for agent interaction that abstracts away from the internal agent implementation • [Castelfranchi 1995]: social commitments as a mediator between an individual and its “normative” relation with other agents • Extensively adopted for flexible specification of multiagent interaction protocols, business contracts, interorganizational business processes (cf. work by Singh et al)
  28. 28. Conditional Commitments • When condition ɸ holds, the debtor agent becomes committed towards the creditor agent to make condition ᴪ true • Agents change the state of affairs implicitly causing conditions to become true/false • Commitments are consequently progressed reflecting the normative state of the interaction CC(debtor,creditor,ɸ,ᴪ)
  29. 29. Literature Example • Contract between Bob (seller) and Alice (customer): • Actions available to agents: CC(bob,alice,item_paid,item_owned) pay_with_cc causes item_paid send_by_courier causes item_owned deliver_manually causes item_owned
  30. 30. Literature Example • Contract between Bob (seller) and Alice (customer): • Actions available to agents: CC(bob,alice,item_paid,item_owned) pay_with_cc causes item_paid send_by_courier causes item_owned deliver_manually causes item_owned Is this satisfactory???
  31. 31. Reality • Multiple customers, sellers, items
 —> Many-to-many business relations established as instances of the same contractual commitment • Need of co-referencing commitment instances through agents and the exchanged data • If Bob gets paid by Alice for a laptop, then Bob is commitment to ensure that Alice owns that laptop • More in general, see work by Ferrario and Guarino on service foundations
  32. 32. From the Literature to Reality (At least) two fixes required [Montali et al, 2014]: 1. Agent actions/messages must carry an explicit data payload (Alice pays an item with cc) 2. Commitments and dynamics have to become data-aware forall Seller S, Customer C, Item I. CC(S,C,Paid(C,I,S),Owned(C,I))
  33. 33. Formal Verification The Conventional, Propositional Case Process control-flow Agent behaviors/protocols (Un)desired property
  34. 34. (Un)desired property Finite-state transition system Propositional temporal formula|= Formal Verification The Conventional, Propositional Case Process control-flow Agent behaviors/protocols
  35. 35. (Un)desired property Finite-state transition system Propositional temporal formula|= Verification via model checking 2007 Turing award: Clarke, Emerson, Sifakis Formal Verification The Conventional, Propositional Case Process control-flow Agent behaviors/protocols
  36. 36. Marriage Act 2
  37. 37. Process+Data Data-aware agent behaviors/protocols (Un)desired property Formal Verification The Data-Aware Case
  38. 38. (Un)desired property First-order temporal formula|= Process+Data Data-aware agent behaviors/protocols Formal Verification The Data-Aware Case Infinite-state, relational transition system [Vardi 2005]
  39. 39. (Un)desired property Infinite-state, relational transition system First-order temporal formula|= ? Process+Data Data-aware agent behaviors/protocols Formal Verification The Data-Aware Case
  40. 40. Why FO Temporal Logics • To inspect data: FO queries • To capture system dynamics: temporal modalities • To track the evolution of objects: FO quantification across states • Example: It is always the case that every order is eventually either cancelled or paid and then delivered
  41. 41. Problem Dimensions Data component Relational DB Description logic KB OBDA system Inconsistency tolerant KB … Process component condition- action rules ECA-like rules Golog program … Task modeling Conditional effects Add/delete assertions Logic 
 programs … External inputs None External services Input DB Fixed input … Network topology Single orchestrator Full mesh Connected, fixed graph … Interaction mechanism None Synchronous Asynchronous and ordered …
  42. 42. Declarative Distributed Computing Distributed, data-centric computing 
 with extensions of Datalog • Pushed the renaissance of Datalog [Loo et al, 2009] [Hellerstein, 2010] • Compares well with standard approaches [Loo et al, 2005] • Many applications: distributed query processing, distributed business processes, web data management, routing algorithms, software-defined networking, …
  43. 43. Declarative Distributed Systems (DDS) We consider fixed, connected graphs
  44. 44. input transport state D2C program Declarative Distributed Systems (DDS)
  45. 45. D2C Programs • Datalog programs extended with • non-determinism: choice construct 
 [Saccà and Zaniolo, 1990] • time: prev construct to refer to the previous state location: @ construct to refer the sender/receiver nodes • Stable model semantics • Each node has initial knowledge about its neighbors, and starts with a given state DB • Input relations are read-only, and may inject fresh data from an infinite data domain (strings, pure names, …)
  46. 46. Node Reactive Behavior Whenever a node receives (a set of) incoming messages, it performs a transition: 1. Incoming messages form the new transport DB 2. The current input DB is incorporated 3. Stable models are computed 4. The node nondeterministically evolves by updating its state and transport with the content of one of the stable models 5. The messages contained in the newly obtained transport DB are sent to the destination nodes
  47. 47. Execution Semantics Relational transition systems with node-indexed databases
 
 Successors constructed considering all possible input DBs and all possible internal choices of nodes … …… …
  48. 48. Sources of Infinity … ………
  49. 49. Sources of Infinity … ……… Infinite-branching 
 due to external input
  50. 50. Sources of Infinity … ……… Runs visiting infinitely many DBs 
 due to usage of external input
  51. 51. Pure Declarative Semantics • Runs of closed DDS can be simulated using standard ASP solvers • D2C programs are compiled into Datalog by • Transforming @ into an additional predicate argument • Priming relations for simulating prev • Transforming transport predicates into send/receive predicates • Additional rules for causality via vector clocks • Additional rules for the semantics of the communication model
  52. 52. Classes synchronous global clock asynchronous ordered interleaving semantics closed no input finite-state 
 transition system infinite-state 
 transition system interactive continuous input infinite-state 
 transition system infinite-state 
 transition system
  53. 53. Classes synchronous global clock asynchronous ordered interleaving semantics closed no input finite-state transition system infinite-state 
 transition system interactive continuous input infinite-state 
 transition system infinite-state 
 transition system
  54. 54. Example Construction of a rooted spanning tree of the network • State schema: keeps neighbors and parent • Transport schema: asks neighbor to become a child
  55. 55. Example • When multiple neighbors request to join, pick one as a parent if you don’t already have one: parent(P) if choice(X,P), join@X, 
 prev not parent(_). • If you have just joined the tree, flood the join request to neighbors (the parent will ignore it): join@N if parent(_), neighbor(N),
 prev not parent(_). • Parent information is kept: parent(P) if prev parent(P).
  56. 56. Another Example Warehouse manager Seller Customer newItem(Barcode,Type) available(Barcode,Type) askAv(Type) reply(yes/no) chkWare Customer
  57. 57. Another Example available(B,T) if chkWare@self,
 newItem(B,T). Warehouse manager Seller Customer newItem(Barcode,Type) available(Barcode,Type) askAv(Type) reply(yes/no) chkWare Customer
  58. 58. Another Example inCat(T) if available(_,T). reply@C(yes) if askAv@C(T),
 inCat(T). reply@C(no) if askAv@C(T),
 not inCat(T). Warehouse manager Seller Customer newItem(Barcode,Type) available(Barcode,Type) askAv(Type) reply(yes/no) chkWare Customer
  59. 59. Domain-specific properties: CTL-FO or LTL-FO with active domain quantification • Maintain: • Broadcast: Generic properties: convergence • Check whether the system 
 always/sometimes reaches quiescence with some/all nodes in a non-faulty state Interesting Questions G(8x.(9n.R@n(~x)) ! F8n0 .R@n0 (~x)) G(8n, p.Parent@n(p) ! GParent@n(p))
  60. 60. Hate and Love Act 3
  61. 61. No injection of data from the external world: • system inherently finite-state • FO: just a nice “surface syntax” • “direct” usage of conventional model checking techniques Closed DDS: the “Easy” Case
  62. 62. Still, convergence is PSPACE-hard, without any assumption on the network topology: 1. Elect a leader 2. Construct a tree rooted in the leader 3. Linearize the tree 4. Compute a corridor tiling problem Closed DDS: the “Easy” Case
  63. 63. Interactive DDS: the Hard Case A node is computing machine with a finite-state control process and an unbounded memory. 
 So what is it? A Turing machine I.e., You are doomed to undecidability, even for propositional reachability!
  64. 64. Interactive DDS: the Hard Case A node is computing machine with a finite-state control process and an unbounded memory. 
 So what is it? A Turing machine I.e., You are doomed to undecidability, even for propositional reachability!
  65. 65. Size-Boundedness Intuition: put a pre-defined bound on the DB size • Extensively studied over the last years - cf. ACSI project (under the name of “state-boundedness”) • In general, the resulting transition system is still infinite-state (even when all relations are 1- bounded) • In DDS we can selectively bound state, transport, input!
  66. 66. Does Size-Boundedness Help? Interactive DDS, linear-time case input bounded state/transport bounded N/Y Y/N Y/Y N convergence undecidable model checking FO-LTL undecidable Y
  67. 67. Reasons for Undecidability (State Unbounded) Simulation of a 2-counter Minsky machine • Single node with 2 unary relations C1 and C2 • 1-bounded, single unary input relation New • Increment counter1: • check whether New contains an object not in C1 • if not, enter into an error state • if so, insert it in C1 • Decrement counter1: pick an object in C1 and remove it • Test counter1 for zero: check that C1 is empty New C1 C1
  68. 68. Reasons for Undecidability (State/Transport/Input Bounded) • Take a DDS with: • a single node • two unary, 1-bounded relations: one for input, one for state • a D2C program that just overwrites the state with the input • It generates all infinite data words over the infinite data domain • Satisfiability of LTL with freeze quantifier is undecidable [Demri and Lazic, 2006], and can be encoded as FO-LTL model checking over this DDS • Undecidability comes from the extreme power of FO quantification across snapshots: variables can store unbounded information!
  69. 69. FO-LTL with Persistent Quantification • Intuition: control the ability of the logic to quantify across snapshots • Only objects that persist in the active domain of some node can be tracked • When an object is lost, the formula trivializes to true or false • E.g.: “guarded” until Persistence-Preserving µ-calculus (µLP) In some cases, objects maintain their identity only if they persist in th active domain (cf. business artifacts and their IDs). . . . StudId : 123 . . . StudId : 123 . . .dismiss(123) newStud() ID() = 123 µLA µLFOG(8s.Student(s) ! Student(s)U(Retired(s) _ Graduated(s)))
  70. 70. Size-Boundedness to the Rescue Interactive DDS, linear-time case 
 with persistent quantification input bounded state/transport bounded N/Y Y/N Y/Y N convergence undecidable model checking FO-LTL with persistence PSPACE- complete Y
  71. 71. DDS Key Properties DDS (and other similar data-aware dynamic systems) enjoy two key properties: they are… • Markovian: Next state only depends on the current state + input. 
 Two states with identical node DBs are bisimilar. • Generic: Datalog (as all query language) does not distinguish structures which are identical modulo uniform renaming of data objects. —> Two isomorphic DDS snapshots are bisimilar
  72. 72. Pruning Infinite-Branching • Consider a system snapshot and its node DBs • Input is bounded —> only boundedly many isomorphic types relating the input objects and those in the DDS active domain • Input configurations in the same isomorphic type produce isomorphic snapshots • Keep only one representative successor state per isomorphic type • The “pruned” transition system is finite- branching and bisimilar to the original one
  73. 73. Example • Input: single unary relation, 1-bounded • Current state: two objects a,b a b c de
  74. 74. Example • Input: single unary relation, 1-bounded • Current state: two objects a,b a b c
  75. 75. Compacting Infinite Runs • Key observation: due to persistent quantification, the logic is unable to distinguish local freshness from global freshness • So we modify the transition system construction: 
 whenever we need to consider a fresh representative object… • … if there is an old object that can be recycled 
 —> use that one • … if not —> pick a globally fresh object • This recycling technique preserves bisimulation!
  76. 76. Compacting Infinite Runs • [Calvanese et al, 2013]: if the system is size- bounded, the recycling technique reaches a point were no new objects are needed
 —> finite-state transition system • N.B.: the technique does not need to know the value of the bound
  77. 77. Recap Prune Recycle
  78. 78. Recap • Input: interactive DDS whose node DBs are all size- bounded • Construct the abstract transition system that works over isomorphic types and recycles old objects • The abstract transition system is • finite-state • a faithful representation of the original one • Use the abstract system to model check “persistent” FO- LTL formulae using conventional techniques (PSPACE upper bound)
  79. 79. Conclusion Marriage between processes and data is challenging, though necessary • Size-boundedness is a robust condition towards the effective verifiability of such systems • The same results hold in by enriching the data component (ontologies, constraints, inconsistency-tolerance, …) • Same formal model for execution and verification
  80. 80. Current and Future Work • Implementations, leveraging the long-standing literature in data management and formal verification • Emphasis on other reasoning services: monitoring, planning, adversarial synthesis • Relaxations of size-boundedness, with the help of • Parameterized verification • Verification via underapproximation • Conceptual conditions that hold in practice
  81. 81. Acknowledgments All coauthors of this research, 
 in particular 
 
 Diego Calvanese
 Giuseppe De Giacomo 
 Alin Deutsch
 Jorge Lobo 
 Fabio Patrizi
  82. 82. Acknowledgments AI*IA 
 
 The AI*IA “2015 Somalvico Award” Committee The external supporters of my nomination:
 Wil van der Aalst
 Thomas Eiter
 Munindar Singh
  83. 83. Acknowledgments Paola Mello 
 Diego Calvanese
 The AI group @ DISI-UNIBO
 The KRDB Group @ UNIBZ
 My colleagues in 
 Ferrara, Rome, Eindhoven, Tartu, Uppsala
  84. 84. Acknowledgments My (unbounded) family

×