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