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
..
KRDB
1
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 and
processes:
Data are the main information source about the history of the domain of
interest, and about the relevant aspects of the current state of aﬀairs.
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
reﬂected into the organizational information system(s).
Data trigger decision-making, which in turn determines the next steps
to 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 Conclusions

Experts’ dichotomy
Survey by Forrester [Karel, Richardson, and Moore 2009]: lack of interaction
between data and process experts:
Business process management professionals: think that data are
subsidiary to processes, and neglect importance of data quality.
Data management experts: claim that data are the main driver of the
organizational 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 properly
account 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
*
*
spawns
0..1
Material
But. . . how do data evolve?
Where can we ﬁnd the “state” of a purchase order?

The other side: conventional process modeling
Focus: control ﬂow 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
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: system is diﬃcult 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
*
*
spawns
0..1
Determine
cancelation
penalty
Notify penalty
Material
Process Engine
Process State
Business rules
For 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
Artiﬁcial Intelligence, traditionally has given important contributions to both
settings:
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, veriﬁcation,
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 modeling
community as well.
Data-process integration is crucial to assess the value of processes and
evaluate 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 of
processes 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, and
computational properties.
2 Enable static analysis of such formalisms.

5 Conclusions

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 influential
topic 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.

Veriﬁcation of complex system behaviour
Automated analysis of a
formal 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 the
system of interest is (implicitly or explicitly) represented.
The temporal logic formulas are checked (i.e., evaluated) over the
transition 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!

5 Conclusions

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 eﬃcient.

Business entities/artifacts
Data-centric paradigm for process modeling.
First: elicitation of relevant business entities that are evolved within
given organizational boundaries.
Then: deﬁnition of the lifecycle of such entities, and how tasks trigger
the progression within the lifecycle.
Information model Lifecycle Artifact
Is an active research area, with concrete languages (e.g., IBM GSM, OMG
CMMN).
Cf. EU project ACSI (2010–2013).
a

iSC


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 process
systems (e.g., GSM).
Data Process Data+Process
Data Layer: Relational databases / ontologies
Data schema, specifying constraints on the allowed states
Data instance: state of the DCDS
Process Layer: key elements are
Atomic actions
Condition-action-rules for application of actions
Service calls: communication with external environment, new data!

Deterministic vs. non-deterministic services
DCDSs admit two diﬀerent semantics for service-execution:
Deterministic services semantics
Along a run, when the same service is called again with the same arguments, it
returns the same result as in the previous call.
Are used to model an environment whose behavior is completely determined by
the 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, it
may return a diﬀerent value than in the previous call.
Are used to model:
an environment whose behavior is determined by parameters that are
outside the control of the system;
input of external users, whose choices depend on external factors.
Example: current temperature, given the location

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 −→ 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 = c −→ 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 eur
h2 eur
PEntry
h1 95 apr-25
h1 80 sep-18
h2 80 sep-18
HC
h1 eur
h2 eur
PEntry
h1 95 apr-25
h1 80 sep-18
h2 80 sep-18
Cur
usd
HC
h1 usd
h2 eur
PEntry
h1 115 apr-25
h1 95 sep-18
h2 80 sep-18
Cur
usd
HC
h1 usd
h2 usd
PEntry
h1 115 apr-25
h1 95 sep-18
h2 95 sep-18
Cur
usd
ChooseCur(): uInputCurr() = usd
ApplyConv(h1,usd):
conv(95,eur,usd,apr-25) = ?115
conv(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.

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 abstraction
of Υ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 propositional
reachability 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 nondeterministic
services.
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 restricted
forms 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 in
DCDSs:
infinite branching, due to external input;
infinite runs, i.e., runs visiting infinitely
many DBs.
P(a) P(a)
P(b)
. . .
. . .
. . .
. . .
To prove decidability of model checking for a specific restriction and a specific
verification formalism:
We use bisimulation as a tool.
We show that restricted DCDSs have a finite-state bisimilar transition
system.

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 sA
1 of A such that sA
⇒A sA
1 , then there exists a
state sB
1 of B such that sB
⇒B sB
1 , and sA
1 and sB
1 are bisimilar;
3 The other direction!
A and B are bisimilar, if their initial states are bisimilar.
A B
sA
sB
sA
1 sB
1
sB
2sA
2
µL invariance property of bisimulation:
Bisimilar transition systems satisfy the same set of µL properties.

Adapting the notion of bisimulation
History Preserving
Bisimulation Invariant Languages
Persistence Preserving
L
CTL
µL
LP
µLP
LA
µLA
µLFO
Propositional
TemporalLogics
FirstOrder
TemporalLogics

Decidability of µL extensions for run-bounded systems
Theorem
Veriﬁcation of µLA over run-bounded DCDSs is decidable and can be reduced
to model checking of propositional µ-calculus over a ﬁnite transition system.
Idea: use isomorphic types instead of
actual 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 reduced
to 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 not
exist anymore.
New values can be replaced with old, non-persisting
ones.
This eventually leads to recycle the old values
without 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, and
LTL-FOP over state-bounded DCDSs
are decidable and can be reduced to model checking of propositional LTL over a
finite transition system.
Moreover:
Theorem
Verification of LTL-FOA over state-bounded DCDSs is undecidable.
Intuition: LTL-FOA can arbitrarily quantify over the infinitely many values
encountered during a single run, and start comparing them.
Proof is based on a reduction from satisfiability of LTL with freeze quantifiers
over 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 be
expressed in µLFO.
Note: This, together with the undecidability of LTL-FOA verification over
state-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 it
has also all successor states that are obtained from s by varying in all
possible ways the fresh values v.
This is a consequence of the fact that the progression mechanism is
defined by means of a logical specification.
Lemma
For generic TSs (with infinite domain), persistence-preserving bisimilarity
and bisimilarity (and hence history-preserving bisimilarity) coincide.
For TSs of state-bounded DCDSs, we can devise finite state abstractions
that are faithful for µLFO formulas (although such abstractions may
depend on the formula).

Results on decidability of veriﬁcation for DCDSs
UnrestrictedDCDSs(Turingcomplete)
State-boundedDCDSs
Run-boundedDCDSs
Finite-stateDCDSs
GR+
-acyclic DCDSs
GR-acyclic DCDSs
Weakly-acyclic DCDSs
for 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 ﬁnite abstraction

5 Conclusions

Semantically-Governed Artifact Systems (SASs)
The data layer in an artifact system might be very complex, and diﬃcult to
interact with.
Hence we can resort to ontology-based technology and ontology-based data
access techniques to support users:
We install “on top” of an artifact system an ontology, capturing the
domain of interest at a higher level of abstraction.
We connect the ontology to the underlying artifact system via declarative
mappings.
Such a setting gives rise to a very rich and still largely unexplored framework, in
which 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 constraints
that deﬁne 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 deﬁne 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 by
rejecting 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 the
system evolves at the Artifact Layer.
Faithful transformation of a temporal property over
Semantic 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 is
reduced to verification of temporal properties over the artifacts.

Decidability of Verification over SASs
We obtain that the verification of (restricted first-order) temporal properties is
decidable, provided the transition system at the Artifact Layer satisfies suitable
boundedness conditions.
Results
The following are decidable, and can be reduced to model checking of
propositional LTL/mu-calculus over a finite transition system:
Verification of LTL-FOA/µLA properties over run-bounded SASs with
deterministic services.
Verification of LTL-FOP /µLP properties over state-bounded SASs (both
with deterministic and with non-deterministic services).

5 Conclusions

Additional, ongoing, and future work
Dealing with state-boundedness:
relaxation of syntactic restrictions
boundedness “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 the
updates 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-art
ﬁnite-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 Assume
Your Business Processes Use Master Data – Synchronize Your Business
Process And Master Data Strategies. Report. Forrester, Sept. 2009.
[3] Andreas Meyer, Sergey Smirnov, and Mathias Weske. Data in Business
Processes. Tech. rep. 50. Available online at
http://opus.kobv.de/ubp/volltexte/2011/5304/.
Hasso-Plattner-Institut for IT Systems Engineering, Universit¨at Potsdam,
2011.
[4] Marlon Dumas. “On the Convergence of Data and Process Engineering”.
In: Proc. 15th Int. Conf. of the Advances in Databases and Information
Systems (ADBIS). Vol. 6909. Lecture Notes in Computer Science.
Springer, 2011, pp. 19–26. doi: 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 Management
Conferences: 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-Aware
Knowledge and Action Bases”. In: Proc. of the 23rd Int. Joint Conf. on
Artificial Intelligence (IJCAI). 2013.
[9] Diego C., Marco Montali, and Ario Santoso. “Verification of Generalized
Inconsistency-Aware Knowledge and Action Bases”. In: Proc. of the 24th
Int. Joint Conf. on Artificial Intelligence (IJCAI). 2015.

References III
[10] Diego C., Ismail Ilkan Ceylan, et al. “Verification of Context-Sensitive
Knowledge and Action Bases”. In: Proc. of the 14th Eur. Conf. on
Logics in Artificial Intelligence (JELIA). Vol. 8761. Lecture Notes in
Computer Science. Springer, 2014, pp. 514–528.
[11] Diego C., Giorgio Delzanno, and Marco Montali. “Verification of
Relational Multiagent Systems with Data Types”. In: Proc. of the 29th
AAAI Conf. on Artificial Intelligence (AAAI). AAAI Press, 2015,
pp. 2031–2037. isbn: 9781577356981.
[12] Diego C., Marco Montali, Fabio Patrizi, et al. “Implementing
Data-Centric Dynamic Systems over a Relational DBMS”. In: Proc. of
the 9th Alberto Mendelzon Int. Workshop on Foundations of Data
Management (AMW). 2015.
[13] Diego C., Giuseppe De Giacomo, et al. “Verification and Synthesis in
Description Logic Based Dynamic Systems”. In: Proc. of the 7th Int.
Conf. on Web Reasoning and Rule Systems (RR). Vol. 7994. Lecture
Notes in Computer Science. Springer, 2013, pp. 50–64.

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (7)

Andere mochten auch

Andere mochten auch (20)

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

Ähnlich wie Data and Processes: Can we Marry Them . . . and Make the Marriage Last? (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

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