Introduction

OWL [16] is a family of languages which are broadly used for knowledge representation purposes. It is based on description logics (DL) [4] and offers versatile means to model terminological knowledge as well as knowledge about data. For knowledge represented in RDF [21], SPARQL [22] provides possibilities to query this knowledge. Similarly, the SPARQL-DL [23] query language, a distinct subset of the SPARQL query language, renders it possible to query OWL knowledge bases. A SPARQL-DL interface is included in every OWL API 3 reasoner which allows these reasoners to answer SPARQL-DL queries.

Besides querying represented knowledge, the management of changes constitutes an interesting challenge. Nearly all represented knowledge is subject to frequent changes and even the construction of a knowledge base can be seen as an evolutionary development. To meet these requirements for dynamics, SPARQL update [9], an update language for RDF graphs, was developed. Even though there is some research on semantics of SPARQL update for RDFS ontologies [1,13] and approaches addressing updates in interplay with rather restricted TBoxes languages [2], up till now there is no definition of semantics for SPARQL updates for OWL knowledge bases. We define SPARQL update semantics for OWL-DL ABoxes and show how existing methods like justification-based explanation can be used to conduct SPARQL updates in the presence of OWL-DL TBoxes.

Running Example

We consider the knowledge base K = (T , A), given in description logic syntax,

T = {SoftwareEngineer Employee,(1)

Secretary Employee,

Student Employee StudentTrainee,

A = {SoftwareEngineer (john), ( 5)

Employee(john),(6)

StudentTrainee(john),

Student(john)} (8) with a SPARQL update which removes the status of being a StudentTrainee from all students who are employees and assigns them to some special course c1.

INSERT {?X :attendsCourse :c1} DELETE {?X a :StudentTrainee} WHERE {?X a :Student, ?X a :Employee}

The update is supposed to be incorporated into the ABox by removing and adding as few assertions as possible. According to [9], the overall processing model is to first evaluate the pattern in the WHERE clause, then to perform the deletion and after that the insertion. In order to use a uniform notation, we stick to description logic syntax and represent the triples which are supposed to be deleted or inserted as ABox assertions. W.r.t. the query presented above, the task is to delete StudentTrainee(john) and to insert attendsCourse(john, c1). To accomplish the deletion, we have to find a minimal set of ABox assertions whose deletion prevents StudentTrainee(john) from being entailed by the knowledge base. This can be done by removing one of the following two sets {StudentTrainee(john), Student(john)} {StudentTrainee(john), Employee(john), SoftwareEngineer (john)} from the ABox. Note that both these possibilities constitute a minimal way to delete StudentTrainee(john) since no proper subset implements the deletion. For example the knowledge base resulting from removing only StudentTrainee(john) from the ABox would still entail StudentTrainee(john) since Student(john), Employee(john) together with the TBox axiom (3) imply StudentTrainee(john).

In general, when considering knowledge bases with expressive TBoxes, there are many possibilities to accomplish a deletion. Determining which assertions to delete leads to different semantics for SPARQL update delete. Sec. 6 introduces some possible choices. Considering the insertion part of the example SPARQL update query, the task is to insert attendCourse(john, c1) into the ABox. Taking a closer look at the knowledge base, the last axiom in the TBox reveals that inserting attendCourse(john, c1) implies Student(john) which directly contradicts the first possibility to delete StudentTrainee(john) mentioned above. This illustrates, that it is not advisable to consider insertion and deletion separately as this might have undesired effects. To remedy this situation, in Sec. 6 we introduce query-driven semantics taking into account the whole query.

Inserting new assertions into an ABox might introduce inconsistencies. In this case, debugging techniques can be used to remove the inconsistency. Choosing one of the possibly many ways to resolve an inconsistency can be done by choosing one of the semantics we introduce in Sec. 6.2.

Background and Related Work

Related Work

The problem of belief revision and updating knowledge bases has received much attention in research [3,12]. [11] introduces a kernel semi-revision operator for belief bases in OWL-DL. The basic idea of this operator is to add the new information to the knowledge base, then compute all justifications for possible inconsistencies and remove one element from each of these justifications. Since in the last step the previously introduced information might be removed, it is not guaranteed that the inserted information is contained in the result. In contrast to this, some of the semantics we introduce guarantee that the result contains the inserted information whenever this is possible.

In [5], the prioritized assertional-based revision of DL-Lite knowledge bases is addressed. In their setting, it is assumed that the data is associated with priority or credibility information, possibly originating from the combination of data from different sources where each source has a certain reliability level.

Instance-level insertion and deletion for DL-Lite F , a tractable extension of DL-Lite which is oriented towards data intensive applications, is investigated in [6]. Since all reasoning tasks in DL-Lite F are tractable, approaches developed for this logic cannot be expected to be suitable for OWL-DL.

With respect to SPARQL update, [1] discusses possible semantics for SPARQL update in the presence of DL-Lite TBoxes. Due to the low expressivity of DL-Lite, inconsistencies are not an issue. [2] addresses the problem of handling inconsistencies due to class disjointness introduced by SPARQL updates. The ap-proach is restricted to a DL-Lite fragment called DL−Lite RDF S¬ covering RDFS as well as concept disjointness axioms. Different semantics of SPARQL ABox updates are defined similar to the notion of the inconsistency tolerant semantics introduced in [15]. [2] use skillful query-rewriting to determine and resolve inconsistencies. These rewritings exploit the fact that in DL − Lite RDF S¬ inconsistencies are caused by at most two ABox assertions. In contrast to this, inconsistencies in OWL-DL can be caused by an arbitrary number of ABox assertions.

[18] presents an approach for interactive ontology revision. User interaction is used to decide if an axiom should be accepted or rejected. This is combined with automated reasoning to ensure consistency.

Further Background

We introduce syntax and semantics of the description logic SHOIN which corresponds to OWL-DL. Given a set of atomic roles N R , the set of roles is defined as Let N C be the set of atomic concepts and N I a set of individuals. The set of concepts is inductively defined using the following grammar: Since this paper only considers updates concerning the ABox, we restrict the following definition to ABox assertions. For the task of deleting assertions from

N R ∪ {R − | R ∈ N R },C → | ⊥ | A | ¬C | C 1 C 2 | C 1 C 2 | ∃R.C | ∀R.C | ≥ nS | ≤ nS | {a} where A ∈ N C , C i SHOIN concepts, R ∈ N R , S ∈ N R a

Concepts and RolesI = ∆ I {a} I = {a I } ⊥ I = ∅ (∀R.C) I = {x | ∀y : (x, y) ∈ R I ⇒ y ∈ C I (¬C) I = ∆ I \C I (∃R.C) I = {x | ∃y : (x, y) ∈ R I ∧ y ∈ C I } (C D) I = C I ∪ D I (≥ n S) I = {x | |{y | (x, y) ∈ S I }| ≥ n} (C D) I = C I ∩ D I (≤ n S) I = {x | |{y | (x, y) ∈ S I }| ≤ n} (R − ) I = {(y, x) | (x, y) ∈ R I } TBox & RBox axioms ABox assertion C D ⇒ C I ⊆ D I A(a) ⇒ a I ∈ A I R S ⇒ R I ⊆ S I R(a, b) ⇒ (a I , b I ) ∈ R I Trans(R) ⇒ (R I ) + ⊆ R I Table 1. Model-theoretic semantics of SHOIN . R + is the transitive closure of R, R − is the inverse of role R. ABox RDF A(x)

x a A. P (x, y)

x P y.

Table 2. SHOIN ABox assertions vs. RDF as presented in [2], with A a concept name, P a role (or property) name, Γ a set of IRIs and x, y ∈ Γ.

a knowledge base or the task of debugging an ABox which is unsatisfiable w.r.t. the TBox and RBox, the notion of justifications is very helpful. Given an ABox assertion α and a knowledge base K = (R, T , A), a justification of α in K is a minimal subset of A which together with T and R implies α.

Definition 1 (Justification [14]) Let K = (R, T , A) be a knowledge base and α be an ABox assertion. J ⊆ A is a justification for α in K if (R, T , J ) |= α and for all J ⊂ J , (R, T , J ) |= α. The set of all justifications for α in K is denoted by Just(α, K).

An Internationalized Resource Identifier (IRI) is a character string used to identify a resource. Blank nodes identify anonymous resources which are not directly identifiable from an RDF statement. A literal is a character string which possibly can be interpreted by means of a certain datatype.

Definition 2 (RDF Triple, RDF Graph) Let I, B and L be disjoints sets of IRIs, blank nodes and literals. An RDF triple is of the form (s, p, o)

∈ (I ∪ B) × I × (I ∪ B ∪ L). A set of RDF triples is called RDF graph.

A triple without blank node is called ground triple. Every SHOIN knowledge base can be mapped to an RDF graph and vice versa. See Tab. 2 for the mapping of ABox assertions and [19] for further details on the mapping. Therefore, we consider a knowledge base K = (R, T , A) to be equivalent to the RDF graph produced by this mapping. Furthermore, for the sake of uniform notation, in most cases we will stick to DL syntax. Definition 3 (BGP, CQ, UCQ, Query Answer [2]) A conjunctive query (CQ) q, or basic graph pattern (BGP), is a set of atoms of the form given in Tab. 2 where x, y ∈ Γ ∪ V with V a countable infinite set of variables (written as '?-' prefixed alphanumeric strings) and Γ a set of IRIs. A union of conjunctive queries (UCQ) or UNION pattern Q, is a set of CGs. V(q) (V(Q)) denotes the set of variables, occurring in q (Q). An answer to a CQ q over a knowledge base K is a substitution θ of the variables in V(q) with constants in Γ such that every model of K satisfies all facts in qθ. The set of all such answers is denoted with ans(q, K). The set of answers to a UCQ Q is ∪ q∈Q ans(q, K).

Please note, that our definition of a BGP disallows blank nodes. Next, we introduce the notion of a SPARQL update operation and simple update semantics. [2]) Let K = (R, T , A) be a knowledge base then the simple update of K w.r.t. an SPARQL update operation u(P d , P i , P w ) is defined as

K u(P d ,Pi,Pw) = (R, T , ((A \ A d ) ∪ A i ) where A d = ∪ θ∈ans(Pw,K) gr(P d θ)

and A i = ∪ θ∈ans(Pw,K) gr(P i θ) with gr a selection function which selects all ground triples from a BGP.

The simple update of a knowledge base w.r.t. u(P d , P i , P w ) results in removing the set of ABox assertions corresponding to P d and adding the set of ABox assertions corresponding to P i . Note that in case of using simple update semantics, it is not guaranteed that the assertions in P d are not entailed anymore. Furthermore, it is possible that the resulting knowledge base is inconsistent. Since this outcome is not always acceptable for an update, in Sec. 6 we suggest different semantics for SPARQL update operations which behave differently.

Overall Architecture

According to [9], the overall processing model for performing a SPARQL update query is to first evaluate the pattern in the WHERE clause, then perform the deletion and after that the insertion. This is why we suggest the workflow given in Algorithm 1.

In Line 1 a CONSTRUCT query for the DELETE and WHERE clause is used to create a graph G D consisting of the triples which are supposed to be deleted. These triples correspond to a set of ABox assertions denoted by A d . Similar to this, Line 2 constructs the set A i of ABox assertions which are supposed to be inserted. Next, the task of deleting the set of assertions given in A d is addressed. For this, in Line 3 function compDeletion is called which, given a knowledge base, a set of ABox assertions which should be deleted and a keyword indicating the desired semantics, determines a subset of A which accomplishes the deletion. The pseudo code for this procedure is given in Algorithm 2. Line 4 checks the satisfiability of Algorithm 1 Perform a SPARQL update query to a knowledge base. Input: K = (R, T , A), SPARQL update query u(P d , P i , P w ), DeleteSem the desired sematics for deletion and InsertSem the desired semantics for insertion. Output: Revised knowledge base K = (R, T , A Revised ) 1: A d = set of ABox ass. for the result of asking CONSTRUCT P d WHERE P w to K 2: A i = set of ABox ass. for the result asking CONSTRUCT P i WHERE P w to K

3: Deletion = compDeletion(K, A d , DeleteSem) 4: if K = (R, T , (A \ Deletion) ∪ A i ) consistent then 5: return K = (R, T , (A \ Deletion) ∪ A i ) 6: else 7: Debug = compDeletion(K = (R, T , (A\Deletion)∪A i ), {⊥}, InsertSem) 8: return K = (R, T , ((A \ Deletion) ∪ A i ) \ Debug) 9: end if

the knowledge base resulting from first deleting the ABox assertions determined by the compDeletion function and then adding the assertions in A i . If the resulting knowledge base is satisfiable, then Line 5 returns the resulting knowledge base. If however the resulting knowledge base is unsatisfiable, the compDeletion procedure is used to debug the knowledge base. For this purpose, the compDeletion procedure is called with {⊥} as the set of assertions which are supposed to be deleted together with the desired insert semantics InsertSem. compDelete computes a set of ABox assertions which should be deleted in order to debug the knowledge base. This approach exploits the fact that debugging a knowledge base can be accomplished by deleting false from the knowledge base. Line 8 returns the knowledge base resulting from removing the computed set Debug, resulting in the knowledge base K = (R, T , ((A \ Deletion) ∪ A i ) \ Debug).

Deletion

For a knowledge base K = (R, T , A) and A d a set of ABox assertions which are supposed to be deleted, we now describe how to determine a minimal subset of A whose deletion prevents the assertions in A d from being entailed by K. Definition 6 (Deletion) Let K = (R, T , A) be a knowledge base and

A d a set of ABox assertions. A deletion D of A d in K is a minimal subset of the ABox A such that no element in A d is entailed by (R, T , A \ D).

As demonstrated by the example provided in Sec. 2, it is not sufficient to only remove all elements contained in A d from the ABox since even after their removal they might still be entailed by the knowledge base. Furthermore, there might be more than one possible way to accomplish the deletion of A d . The latter aspects will be addressed in Sec. 6. To determine a deletion of A d in a knowledge base K, we suggest to use justifications.

Justification based Deletion

Justifications can be used to compute a deletion for an assertion α from a knowledge base K = (R, T , A). Please note that according to Def. 1, we restrict jus-tifications to be subsets of the ABox. Since the set of all justifications for α in K = (R, T , A) corresponds to the set of all minimal subsets of A which together with R and T imply α, it is sufficient to delete exactly one element from each justification in order to prevent α from being entailed. This corresponds to the construction of a minimal hitting set of the set of all justifications for α in K.

Definition 7 (Hitting Set) Let S = {S 1 , . . . S n } be a set of sets. A hitting set for S is a set

H ⊆ ∪ n i=1 S i with H ∩ S i = ∅, ∀1 ≤ i ≤ n.

If further no proper subset of H is a hitting set for S, H is called a minimal hitting set. The set of all minimal hitting sets for S is denoted by HS (S).

Each minimal hitting set in HS (Just(α, K)) constitutes a deletion of {α} in K.

Example 1

The set of all justifications for StudentTrainee(john) in the knowledge base K given in Sec. 2 is: Just(StudentTrainee(john), K) = {{StudentTrainee(john)}, {Student(john), Employee(john)},

{Student(john), SoftwareEngineer (john)}}

The two minimal hitting sets for Just(StudentTrainee(john), K), which both provide a deletion for StudentTrainee(john) in K, are:

H 1 ={StudentTrainee(john), Employee(john), SoftwareEngineer (john)} H 2 ={StudentTrainee(john), Student(john)}

Potentially every subset of the ABox can be a justification for α, resulting in justifications with arbitrary cardinalities. Hence, there can be more than one hitting set for the set of all justifications of α and different ways to perform a deletion. When dealing with SPARQL update queries, it is reasonable to assume that more than one ABox assertion is supposed to be deleted. The first idea to compute all possible deletions for a set of assertions A d would be to compute all justifications for all assertions in A d separately and then compute all minimal hitting sets for these justifications. However this approach considers an unnecessarily high number of justifications because the union of all justifications might contain non-minimal sets. Only the justifications {StudentTrainee(john)} and {Student(john)} have to be considered for the construction of the hitting set, since the other justifications are supersets of {Student(john)}. This leads to the notion of root justifications.

Definition 8 (Root Justification [17]) Let K = (R, T , A) be a knowledge base, U = {α 1 , . . . , α n } a set of ABox assertions and Just(α i , K) the set of all justifications of

α i in K. A set J ∈ ∪ n i=1 Just(α i , K) is a root justification for U in K iff there is no J ∈ ∪ n i=1 Just(α i , K) with J ⊂ J.

All justifications in ∪ n i=1 Just(α i , K) which are not a root justification are called derived justification. As shown in [17], for a set of assertions A d which are supposed to be deleted from a knowledge base K it is sufficient to consider only root justifications in order to determine what to delete.

Next we present Algorithm 2 which uses the notion of root justifications to compute a deletion for a set of ABox assertions from a knowledge base. We use a black box for the computation of root justifications. One way to compute all root justifications for a given set of assertions A d is to use an off the shelf reasoner like Pellet [24] to compute first all justifications for the different elements of A d and then to remove all derived justifications. Another way is to use the algorithm introduced in [17] which directly computes the root justifications. For a knowledge Algorithm 2 (compDeletion) Given K = (R, T , A) and a set of ABox assertions A d which should be deleted, construct a minimal set A with A ⊆ A and (R, T , A \ A ) |= A for all A ∈ A d . Input: K = (R, T , A), a set of ABox assertions A d which should be deleted and the desired semantics. Output: A deletion for A d in K.

1: RJust = set of all root justifications for A d in K 2: HS = set of all minimal hitting sets for RJust 3: Deletion = chooseDeletion(K, u(P d , P i , P w ), HS , Semantics) 4: return Deletion base K and a set of ABox assertions A d which are supposed to be deleted, line 1 computes all root justifications for A d in K. Next, line 2 constructs all minimal hitting sets for the set of root justifications. Line 3 uses these minimal hitting sets together with a specified semantic to choose a subset of the ABox which should be deleted. The next Section presents possible choices for these semantics.

Semantics

In the previous section, we learnt that there can be more than one possible way to delete a set of assertions from a knowledge base. Furthermore, there might be more than one possible way to debug a knowledge base resulting from an insertion. To handle this problem, different semantics are suggested to choose among the possibilities.

Semantics for Deletion

Maxichoice Semantics [8]: In maxichoice semantics, the deletion with minimal cardinality is chosen. This corresponds to maximizing the number of ABox assertions which are preserved. Thus the resulting ABox implements the deletion while possessing maximal cardinality.

In cases, where there is more than one deletion with minimal cardinality, the maxichoice semantics does not specify which of these deletions to choose. We refrain from choosing an arbitrary one just for the sake of determinism. One way to solve this issue would be to offer the different possibilities to the user and let the user choose. Another possibility would be to use additional information associated with the ABox assertions like suggested in the priority/credibility based semantics introduced at the end of this section.

Meet Semantics [8]: This semantics is rather pessimistic since it removes all assertions occurring in a deletion. Thus the resulting ABox implements the deletion while possessing minimal cardinality.

Priority/Credibility based Semantics [8]: In some cases, additional information associated to the assertions in the ABox is available. Examples for this kind of information are credibility or time stamps and are summarized by the term provenance information. This provenance information can be used to decide which assertions to delete by for example preferably deleting those assertions associated with a low credibility or an old time stamp [20].

Semantics for Insertion

Insertion of a set of ABox assertions A i can be accomplished by adding it to the knowledge base and then checking if the resulting knowledge base is satisfiable. If it is satisfiable, the resulting knowledge base corresponds to the result of the update operation. If it is unsatisfiable, the methods for deletion can be used to remove the inconsistencies from the knowledge base by deleting {⊥} from the knowledge base. As soon as a debugging step is used during an insertion, there might be several possibilities to perform the insertion. Different semantics can be used to pick one of these possibilities. Please note that it is possible that some (or even all) possibilities to debug the knowledge base remove the inserted assertions.

In addition to the semantics introduced in the previous section, semantics for insertion can take into account the fact that one can distinguish between old information, which was present in the ABox before the insertion and new information which was introduced by the insertion. The semantics presented below build on this distinction and were first introduced in [2] for DL − Lite RDF S¬ .

Brave Semantics: This semantics gives priority to new assertions which are inserted by the query meaning that the possibility to debug is selected which contains the highest number of assertions in A i .

Note that there are cases, where there is is more than one possible way for debugging which contains the highest number of assertions in A i . Similar to the maxichoice semantics we are facing non-determinism here and refrain from choosing an arbitrary possibility to debug just for the sake of determinism. One way to solve this issue would be to leave the decision to the user by offering the different debugging possibilities to the user. Another possibility would be to use provenance information associated with the ABox assertions.

Cautious Semantics: In contrast to brave semantics, the cautious semantics gives priority to assertions which were already present before the insertion. This means that the possibility to debug is selected, which preserves as many of the already present assertions as possible. In the worst case, the debugging step removes the inserted assertion, making the insertion a semi-revision operator as corresponding to the one introduced in [11].

Fainthearted Semantics: This semantics is rather overcautious since it totally discards an insertion as soon as there is a conflict between the inserted assertions and the already present assertions.

Update Semantics taking into account the Interplay of Deletion and Insertion

Next, we introduce another semantics, which aims at optimizing the overall result of an update. When considering the deletion and the insertion part of an update separately, it is possible that the insertion cancels the deletion. More precisely, it is possible that inserting assertions causes other assertions to be entailed which were deleted by the very same update. Ex. 4 illustrates that, in order to optimize the overall result of an update operation, it might be worthwhile not to consider the deletion and the insertion separately but to take their interplay into account. Before presenting semantics implementing this idea, we introduce the notion of an implementation of an update operation to a knowledge base, which corresponds to one possibility to perform an update operation to this knowledge base. Definition 9 (Implementation of an Update Operation) Let K = (R, T , A) be a knowledge base, u(P d , P i , P w ) an update operation, A d the set of ABox assertions for the result of asking CONSTRUCT P d WHERE P w , A i set of ABox assertions for the result of asking CONSTRUCT P i WHERE P w to K. Then (Del , Dbg) is called an implementation of update operation u(P d , P i , P w ) w.r.t. K, if Del is a deletion for A d in K and Dbg is a deletion for {⊥} in (R, T , (A\Del )∪A i ). The knowlege base resulting from (Del , Dbg) is defined as K (Del,Dbg)

u(P d ,Pi,Pw) = (R, T , ((A\Del )∪A i )\Dbg).

We omit the knowledge base if it is clear from the context and simply say that (Del , Dbg) is an implementation of update operation u(P d , P i , P w ). Next we present query-driven semantics which, can be used to choose one of the possible implementations of an update operation u(P d , P i , P w ).

Query-driven Semantics: Given knowledge base K = (R, T , A), an update operation u(P d , P i , P w ), A d , A i defined as in Def. 9 and an implementation (Del , Dbg) of u(P d , P i , P w ). All assertions in A d which are not entailed by K (Del,Dbg) u(P d ,Pi,Pw) can be seen as successful deletions (w.r.t. this implementation (Del , Dbg)). Similarly, all assertions in A i which are entailed by K (Del,Dbg) u(P d ,Pi,Pw) can be seen as successful insertions (w.r.t. this implementation (Del , Dbg)). The aim of query-driven semantics is to maximize the number of successful deletions and insertions.

Definition 10 (Query-driven Update Semantics) Let K = (R, T , A) be a knowledge base, u(P d , P i , P w ) an update operation, A d the set of ABox assertions for the result of asking CONSTRUCT P d WHERE P w and A i the set of ABox assertions for the result of asking CONSTRUCT P i WHERE P w to K. The query-driven update of K w.r.t. u(P d , P i , P w ) is K Sem qd u(P d ,Pi,Pw) = (R, T , ((A \ Del ) ∪ A i ) \ Dbg) where (Del , Dbg) is the implementation of u(P d , P i , P w ) maximizing

|{α ∈ A d | K (Del,Dbg) u(P d ,Pi,Pw) |= α}| + |{β ∈ A i | K (Del,Dbg) u(P d ,Pi,Pw) |= β}|(9)

If the SPARQL update query does not contain a DELETE clause, Del is empty and the query-driven update semantics behaves like the brave semantics. If the SPARQL update query does not contain an INSERT clause, Equation 9does not choose a deletion. For these cases, query-driven semantics should be combined with one of the semantics for deletion presented in Sec. 6.1.

Note that there are other cases where query-driven semantics still leaves some choices: there could be more than one combination of deletion and debugging maximizing Eq. ( 9). This non-determinism could be avoided by presenting the set of successful deletions and insertions for these combinations to the user and let the user decide which of the possibilities is closest to the desired result. Another possibility would be to enhance the query mechanism such that the user is able to give priorities to certain parts of the query. Considering for example the query presented in Sec. 2 the user could specify that the deletion of the StudentTrainee status is more important than the assignment of those students to course c1.

K 1 = (T , (A \ Del 1 ) ∪ A i ) K 2 = (T , (A \ Del 2 ) ∪ A i )

Secretary(john) constitutes a successful insertion in both K 1 and K 2 . Since K 1 |= StudentTrainee(john) and K 2 |= StudentTrainee(john), StudentTrainee(john) is a successful deletion in K 2 but not in K 1 . Query-driven semantics results in K 2 since it maximizes the number of successful insertions and deletions.

Query-driven semantics aims at the optimization of the overall result of the query. In extreme cases, where the sizes of A d and A i differ dramatically, it could happen that the smaller set is neglected. For example if |A d | = 5 and |A i | = 1000, Eq. ( 9) is dominated by the set of successful insertions. This could be remedied by introducing a weight indicating the importance of the desired deletion or insertion.

Conclusion and Future Work

In this paper, we presented an approach to compute SPARQL ABox update in the presence of OWL-DL TBoxes. We address the fact that there might be more than one way to perform a deletion with different semantics according to which one of the possibilities is chosen. To master the interplay of the deletion and the insertion task of a SPARQL update query, we introduce query-driven semantics which aim at maximizing the overall effect of an update operation.

An implementation of our approach is on the way. We are using SPARQL-DL to evaluate the CONSTRUCT query and Pellet to compute all possible justifications.

Besides evaluating the approach, future work addresses the use of summarization techniques to efficiently compute justifications. Since the set of ABox assertions which are supposed to be deleted are created by a basic graph pattern, this set is likely to contain many similar assertions. We want to exploit these similarities by first aggregating similar individuals into one individual and then computing the justification for a bunch of assertions in one single step. Possible summarization techniques we are looking into are [7] and [10].