Abstract
In order to ensure the interoperability between semantic web and relational databases, several approaches have been developed to ensure SQL-to-SPARQL query transformation direction, but all these approaches have the same weakness. In fact, they convert directly the input SQL query to its equivalent SPARQL one without any pre-processing phase enabling the optimization of this input query filled by users before starting the conversion process. This weakness has motivated us to add a pretreatment phase aiming to optimize the most important SQL statements which seem to have the biggest impact on the effectiveness of the transformed queries. Our main contribution is to enrich these rewriting systems by adding an optimization layer that integrate a set of simplification rules of Left, Right and Full Outer Join in order to avoid, firstly unnecessary operations during the conversion process, and secondly SPARQL queries with a high complexity due to Optional patterns obtained from outer join in this conversion context.
Highlights
The semantic web [10] has emerged as an extension of the classic web aiming to exploit the full web potential by providing a common framework for knowledge to be shared across applications
Some approaches have been made regarding SQL to SPARQL query transformation in order to facilitate data extraction for relational users by querying RDF stores with SQL language, but all these approaches have the same weakness in their proposed systems since they convert directly the input SQL query to its equivalent SPARQL one without any optimization phase enabling the pre-processing of this SQL query before starting the mapping process
Condition 2: ensuring that the left outer join succeed by verifying the columns of the right relation which must in no case be all nulls, else the left outer join is reduced to a simple selection of the left table elements
Summary
Abstract—In order to ensure the interoperability between semantic web and relational databases, several approaches have been developed to ensure SQL-to-SPARQL query transformation direction, but all these approaches have the same weakness. They convert directly the input SQL query to its equivalent SPARQL one without any pre-processing phase enabling the optimization of this input query filled by users before starting the conversion process. This weakness has motivated us to add a pretreatment phase aiming to optimize the most important SQL statements which seem to have the biggest impact on the effectiveness of the transformed queries.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
