Slide 1

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

Slide 2

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

Slide 3

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?

Slide 4

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

Slide 5

[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...

Slide 6

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:

Slide 7

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

Slide 8

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 }

Slide 9

Baseline semantics Sem 0 Nave Update followed by re-materialization 9

Slide 10

Sem 0 : Nave Update followed by re-materialization 10... 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!

Slide 11

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

Slide 12

Sem 1a : Delete and rederive 12... 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"

Slide 13

Sem 1a : Delete and rederive 13... 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!

Slide 14

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

Slide 15

Sem 1b : Delete and rederive with separating "explicit" and "implicit" ABox 15... 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

Slide 16

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

Slide 17

17 Sem 2

Slide 18

18 Sem 2

Slide 19

19 Sem 2 DELETE following INSERT is NOT idempotent!

Slide 20

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 lets check the intuition 20

Slide 21

21 Sem 3

Slide 22

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

Slide 23

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

Slide 24

Minimal cuts are ambiguous! 24

Slide 25

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

Slide 26

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

Slide 27

27 Sem outcut

Slide 28

28 Sem outcut

Slide 29

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

Slide 30

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

Slide 31

31 SPARQL 1.1 property path

Slide 32

32

Slide 33

Prototype & Evaluation A prototype is available in Java using Jena API implementing the proposed update semantics http://dbai.tuwien.ac.at/user/ahmeti/sparqlupdat e-rewriter/index.html http://dbai.tuwien.ac.at/user/ahmeti/sparqlupdat e-rewriter/index.html 33

Slide 34

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

Slide 35

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