SPARQL Update for Materialized Triple Stores under DL- Lite RDFS Entailment

1

SPARQL Update for Materialized Triple Stores under DL-LiteRDFS Entailment

Albin Ahmeti (TU Wien)Diego Calvanese (Uni Bolzano)

Axel Polleres (WU Wien)

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

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?

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

5

[Munoz et al., ESWC2007] Minimal RDFS (ABox-) Inference Rules

(Abox-)Materialized stores:

materialize(G)

...

S P O

:Mother rdfs:subClassOf :Parent

:hasMother rdfs:subPropertyOf :hasParent

:hasMother rdfs:range :Mother

:hasParent rdfs:domain :Child

:hasParent rdfs:range :Parent

...

6

SPARQL Query answering under RDFS Entailment:

materialize(G)

...

SELECT ?Y WHERE { :joe :hasParent ?Y . }

S P O






...

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:

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

– Restrict on BGPs to only allow ABox Insert/DeletesINSERT {:joe :hasFather ?Y } WHERE{:joe :hasParent ?Y }

INSERT {:joe ?Y :foo} WHERE{:joe rdf:type ?Y }

8

Proposed ABox update semantics

• Materialized-preserving semantics– Sem0 … baseline semantics

– Sem1a

– Sem1b

– Sem2 … delete incl. causes and rewrite upon inserts

– Sem3 … intuition: combination of Sem1 and Sem2

inspired by DRed: delete incl. effects and rederive upon inserts }

9

Baseline semantics

• Sem0

– Naïve Update followed by re-materialization

10

Sem0: Naïve Update followed by re-materialization

...

S P O






...

S P O

:joe :hasMother :jane

:joe a :Child

:joe :hasParent :jane

:jane a :Mother

:jane a :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 . }

S P O



:jane a :Mother

:jane a :Parent

materialize(G)

S P O


:joe a :Child


:jane a :Mother

:jane a :Parent

No effect!

11

Alternative Materialized-pres. semantics

• Sem1a

– “Delete and rederive”

1. Remove DELETEs triples incl. Effects2. INSERT triples3. Re-materialize

12

Sem1a: Delete and rederive

...

S P O






...

S P O


:joe a :Child


:jane a :Mother

:jane a :Parent

DELETE { :joe :hasMother :jane. }

DELETE { :joe :hasMother :jane . :joe :hasParent :jane .

:joe a Child .:jane a Mother.:jane a Parent. }

S P O

materialize(G)

S P OMay be viewed quite

"radical"

13

Sem1a: Delete and rederive

...

S P O






...

S P O


:joe a :Child


:jane a :Mother

:jane a :Parent

DELETE { :joe :hasParent :jane. }

DELETE { :joe :hasParent :jane .:joe a Child .

:jane a Parent. }

S P O


:jane a :Mothermaterialize(G)

S P O


:joe a :Child


:jane a :Mother

:jane a :Parent

Again: no

effect!

14


• Sem1b

– Variant of Sem1a, that makes a distinction between explicit and implicit triples

– Re-materialization from scratch from

15

Sem1b: Delete and rederive with separating "explicit" and "implicit" ABox

...

S P O






...

S P O


:joe a :Child


:jane a :Mother

:jane a :Parent

DELETE { :joe :hasParent :jane. }

materialize(G)

S P O


:joe a :Child


:jane a :Mother

:jane a :Parent

Again: no

effect!

ABoxexpl

ABoximpl

S P O



S P O


Abox'impl

16


• Sem2 – Delete the instantiations of 𝑃𝑑 plus all their causes;

– Insert the instantiations of 𝑃𝑖 plus all their effects.

17

Sem2

18

Sem2

19

Sem2

DELETE following INSERT is

NOT idempotent!

20

Another alternative Materialized-pres. semantics

• Sem3

– Idea: Combine Sem1 and Sem2 , 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…

21

Sem3

22

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

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

24

Minimal cuts are

ambiguous!

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

26

Proposed TBox update semantics

• Outbound cut: Intuition 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

Semoutcut

28

Semoutcut

30

Analogous alternative: Semincut

• Inbound cut: Intuition DELETE { ?X rdfs:subClassOf :F. }WHERE { :A rdfs:subClassOf* ?X .

?X rdfs:subClassOf :F. }

33

Prototype & Evaluation

• A prototype is available in Java using Jena API implementing the proposed update semantics– http://dbai.tuwien.ac.at/user/ahmeti/

sparqlupdate-rewriter/index.html

http://dbai.tuwien.ac.at/user/ahmeti/sparqlupdate-rewriter/index.html








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!

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

Documents

SPARQL Update for Materialized Triple Stores under DL- Lite RDFS Entailment