Active Integrity Constraints for Multi-Context Systems
Luís Cruz-Filipe, Graça Gaspar, Isabel Nunes, Peter Schneider-Kamp
aa r X i v : . [ c s . D B ] S e p Active Integrity Constraints for Multi-ContextSystems ⋆ Lu´ıs Cruz-Filipe , Gra¸ca Gaspar , Isabel Nunes , and Peter Schneider-Kamp Dept. of Mathematics and Computer Science, University of Southern Denmark BioISI—Biosystems & Integrative Sciences Institute, Faculty of Sciences,University of Lisbon
Abstract.
We introduce a formalism to couple integrity constraints overgeneral-purpose knowledge bases with actions that can be executed to re-store consistency. This formalism generalizes active integrity constraintsover databases. In the more general setting of multi-context systems,adding repair suggestions to integrity constraints allows defining simpleiterative algorithms to find all possible grounded repairs – repairs forthe global system that follow the suggestions given by the actions in theindividual rules. We apply our methodology to ontologies, and show thatit can express most relevant types of integrity constraints in this domain.
Integrity constraints (ICs) for databases have been an important topic of researchsince the 1980s [1]. An early survey [26] already identified over 90 relevant typesof integrity constraints. Since then, significant effort has been focused not onlyon identifying inconsistencies, but also on repairing inconsistent databases.The same problem has been studied in other domains of knowledge represen-tation. Integrity constraints for deductive databases [2] were also considered inthe 1980s. More recently, interest for integrity constraints has arisen in the on-tology domain, with several approaches on how to define them and how to checktheir satisfaction [14, 19, 21]. Given its challenges, the more complex problem ofrepairing inconsistent knowledge bases has not received as much attention.In this paper, we address the problem of computing repairs by combining twoideas: clausal-form integrity constraints for multi-context systems (MCSs) [11]and active integrity constraints (AICs) for relational databases [16]. We demon-strate the expressiveness of our formalism and show how it can be used to com-pute repairs for inconsistent MCSs in general, and for ontologies, in particular.
Contribution.
The main contribution of this paper is a notion of AIC for MCSs,which enables us to compute repairs for inconsistent MCSs automatically, requir-ing only decidability of entailment in the individual contexts. Particularized to ⋆ This work was supported by the Danish Council for Independent Research, NaturalSciences, grant DFF-1323-00247, and by FCT/MCTES/PIDDAC under centre grantto BioISI (Centre Reference: UID/MULTI/04046/2013). ntologies, our framework is expressive enough to capture all types of integrityconstraints identified as relevant in [14], as we exemplify in the text.The step from ICs for MCSs to AICs for MCSs is inspired by the similar stepin the database case [16]. However, we draw more significant benefits in this moregeneral setting. AICs are ICs that also specify possible repair actions in theirhead. In the database case, every clausal IC can be transformed into an AICautomatically. The goal, though, is to restrict in order to establish preferencesamong different possible repairs. In the general case, such a transformation wouldrequire solving complex abduction problems [17].Using AICs, we can automatically compute repairs for inconsistent MCSs,bypassing the need to solve such reasoning problems. The price to pay is theneed to prove that an AIC is valid (Definition 4). The key observation here isthat AICs should be written with a very clear semantic idea in mind, typicallyby an engineer with a deep knowledge of the underlying system, who should beable to show their validity formally. Thus, in practice, the complexity involvedin computing each repair is moved to a one-time verification of validity of AICs.
Structure.
We review previous work in Section 2, summarizing the key notionsfrom [5, 8, 11]. Section 3 introduces AICs for MCSs, showing that they generalizethe corresponding notion for relational databases, and studies their properties ingeneral. Section 4 focuses on the case of ontologies and evaluates our formalismagainst the classes of integrity constraints identified in [14]. Section 5 discusseshow algorithms to compute repairs in the database setting can be adapted tothe general case of MCSs. We conclude in Section 6.
Database repairs.
ICs for databases have been extensively studied throughoutthe last decades, and we restrict ourselves to works most directly related to ours.Integrity constraints are typically grouped in different syntactic categories [26].Many important classes can be expressed as first-order formulas, and can alsobe written in denial (clausal) form – the fragment expressable in our formalism.Whenever an integrity constraint is violated, the database must be repaired to regain consistency. The problem of database repair is to determine whethersuch a transformation is possible, and many authors have invested in algorithmsfor computing database repairs efficiently. Typically, there are several possibleways of repairing an inconsistent database, and several criteria have been pro-posed to evaluate them. Minimality of change [13, 27] demands that the databasebe changed as little as possible, while the common-sense law of inertia [23] statesthat every change should have an underlying reason. While these criteria nar-row down the possible database repairs, it is commonly accepted that humaninteraction is ultimately required to choose the “best” possible repair [25].
Active integrity constraints (AICs).
The formalism of AICs, introduced in [16],addresses the issue of choosing among several possible repairs. An AIC specifiesnot only an integrity constraint, but it also gives indications on how inconsistentatabases can be repaired through the inclusion of update actions , which canbe addition and removal of tuples from the database – a minimal set that canimplement the three main operations of database updates [1].The original, declarative, semantics of AICs defined founded repairs [5], inwhich every action is supported : it occurs in the head of a constraint that isviolated if that action is not included. Despite this characterization, there areunnatural founded repairs where two actions mutually support each other, butdo not have support from other actions. The same authors then proposed justi-fied repairs [7], which however are not intuitive and pose further problems [9].Furthermore, justified repairs are intrinsically linked to the syntactic structure ofdatabases, and cannot be adapted to other knowledge representation formalisms.
Grounded repairs [8] form a middle ground between both semantics, requiringsupport for arbitrary subsets of the repair. They are grounded fixed points ofthe intuitive operation of “applying one action from the head of each AIC thatis not satisfied”, which is in line with the intuitive motivation for studying AICs.Founded and justified repairs can be computed via revision programming [7].Alternatively, an operational semantics for AICs [9] was implemented for SQLdatabases [10]. There, repairs are leaves of particular trees, yielding a semanticsequivalent to the declarative one when existence of a repair is an NP-completeproblem. For grounded and justified repairs, where this existence problem is Σ P -complete, the trees still contain all repairs, but may also include spurious leaves– requiring a post test that brings the overall complexity to the theoretical limit. Multi-context systems (MCSs).
MCSs, as defined in [3], can be informally de-scribed as collections of logic knowledge bases – the contexts – connected byDatalog-style bridge rules . Since their introduction, several variants of MCSshave been proposed that add to their potential fields of application. RelationalMCSs [15] were proposed as a way to allow a formal first-order syntax, intro-ducing variables and aggregate expressions in bridge rules, and extending thesemantics of MCSs accordingly. Managed MCSs [4], which we describe in Sec-tion 2, further generalize MCSs by abstracting from the possible actions thatchange individual knowledge bases. Other variants, which are not directly rele-vant for this work, are discussed in [11]. A different line of research deals withrepairing logical inconsistency of an MCS (non-existence of a model) [12].
ICs in ontologies.
Integrating ICs with ontology-based systems poses severalchallenges, mainly due to the open-world assumption and the absence of theunique name assumption [14, 20, 22, 24]. In this context, ICs are conventionallymodelled as T-Box axioms [19], but variants based on hybrid knowledge bases,auto-epistemic logic, modal logic, and grounded circumscription have recentlybeen proposed. For an overview of these proposals see Section 2 in [21]. For detailson how some of these can be expressed by ICs over MCSs, using a systematicinterpretation of ontologies as MCSs, see Section 4.5 in [11]. The interpretationwe use in Section 4 is a variant of the one presented therein.
Background
AICs for databases.
Let Σ be a first-order signature without function symbols. Adatabase is a set of ground atoms over Σ , and an update action is an expressionof the form + a or − a , where a is a ground atom over Σ . An active integrityconstraint (AIC) over a database DB is a rule r of the form p , . . . , p m , not ( p m +1 ) , . . . , not ( p ℓ ) = ⇒ α | · · · | α k (1)where each p i is an atom over the database’s signature, every variable freein p m +1 , . . . , p ℓ occurs in p , . . . , p m , and each update action α i is either − p j for some 1 ≤ j ≤ m or + p j for m < j ≤ ℓ . The body of r is body ( r ) = p , . . . , p m , not ( p m +1 ) , . . . , not ( p ℓ ), and the head of r is head ( r ) = α | . . . | α k .If r is ground, then DB satisfies r , denoted DB | = r , if DB = p i for some1 ≤ i ≤ m or DB | = p i with m < i ≤ ℓ . In general, DB | = r if DB satisfies allground instances of r . Otherwise, r is applicable in DB [16]. If η is a set of AICs,then DB | = η if DB | = r for every r ∈ η .A set of update actions U is consistent if it does not contain both + a and − a for any ground atom a . Given a consistent U , we write U ( DB ) for the resultof applying all actions in U to DB , and say that U is a weak repair for h DB , η i if:(i) every action in U changes DB and (ii) U ( DB ) | = η . U is a repair if V ( DB ) = η for every V ( U [5], and U is grounded if, for every V ( U , there exists a groundinstance r of a rule in η such that V ( DB ) = r and head ( r ) ∩ ( U \ V ) = ∅ [8]. Multi-Context Systems.
We now describe the variant of multi-context systemswe use: managed multi-context systems (also abbreviated to MCSs) [4].A relational logic L is a tuple h KB , BS , ACC , Σ i , where KB is the set of well-formed knowledge bases of L (sets of well-formed formulas), BS is a set of possiblebelief sets (candidate models), ACC : KB → BS is a function assigning to eachknowledge base a set of acceptable belief sets (its models), and Σ is a signaturegenerating first-order sublanguages of S KB and S BS .A managed multi-context system is a collection of managed contexts { C i } ni =1 ,with each C i = h L i , kb i , br i , D i , OP i , mng i i where: L i = h KB i , BS i , ACC i , Σ i i isa relational logic; kb i ∈ KB i ; D i (the import domain ) is a set of constants from Σ i ; OP i is a set of operation names; mng i : ℘ ( OP i × S KB i ) × KB i → KB i is a management function ; and br i is a set of managed bridge rules , with the form( i : o ( p )) ← ( i : p ) , . . . , ( i q : p q ) , not ( i q +1 : p q +1 ) , . . . , not ( i m : p m ) (2)such that o ∈ OP i , p ∈ S KB i , 1 ≤ i, i j ≤ n , and each p j is a belief of L c j .Intuitively, kb i is the knowledge base of context C i and OP i are the namesof the operations that can be applied to change it. The management function In [16], existentially quantified variables can also occur in negative literals. This wasnot discussed in subsequent work, and we ignore it for simplicity of presentation. Technically, P p is a relational element of C i p : it can include variables, which wheninstantiated yield elements of S BS i p – see [4] for details. efines the semantics of these operations: mng i ( O, kb ) is the result of applyingthe operations in O to kb . Bridge rules govern the interaction between contexts. A belief state for an MCS M = { C i } ni =1 is a set S = { S i } ni =1 such that each S i ∈ BS i . A ground instance of bridge rule (2) is applicable in S if p i ∈ S i for 1 ≤ i ≤ q and p i S i for q < i ≤ m ; the variables in the rule can only beinstantiated by elements of the import domain D i . A belief state is an equilibrium for M if it is stable under application of all bridge rules, i.e.: S i ∈ ACC i ( mng i ( { head ( r ) | r ∈ br i applicable in S } , kb i ))In general, M can have zero, one or several equilibria; if at least one exists, then M is logically consistent . We present examples of MCSs in the next sections. Integrity constraints for general-purpose knowledge bases.
ICs for MCSs [11]generalize clausal ICs to a generic framework for reasoning systems – covering notonly relational databases, but also deductive databases, peer-to-peer systems andontologies, among others. Syntactically, ICs are bridge rules with empty head,forming an added layer on top of an MCS that does not affect its semantics.As MCSs may have several equilibria, satisfaction of a set of ICs η can be weak – there is an equilibrium satisfying all rules in η – or strong – all equilibriasatisfy all rules in η . In order to avoid vacuous quantifications, strong satisfactiononly holds for logically consistent MCSs. In general these properties are unde-cidable [11], but if entailment in every context is decidable then satisfaction ofa set of ICs is in most cases as hard as the hardest entailment decision problem.In this paper, we do not explicitly mention the set of ICs when clear from thecontext. Moreover, our development applies both to weak and strong satisfaction,and we simply say that an MCS is consistent if it satisfies the given set of ICs.We explicitly write “logical consistency” for existence of an equilibrium. We begin by defining active integrity constraints over multi-context systems.
Definition 1.
An AIC over an MCS M = { C i } ni =1 is a rule r of the form ( i : P ) , . . . , ( i m : P m ) , not ( i m +1 : P m +1 ) , . . . , not ( i ℓ : P ℓ )= ⇒ ( j : α ) | · · · | ( j k : α k ) (3) where ≤ i p , j q ≤ n , each P p is a belief in C i p , each update action α q ∈ OP j q × S KB j q , and all variables in P m +1 , . . . , P ℓ occur in P , . . . , P m . This definition follows the one for databases (1), and we define body and head of r similarly. Equation (3) also generalizes ICs for MCSs: each AIC corresponds For the sake of presentation, we simplified the management function, which in theoriginal work is allowed to return several possible effects for each action. o an IC by ignoring its head, immediately yielding notions of weak and strongsatisfaction for an AIC. We also say that r is applicable to an MCS M if M = r .Intuitively, in this case M should be repaired by applying actions in head ( r ).The reasoning capabilities of MCSs dictate that we cannot restrict the actionsin the head of an AIC syntactically (as in the database world, see Section 2).We thus relax this requirement by only demanding that the actions are capableof solving the inconsistency. It is also not reasonable to require that every ac-tion in head ( r ) be able to solve every inconsistency detected by body ( r ): sinceinconsistencies may be triggered by derived information, they may have differentorigins, and the different actions may be solutions for those different causes.We are interested in sets of update actions that are applied simultaneously,i.e. the order in which actions are executed should be irrelevant. This correspondsto the consistency requirement usually considered in databases. Definition 2.
Let M = { C i } ni =1 be an MCS, U be a finite set of update actions,and U i be the set of actions in U affecting C i . U i is consistent w.r.t. kb i if, for every permutation α , . . . , α k of the ele-ments of U i , mng i ( U i , kb i ) = mng i ( α , mng i ( . . . , mng i ( α k , kb i ) . . . )) . U is consis-tent w.r.t. M if each U i is consistent w.r.t. kb i , and in this case we write U ( M ) for the result of applying each U i to each kb i .Example 1. We consider a concrete toy example of a deductive database withtwo unary base relations p and q , a view consisting of a relation r such that r ( x ) ↔ p ( x ) ∨ q ( x ), and the integrity constraint ¬ r ( a ).We formalize this as an MCS M = h C E , C I i where C E is an extensionaldatabase including predicates p and q (but not r ), C I is the view context includ-ing predicate r (but not p or q ), and they are connected by the bridge rules( I : r ( X )) ← ( E : p ( X )) ( I : r ( X )) ← ( E : q ( X )) . Furthermore, mng E allows addition and removal of any tuples to C E , usingoperations add and del , while mng I does not allow any changes. (See [11] fordetails of this construction.)From the structure of M , we know that r ( a ) can only arise as a deductionfrom p ( a ) or q ( a ) (or both), so it makes sense to write an AIC( I : r ( a )) = ⇒ ( E : del ( p ( a ))) | ( E : del ( q ( a ))) . The actions on the head of this AIC solve the problem in all future states of M ,since C I cannot change. However, restoring consistency may require performingboth actions (if the database contains both p ( a ) and q ( a )).This example also illustrates an important point: repair actions are writtenwith a particular structure of the MCS in mind. Definition 3.
The set of variants to an MCS M , denoted vrt ( M ) , is vrt ( M ) = {U ( M ) | U is a finite set of update actions over M } . estrictions on the actions in the head of AICs only range over vrt ( M ), whichcontains all possible future evolutions of M . Definition 4.
An AIC r of the form (3) is valid w.r.t. an MCS M if: – for every logically consistent M ′ ∈ vrt ( M ) such that M ′ = r , there is U ⊆ head ( r ) with U ( M ′ ) | = r ; – for every α ∈ head ( r ) , there is M ′ ∈ vrt ( M ) with M ′ = r and α ( M ′ ) | = r . These conditions require that the set of suggested actions be complete (it cansolve all inconsistencies) and that it does not contain useless actions.
Example 2.
The AIC in Example 1 is valid: the only possible changes to M arein kb E , which only contains information about p and q , thus, in any element of vrt ( M ) the only way to derive r ( a ) is still from either p ( a ) or q ( a ). The secondcondition follows by considering M ′ with kb E = { p ( a ) } and kb E = { q ( a ) } . Proposition 1.
Deciding whether an AIC is valid is in general undecidable.Proof (sketch).
Let L be a logic with an undecidable entailment problem, C bea context over L with add ∈ OP C such that mng C ( add ( ϕ ) , Γ ) = Γ ∪ { ϕ } , and M = { C } . Assume also that vrt ( M ) includes all knowledge bases over L . Then( C : ¬ B ) = ⇒ ( C : add ( A )) is valid iff A | = L B . ⊓⊔ In practice, proving validity of AICs should not pose a problem: AICs arewritten by humans with a very precise semantic motivation in mind, and thismeans that the conditions in Definition 4 should be simple for a human to prove.We now show that the framework we propose generalizes the database case.A database DB can be seen as an MCS M ( DB ), defined as having a single contextover first-order logic, whose knowledge base is DB , with management functionallowing addition (+) or removal ( − ) of facts, and where the only set of beliefsadmissible w.r.t. a given database is the set of literals that are true in thatdatabase (see [11] for a detailed definition). Proposition 2.
Every AIC over a database DB yields a valid AIC over M ( DB ) .Proof (sketch). We write a generic AIC over a database (1) as the AIC(1 : p ) , . . . , (1 : p m ) , not (1 : p m +1 ) , . . . , not (1 : p ℓ ) = ⇒ (1 : α ) | · · · | (1 : α k )over M ( DB ). If DB does not satisfy the body of (1), then it can always berepaired by performing exactly one of the actions in its head [6], establishingboth conditions for validity. ⊓⊔ Definition 5.
Let M = { C i } ni =1 be an MCS, η be a set of AICs over M and U be a finite set of update actions. U is a weak repair for h M, η i if U is consistentw.r.t. M and U ( M ) | = η . Furthermore, U is grounded if: for every V ( U , thereis an AIC r ∈ η such that V ( M ) = r and head ( r ) ∩ ( U \ V ) = ∅ . The definitions of weak and grounded repair directly correspond to those for thedatabase case (Section 2). The notion of grounded repair implies, in particular,minimality under inclusion [8].
Application: the Case of Ontologies
This section is devoted to examples illustrating how our framework can be ap-plied to the particular case of integrity constraints over ontologies.Previous work [3, 11] shows how to view an ontology as a context of an MCS.In the present work, we refine this interpretation by representing an ontology as two contexts: one for the A-Box, one for the T-Box, connected by bridge rulesthat port every instance from the former into the latter. (This is reminescentof how deductive databases are encoded in MCSs, see [11].) This finer encodingallows us, in particular, to reason about asserted instances (which are given inthe A-Box) and those that are derived using the axioms (see Example 5).We further assume that the A-Box only contains instances of atomic conceptsor roles ( C ( t ) or R ( t, t ′ )). This option does not restrict the expressive power ofthe ontology, but it helps structure AICs: to include instance axioms aboute.g. C ⊔ D , one instead defines a new concept E = C ⊔ D in the T-Box andincludes instance axioms about E in the A-Box (see also Example 7). Definition 6.
A description logic L is represented as the relational logic L L = h KB L , BS L , ACC L , Σ L i , where: – KB L contains all well-formed knowledge bases of L ; – BS L contains all sets of queries in the language of L ; – ACC L ( kb ) is the singleton set containing the set of queries to which kb an-swers “Yes”. – Σ L is the first-order signature underlying L .An ontology O = h T, A i based on L induces the multi-context system M ( O ) = h Ctx ( T ) , Ctx ( A ) i where Ctx ( T ) = h L L , T, br T , Σ , ∅ , ∅i with – br T contains all rules of the form ( T : C )( X ) ← ( A : C )( X ) where C is aconcept, and ( T : R )( X, Y ) ← ( A : R )( X, Y ) where R is a role; – Σ is the set of constants in Σ L ;and Ctx ( A ) = h L L , A, ∅ , Σ , OP, mng i where OP and mng are the set of allowedupdate operation names and their definition. The management function does not allow changes to the T-Box; the particularoperations in the A-Box depend on the concrete ontology. This is in line withour motivation that writing AICs requires knowledge of the system’s deductiveabilities (expressed by the T-Box), which should not change.We now evaluate the expressivity of our development by showing how toformalize several types of ICs over ontologies. We follow the classification inSection 4.5 of [14], which describes families of ICs determined by OWL engineersand ontologists as the most interesting, as well as other types of ICs consideredin the scientific literature. Several classes of ICs are syntactically similar, so wedo not include examples for all categories in [14], but explain in the text howthe missing ones can be treated.ost of our examples are adapted from [14], which frames them in a vari-ant of the Lehigh University Benchmark [18], an ontology designed with thegoal of providing a realistic scenario for testing. This ontology considers con-cepts student , gradStudent , class and email , and roles hasEmail , enrolled and webEnrolled . Our semantics is: class is a concept including all classes of a commoncourse; enrolled ( c , s ) holds if student s is enrolled in course s ; and webEnrolled holds if the student is furthermore to be contacted only electronically. The ac-tual contents of the A-Box are immaterial for our presentation, and we restrictourselves to the fragment of the T-Box containing the following axioms. gradStudent ⊑ student ∃ enrolled . student ⊑ classwebEnrolled ⊑ enrolled ∃ hasEmail . email ⊑ student ∃ webEnrolled R . class ⊑ ∃ hasEmail Functional dependencies are one of the most frequently occurring families ofICs: requirements that certain relations be functional on one argument. In ourexample, this applies to hasEmail : two distinct students cannot have the samee-mail.Since ontologies do not have the Unique Name Assumption, we cannot dis-tinguish individuals by checking name equality (as in databases), but must querythe ontology instead. Furthermore, while in the database world such violationscan only be repaired by removing one of the offending instances, in ontologies,we can also add the information that two individuals are the same.
Example 3.
Suppose that the management function includes operations add and del to add or remove a particular instance from the A-Box, as well as assertEqual ,establishing equality of two individuals. Under these assumptions, we can expressfuncionality of e-mail as the following AIC.( A : hasEmail ( X, Z )) , ( A : hasEmail ( Y, Z )) , not ( T : ( X = Y ))= ⇒ ( A : del ( hasEmail ( X, Z ))) | ( A : assert ( X = Y )) (4)Observe that, if T explicitly proves that X = Y , then only the first action canbe used, as asserting equality between X and Y would lead to an inconsistency.However, if this is not the case then the second action is also a repair possibility,and hence this AIC is valid. There are several possibilities for the implementationof assert : it can add the equality X = Y to the A-Box, but it can also syntacticallyreplace every occurrence of one of them for the other.Several other types of dependencies (e.g. key constraints, uniqueness con-straints, functionality constraints) are expressed by similar formulas. Likewise,max-cardinality constraints can be represented as AICs with similar types ofactions in the head (deleting some instances or unifying some individuals). This semantics is slightly changed from that of [14], in order to make some aspectsof our example more realistic. .2 Property domain constraints
This family of ICs specifies that the domain of a role should be a subset of aparticular concept. In case such a constraint is violated, the offending elementhas to be added as an instance of that concept. The treatment of these ICs isthus very similar to the database case.
Example 4.
To model that only students can be enrolled in courses, we writethe following AIC.( T : enrolled ( X, Y ) , not ( T : student ( Y )) = ⇒ ( A : add ( student ( Y ))) (5)We could also add the action ( A : del ( enrolled ( X, Y ))) to the head of this AIC;note that it would only restore consistency in the case where this fact is explicitlystated in the A-Box and not otherwise derivable. Property range constraints(restricting the range of a role) can be similarly treated.
In many applications, it is interesting to minimize redundancy in the A-Box.In particular, in the presence of inclusion axioms, it is often desirable only toinclude instances pertaining to the most specific type class of each individual.
Example 5.
Since gradStudent ⊑ student , we guarantee that the A-Box onlycontains instances of the most specific class a student belongs to by writing:( A : gradStudent ( X )) , ( A : student ( X )) = ⇒ ( A : del ( student ( X ))) (6)Thus, if the A-Box contains e.g. student ( john ) and gradStudent ( john ), thenthe axiom student ( john ) will be removed. The system will still be able to derive student ( john ), but only in context C T (using the information in the T-Box). Theseparation of the A-Box and T-Box in different contexts is essential to expressthis integrity constraint in our formalism. Constraints that distinguish betweenassertions explicitly stated in the A-Box and derived ones have been considerede.g. in [22]. We now consider a more interesting type of ICs: min-cardinality constraints.Inconsistencies arising from the violation of such constraints are hard to repareautomatically, as such a repair requires “guessing” which instances to add. UsingAICs and adequate management functions, we can even specify the constructionof “default” values that may depend on the actual ontology.
Example 6.
We want to express that each class must have a minimum of 10students. Classes with less enrolled students should be closed, and those studentsmoved to the smallest remaining class using an operation redistribute .( T : ( ≤ . enrolled )( X )) = ⇒ ( A : redistribute ( ¬ class ( X ))) (7)or this AIC to be valid, redistribute must check whether students are enrolled or webEnrolled and change the appropriate instance in the A-Box. This also usesthe knowledge that instances of enrolled cannot be derived in other ways.A similar kind of constraints are totality constraints, which require that arole be total on one of its arguments. In our example, we could require everystudent to be enrolled in some class, and use an adequate management functionto add non-enrolled students to e.g. the smallest class. We now turn our attention to a kind of ICs that is also very common in ontolo-gies: disallowing unnamed individuals for particular properties [22].
Example 7.
Our ontology specifies that all students that are webEnrolled in aclass must have an e-mail address. However, for the purpose of contacting theseindividuals, this e-mail address must be explicitly provided. We address thisissue with the following AIC.( T : ( ∃ hasEmail )( X )) , not ( T : hasEmail ( X, Y ))= ⇒ ( A : unregister ( ¬∃ webEnrolled R ( X ))) (8)Here, unregister replaces the axiom webEnrolled ( X ) with enrolled ( X ), as it makessense to keep the student enrolled in the course. Validity of this AIC follows fromobserving that the only possible ways to derive ∃ hasEmail ( X ) are either from anexplicit assertion hasEmail ( X, Y ) or indirectly from webEnrolled ( Z, X ).This example also justifies our requirement that the A-Box can only containinstances of atomic concepts or roles. If the A-Box were allowed to containe.g. ∃ hasEmail ( john ), then AIC (8) would no longer be valid. By restricting toatomic concepts, the only way to perform a similar change would be by defining anew concept as equivalent to ∃ hasEmail – and this information would be presentin the T-Box, making it clear that AICs should consider it. Finally, we illustrate how we can write AICs in different ways to control whetherthey range over all individuals of a certain class, or only over named ones.
Example 8.
For ecological reasons, we want all students with an e-mail addressto be enrolled in the web version of courses. We can write this as follows.( T : ( hasEmail )( Y, Z )) , ( T : enrolled ( X, Y )) , not ( T : webEnrolled ( X, Y ))= ⇒ ( A : webEnroll ( webEnrolled ( X, Y ))) (9)Operation webEnroll will replace enrolled ( X, Y ) with webEnrolled ( X, Y ), duallyto unregister in the previous example.lternatively, we could consider writing( T : ( ∃ hasEmail )( Y )) , ( T : enrolled ( X, Y )) , not ( T : webEnrolled ( X, Y ))= ⇒ ( A : webEnroll ( webEnrolled ( X, Y ))) (10)In this particular context, this formulation is undesirable, as it will also affectindividuals who do not have a known e-mail address. By writing an explicitvariable in the first query of the body, as in (9), we guarantee that we onlyaffect those individuals whose e-mail address is known.Similar considerations about the two possible ways to formulate this type of ICscan be found in [22].
In [9], we showed how to use active integrity constraints to compute repairs forinconsistent databases, by using the actions in the head of unsatisfied AICs tobuild a repair tree whose leaves were the repairs. We showed how the constructionof the tree could be adapted to the different types of repairs considered originallyin [7]; in particular, for the case of grounded repairs (which is the one we areinterested in this work), it is enough to expand each node with the actions inthe heads of the AICs that are not satisfied in that node.We adapt this construction to the framework of AICs over MCSs. As we willsee, the algorithms have to be adapted to this more general scenario, but we canstill construct all grounded repairs for a given (inconsistent) MCS automatically,as long as entailment in all contexts is decidable.
Definition 7.
Let M be an MCS and η be a set of integrity contraints over M .The repair tree for h M, η i , T h M,η i , is defined as follows. – Each node is a set of update actions. – A node n is consistent if: (i) n ( M ) is logically consistent and (ii) if n ′ is theparent of n , then n is a consistent set of update actions w.r.t. n ′ ( M ) . – Each edge is labeled with a closed instance of a rule. – The root of the tree is the empty set ∅ . – For each consistent node n and rule r , if n ( M ) = r then n ′ = n ∪ U isa child of n if (i) U ⊆ head ( r ) , (ii) n ′ ( M ) | = r and (iii) if U ′ ⊆ U then ( n ∪ U ′ )( M ) = r . In the database case [9], it is straightforward to show that repair trees arefinite, since the syntactic restrictions on database AICs guarantee that each rulecan only be applied at most once in every branch. In the general MCS case, thisis not true, as the following example shows.
Example 9.
Consider an ontology (represented as an MCS as in Section 3) withfour concepts B , B , B and D . The T-Box contains axioms B ⊑ D and B ⊓ B ⊑ D nd the A-Box is { B ( a ) , B ( a ) } . Furthermore, we have integrity constraints( T : D )( a ) = ⇒ ( A : del ( B )( a )) | ( A : del ( B )( a )) ( r ) not ( T : B )( a ) , not ( T : B )( a ) = ⇒ ( A : add ( B )( a )) ( r ) ∅ r (cid:15) (cid:15) { del ( B )( a ) } r (cid:15) (cid:15) { del ( B )( a ) , add ( B )( a ) } r (cid:15) (cid:15) { del ( B )( a ) , add ( B )( a ) , del ( B )( a ) } Following this construction, weobtain the tree on the right, and itsleaf is a grounded repair.
Lemma 1. T h M,η i is finite.Proof. By definition, every node of T h M,η i has a finite number of descen-dants, since there are only finitelymany ground instances of AICs with afinite number of actions in each one’shead. By construction, in every branch the labels of the nodes form an increasingsequence (w.r.t. set inclusion), and each node is again a subset of the (finite)set of all actions in the heads of all rules. Therefore, T h M,η i has finite depth andfinite degree, hence it is finite. ⊓⊔ Lemma 2.
Every grounded repair for h M, η i is a leaf of T h M,η i .Proof. Let U be a grounded repair for M and η . By definition of grounded repair,if U ′ ⊆ U then there is a ground instance r of an AIC such that: there exists V ⊆ head ( r ) ∩ U such that ( U ′ ∪ V )( M ) | = r . This directly yields a branch of therepair tree ending at U . ⊓⊔ (This is essentially the same argument for showing that, in the database case,grounded repairs are well-founded, see [8].) T h M,η i is constructed as the well-founded repair tree in the database case [9]. In both cases, this tree may, in general, contain leaves that are not groundedrepairs [8]. Under the assumption that P = NP, this cannot be avoided, sinceexistence of grounded repairs for databases is a Σ P -complete problem [8]. Complexity.
The proof of Lemma 1 shows that the depth of T h M,η i is polynomialin the size of the grounded instances of η . Therefore, given an oracle that decideswhether an MCS satisfies a set of AICs, the problem of existence of a groundedrepair for h M, η i is Σ P -complete: T h M,η i can be built in non-deterministic poly-nomial time (guessing which rule to apply at each node and using the oracle todecide whether the descendant is a leaf), and the validation step can be done inco-NP time (if the leaf is not a grounded repair, then we guess the subset thatviolates the definition and use the oracle to confirm this). There is also a notion of repair tree for databases in [9], but it relies on the abilityof inferring heads of AICs automatically, which does not exist in the MCS setting.
Discussion and Conclusions
Validity.
At the end of Example 1, we pointed out that restoring consistentw.r.t. an AIC r may require applying several actions in head ( r ). This suggestsallowing sets of actions (rather than actions) in the heads of AICs. Besides in-creasing the complexity of our development, it is not clear that this change wouldbring significant benefits. In terms of computing repairs, we already cover thosecases, since we add sets of actions when going from a node to its descendents.Also, it is not clear that there exists a situation when every possible inconsistentMCS requires a set of actions to repair.One could also remove the second condition of validity of an AIC, i.e. allowthe actions in the head to be insufficient to restore consistency of some MCSs.This would remove some burden from the programmer who has to specify theAICs, and would not affect the performance of the algorithms in Section 5.However, it would contradict the original motivation for AICs [16]: that theactions in the head of a rule should provide the means for restoring consistency. Variants of AICs.
The authors of [16] also considered conditioned active integrityconstraints , where the actions on the head of AICs are guarded by additionalconditions that have to be satisfied. In their setting, conditioned AICs do notadd expressive power to the formalism, as they can be split into several uncon-ditioned AICs (with more specific bodies) preserving the notions of consistencyand repairs. In our setting, this transformation is not possible, and it wouldthus be interesting to study conditioned active integrity constraints over multi-context systems. However, we point out that the management function can useinformation about the actual knowledge bases in its implementation, so someconditions can actually be expressed in our setting (see Example 6).
Conclusion.
We proposed active integrity constraints for multi-context systemsand showed that, using them, we can compute grounded repairs for inconsistentMCSs automatically. Although validity of AICs is in general undecidable, weshowed that we can cover the most common types of ICs in our framework.
References
1. S. Abiteboul. Updates, a new frontier. In
ICDT , volume 326 of
LNCS , pages 1–18.Springer, 1988.2. P. Asirelli, M. de Santis, and M. Martelli. Integrity constraints for logic databases.
J. Log. Program. , 2(3):221–232, 1985.3. G. Brewka and T. Eiter. Equilibria in heterogeneous nonmonotonic multi-contextsystems. In
AAAI , pages 385–390. AAAI Press, 2007.4. G. Brewka, T. Eiter, M. Fink, and A. Weinzierl. Managed multi-context systems.In
IJCAI , pages 786–791. IJCAI/AAAI, 2011.5. L. Caroprese, S. Greco, C. Sirangelo, and E. Zumpano. Declarative semantics ofproduction rules for integrity maintenance. In
ICLP , volume 4079 of
LNCS , pages26–40. Springer, 2006.. L. Caroprese and M. Truszczynski. Declarative semantics for active integrity con-straints. In
ICLP , volume 5366 of
LNCS , pages 269–283. Springer, 2008.7. L. Caroprese and M. Truszczy´nski. Active integrity constraints and revision pro-gramming.
Theory Pract. Log. Program. , 11(6):905–952, November 2011.8. L. Cruz-Filipe. Grounded fixpoints and active integrity constraints. In
ICLP ,OASICS. Dagstuhl, 2016. Accepted for publication.9. L. Cruz-Filipe, P. Engr´acia, G. Gaspar, and I. Nunes. Computing repairs fromactive integrity constraints. In
TASE , pages 183–190. IEEE, 2013.10. L. Cruz-Filipe, M. Franz, A. Hakhverdyan, M. Ludovico, I. Nunes, andP. Schneider-Kamp. repAIrC: A tool for ensuring data consistency by means ofactive integrity constraints. In
KMIS , pages 17–26. SciTePress, 2015.11. L. Cruz-Filipe, I. Nunes, and P. Schneider-Kamp. Integrity constraints for general-purpose knowledge bases. In
FoIKS , volume 9616 of
LNCS , pages 235–254.Springer, 2016.12. T. Eiter, M. Fink, G. Ianni, and P. Sch¨uller. Towards a policy language for man-aging inconsistency in multi-context systems. In
Workshop on Logic-based Inter-pretation of Context: Modelling and Applications , pages 23–35, 2011.13. T. Eiter and G. Gottlob. On the complexity of propositional knowledge baserevision, updates, and counterfactuals.
Artif. Intell. , 57(2-3):227–270, 1992.14. M. Fang. Maintaining integrity constraints in semantic web. Ph.D. thesis, GeorgiaState University, 2013.15. M. Fink, L. Ghionna, and A. Weinzierl. Relational information exchange andaggregation in multi-context systems. In
LPNMR , volume 6645 of
LNCS , pages120–133. Springer, 2011.16. S. Flesca, S. Greco, and E. Zumpano. Active integrity constraints. In
PPDP , pages98–107. ACM, 2004.17. A. Guessoum. Abductive knowledge base updates for contextual reasoning.
J.Intell. Inf. Syst. , 11(1):41–67, 1998.18. Y. Guo, Z. Pan, and J. Heflin. LUBM: A benchmark for OWL knowledge basesystems.
J. Web Sem. , 3(2–3):158–182, 2005.19. B. Motik, I. Horrocks, and U. Sattler. Bridging the gap between OWL and re-lational databases.
Web Semantics: Science, Services and Agents on the WorldWide Web , 7(2), 2011.20. B. Motik and R. Rosati. Reconciling description logics and rules.
J. ACM , 57,June 2010. Article Nr 30.21. D. Ouyang, X. Cui, and Y. Ye. Integrity constraints in OWL ontologies based ongrounded circumscription.
Frontiers of Computer Science , 7(6):812–821, 2013.22. P.F. Patel-Schneider and E. Franconi. Ontology constraints in incomplete andcomplete data. In
ISWC , volume 7649 of
LNCS , pages 444–459. Springer, 2012.23. T.C. Przymusinski and H. Turner. Update by means of inference rules.
J. Log.Program. , 30(2):125–143, 1997.24. J. Tao, E. Sirin, J. Bao, and D.L. McGuinness. Integrity constraints in OWL. In
AAAI . AAAI Press, 2010.25. E. Teniente and A. Oliv´e. Updating knowledge bases while maintaining theirconsistency.
VLDB J. , 4(2):193–241, 1995.26. B. Thalheim.
Dependencies in Relational Databases . Teubner-Texte zur Mathe-matik. B.G. Teubner, 1991.27. M. Winslett.