An Effective SPARQL Support over Relational Database

Jing Lu, Feng Cao, Li Ma, Yong Yu, Yue PanSWDB-ODBIS 2007

SNU IDB Lab.Hyewon Lim

July 30th, 2009

2

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

3

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

4

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

5

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

6

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

7

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 ob-ject is used in a function or operator Define “facets” of RDF objects

8

Problem Statement (2) Facet of an RDF object

Facet explanation Primi-tive

datatype

Available for

IRI Facet Full IRI string of an IRI reference

string Except literals

Lexical Facet Lexical form of a literal string LiteralsLanguage Facet

Language tag of a literal string Literals

Datatype Facet

Full IRI of the datatype of a typed literal

string Literals

Numeric Facet Numeric value of a nu-meric literal

double Typed literals with xsd:float, xsd:double, xsd:decimal

Boolean Facet Boolean value of a bool-ean literal

Trans-lated into SQL pred-

icates

Typed literals with xsd:boolean

Date time Facet

Date time value of a date time literal

64-bit in-teger

Typed literal with xsd:dateTime

ID facet Internal ID of the RDF ob-ject

integer Variables

9

SPARQL to SQL Translation Facet-based approach (FSparql2Sql)

Translation of pattern nodes Translation of filter expressions

10

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

sponding variable names One variable appears multiple times, equiva-

lent constraint should be added to the WHERE clause

11

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

12

SPARQL to SQL Translation- Translation of Filter Expressions (1)

A Filter expression can be parsed into a fil-ter expression tree

13

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

tors Can not be used between all kinds of RDF terms

Different comparison methods should be used for different types of operands

14

SPARQL to SQL Translation- Translation of Filter Expressions (3)

CASE Expression Types of operands need to be bound dynami-

cally Use SQL CASE expression (CASE…WHEN) in the trans-

lation

15

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

16

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 re-sult into a string

17

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

translation

optimization

18

An Example of Translation (1) Translation for filter expressions

Goal Generate SQLs for the

Boolean facet of the root node E1

19

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

re-move

20

Experimental Analysis (1) University Ontology Benchmark (UOBM) Effectiveness analysis

Q0: w/o filter Q1: w/ filter Q2: w/ nested fil-ter

More complex query Q3: w/o filter Q4: w/ filter Q5: w/ nested fil-ter

21

Experimental Analysis (2) Scalability test

22

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