1 / 32

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

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

ilana
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 . } Whatshould a triplestore do in such a situation? • Whatdoesitmeanto... • DELETE an implicittriple? • INSERT an alreadyimpliedtriple? • WHERE matching variables on implicittriples?

  4. State of the art • What do off-the-shelf triple stores do? • Entailmenttypically 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. (Abox-)Materializedstores: [Munoz et al., ESWC2007] Minimal RDFS (ABox-) Inference Rules ... materialize(G)

  6. SPARQL Query answeringunder RDFS Entailment: SELECT ?Y WHERE { { :joe:hasParent?Y . } UNION {:joe :hasMother ?Y . } UNION {:joe :hasFather?Y . } SELECT ?Y WHERE { :joe:hasParent?Y . } rewrite(q,T) ... ans(rewrite(q, T), G \ T) = ans(q, materialize(G) \ T) Wellknown: materialize(G)

  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/Deletes INSERT {:joe :hasFather ?Y } WHERE {:joe :hasParent ?Y } INSERT {:joe ?Y :foo} WHERE {:joerdf: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 DELETE { ?X a :Child . } INSERT { ?Y a :Mother . } WHERE { ?X :hasParent?Y . } ... DELETE { :joea :Child . } INSERT { :janea :Mother . } ?X=:joe ?Y=:jane No effect! materialize(G)

  11. Alternative Materialized-pres. semantics • Sem1a • “Delete and rederive” 1. Remove DELETEs triplesincl. Effects 2. INSERT triples 3. Re-materialize

  12. Sem1a: Delete and rederive DELETE { :joe :hasMother :jane. } DELETE { :joe :hasMother :jane . :joe :hasParent :jane . :joe a Child . :janea Mother. :jane a Parent.} ... May be viewed quite "radical" materialize(G)

  13. Sem1a: Delete and rederive DELETE { :joe :hasParent :jane. } DELETE { :joe :hasParent :jane . :joe a Child . :jane a Parent.} ... Again: no effect! materialize(G)

  14. Alternative Materialized-pres. semantics • 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 DELETE { :joe :hasParent :jane. } ... ABoxexpl Abox'impl ABoximpl Again: no effect! materialize(G)

  16. Alternative Materialized-pres. semantics • 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 Sem1and 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 • Tboxinserts are trivial in this setting of RDFS. • TBoxdeletions 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 implicitTBox triples • Outbound cut • For each triple , where • we replace with: • add to

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

  27. Semoutcut

  28. Semoutcut

  29. Analogous alternative: Semincut DELETE { ?Xrdfs:subClassOf :F. } WHERE { :A rdfs:subClassOf* ?X . ?X rdfs:subClassOf :F. } • Inbound cut: Intuition

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

  31. 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!

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

More Related