An Effective SPARQL Support over Relational Database Jing Lu, Feng Cao, Li Ma, Yong Yu, Yue Pan SWDB-ODBIS 2007 SNU IDB Lab. Hyewon Lim July 30 th, 2009

Contents  Introduction  Problem Statement  SPARQL to SQL Translation  Optimization  An Example of Translation  Experimental Analysis  Conclusion 2

Introduction (1)  SPARQL query consists of  Pattern – matched against given data source D  Values – obtained from the matching  SPARQL filter expression  Restricts the graph pattern matching solutions  Functionalities  Ability to restrict the value of literal and arithmetic expression  Ability to preprocess the RDF data by built-in functions 3

Introduction (2)  Previous methods on supporting SPARQL over relational databases  mainly supported basic SPARQL query patterns  Filter expressions  Ignored due to complexity, or  Adopted memory-based method for evaluation  Ex. Sesame or Jena2  Translated into a SQL without filter expressions  Then, the results are further filtered in Java program 4

Introduction (3)  Filter expression translation is difficult  Filter expressions often consist of multiple functions and operators  Operator may have different operands  When operands are variables or complex expressions  Hard to determine their actual type  Variables may be bound to different kinds of literals  The type of RDF resources needs to be dynamically determined in the translation 5

Introduction – SPARQL Pattern Tree  The graph pattern part can be expressed as a SPARQL pattern tree  Used in the translation  Four possible types of nodes 6

Problem Statement (1)  A SPARQL filter can not be translated into a SQL expression straightforwardly  Result of filter expression is an RDF object  literal, IRI reference, or an error  Result of a SQL expression is a primitive value  Usually only a primitive part of an RDF object is used in a function or operator  Define “facets” of RDF objects 7

Problem Statement (2)  Facet of an RDF object 8 FacetexplanationPrimitive datatype Available for IRI FacetFull IRI string of an IRI reference stringExcept literals Lexical FacetLexical form of a literalstringLiterals Language FacetLanguage tag of a literalstringLiterals Datatype FacetFull IRI of the datatype of a typed literal stringLiterals Numeric FacetNumeric value of a numeric literal doubleTyped literals with xsd:float, xsd:double, xsd:decimal Boolean FacetBoolean value of a boolean literal Translated into SQL predicates Typed literals with xsd:boolean Date time FacetDate time value of a date time literal 64-bit integer Typed literal with xsd:dateTime ID facetInternal ID of the RDF objectintegerVariables

SPARQL to SQL Translation  Facet-based approach (FSparql2Sql)  Translation of pattern nodes  Translation of filter expressions 9

SPARQL to SQL Translation - Translation of pattern nodes (1)  TRIPLE node  Translated into a simple SELECT query  If there are constants, WHERE clause is added  Otherwise, columns are renamed to the corresponding variable names  One variable appears multiple times, equivalent constraint should be added to the WHERE clause 10

SPARQL to SQL Translation - Translation of pattern nodes (2)  AND node  Translated into a query on consequent joins of the sub-queries from its child pattern nodes  If a child node is optional, a left join is used  If there are child FILTER nodes,  Translated into SQL expressions  Added to the WHERE clause  OR node  Translated into a UNION of the sub-queries 11

SPARQL to SQL Translation - Translation of Filter Expressions (1)  A Filter expression can be parsed into a filter expression tree 12

SPARQL to SQL Translation - Translation of Filter Expressions (2)  Literal Constants and IRI Constants  Translation is rather straightforward  Translation results for all kinds of supported facets are just SQL constants  Variables  If the SQL for a specific facet of a variable is requested, the corresponding table is added to the SQL query  Comparison Operators (, =, <=, …)  Most complex because of non-equality operators  Can not be used between all kinds of RDF terms  Different comparison methods should be used for different types of operands 13

SPARQL to SQL Translation - Translation of Filter Expressions (3)  CASE Expression  Types of operands need to be bound dynamically  Use SQL CASE expression (CASE…WHEN) in the translation 14

SPARQL to SQL Translation - Translation of Filter Expressions (4)  Built-in Functions  Always return an IRI or a literal with a fixed type as the result  bound, isIRI, regex: boolean typed literal  Lang, str: plain literal with no language tag  Datatype: IRI reference  Calculation Operators (+, -, *, /)  Used between numeric literals  Always gives a numeric literal  When the lexical facet is required  Use a SQL function to convert the numeric result into a string 15

SPARQL to SQL Translation - Translation of Filter Expressions (5)  Logical Operators (&&, ||, !)  Used between boolean literals  Always returns a boolean literal  Language, datatype facet: give constant  If the lexical facet is required  Use an additional CASE expression to change the result into a string 16

Optimization  Facet-based translation may generate very complex result SQL statement  Requirements  One side is a constant while other side is a CASE expression with exactly two WHEN clauses  Two WHEN clauses are exactly the negation of each other  One of the results matches the constant on the other side of the “=“ while the other does not 17 translation optimization

An Example of Translation (1)  Translation for filter expressions 18  Goal  Generate SQLs for the Boolean facet of the root node E1

An Example of Translation (2)  Optimization for the generated SQL 19 remove

Experimental Analysis (1)  University Ontology Benchmark (UOBM)  Effectiveness analysis 20 Q0: w/o filter Q1: w/ filter Q2: w/ nested filter More complex query Q3: w/o filter Q4: w/ filter Q5: w/ nested filter

Experimental Analysis (2)  Scalability test 21

Conclusion  Contributions  Propose an effective method to translate a complete SPARQL query into a single SQL  Idea of facet-based scheme to translate filter expressions into SQL statements  Propose optimization strategy  Future work  Support more SPARQL features, such as XQuery functions 22