The document discusses representing and querying norm states using temporal ontology-based data access (OBDA). It presents the QUEN framework which models norms and their state transitions declaratively on top of a relational database. QUEN has three layers: 1) an ontological layer representing norms, 2) a specification of norm state transitions in response to database events, and 3) a legacy relational database storing events. It demonstrates QUEN on an example of patient data access consent, modeling authorizations and their lifecycles. Norm state queries are answered directly over the database using the declarative specifications without materializing states.

1. Representing and Querying Norm States
Using Temporal Ontology-Based Data Access
Evellin Cardoso, Marco Montali, Diego Calvanese
Free University of Bozen-Bolzano, Italy

2. model-
driven
data-
driven
digital enterprise

3. model-
driven
data-
driven
Governance
Workforce
Governance

4. Governancemodel-
driven
data-
driven
Governance
WorkforceWorkforce
contract

5. Governancemodel-
driven
data-
driven
Governance
Workforce
contract

6. Governancemodel-
driven
data-
driven
Governance
Workforce
contract
z
Is delivery 123 still
pending?
Which
commitments did
we violate in 2018?
customer
manager

7. Governancemodel-
driven
data-
driven
Governance
Workforce
contract
z
Is delivery 123 still
pending?
Which
commitments did
we violate in 2018?
customer
manager
Problem #1
How to represent
relational
normative primitives
and their evolution

8. Governancemodel-
driven
data-
driven
Governance
Workforce
contract
Is delivery 123 still
pending?
Which
commitments did
we violate in 2018?
customer
managerqueries

9. Governancemodel-
driven
data-
driven
Governance
Workforce
contract
norm
states
Is delivery 123 still
pending?
Which
commitments did
we violate in 2019?
customer
managerqueries
extension of
answers

10. Governancemodel-
driven
data-
driven
Governance
Workforce
contract
norm
states
Is delivery 123 still
pending?
Which
commitments did
we violate in 2019?
customer
managerqueries
extension of
answers
Problem #2
How to compute
norm instances and
their states from
legacy data

11. Governancemodel-
driven
data-
driven
Governance
Workforce
contract
norm
states
Is delivery 123 still
pending?
Which
commitments did
we violate in 2019?
customer
managerqueries
extension of
answers
Problem #2
How to compute
norm instances and
their states from
legacy relational data
without materializing

12. Outline
1. Example (data consent)
2. The QUEN framework as a black box
3. The QUEN framework as a white box

13. Example:
access consent to patient data
patient health vault provider third-parties

14. Example:
access consent to patient data
patient health vault provider third-parties
allow
disclosure token
Allowed(pid,hid,discid,tpid,t)

15. Example:
access consent to patient data
patient health vault provider third-parties
send creds
disclosure token
allow
SentCred(hid,tpid,discid,t)
Allowed(pid,hid,discid,tpid,t)

16. Example:
access consent to patient data
patient health vault provider third-parties
send creds
disclosure token
allow
SentCred(hid,tpid,discid,t)
Allowed(pid,hid,discid,tpid,t)
ReqData(tpid,hid,reqid,discid,t)
request

17. Example:
access consent to patient data
patient health vault provider third-parties
send creds
disclosure token
allow
SentCred(hid,tpid,discid,t)
Allowed(pid,hid,discid,tpid,t)
request
ReqData(tpid,hid,reqid,discid,t)
Accessed(tpid,hid,reqid,discid,t)
access

18. Example:
access consent to patient data
SentCred(hid,tpid,discid,t)
Allowed(pid,hid,discid,tpid,t)
ReqData(tpid,hid,reqid,discid,t)
Accessed(tpid,hid,reqid,discid,t)
Who are the involved agents?
Where is the notion of “disclose authorization”? How many
authorizations have been created? What is their current status?
Is third-party xyz authorised now to access certain data?

19. QUEN in a nutshell
• Full relational (first-order) modeling of norms.
• Three conceptual layers:
1. Ontological layer of norms: norms as explicit relations.
2. Norm state evolution: declarative specification of norm
state transitions as induced by the raw database facts.
3. Legacy relational database: tuples with timestamps as
implicit events.
• “Virtual norm store”:
• data;
• queries and answers.

20. QUEN in a nutshell
• Full relational (first-order) modeling of norms.
• Three conceptual layers:
1. Ontological layer of norms: norms as explicit relations.
2. Norm state evolution: declarative specification of norm
state transitions as induced by the raw facts in the data
3. Legacy relational database: tuples with timestamps as
implicit events.
• “Virtual norm store”:
• data;
• queries and answers.

21. Upper knowledge
- crt: timestamp
- ext: timestamp [0..1]
- det: timestamp [0..1]
- dit: timestamp [0..1]
Normative
Primitive
Authorization
Prohibition
Power
is expector for
Commitment
Agent
is expectee for
Thing
1
1
*
* * 1
targets
- vit: timestamp [0..1]
Violable Normative
Primitive
Static Dynamic

22. Upper knowledge
- crt: timestamp
- ext: timestamp [0..1]
- det: timestamp [0..1]
- dit: timestamp [0..1]
Normative
Primitive
Authorization
Prohibition
Power
is expector for
Commitment
Agent
is expectee for
Thing
1
1
*
* * 1
targets
- vit: timestamp [0..1]
Violable Normative
Primitive
Static Dynamic

23. created
detachedexpired
dischargedviolated
create
when ante detach
when never ante
expire
when cons
discharge
when cons dischargewhen never cons violate
Figure 1: Lifecycle of norm types (from [9]). The violated state e
only for prohibition and commitment.
a timestamp column, and whose tuples record the diffe
instances recorded in the system for that event.
Example 1 (Inspired from [9]). The following informa
schema captures three event types related to the request
access to patient data within a sanitary organization, where
Upper knowledge
- crt: timestamp
- ext: timestamp [0..1]
- det: timestamp [0..1]
- dit: timestamp [0..1]
Normative
Primitive
Authorization
Prohibition
Power
is expector for
Commitment
Agent
is expectee for
Thing
1
1
*
* * 1
targets
- vit: timestamp [0..1]
Violable Normative
Primitive
Static Dynamic

24. Step 1/3: Domain-specific norm types
- crt: timestamp
- ext: timestamp [0..1]
- det: timestamp [0..1]
- dit: timestamp [0..1]
Normative
Primitive
Authorization
Prohibition
Power
Third
Party
HealthVault
Provider
is expector for
Commitment
Disclosure
Auth
Agent
is expectee for
given by
used by attached to
Disclosure
Token
Thing
1
1
*
* * 1
targets
- vit: timestamp [0..1]
Violable Normative
Primitive
1
1
*
*
0..1 1
Patient
emits1
*

25. Step 1/3: Domain-specific norm types
- crt: timestamp
- ext: timestamp [0..1]
- det: timestamp [0..1]
- dit: timestamp [0..1]
Normative
Primitive
Authorization
Prohibition
Power
Third
Party
HealthVault
Provider
is expector for
Commitment
Disclosure
Auth
Agent
is expectee for
given by
used by attached to
Disclosure
Token
Thing
1
1
*
* * 1
targets
- vit: timestamp [0..1]
Violable Normative
Primitive
1
1
*
*
0..1 1
Patient
emits1
*
- crt: timestamp
- ext: timestamp [0..1]
- det: timestamp [0..1]
- dit: timestamp [0..1]
Normative
Primitive
Authorization
Prohibition
Power
Third
Party
HealthVault
Provider
is expector for
Commitment
Disclosure
Auth
Agent
is expectee for
given by
used by attached to
Disclosure
Token
Thing
1
1
*
* * 1
targets
- vit: timestamp [0..1]
Violable Normative
Primitive
1
1
*
*
0..1 1
Patient
emits1
*

26. Step 2/3: Norm State Transitions
We take inspiration from Custard [Chopra and Singh, AAMAS 2016].
Each norm type N in the lower ontology comes with a
corresponding QUEN specification:
and is a sub-relation of the expector relation in On (thus
qualifying the domain-specific expector for N);
• Rc be a domain-specific relation that is attached to N
and is a sub-relation of the expectee relation in On (thus
qualifying the domain-specific expectee for N);
• Rt be a domain-specific relationship that is attached to
N and is a sub-relation of the target relation in On (thus
qualifying the domain-specific target for N).
A QUEN lifecycle specification for this combination of ele-
ments has the following form:
T N Rd d Rc c Rt o
create Qcr
(d, c, o, tcr)
expire Qex
d,c,o,tcr
(tex)
detach Qde
d,c,o,tcr
(tde)
discharge Qdi
d,c,o,tcr,tde
(tdi)
[violate Qvi
d,c,o,tcr,tde
(tvi) ]
where the last line is only present if T ∈

27. We take inspiration from Custard [Chopra and Singh, AAMAS 2016].
Each norm type N in the lower ontology comes with a
corresponding QUEN specification:
and is a sub-relation of the expector relation in On (thus
qualifying the domain-specific expector for N);
• Rc be a domain-specific relation that is attached to N
and is a sub-relation of the expectee relation in On (thus
qualifying the domain-specific expectee for N);
• Rt be a domain-specific relationship that is attached to
N and is a sub-relation of the target relation in On (thus
qualifying the domain-specific target for N).
A QUEN lifecycle specification for this combination of ele-
ments has the following form:
T N Rd d Rc c Rt o
create Qcr
(d, c, o, tcr)
expire Qex
d,c,o,tcr
(tex)
detach Qde
d,c,o,tcr
(tde)
discharge Qdi
d,c,o,tcr,tde
(tdi)
[violate Qvi
d,c,o,tcr,tde
(tvi) ]
where the last line is only present if T ∈
Static/dynamic KB
Relational DB
Step 2/3: Norm Lifecycle

28. Third
Party
HealthVault
Provider
Disclosure
Auth
given by
used by attached to
Disclosure
Token
1
1
*
*
0..1 1
Patient
emits1
*
SentCred(hid,tpid,discid,t)
Allowed(pid,hid,discid,tpid,t)
ReqData(tpid,hid,reqid,discid,t)
Accessed(tpid,hid,reqid,discid,t)
Step 2/3: Norm Lifecycle

29. Third
Party
HealthVault
Provider
Disclosure
Auth
given by
used by attached to
Disclosure
Token
1
1
*
*
0..1 1
Patient
emits1
*
authorization DisclosureAuth used by tp given by h attached to d
create SELECT c.tpid AS tp, c.hid AS h, c.discid AS d, c.t AS tcr
FROM SentCred c, Allowed a WHERE c.discid = a.discid AND c.tpid = a.tpid AND c.hid = a.hid
detach SELECT r.t AS tde FROM ReqData r WHERE r.discid = d AND r.t > tcr
discharge SELECT a.t AS tdi FROM Accessed a WHERE a.discid = d AND a.t ≥ tde + 1 AND a.t ≤ tde + 10
Figure 4: QUEN lifecycle specification of the disclosure authorization on top of the database schema of Example 1.
where object constructors simply use (abbreviations of) the
names of the corresponding endpoint classes. Notice that
this mapping also implicitly populate the Patient class with
pat(pid), given that the domain of emits is Patient as dictated
by the ontology. ▹
D. Putting Everything Together
A. From Lifecycle Specifications to Mappings
As a preliminary step for the translation, we need to d
how a query with parameters can be suitably merge w
query providing those parameters, so as to obtain a stan
SQL query as result. This is done by simply computing
join (in the standard SQL sense).
Specifically, let Q1
(⃗x, t1) be a query without paramete
SentCred(hid,tpid,discid,t)
Allowed(pid,hid,discid,tpid,t)
ReqData(tpid,hid,reqid,discid,t)
Accessed(tpid,hid,reqid,discid,t)
Step 2/3: Norm Lifecycle

30. Third
Party
HealthVault
Provider
Disclosure
Auth
given by
used by attached to
Disclosure
Token
1
1
*
*
0..1 1
Patient
emits1
*
authorization DisclosureAuth used by tp given by h attached to d
create SELECT c.tpid AS tp, c.hid AS h, c.discid AS d, c.t AS tcr
FROM SentCred c, Allowed a WHERE c.discid = a.discid AND c.tpid = a.tpid AND c.hid = a.hid
detach SELECT r.t AS tde FROM ReqData r WHERE r.discid = d AND r.t > tcr
discharge SELECT a.t AS tdi FROM Accessed a WHERE a.discid = d AND a.t ≥ tde + 1 AND a.t ≤ tde + 10
Figure 4: QUEN lifecycle specification of the disclosure authorization on top of the database schema of Example 1.
where object constructors simply use (abbreviations of) the
names of the corresponding endpoint classes. Notice that
this mapping also implicitly populate the Patient class with
pat(pid), given that the domain of emits is Patient as dictated
by the ontology. ▹
D. Putting Everything Together
A. From Lifecycle Specifications to Mappings
As a preliminary step for the translation, we need to d
how a query with parameters can be suitably merge w
query providing those parameters, so as to obtain a stan
SQL query as result. This is done by simply computing
join (in the standard SQL sense).
Specifically, let Q1
(⃗x, t1) be a query without paramete
SentCred(hid,tpid,discid,t)
Allowed(pid,hid,discid,tpid,t)
ReqData(tpid,hid,reqid,discid,t)
Accessed(tpid,hid,reqid,discid,t)
Step 2/3: Norm Lifecycle

31. Step 3/3: Add explicit mappings
Third
Party
HealthVault
Provider
Disclosure
Auth
given by
used by attached to
Disclosure
Token
1
1
*
*
0..1 1
Patient
emits1
*
Allowed(pid,hid,discid,tpid,t)

32. Step 3/3: Add explicit mappings
Third
Party
HealthVault
Provider
Disclosure
Auth
given by
used by attached to
Disclosure
Token
1
1
*
*
0..1 1
Patient
emits1
*
Allowed(pid,hid,discid,tpid,t)

33. Step 3/3: Add explicit mappings
Third
Party
HealthVault
Provider
Disclosure
Auth
given by
used by attached to
Disclosure
Token
1
1
*
*
0..1 1
Patient
emits1
*
Allowed(pid,hid,discid,tpid,t)
nd the
t-based
eries, it
viola-
scharge
ned.
cations
Exam-
one in
fication
Figure 4 focuses on the DisclosureAuth class and sur
relations (which implicitly includes also the endpoin
attached to those relations, given that UML univocall
the endpoint classes to each binary relation). Howeve
not mention directly the Patient class, nor the corre
emits relation. The underlying database schema intro
Example 1 actually provides us the raw data to cha
the extension of such elements: it is enough to in
Allowed relation and filter it by retaining the pid an
fields. We can then construct the following mapping
SELECT pid,discid FROM Allowed
emits(pat(pid), dtoken(discid))

34. QUEN components
temporal
SPARQL
DB schema
Static upper KB
(agents/norms) Dynamic upper KB
(norm states)Domain-specific
KB
Mappings
Norm state transitions
specification

35. QUEN components
temporal
SPARQL
DB schema
Static upper KB
(agents/norms) Dynamic upper KB
(norm states)Domain-specific
KB
Mappings
Norm state transitions
specification
DiscloseAuth(x)
^ Detached(x)[t1, t2)

36. QUEN components
temporal
SPARQL
DB schema
Static upper KB
(agents/norms) Dynamic upper KB
(norm states)Domain-specific
KB
Mappings
Norm state transitions
specification
DiscloseAuth(x)
^ Detached(x)[t1, t2)
?

37. Motivation Semantic Web OBDA Framework References
Query answering by rewriting (conceptual framework)
Ontology
Mappings
Data
Sources
. . .
. . .
. . .
. . .
qresult
Ontology-based data access

38. Motivation Semantic Web OBDA Framework References
Query answering by rewriting (conceptual framework)
Ontology
Mappings
Data
Sources
. . .
. . .
. . .
. . .
Ontological Query q
Rewritten Query
SQLRelational Answer
Ontological Answer
Rewriting
Unfolding
Evaluation
Result Translation
Ontology-based data access

39. Temporal OBDA
Extension of the classical OBDA paradigm with (metric) time
• Facts have an attached time interval.
• Static ontology: OWL 2 QL.
• Temporal ontology: non-recursive Datalog extended with
metric temporal logic operators.
• Temporal mappings indicate how to extract facts and their
interval extreme timestamps from the underlying database.
• Support for temporal SPARQL.
• Ongoing implementation effort inside Ontop.

40. Making QUEN Operational
temporal
SPARQL
DB schema
Static upper KB
(agents/norms) Dynamic upper KB
(norm states)Domain-specific
KB
Mappings
Norm state transitions
specification

41. Making QUEN Operational
temporal
SPARQL
DB schema
Static OWL 2 QL
ontology
Basic temporal
ontology
Mappings
Norm state transitions
specification

42. Making QUEN Operational
temporal
SPARQL
DB schema
Mappings
Norm state transitions
specification
Automatic
mapping
encoder
Static OWL 2 QL
ontology
Basic temporal
ontology

43. Making QUEN Operational
temporal
SPARQL
DB schema
Mappings Temporal mappings
Automatic
mapping
encoder
Static OWL 2 QL
ontology
Basic temporal
ontology

44. Making QUEN Operational
temporal
SPARQL
DB schema
Mappings Temporal mappings
Static OWL 2 QL
ontology
Basic temporal
ontology
Temporal
OBDA

45. Debugging
QUEN specification of norm lifecycle may be wrong:
• Ambiguous transition: multiple timestamps.
Violates functionality on timestamp attribute.
• State superposition: norm in two states at the same time.
We cannot reason on this in general, but we can debug
whether such issues arise given a database:
• Transform these checks into queries.
• If answers returned -> issue.
Example: fetch norms that are simultaneously discharged
and violated…
TOBDA framework to have a fine-grained understanding of
such a root cause, using standard techniques [13]. Specifically,
it is possible to automatically construct a SQL query that,
once submitted to the underlying database, returns those norm
instances that have at least two creation times (and similarly
for the other time attributes).
The case of state superposition can instead be simply
handled by formulating suitable semantic queries that retrieve
those norm instances that are simultaneously present in two
states. By inspecting the temporal mappings, a case of state
superposition can only arise if the norm instance simultane-
ously undergoes a transition to two different states. Hence, to
retrieve all norm instances that experienced a superposition
of state violated and discharged (and when this undesired
superposition arose), we can issue the following query:
Qdv(n, t) = violated(n)@[t, t1) ∧ discharged(n)@[t, t2)

46. Conclusion
QUEN framework:
• Relational modeling of norms and their evolution at
the ontological level.
• Conceptual link to underlying legacy DB.
• Operational thanks to automated encoding to
temporal OBDA: “virtual norm state store”.
• Example of OBDA with a fixed target ontology.
Future work:
• Implementation (ongoing effort).
• From offline to online: streaming and operational
support!

47. M
Marco
Montali
montali@inf.unibz.it
Thanks!