Score-Based Explanations in Data Management and Machine Learning: An Answer-Set Programming Approach to Counterfactual Analysis

06/19/2021
by   Leopoldo Bertossi, et al.
Universidad Adolfo Ibáñez
0

We describe some recent approaches to score-based explanations for query answers in databases and outcomes from classification models in machine learning. The focus is on work done by the author and collaborators. Special emphasis is placed on declarative approaches based on answer-set programming to the use of counterfactual reasoning for score specification and computation. Several examples that illustrate the flexibility of these methods are shown.

READ FULL TEXT VIEW PDF

Authors

page 27

page 30

07/24/2020

Score-Based Explanations in Data Management and Machine Learning

We describe some approaches to explanations for observed outcomes in dat...
08/25/2021

Reasoning about Counterfactuals and Explanations: Problems, Results and Directions

There are some recent approaches and results about the use of answer-set...
10/27/2021

Counterfactual Shapley Additive Explanations

Feature attributions are a common paradigm for model explanations due to...
11/15/2020

Declarative Approaches to Counterfactual Explanations for Classification

We propose answer-set programs that specify and compute counterfactual i...
07/21/2021

Answer-Set Programs for Reasoning about Counterfactual Interventions and Responsibility Scores for Classification

We describe how answer-set programs can be used to declaratively specify...
01/02/2019

Efficient Search for Diverse Coherent Explanations

This paper proposes new search algorithms for counterfactual explanation...
06/09/2022

A Learning-Theoretic Framework for Certified Auditing of Machine Learning Models

Responsible use of machine learning requires that models be audited for ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

In data management and machine learning one wants explanations

for certain results. For example, for query results from databases, and for outcomes of classification models in machine learning (ML). Explanations, that may come in different forms, have been the subject of philosophical enquires for a long time, but, closer to our discipline, they appear under different forms in model-based diagnosis and in causality as developed in artificial intelligence.

In the last few years, explanations that are based on numerical scores assigned to elements of a model that may contribute to an outcome have become popular. These scores attempt to capture the degree of contribution of those components to an outcome, e.g. answering questions like these: What is the contribution of this tuple to the answer to this query?  What is the contribution of this feature value of an entity to the displayed classification of the latter?

For an example, consider a financial institution that uses a learned classifier,

, e.g. a decision tree, to determine if clients should be granted loans or not, returning labels

or , resp. A particular client, represented as an entity , applies for a loan, and the classifier returns , i.e. the loan is rejected. The client requests an explanation.

A common approach consists in giving scores to the feature values in , to quantify their relevance in relation to the classification outcome. The higher the score of a feature value, the more explanatory is that value. For example, the fact that the client has value “5” for feature Age (in years) could have the highest score. That is, the rejection of the loan application is due mostly to the client’s very young age.

In the context of explainable AI [39], different scores have been proposed in the literature, and some that have a relatively older history have been applied. Among the latter we find the general responsibility score as found in actual causality [26, 19]. For a particular kind of application, one has to define the right causality setting, and then apply the responsibility measure to the participating variables (see [27] for a newer treatment of the subject). In particular, in data management, responsibility has been used to quantify the strength of a tuple as a cause for a query result [36, 5]. The Shapley value, as found in

coalition game theory

[45], has been used for the same purpose [30]. Defining the right game function, the Shapley value assigned to a player reflects its contribution to the wealth function, which in databases corresponds to the query result.

In the context of explanations to outcomes from classification models in ML, the Shapley value has been used to assign scores to the feature values taken by an entity that has been classified. With a particular game function, it has taken the form of the Shap score, which has become quite popular and influential [34, 35].

Also recently, a responsibility score, Resp, has been introduced and investigated for the same purpose in [9]. It is based on the notions of counterfactual intervention as appearing in actual causality, and causal responsibility. More specifically, (potential) executions of counterfactual interventions on a structural logico-probabilistic model  [26] are investigated, with the purpose of answering hypothetical questions of the form:  What would happen if we change …?.

Counterfactual interventions can be used to define different forms of score-based explanations. This is the case of causal responsibility in databases (c.f. Section 12). In explainable AI, and more commonly with classification models of ML, counterfactual interventions become hypothetical changes on the entity whose classification is being explained, to detect possible changes in the outcome (c.f. [11, Sec. 8] for a more detailed discussion and references).

Score-based explanations can also be defined in the absence of a model, and with or without explicit counterfactual interventions. Actually, explanation scores such as Shap and Resp can be applied with black-box

models, in that they use, in principle, only the input/output relation that represents the classifier, without having access to the internal components of the model. In this category we could find classifiers based on complex neural networks, or XGBoost

[33]. They are opaque enough to be treated as black-box models.

The Shap and Resp scores can also be applied with open-box models, with explicit models. Without having access to the elements of the classification model, the computation of both Shap and Resp is in general intractable, by their sheer definitions, and the possibly large number of counterfactual combinations that have to be considered in the computation. However, for certain classes of classifiers, e.g. decision trees, having access to the mathematical model may make the computation of Shap tractable, as shown in [3, 48], where it is also shown that for other classes of explicit models, its computation is still intractable. Something similar applies to Resp [9].

Other explanation scores used in machine learning appeal to the components of the mathematical model behind the classifier. There can be all kinds of explicit models, and some are easier to understand or interpret or use for this purpose. For example, the FICO score proposed in [18]

, for the FICO dataset about loan requests, depends on the internal outputs and displayed coefficients of two nested logistic regression models. Decision trees

[38]

, random forests

[12], rule-based classifiers, etc., could be seen as relatively easy to understand and use for providing explanations.  In [9], the Shap and Resp scores were experimentally compared with each other, and also with the FICO score.

One can specify in declarative terms the counterfactual versions of tuples in databases and of feature values in entities under classification. On this basis one can analyze diverse alternative counterfactuals, reason about them, and also specify the associated explanation scores. In these notes we do this for responsibility scores in databases and classifications models. More specifically, we use answer-set programming

, a modern logic-programming paradigm that has become useful in many applications

[13, 24]. We show examples run with the DLV system and its extensions [29]. An important advantage of using declarative specifications resides in the possibility of adding different forms of domain knowledge and semantic constraints. Doing this with purely procedural approaches would require changing the code accordingly.

The answer-set programs (ASPs) we use are influenced by, and sometimes derived from, repair programs. These are ASPs that specify and compute the possible repairs of a database that is inconsistent with respect to a given set of integrity constraints [4]. A useful connection between database repairs and actual causality in databases was established in [5]. Hence, the use of repairs and repair programs.

In this article we survey some of the recent advances on the use and computation of the above mentioned score-based explanations, both for query answering in databases and for classification in ML. This is not intended to be an exhaustive survey of the area. Instead, it is heavily influenced by our latest research. Special emphasis is placed on the use of ASPs (for many more details on this see [11]). Taking advantage of the introduced repair programs, we also show how to specify and compute a numerical measure of inconsistency of database [7]. In this case, this would be a global score, in contrast with the local scores applied to individual tuples in a database or feature values in an entity.  To introduce the concepts and techniques we will use mostly examples, trying to convey the main intuitions and issues.

This paper is structured as follows. In Section 2 we provide some background material on databases and answer-set programs. In Section 3 we concentrate on causal explanations in databases, the responsibility score, and also the causal-effect score [44], as an alternative to the latter. In Section 4, we present the causality-repair connection and repair programs for causality and responsibility computation. In Section 5, we consider causality in databases at the attribute level, as opposed to the tuple level. In Section 6, we introduce causality and responsibility in databases that are subject to integrity constraints. In Section 7 we present the global inconsistency measure for a database and the ASPs to compute it. In Section 8, we describe the use of the Shapley value to provide explanation scores in databases. In Section 8, we describe in general terms score-based explanations for classification results. In Section 10 we introduce and study the x-Resp score, a simpler version of the more general Resp score that we introduce in Section 12. In Section 11 we introduce counterfactual intervention programs (CIP), which are ASPs that specify counterfactuals and the x-Resp score. In Section 13, and for completeness, we briefly present the Shap score. We end in Section 14 with some final conclusions.

2 Background

2.1 Basics of Relational Databases

A relational schema contains a domain of constants, , and a set of predicates of finite arities, .   gives rise to a language of first-order (FO) predicate logic with built-in equality, . Variables are usually denoted with ; and finite sequences thereof with ; and constants with , etc. An atom is of the form , with -ary and terms, i.e. constants, or variables. An atom is ground (a.k.a. a tuple) if it contains no variables. A database (instance), , for is a finite set of ground atoms; and it serves as an interpretation structure for .

A conjunctive query (CQ) is a FO formula, , of the form  , with , and (distinct) free variables . If has (free) variables,  is an answer to from if , i.e. is true in when the variables in are componentwise replaced by the values in . denotes the set of answers to from . is a Boolean conjunctive query (BCQ) when is empty; and when true in , . Otherwise, it is false, and . Sometimes CQs are written in Datalog notation as follows:  .

We consider as integrity constraints (ICs), i.e. sentences of : (a) denial constraints  (DCs), i.e. of the form , where , and ; and (b) functional dependencies  (FDs), i.e. of the form .111The variables in do not have to go first in the atomic formulas; what matters is keeping the correspondences between the variables in those formulas. Here, , and is an abbreviation for . A key constraint  (KC) is a conjunction of FDs:  , with , and generically stands for the th variable in . For example, , is an FD (and also a KC) that could say that an employee () can have at most one salary. This FD is usually written as . In the following, we will include FDs and key constraints among the DCs.

We will also consider inclusion dependencies (INDs), which are constraints of the form  , where , and .

If an instance does not satisfy the set of ICs associated to the schema, we say that is inconsistent, which is denoted with  .

2.2 Basics of Answer-Set Programming

We will give now a brief review of the basics of answer-set programs (ASPs). As customary, when we talk about ASPs, we refer to disjunctive Datalog programs with weak negation and stable model semantics [23, 24]. For this reason we will, for a given program, use the terms “stable model” (or simply, “model”) and “answer-set” interchangeably.  An answer-set program consists of a finite number of rules of the form

(1)

where , and are (positive) atoms, i.e. of the form , where is a predicate of a fixed arity, say, , and is a sequence of length of variables or constants. In rule (6), are called literals, with positive, and , negative. All the variables in the appear among those in the . The left-hand side of a rule is called the head, and the right-hand side, the body. A rule can be seen as a (partial) definition of the predicates in the head (there may be other rules with the same predicates in the head).

The constants in program form the (finite) Herbrand universe of the program. The ground version of program , , is obtained by instantiating the variables in in all possible ways using values from . The Herbrand base, , of contains all the atoms obtained as instantiations of predicates in with constants in .

A subset of is a model of if it satisfies , i.e.: For every ground rule of , if and , then . is a minimal model of if it is a model of , and has no model that is properly contained in . denotes the class of minimal models of . Now, for , transform into a new, positive program (i.e. without ), as follows: Delete every rule for which . Next, transform each remaining rule into . Now, is a stable model of if . Every stable model of is also a minimal model of . Stable models are also commonly called answer sets, and so are we going to do most of the time.

A program is unstratified if there is a cyclic, recursive definition of a predicate that involves negation. For example, the program consisting of the rules ;  , and is unstratified, because there is a negation in the mutually recursive definitions of and . The program in Example 8 below is not unstratified, i.e. it is stratified. A good property of stratified programs is that the models can be upwardly computed following strata (layers) starting from the facts, that is from the ground instantiations of rules with empty bodies (in which case the arrow is usually omitted). We refer the reader to [24] for more details.

Query answering under the ASPs comes in two forms. Under the brave semantics, a query posed to the program obtains as answers those that hold in some model of the program. However, under the skeptical (or cautious) semantics, only the answers that simultaneously hold in all the models are returned. Both are useful depending on the application at hand.

Example 1

Consider the following program that is already ground.

o

The program has two stable models:   and .

Each of them expresses that the atoms in it are true, and any other atom that does not belong to it, is false.

These models are incomparable under set inclusion, and are minimal models in that any proper subset of any of them is not a model of the program (i.e. does not satisfy the program).

3 Causal Explanations in Databases

In data management we need to understand and compute why certain results are obtained or not, e.g. query answers, violations of semantic conditions, etc.; and we expect a database system to provide explanations.

3.1 Causal responsibility

Here, we will consider causality-based explanations [36, 37], which we will illustrate by means of an example.

Example 2

Consider the database , and the Boolean conjunctive query (BCQ)

oo

oo

(2)

It holds:  , i.e. the query is true in .

We ask about the causes for to be true:  A tuple is counterfactual cause for (being true in ) if    and  .  In this example, is a counterfactual cause for :  If is removed from , is no longer true.

Removing a single tuple may not be enough to invalidate the query. Accordingly, a tuple is an actual cause for if there is a contingency set  , such that    is a counterfactual cause for in .  In this example, is an actual cause for with contingency set :  If is removed from , is still true, but further removing makes false.

Notice that every counterfactual cause is also an actual cause, with empty contingent set. Actual causes that are not counterfactual causes need company to invalidate a query result.  Now we ask how strong are tuples as actual causes.  To answer this question, we appeal to the responsibility of an actual cause for [36], defined by:

where is the size of a smallest contingency set, , for ,  and , otherwise.

Example 3

(ex. 2 cont.)  The responsibility of is    (its several smallest contingency sets have all size ).

and are also actual causes with responsibility  ; and is actual (counterfactual) cause with responsibility   .

High responsibility tuples provide more interesting explanations. Causes in this case are tuples that come with their responsibilities as “scores”. All tuples can be seen as actual causes, but only those with non-zero responsibility score matter.  Causality and responsibility in databases can be extended to the attribute-value level [5, 8] (c.f. Section 5).

As we will see in Section 4.1, there is a connection between database causality and repairs of databases w.r.t. integrity constraints (ICs) [4]. There are also connections to consistency-based diagnosis  and  abductive diagnosis, that are two forms of model-based diagnosis [46]. These connections have led to new complexity and algorithmic results for causality and responsibility [5, 6]. Actually, the latter turns out to be intractable (c.f. Section 4.1). In [6], causality under ICs was introduced and investigated. This allows to bring semantic and domain knowledge into causality in databases (c.f. Section 6).

Model-based diagnosis is an older area of knowledge representation where explanations form the subject of investigation. In general, the diagnosis analysis is performed on a logic-based model, and certain elements of the model are identified as explanations. Causality-based explanations are somehow more recent. In this case, still a model is used, which is, in general, a more complex than a database with a query. In the case of databases, actually there is an underlying logical model, the lineage or provenance of the query [14, 47] that we will illustrate in Section 3.2, but it is still a relatively simple model.

3.2 The causal-effect score

Sometimes, as we will see right here below, responsibility does not provide intuitive or expected results, which led to the consideration of an alternative score, the causal-effect score. We show the issues and the score by means of an example.

Example 4

Consider the database that represents the graph below, and the Boolean Datalog query that is true in if there is a path from to . Here, . Tuples have global tuple identifiers (tids) in the left-most column, which is not essential, but convenient.

All tuples are actual causes since every tuple appears in a path from to . Also, all the tuples have the same causal responsibility, , which may be counterintuitive, considering that   provides a direct path from to .

In [44], the notion causal effect was introduced. It is based on three main ideas, namely, the transformation, for auxiliary purposes, of the database into a probabilistic database, the expected value of a query, and interventions on the lineage of the query. The lineage of a query represents, by means of a propositional formula, all the ways in which the query can be true in terms of the potential database tuples, and their combinations. Here, “potential” refers to tuples that can be built with the database predicates and the database (finite) domain. These tuples may belong to the database at hand or not. For a given database, , some of those atoms become true, and others false, which leads to the instantiation of the lineage (formula) o . This is all shown in the next example.

Example 5

Consider the database   below, and a BCQ.

, which is true in .

For the database in our example, the lineage of the query instantiated on is given by the propositional formula:

(3)

where is a propositional variable that is true iff .  Here,  takes value in .

Now, for illustration, we want to quantify the contribution of tuple

to the query answer.  For this purpose, we assign, uniformly and independently, probabilities to the tuples in

, obtaining a probabilistic database   [47].  Potential tuples outside get probability .

prob
prob

The

’s become independent, identically distributed Boolean random variables;  and

becomes a Boolean random variable. Accordingly, we can ask about the probability that takes the truth value (or ) when an intervention is performed on .

Interventions are of the form , meaning making take value , with , in the structural model, in this case, the lineage. That is, we ask, for  , about the conditional probability , i.e. conditioned to making false or true.

For example, with and , the lineage in (3) becomes, resp., and abusing the notation a bit:

On the basis of these lineages and  ,  when is made false,  the probability that the instantiated lineage becomes true in is:

.

Similarly, when is made true,  the probability of the lineage becoming true in is:

The causal effect of a tuple is defined by:

In particular, using the probabilities computed so far:

Then,  the causal effect for the tuple is: , showing that the tuple is relevant for the query result, with a relevance score provided by the causal effect, of .

Let us now retake the initial example of this section.

Example 6

(ex. 4 cont.)  The Datalog query, here as a union of BCQs, has the lineage:   It holds:

The causal effects are different for different tuples, and the scores are much more intuitive than the responsibility scores.

The definition of the causal-effect score may look rather ad hoc and arbitrary. We will revisit it in Section 8, where we will have yet another explanation score in databases; namely one that takes a new approach, measuring the contribution of a database tuple to a query answer through the use of the Shapley value, which is firmly established in game theory, and is also used in several other areas [45, 43].

The main idea is that several tuples together, much like players in a coalition game, are necessary to violate an IC or produce a query result. Some may contribute more than others to the wealth distribution function (or simply, game function), which in this case becomes the query result, namely or if the query is Boolean, or a number if the query is an aggregation. The Shapley value of a tuple can be used to assign a score to its contribution. This was done in [30], and will be retaken in Section 8. But first things first.

4 Answer-Set Programs for Causality in Databases

In this section we will first establish a useful connection between database repairs and causes as tuples in a database. Next, we provide the basics of answer-set programs ASPs. Then, we use ASPs, taking the form of repair programs, to specify and compute database repairs and tuples as causes for query answers. We end this section with a fully developed example using the DLV system and its extensions [29].

4.1 The repair connection

The notion of repair of a relational database was introduced in order to formalize the notion of consistent query answering (CQA), as shown in Figure 1: If a database is inconsistent in the sense that is does not satisfy a given set of integrity constraints, , and a query is posed to (left-hand side of Figure 1), what are the meaningful, or consistent, answers to from ? They are sanctioned as those that hold (are returned as answers) from all the repairs of . The repairs of are consistent instances (over the same schema of ), i.e. , and minimally depart from [2, 4] (right-hand side of Figure 1).

                              

Figure 1: Database repairs and consistent query answers

Notice that: (a) We have now a possible-world semantics for (consistent) query answering; and (b) we may use in principle any reasonable notion of distance between database instances, with each choice defining a particular repair semantics. In the rest of this section we will illustrate two classes of repairs, which have been used and investigated the most in the literature. Actually, repairs in general have got a life of their own, beyond consistent query answering.

Example 7

Let us consider the following set of denial constraints (DCs) and a database , whose relations (tables) are shown right here below. is inconsistent, because it violates the DCs: it satisfies the joins that are prohibited by the DCs.

ooo

A
a
e
A B
a b
A C
a c

We want to repair the original instance by deleting tuples from relations. Notice that, for DCs, insertions of new tuple will not restore consistency. We could change (update) attribute values though, a possibility we will consider in Section 5.

Here we have two subset repairs, a.k.a. S-repairs. They are subset-maximal consistent subinstances of :    and   . They are consistent, subinstances of , and any proper superset of them (still contained in ) is inconsistent. (In general, we will represent database relations as set of tuples.)

We also have cardinality repairs, a.k.a. C-repairs. They are consistent subinstances of that minimize the number of tuples by which they differ from . That is, they are maximum-cardinality consistent subinstances. In this case, only is a C-repair.  Every C-repair is an S-repair, but not necessarily the other way around (as this example shows).

Let us now consider a BCQ

(4)

which we assume is true in a database .  It turns out that we can obtain the causes for  to be true , and their contingency sets from database repairs. In order to do this, notice that  becomes a DC

(5)

and that holds in  iff   is inconsistent w.r.t. .

It holds that S-repairs are associated to causes with minimal contingency sets, while C-repairs are associated to causes for with minimum contingency sets, and maximum responsibilities [5]. In fact, for a database tuple  :

  •  is actual cause for with subset-minimal contingency set  iff    is an S-repair (w.r.t. ), in which case, its responsibility is  .

  •  is actual cause with minimum-cardinality contingency set  iff    is C-repair, in which case, is a maximum-responsibility actual cause.

Conversely, repairs can be obtained from causes and their contingency sets [5]. These results can be extended to unions of BCQs (UBCQs), or equivalently, to sets of denial constraints.

One can exploit the connection between causes and repairs to understand the computational complexity of the former by leveraging existing results for the latter. Beyond the fact that computing or deciding actual causes can be done in polynomial time in data for CQs and UCQs [36, 5], one can show that most computational problems related to responsibility are hard, because they are also hard for repairs, in particular, for C-repairs (all this in data complexity) [32]. In particular, one can prove [5]: (a) The responsibility problem, about deciding if a tuple has responsibility above a certain threshold, is -complete for UCQs.  (b) Computing  is -complete for BCQs. This the functional, non-decision, version of the responsibility problem. The complexity class involved is that of computational problems that use polynomial time with a logarithmic number of calls to an oracle in NP.  (c) Deciding if a tuple is a most responsible cause is -complete for BCQs. The complexity class is as the previous one, but for decision problems [1].

4.2 Answer-set programs

We will give now a brief review of the basics of answer-set programs (ASPs). As customary, when we talk about ASPs, we refer to disjunctive Datalog programs with weak negation and stable model semantics [23, 24]. For this reason we will, for a given program, use the terms “stable model” (or simply, “model”) and “answer-set” interchangeably.  An answer-set program consists of a finite number of rules of the form

(6)

where , and are (positive) atoms, i.e. of the form , where is a predicate of a fixed arity, say, , and is a sequence of length of variables or constants. In rule (6), are called literals, with positive, and , negative. All the variables in the appear among those in the . The left-hand side of a rule is called the head, and the right-hand side, the body. A rule can be seen as a (partial) definition of the predicates in the head (there may be other rules with the same predicates in the head).

The constants in program form the (finite) Herbrand universe of the program. The ground version of program , , is obtained by instantiating the variables in in all possible ways using values from . The Herbrand base, , of contains all the atoms obtained as instantiations of predicates in with constants in .

A subset of is a model of if it satisfies , i.e.: For every ground rule of , if and , then . is a minimal model of if it is a model of , and has no model that is properly contained in . denotes the class of minimal models of . Now, for , transform into a new, positive program (i.e. without ), as follows: Delete every rule for which . Next, transform each remaining rule into . Now, is a stable model of if . Every stable model of is also a minimal model of . Stable models are also commonly called answer sets, and so are we going to do most of the time.

A program is unstratified if there is a cyclic, recursive definition of a predicate that involves negation. For example, the program consisting of the rules ;  , and is unstratified, because there is a negation in the mutually recursive definitions of and . The program in Example 8 below is not unstratified, i.e. it is stratified. A good property of stratified programs is that the models can be upwardly computed following strata (layers) starting from the facts, that is from the ground instantiations of rules with empty bodies (in which case the arrow is usually omitted). We refer the reader to [24] for more details.

Query answering under the ASPs comes in two forms. Under the brave semantics, a query posed to the program obtains as answers those that hold in some model of the program. However, under the skeptical (or cautious) semantics, only the answers that simultaneously hold in all the models are returned. Both are useful depending on the application at hand.

Example 8

Consider the following program that is already ground.

o

The program has two stable models:   and .

Each of them expresses that the atoms in it are true, and any other atom that does not belong to it, is false.

These models are incomparable under set inclusion, and are minimal models in that any proper subset of any of them is not a model of the program (i.e. does not satisfy the program).

4.3 Repair-programs for causality in databases

Answer-set programs (ASPs) can be used to specify, compute and query S- and C-repairs. These ASPs are called “repair programs”. We will show the main ideas behind them by means of an example. For a more complete treatment see [17, 4].

Example 9

(example 2 cont.)  Let us consider the DC associated to the query in (2):  .

The given database is inconsistent w.r.t. , and we may consider its repairs.  Its repair program contains the  as set of facts, now (only for convenience) with global tuple identifiers (tids) in the first attribute:   .

The main rule is the properly repair rule:

Here, d is an annotation constant for “tuple deleted”.  This rule detects in its body (its right-hand side) a violation of the DC. If this happens, its head (its left-hand-side) instructs the deletion of one of the tuples participating in the violation. The semantics of the program forces the choice of only one atom in the head (unless forced otherwise by other rules in the program, which does not occur in repair programs). Different choices will lead to different models of the program, and then, to different repairs.

In order to “build” the repairs, we need the collection rules:

Here,  s is an annotation for “tuple stays in repair”; and the rule collects the tuples in the original instance that have not been deleted.

There is a one-to-one correspondence between the answer-sets of the repair program and the database repairs. Actually, a model of the program determines an S-repair of , as .  Conversely, every S-repair can obtained in this way.

In this example, the S-repair,  ,  can be obtained from the model   . Actually, is a C-repair.

There is another S-repair, , that is associated to the model . This is not a C-repair.

For sets of DCs, repair programs can be made normal, i.e. non-disjunctive [17]. CQA becomes query answering under the cautious or skeptical semantics of ASPs (i.e. true in all repairs), which, for normal programs, is -complete (in data). This matches the data complexity of consistent QA under DCs (c.f. [4] for references to complexity of CQA).

Now, if we want to obtain from the program only those models that correspond to C-repairs, we can add  weak program constraints  (WCs), as shown in the example.

Example 10

(example 9 cont.)  Let us add to the program the WCs

A (hard) program constraint in a program [29], usually denoted as

leads to discarding all the models where the join in the RHS of the constraint holds. Weak program constraints, now preceded by a “”, may be violated by a model, buy only the models where the number of violations of them is minimized are kept.  In our example, the WCs have the effect of minimizing the number of deleted tuples. In this way, we obtain as models only C-repairs.

In our example, we obtain C-repair , corresponding to model , but not S-repair , because it is associated to model that is discarded due to the WCs.

As we already mentioned, C-repairs are those that can be used to obtain most-responsible actual causes. Accordingly, the latter task can be accomplished through the use of repair programs with weak constraints. We illustrate this by means of our example (c.f. [8] for a detailed treatment). Actually, cause and responsibility computation become query answering on extended repair programs. In them, causes will be represented by means of the tids we introduced for repair programs.

Example 11

(example 10 cont.)  The causes can be obtained through a new predicate, defined by the rules

because they correspond to deleted tuples in a repair. If we want to obtain them, it is good enough to pose a query under the brave semantics, which returns what is true in some model:  ?

However, we would like to obtain contingency sets (for causes) and responsibilities. We will concentrate on maximum-responsibility causes and their (maximum) responsibilities, for which we assume the repair program has weak constraints, as above (c.f. [8] for non-maximum responsibility causes).

We first introduce a new binary predicate, to collect a cause and an associated contingency tuple (which is deleted together with the tuple-cause in a same repair). This predicate is of the form  , indicating that  is actual cause, and  is a member of the former’s contingency set. For this, for each pair of predicates , not necessarily different, in the DC  , we introduce the rule:

This will make a member of ’s contingency set.  In our example,  we have the rule:

where the inequality is not needed (for having different predicates), but also, among others,

In model , corresponding to C-repair , where there is no pair of simultaneously deleted tuples, we have no atoms. Had model not been discarded due to the WCs, we would find in it (actually in its extension) the atoms:    and  .

Contingency sets, which is what we want next, are sets, which in general are not returned as objects from an ASP. However, there are extensions of ASP and their implementations, such as DLV [29], that, trough aggregations, support set construction. This is the case of DLV-Complex [15, 16], that we have used in for running repair programs and their extensions. We do this as follows (in the program below , are variables).

(7)
(8)
(9)
(11)

The auxiliary predicate in rule (2) is used to avoid a non-safe negation. That predicate is defined by rule (8). We are capturing here causes that do not have contingency companions, and then, they have an empty contingency set. Rule (9 is indeed redundant, but shows the main idea: a contingency companion of a cause is taken as element into the latter’s pre-contingency set. In rule (11) we have an auxiliary predicate for the same reason as in the first rule. The main idea is to stepwise keep adding by means of set union (c.f. rule (4.3), a contingent element to a possibly partial contingency set, until there is nothing left to add.  These maximal contingency sets are obtained with rule (11).

In each model of the program with WCs, these contingency sets will have the same minimum size, and will lead to maximum responsibility causes. Responsibility computation can be done, with numerical aggregation supported by DLV-Complex, as follows:

The first rule gives us the (minimum) size, , of contingency sets, which leads to a responsibility of .  The responsibility of a (maximum responsibility) cause can be obtained through a query to the extended program:  .

ASP with WCs computation has exactly the required expressive power or computational complexity needed for maximum-responsibility computation [8].

4.4 The example with DLV-Complex

In this section we show in detail the running example in Section 4.3, fully specified and executed with the DLV-Complex system [15, 16]. C.f. [8] for more details.

Example 12

(ex. 9 cont.)  The first fragment of the DLV program below, shows facts for database , and the disjunctive repair rule for the DC . In it, and in the rest of this section, R_a, S_a, ... stand for used before, with the subscript _a for “auxiliary”. We recall that the first attribute of a predicate holds a variable or a constant for a tid; and the last attribute of R_a, etc. holds an annotation constant, d or s, for “deleted” (from the database) or “stays” in a repair, resp.  (In DLV programs, variables start with a capital letter, and constants, with lower-case.)

    R(1,a,b). R(2,c,d). R(3,b,b). S(4,a). S(5,c). S(6,b).

    S_a(T1,X,d) v R_a(T2,X,Y,d) v S_a(T3,Y,d) :- S(T1,X),R(T2,X,Y), S(T3,Y).
    S_a(T,X,s)   :- S(T,X), not S_a(T,X,d).
    R_a(T,X,Y,s) :- R(T,X,Y), not R_a(T,X,Y,d).

DLV returns the stable models of the program, as follows:

    {S_a(6,b,d), R_a(1,a,b,s), R_a(2,c,d,s), R_a(3,b,b,s),
     S_a(4,a,s), S_a(5,c,s)}

     {R_a(1,a,b,d), R_a(3,b,b,d), R_a(2,c,d,s), S_a(4,a,s),
     S_a(5,c,s), S_a(6,b,s)}

    {S_a(4,a,d), R_a(3,b,b,d), R_a(1,a,b,s), R_a(2,c,d,s),
     S_a(5,c,s), S_a(6,b,s)}

These three stable models (that do not show here the original EDB) are associated to the S-repairs , resp. Only tuples with tids are at some point deleted. In particular, the first model corresponds to the C-repair

.

Now, to compute causes and their accompanying deleted tuples we add to the program the rules defining and :

         cause(T) :- S_a(T,X,d).
         cause(T) :- R_a(T,X,Y,d).
    cauCont(T,TC) :- S_a(T,X,d), S_a(TC,U,d), T != TC.
    cauCont(T,TC) :- R_a(T,X,Y,d), R_a(TC,U,V,d), T != TC.
    cauCont(T,TC) :- S_a(T,X,d), R_a(TC,U,V,d).
    cauCont(T,TC) :- R_a(T,X,Y,d), S_a(TC,U,d).

Next, contingency sets can be computed by means of DLV-Complex, on the basis of the rules defining predicates and above:

              preCont(T,{TC}) :- cauCont(T,TC).
    preCont(T,#union(C,{TC})) :- cauCont(T,TC), preCont(T,C),
                                 not #member(TC,C).
                  cont(T,C)   :- preCont(T,C), not HoleIn(T,C).
                  HoleIn(T,C) :- preCont(T,C), cauCont(T,TC),
                                 not #member(TC,C).
                  tmpCont(T)  :- cont(T,C), not #card(C,0).
                  cont(T,{})  :- cause(T), not tmpCont(T).

The last two rules associate the empty contingency set to counterfactual causes.

The three stable models obtained above will now be extended with - and -atoms, among others (unless otherwise stated, -, -, and -atoms will be filtered out from the output); as follows:

    {S_a(4,a,d), R_a(3,b,b,d), R_a(1,a,b,s), R_a(2,c,d,s),
     S_a(5,c,s), S_a(6,b,s), cause(4), cause(3), cauCont(4,3),
     cauCont(3,4), cont(3,{4}), cont(4,{3})}

    {R_a(1,a,b,d), R_a(3,b,b,d), R_a(2,c,d,s), S_a(4,a,s),
     S_a(5,c,s), S_a(6,b,s), cause(1), cause(3), cauCont(1,3),
     cauCont(3,1), cont(1,{3}), cont(3,{1})}

    {S_a(6,b,d), R_a(1,a,b,s), R_a(2,c,d,s), R_a(3,b,b,s),
     S_a(4,a,s), S_a(5,c,s), cause(6), cont(6,{})}

The first two models above show tuple 3 as an actual cause, with one contingency set per each of the models where it appears as a cause. The last line of the third model shows that cause (with tid) 6 is the only counterfactual cause (its contingency set is empty).

The responsibility can be computed via predicate that returns , that is the inverse of the responsibility, for each tuple with tid and local to a model that shows as a cause. We concentrate on the computation of in order to compute with integer numbers, as supported by DLV-Complex, which requires setting an upper integer bound by means of maxint, in this case, at least as large as the largest tid:

    #maxint = 100.
    preRho(T,N + 1) :- cause(T), #int(N), #count{TC: cauCont(T,TC)} = N.

where the local (pre)responsibility of a cause (with tid) within a repair is obtained by counting how many instances of exist in the model, which is the size of the local contingency set for plus 1. We obtain the following (filtered) output:

    {S_a(4,a,d), R_a(3,b,b,d), cause(4), cause(3),
     preRho(3,2), preRho(4,2), cont(3,{4}), cont(4,{3})}

    {R_a(1,a,b,d), R_a(3,b,b,d), cause(1), cause(3),
     preRho(1,2), preRho(3,2), cont(1,{3}), cont(3,{1})}

    {S_a(6,b,d), cause(6), preRho(6,1), cont(6,{})}

The first model shows causes 3 and 4 with a pre-rho value of . The second one, causes 3 and 1 with a pre-rho value of . The last model shows cause 6 with a pre-rho value of . This is also a maximum-responsibility cause, actually associated to a C-repair. Inspecting the three models, we can see that the overall pre-responsibility of cause 3 (the minimum of its pre-rho values) is , similarly for cause 1. For cause 6 the overall pre-responsibility value is .

Now, if we want only maximum-responsibility causes, we add weak program constraints to the program above, to minimize the number of deletions:

    :~ S_a(T,X,d).
    :~ R_a(T,X,Y,d).

DLV shows only repairs with the least number of deletions, in this case:

    Best model: {S_a(6,b,d), R_a(1,a,b,s), R_a(2,c,d,s), R_a(3,b,b,s),
                 S_a(4,a,s), S_a(5,c,s), cause(6), preRho(6,1), cont(6,{})}
    Cost ([Weight:Level]): <[1:1]>

As expected, only repair is obtained, where only is a cause, and with responsibility , making it a maximum-responsibility cause.

5 Causal Explanations in Databases: Attribute-Level

In Section 4.1 we saw that: (a) there are different database repair-semantics; and (b) tuples as causes for query answering can be obtained from S- and C-repairs. We can extrapolate from this, and define, as opposed to only reobtain, notions of causality on the basis of a repair semantics. This is what we will do next in order to define attribute-level causes for query answering in databases.

We may start with a repair-semantics for databases under, say denial constraints (this is the case we need here, but we could have more general ICs). Now, we have a database and a true BCQ . As before, we have an associated (and violated) denial constraint  . There will be -repairs, i.e. sanctioned as such by the repair semantics . More precisely, the repair-semantics identifies a class    of admissible and consistent instances that “minimally” depart from . On this basis, -causes can be defined as in Section 4.1(a)-(b). Of course, “minimality” has to be defined, and comes with .

We will develop this idea, at the light of an example, with a particular repair-semantics, and we will apply it to define attribute-level causes for query answering, i.e. we are interested in attribute values in tuples rather than in whole tuples.  The repair semantics we use here is natural, but others could be used instead.

Example 13

Consider the database , with tids, and query  , of Example 2  and  the associated denial constraint  .

A B
C

Since , we need to consider repairs of w.r.t. .

Repairs will be obtained by “minimally” changing attribute values by NULL, as in SQL databases, which cannot be used to satisfy a join. In this case, minimality means that the set of values changed by NULL is minimal under set inclusion. These are two different minimal-repairs:

A B
C
A B
C

It is easy to check that they do not satisfy .  If we denote the changed values by the tid with the position where the changed occurred, then the first repair is characterized by the set , whereas the second, by the set