SPARQL Update for Materialized Triple Stores under DL-Lite RDFS Entailment Albin Ahmeti (TU Wien) Diego Calvanese (Uni Bolzano) Axel Polleres (WU Wien) 1

Motivation Recent standardization of SPARQL 1.1 Update, and SPARQL 1.1 Entailment Regimes with triple stores implementing those standards (often done with materialization) Query rewriting techniques already explored in the context of DL-Lite and OBDA… do they help us with updates as well? Emerging the need for a more systematic approach of dealing with SPARQL 1.1 Update over ABoxes & TBox-es Nothing endures but change. - Heraclitus 2

3 DELETE { ?X a :Child. } INSERT { ?Y a :Mother. } WHERE { ?X :hasParent ?Y. } What should a triple store do in such a situation? What does it mean to... DELETE an implicit triple? INSERT an already implied triple? WHERE matching variables on implicit triples?

State of the art What do off-the-shelf triple stores do? – Entailment typically only handled at (bulk) loading by materialization but not in the context of Updates. – no “standard” behavior for Delete &Insert upon materialized stores. – interplay of Entailments and Update left out in the SPARQL 1.1 spec. Approaches in the literature on updates and RDFS (or also DLs) limited to atomic update operations… – [Gutierrez et al., ESWC2011] ABox deletions in the context of RDFS – [Calvanese et al., ISWC2010] ABox & TBox insertions in the context of DL-Lite (incl. inconsistency repair) …but no combined treatment of DELETE + INSERT + BGP matching in the WHERE clause as in SPARQL1.1 Update Also related to our approach – Deductive DBs: [Gupta et al., SIGMOD93], Maintaining Views Incrementally – KB evolution, Belief revision, etc.: Various works in classical AI and philosophy 4

[Munoz et al., ESWC2007] Minimal RDFS (ABox-) Inference Rules (Abox-)Materialized stores: 5 materialize(G)... SPO :Motherrdfs:subClassOf:Parent :hasMotherrdfs:subPropertyOf:hasParent :hasMotherrdfs:range:Mother :hasParentrdfs:domain:Child :hasParentrdfs:range:Parent...

SPARQL Query answering under RDFS Entailment: 6 materialize(G)... SELECT ?Y WHERE { :joe :hasParent ?Y. } SPO :Motherrdfs:subClassOf:Parent :hasMotherrdfs:subPropertyOf:hasParent :hasMotherrdfs:range:Mother :hasParentrdfs:domain:Child :hasParentrdfs:range:Parent... SELECT ?Y WHERE { { :joe :hasParent ?Y. } UNION {:joe :hasMother ?Y. } UNION {:joe :hasFather ?Y. } rewrite(q,T) ans(rewrite(q, T), G \ T) = ans(q, materialize(G) \ T) Well known:

What does that now mean for updates? Our Contribution: Discuss possible update semantics in the context of materialized stores & RDFS. Even in this restricted setting (RDFS) this turns out to be challenging: Our setting: – In case of ABox updates, TBox fixed – Use "minimal"RDFS as TBox language (without axiomatic triples, blank nodes) … i.e., DL-Lite RDFS – Restrict on BGPs to only allow ABox Insert/Deletes INSERT {:joe :hasFather ?Y } WHERE {:joe :hasParent ?Y } INSERT {:joe :hasFather ?Y } WHERE {:joe :hasParent ?Y } INSERT {:joe ?Y :foo} WHERE {:joe rdf:type ?Y } INSERT {:joe ?Y :foo} WHERE {:joe rdf:type ?Y } 7

Proposed ABox update semantics Materialized-preserving semantics – Sem 0 … baseline semantics – Sem 1a – Sem 1b – Sem 2 … delete incl. causes and rewrite upon inserts – Sem 3 … intuition: combination of Sem 1 and Sem 2 8 inspired by DRed: delete incl. effects and rederive upon inserts }

Baseline semantics Sem 0 – Naïve Update followed by re-materialization 9

Sem 0 : Naïve Update followed by re-materialization SPO :Motherrdfs:subClassOf:Parent :hasMotherrdfs:subPropertyOf:hasParent :hasMotherrdfs:range:Mother :hasParentrdfs:domain:Child :hasParentrdfs:range:Parent... SPO :joe:hasMother:jane :joea:Child :joe:hasParent:jane a:Mother :janea:Parent DELETE { ?X a :Child. } INSERT { ?Y a :Mother. } WHERE { ?X :hasParent ?Y. } ?X=:joe ?Y=:jane DELETE { :joe a :Child. } INSERT { :jane a :Mother. } DELETE { :joe a :Child. } INSERT { :jane a :Mother. } SPO :joe:hasMother:jane :joe:hasParent:jane a:Mother :janea:Parent materialize(G) SPO :joe:hasMother:jane :joea:Child :joe:hasParent:jane a:Mother :janea:Parent No effect!

Alternative Materialized-pres. semantics Sem 1a – “Delete and rederive” Remove DELETEs triples incl. Effects 2. INSERT triples 3. Re-materialize

Sem 1a : Delete and rederive SPO :Motherrdfs:subClassOf:Parent :hasMotherrdfs:subPropertyOf:hasParent :hasMotherrdfs:range:Mother :hasParentrdfs:domain:Child :hasParentrdfs:range:Parent... SPO :joe:hasMother:jane :joea:Child :joe:hasParent:jane a:Mother :janea:Parent DELETE { :joe :hasMother :jane. } DELETE { :joe :hasMother :jane. :joe :hasParent :jane. :joe a Child. :jane a Mother. :jane a Parent. } DELETE { :joe :hasMother :jane. :joe :hasParent :jane. :joe a Child. :jane a Mother. :jane a Parent. } SPO materialize(G) SPO May be viewed quite "radical"

Sem 1a : Delete and rederive SPO :Motherrdfs:subClassOf:Parent :hasMotherrdfs:subPropertyOf:hasParent :hasMotherrdfs:range:Mother :hasParentrdfs:domain:Child :hasParentrdfs:range:Parent... SPO :joe:hasMother:jane :joea:Child :joe:hasParent:jane a:Mother :janea:Parent DELETE { :joe :hasParent :jane. } DELETE { :joe :hasParent :jane. :joe a Child. :jane a Parent. } DELETE { :joe :hasParent :jane. :joe a Child. :jane a Parent. } SPO :joe:hasMother:jane a:Mother materialize(G) SPO :joe:hasMother:jane :joea:Child :joe:hasParent:jane a:Mother :janea:Parent Again: no effect!

Alternative Materialized-pres. semantics Sem 1b – Variant of Sem 1a, that makes a distinction between explicit and implicit triples – Re-materialization from scratch from 14

Sem 1b : Delete and rederive with separating "explicit" and "implicit" ABox SPO :Motherrdfs:subClassOf:Parent :hasMotherrdfs:subPropertyOf:hasParent :hasMotherrdfs:range:Mother :hasParentrdfs:domain:Child :hasParentrdfs:range:Parent... SPO :joe:hasMother:jane :joea:Child :joe:hasParent:jane a:Mother :janea:Parent DELETE { :joe :hasParent :jane. } materialize(G) SPO :joe:hasMother:jane :joea:Child :joe:hasParent:jane a:Mother :janea:Parent Again: no effect! ABox expl ABox impl SPO :joe:hasMother:jane :joe:hasParent:jane SPO :joe:hasMother:jane Abox' impl

Alternative Materialized-pres. semantics Sem 2 – Delete the instantiations of plus all their causes; – Insert the instantiations of plus all their effects. 16

17 Sem 2

18 Sem 2

19 Sem 2 DELETE following INSERT is NOT idempotent!

Another alternative Materialized-pres. semantics Sem 3 – Idea: Combine Sem 1 and Sem 2, i.e. – Additionally (recursively) delete “dangling” effects for instantiations of i.e. triples that would not be implied any longer by any non-deleted triples after deletion No formalization given yet, but let’s check the intuition… 20

21 Sem 3

22 Recall: the intuition was to additionally delete triples that would not be implied any longer by any non-deleted triples after deletion.

TBox updates In this setting – We expand BGPs to take into account TBox Inserts/Deletes – general BGPs – Tbox inserts are trivial in this setting of RDFS. – TBox deletions for RDFS are ambiguous (minimal cuts) [Gutierrez et al., ESWC2011] Opens various degrees of freedom… What if we consider a materialized Tbox? – We also use two RDFS rules for TBox materialization. DELETE {:A rdfs:subClassOf ?C. } 23

Minimal cuts are ambiguous! 24

Proposed TBox update semantics For materialized Tboxes, we define a canonical way to delete explicit and implicit TBox triples – Outbound cut For each triple, where we replace with: add to 25

Proposed TBox update semantics Outbound cut: Intuition 26 DELETE { :A rdfs:subClassOf :F. } DELETE { :A rdfs:subClassOf ?X. } WHERE { :A rdfs:subClassOf ?X. ?X rdfs:subClassOf* :F. } Idea: Can be implemented with SPARQL 1.1 property paths

27 Sem outcut

28 Sem outcut

Proposed TBox update semantics Canonical way to delete explicit and implicit TBox triples – Inbound cut For each triple, where we replace with: add to 29

Analogous alternative: Sem incut Inbound cut: Intuition 30 DELETE { ?X rdfs:subClassOf :F. } WHERE { :A rdfs:subClassOf* ?X. ?X rdfs:subClassOf :F. }

31 SPARQL 1.1 property path

32

Prototype & Evaluation A prototype is available in Java using Jena API implementing the proposed update semantics – e-rewriter/index.html e-rewriter/index.html 33

Conclusions This preliminary research is the first step to close the gap left by the current standards (SPARQL1.1 Update vs. SPARQL1.1 Entailment Regimes) We looked into various materialized preserving semantics – Seemingly no “one-size fits all” semantics – Non-intuitive corner cases in each semantics  depends on use case? SPARQL 1.1 Update, i.e. pairing DELETE and INSERT templates with a common WHERE clause (BGP matching) imposes a non-trivial challenge! 34

Future work Extend with OWL QL/RL features for expressing TBox – Benefit from a more expressive query language – Exploit different Query rewriting algorithms? Optimisations – Imposes new challenges such as dealing with inconsistencies – Discuss complexity Implementation and evaluation of proposed update semantics against different triple stores 35