Left Outer Join preserving Semantics SQL-to-SPARQL query translation for Nested Rightand Technology Journal of Applied Researchand

(1)

Availableonlineatwww.sciencedirect.com

Journal of Applied Research and Technology

www.jart.ccadet.unam.mx JournalofAppliedResearchandTechnology15(2017)504–512

Review

Semantics preserving SQL-to-SPARQL query translation for Nested Right and Left Outer Join

Nassima Soussi

^∗

, Mohamed Bahaj

Hassan1stUniversity,FacultyofScienceandTechnologies/DepartmentofMathematics&ComputerScience,Settat,Morocco

Abstract

Despitetheemergenceofsemanticwebduetoitshighperformanceinmanagingalargeamountofdatathroughsemanticfilters,therelational databasesarestillthe mostused.Thereforeestablishingaconnectionbetweenbothheterogeneoussystemsbecomesarelevantneedsoasto bridgethegapbetweenthem.Regardingthequerymappingfromrelationalworldtosemanticworld(SQL-to-SPARQL),somesolutionshavebeen developedtorealizethistransformationbutunfortunately,allexistingapproachesdonotconsiderthesemanticcorrespondencebetweenLeft/Right OuterJoincommand(s)andOptionalpattern(s).Thisweaknesshasmotivatedustoinvestigateinthisdirectionandsuggestanefficientsolution todealwiththisproblembyproposing,tothebestofourknowledge,thefirstquerymappingalgorithmensuringthesemantictransformation ofsimple/nestedLeft/RightOuterJoincommand(s)inSQLqueriestoasimple/nestedOptionalpattern(s)inSPARQLequivalentoneswithout physicaltransformationofdata.

Keywords: SQL-to-SPARQL;Querytransformation;NestedLeftOuterJoin;NestedRightOuterJoin;Nestedoptionalpattern

1. Introduction

Themajorityofwebinformationisstoredcurrentlyinrela- tionaldatabasessincetheyweredominantforthepastseveral decadesduetotheirsimplicityandperformanceinmanaging data.However,theamountofinformationisgrowingdaybyday exposingthewebfacedinevitableproblemsowingofthe low competence of thistraditionalsystemtomanage intelligently thisbigamountofdataaswellastheabsenceoflogicalreason- inginqueryanswering.Inordertoovercomethepreviousgaps andenablenotonlytousersbutalsotomachinestofind,share, andcombineinformationmoreeasily,theW3Chasgivenbirth tosemantic webaimingtoexploit the fullwebpotential and permitmachinestointelligentlyaccessdifferentdatasources.

Thissemanticdataisrepresentedviaastandardmodelcalled RDF(ResourceDescriptionFramework)(Vertan&Merkmale, 2004),characterizedbyasimpleandpowerfulstructureoftriples (Subject-Predicate-Object);thesubjectrepresentstheresource andthepredicaterepresentstherelationshipbetweenthesubject

∗Correspondingauthor.

E-mailaddress:[email protected](N.Soussi).

PeerReviewundertheresponsibilityofUniversidadNacionalAutónomade México.

andobject.Thisstructuremakessemanticdataverysimilarto humanlanguage(Subject-Verb-Object).

Since mostofRDBMS usersareunfamiliarwithsemantic webphilosophy,principlesandtechnologies,itbecomesarele- vantneedtoestablishforthemasuitablebridgetoqueryRDF data.Therefore,someresearchershavebeen madetoachieve thisgoalandensureaquerymappingfromrelationalworldto semanticworld(SQL-to-SPARQL),butunfortunately,allthese approaches havecommonweaknessesinthe considerationof theequivalencebetweenLeft/RightOuterJoincommand(s)and Optionalpattern(s)inthequerymappingtranslation.Thisprob- lemhasmotivatedustooperateinthistopicsoastoremedythis gapandestablish,tothebestofourknowledge,thefirstalgo- rithmconvertingSQLqueriescontainingLeft/RightOuterJoin command(s)(simpleandnested form)toSPARQLoneswith Optionalpattern(s)(simpleandnested).Oursystemisveryhelp- fulfororganizationsworkingentirelywithRDBMSandaiming tointeractwithsemanticdatabaseswithoutspendingsomuch inthemigrationof theirsystemandtrainingtheirusersinthe semantictechnologiesnewforthem,inaddition,thissolutionis beneficialintermsofcomplexityandexecutiontimeofqueries by replacingthe heavy and costly SQL joins with SPARQL Optional clauses.Anotheradvantage ofour solutionisthat it facilitates connection and interoperability between relational

http://dx.doi.org/10.1016/j.jart.2017.05.001

1665-6423/©2017UniversidadNacionalAutónomadeMéxico,CentrodeCienciasAplicadasyDesarrolloTecnológico.Thisisanopenaccessarticleunderthe CCBY-NC-NDlicense(http://creativecommons.org/licenses/by-nc-nd/4.0/).

(2)

databasesandRDFstoreswithoutphysicaltransformationof data.

Theremainder of thispaper isstructured as follows:Sec- tion2analysessomeexistingapproachestothe currenttopic.

Section 3 introduces the context of this work by describing the syntax of each query language via its own metamodel anddiscussing thesimilarityanddiscordancesbetweenthem.

Section4describesbyexamplesadifferentmechanismencap- sulated in our strategy. Our contribution is presented in Section 5 that exposes our query mapping algorithm allow- ingthe semantictransformation ofLeft OuterJoincommand (in its simple and nested format) to SPARQL equivalent Optional pattern. In Section 6 we expose the developed java applicationimplementingoursolution.Finally,Section7con- cludesthis workandsuggestssomefutureextensions of this topic.

2. Relatedworks

In order to establish an efficient connection between the semanticwebandrelationalworld(consideredasthemostused database management system), more precisely,to ensure the queryinteroperabilitybetweenSQL andSPARQLlanguages, several researches have been developed regarding SPARQL- to-SQL direction, we quote as example:(Chebotko, Lu, &

Fotouhi, 2009; Rodriguez-Muro & Rezk, 2015) and (Atre, 2015);all thesepapers haveconsidered thesemantic equiva- lencebetween Left Outer Join and optional pattern but they didnottreattheRightOuterJoin.Ontheotherhand,thereare not so much works related to the reversedirection (SQL-to- SPARQLrepresentedthesubjectofthecurrentwork),andthe fewexistingapproacheshaveseveralweaknessesaspresented subsequently.

RETRO method (Rachapalli, Khadilkar, Kantarcioglu, &

Thuraisingham,2009)contributeintheinteroperabilitybetween RDFStoresandRDBMSbyfirstlyderivingarelationalschema fromtheRDFstore,andsecondlyprovidingameanstotrans- lateanSQLquerytoasemanticallyequivalentSPARQLquery.

RETROdealswithschemamappinginadditiontoquerymap- pingandchoosesnottophysicallytransformthedata.However, theauthorsconsiderjustabasicqueryinitstransformationpro- cessandtheyhavenotproposedan implementationof setof experiments.

SQL2SPARQLsolution (“SQL2SPARQL”,inpress.)aims alsototransformSQLqueriesintoSPARQLonesusingsome dynamicmappingsandtransformationrulesbasedonthecom- bination of ideas already presented in other works. In this approach,onlyclassicandbasicqueriesaresupportedandthey didnotdescribetheirtransformationmethodinadetailedway viaanalgorithm,inaddition,theyhavejustassembledandcom- binedthetoolsofsomeexistingworksinordertocarryoutthis paperandtheyhavenotaddedanythingnew.However,theycre- atedajavaapplicationtodemonstratetheeffectivenessoftheir work.

R2D method (Ramanujam, Gupta, Khan, Seida, & Thu- raisingham,2009) operatesinthesame mappingdirection; it proposesamechanismwhichenablesreusabilityof relational

tools on RDF data including SQL-to-SPARQL translation;

R2Dsystem converts SQL queries (with pattern matching, aggregation and blank nodes) into the SPARQL equivalent ones. This translation is presented with algorithmic details validatedviaanimplementationofsetofexperiments.

The authors in (Alaoui, Abatal, Alaoui, Bahaj, & Cherti, 2015)proposeanalgorithmforqueryingRDFdatausingSQL language by translating SQL queries (simple and complex ones containing UNION, INTERSECT or EXCEPT expres- sions)intoanequivalentSPARQLqueriesbasedonmodeling RDF data by a relational schema.They have concluded this work by presenting screenshots of the implementation of experiments.

All the previous approaches have the same and common weakness that theydo not consider the equivalence between Right and Left Outer Join and Optional pattern(s) in their transformationmechanismofrewritingSQLqueriesintotheir semanticallyequivalentSPARQLqueries.Thefirstworkestab- lished in this direction that highlighted this equivalence is presented in (Ramanujam, Gupta, Khan, Seida, & Thurais- ingham,2009) byindicating the abilityto optionallyretrieve reificationdata,whenpresent,throughjoins;nevertheless,this approach does not propose a clear transformation rules or proposing a detailed algorithm describing the different steps toensurethisequivalence. Inaddition,all quotedapproaches do not consider a nested form of Left/Right Outer Join and Optional.

3. Querylanguagesdescription

In thissection,we describethequerylanguagestreatedin our workin ordertopresent the concept of each one via its ownmetamodel:thefamousrelationalquerylanguagedesigned formanagingdatainaRDBMS(SQL)andthesemanticquery languagededicatedtoqueryRDFstores(SPARQL).

3.1. SQL:structuredquerylanguage

SQL is astandardquery languagefor operating relational databases by providing the ability tosearch, add, modify or deletedata.Thislanguageiscreatedin1974,standardizedsince 1986, and currently,it is recognizedby the vast majorityof RDBMSusers.

SQLqueriescanhavenumerouspossibletypes(CREATE, INSERT,SELECT,UPDATE,DELETEandDROP),butinthe current study,we are onlyinterestedby SELECTquerycon- tainingLeftandRightOuterJoincommand(s).Asillustratedin Figure1,SQLSELECTquery(“SQLGrammar”,inpress)con- sists of six clauses: SelectClause,FromClause, WhereClause, GroupByClause, OrderByClause and HavingClause; the two firstclausesaremandatoryinSELECTSQLqueries.

SELECTclauseis composedofasetof propertiesthat will beappearedintheresult,whereasFROMclausecancontain oneormoretable(s)whenthequery’stypeissimple(SELECT varListFROMtable(s)name(s)...),orsquarelyanSQLJoin clausewhenthequery’stypeiscomplex;thissecondcaseaimsto combinedatafrommultipletablesefficientlyinordertoexploit

(3)

SQL Select Query

SelectClause WhereClause OrderByClause

GroupByClause

HavingClause

FromClause

PropertyList 1

Fig.1.MetamodelofSQLSELECTClause.

FromClause

1

1 1 1 1

1 1

0..1 0..1

0..1

0..1 TableExpression 0..1

CondExpression LeftExpression JoinOperator RightExpression OnCondition

LOJoperator

ROJopetator OnOperator

JoinClause

Fig.2.MetamodelofSQLFROMClause.

the power of relational databases. SQL language has several typesof Join: (1) InnerJoinreturns all rowswhen there is a matchinbothtables,(2)LeftOuterJoin(LOJ)returnsallrows fromthelefttableandthematchedrowsfromtherighttable, (3)RightOuterJoin(ROJ)returnsallrowsfromtherighttable andthematchedrowsfromthelefttableand(4)FullOuterJoin Returnallrowswhenthereisamatchinoneofthetables.In thispaper,wefocusonLeftandRightOuterJoindescribedin Figure2representingthemainsubjectofourstudy.

TheLeftandRightOuterJoinarecomposedoffourmanda- torystatements:LeftExpression,JoinOperator(LOJorROJ), RightExpressionandOnConditionrepresentingthejoincrite- riaformatchingrowsthatwillbereturnedintheresult.Theleft andrightexpressionscanbesimple(table)or complex(join- ing query) depending on SQL query type (simple or nested Left/RightOuterJoinquery).

3.2. SPARQL:RDFquerylanguage

SPARQL (SPARQLProtocol and RDF Query Language) [a],asitsnameindicates,isbothaprotocolandquerylanguage thatisabletomanipulatedatastoredinRDFformat.Itiscon- sidered as astandard andoneof the key technologiesof the semantic web.In addition, SPARQLcontainscapabilities for queryingrequiredandoptionalgraphpatternsalongwiththeir conjunctionsanddisjunctionswhichindicatesthatthisfamous languageisbasedonthegraphpatternconceptintheselection of data(RDFtriples)fromRDF source.Inordertocarryout ourmappingapproachandestablishanefficientalgorithm,we havedefinedametamodelofthetargetlanguagedescribingits concretesyntax.

SparqlQuery

SelectQuery ConstructQuery DescribeQuery AskQuery

Fig.3.MetamodelofSPARQLQueryTypes.

Object Predicate FilterConstraint

TripleSameSubject UnionGraphPattern OptionalGraphPattern GroupGraphPattern

GraphPattern

FilterPattern

Subject SelectClause

Variable

WhereClause SelectQuery

1

1..^∗

1..^∗ 1..^∗ 1..^∗

1..^∗

1 1

Fig.4.MetamodelofSPARQLSELECTQuery.

SPARQL query can have a different possible type as described inFigure 3 (Select, Construct, Describeand Ask);

in this study, we are only interested by SELECT query as showninFigure4illustratingametamodelofthislaterbasedon theSPARQLgrammar(Harris,Seaborne,&Prud’hommeaux, 2013).

SELECTqueryconsistsoftwomainstatements:(1)Select- Clause identifies the variables to appear in the results, and (2)WhereClausewhichconsists,initsturn,ofGroupGraphPat- ternthatidentifiesasetofGraphPatternrepresentedinmultiple forms.Wequote:

- FilterPattern:usedtofilterasetofobjectsusingavariouscrite- riaandrequirements.Thefilterexpressionscanbecombined through the logicaloperationsso astoform morecomplex FILTERconstraints.

- TripleSameSubject:includesasubjectandassociatedproper- ties.

- UnionGraphPattern:unionofpatterns.

- OptionalGraphPattern:optionalpatterns.

(4)

Table 1

Where table2.fk_id is null On table1.id=table2.fk_id On table1.id=table2.fk_id Left outer join table2 Left outer join table2 Select ^∗ from table1 Select ^∗ from table1

Table 1 Table 2

Table 2

Fig.5.LeftOuterJoinDescription.

Table 1

Where table1.fk_id is null On table1.id=table2.fk_id On table1.id=table2.fk_id Right outer join table2 Right outer join table2 Select ^∗ from table1 Select ^∗ from table1

Table 2

Table 2 Table 1

Fig.6.RightOuterJoinDescription.

3.3. SQLvs.SPARQL

Atfirstblush,SQLandSPARQLseemssimilarsincethey offertousersthepossibilityofaccessing,creating,combining, andconsumingstructureddata,butinreality,thedirectcompar- isonbetweenthemisratherdifficult(Kumar,Kumar,&Kumar, 2011;Singh&Jain,2014).Infact,SQLoperatesonrelational datarepresentedastablesandSPARQLoperatesonsemantic datainRDFstoresrepresentedastriples(subject,predicateand object).

According to the metamodels elaborated above which describetheconceptsofeachlanguage,numerouscommonali- tiesexistbetweenthem:

- TheaggregatefunctionsusingwithGROUPBYoperator, - Orderingquery’sresultsviatheORDERBYoperator, - Logicoperators,

- OptionaldatarepresentedwithLeftOuterJoincommand(s) inSQLandOptionalpattern(s)inSPARQL.

Otherwise,thereisalargedifferencebetweenthisbothlan- guagesonseveralpoints:

- Data source structure: SQL operates on tables whereas SPARQLoperatesontriples.

- Syntax(lookSQL/SPARQLmetamodelsillustratedabove).

- Query types: we quote as example that SPARQLlanguage supports ASK queries (returns a Boolean result indicating

whetheraquerypatternmatches)whichareunknownforSQL language.

4. Strategyoverview

4.1. RightOuterJoinvs.LeftOuterJoin

In relationalterms,SQLlanguage hasLeftOuter Joinkey wordusedwhenwejointworelationsandweneedtopreserve alltuplesofthefirstoneintheresult;thislatercanbeNULLin therightsidewhenthereisnomatchbetweenthesetworelations.

ThiscommandisusedaspresentedinFigure5.

Onthe otherhand,RightOuterJoinkeywordas presented inFigure6,isusedtojointworelationsinordertopreserveall tuplesofthesecondone(righttable)intheresult;wecanhave NULLtuplesintheleftsidewhenthereisnomatchbetween thesetworelations.

Similarly,semanticwebworldoffersviaitsquerylanguage SPARQLtheOptionalpattern thataimstomatchagraphpat- terns, but if the optional match fails, the whole query does not fail, and in this case, a NULL value will be returned for unbound (no value)variables. Hence, we deduce that the basicequivalentsemantic of LeftOuter Joinis Optional pattern. In addition,if we consider the conversionrule between LOJandROJdefinedas Table1ROJTable2<=>Table2LOJ Table1,weconcludethattheprincipleofLOJandROJinrela- tionaldatabasesisequivalenttoOptionalpattern(s)insemantic world.

(5)

LOJ_m

LOJ_m-1

LOJ₁

R₁ R₂

R_n

R_n-1

1

r

Fig.7.GeneralformofLOJBinaryTreeT.

4.2. Methodologydescription

OurstrategyaimstoenhancetheSQL-to-SPARQLexisting approachesbyproposingthefirstefficientalgorithmensuringa semantictransformation,whenexist,ofsimple/nestedLOJand ROJcommand(s)inSQL queriestoasimple/nestedOptional pattern(s)inSPARQLequivalentqueries.Toachievethisgoal, wehavefollowedtwosteps:

- Step1:ExtractingthejoiningpartfromtheinputSQLquery and we convert it to an equivalent binary tree in order to facilitateaccessingitsdifferentcomponents,

- Step2:Join tree toOptional pattern(s): ifthe join’stype is LOJ, we develop an algorithm for transforming LOJ command(s)(initssimpleornestedform)representedas atree toanequivalentOptionalpattern(s),elseifthejoin’stypeis ROJ,weexploit theconversionrulebetweenLOJandROJ (describedintheprecedentparagraph)totransformtheROJ treetoaLOJtree andusethe previousalgorithmtoensure thisconversioninordertoavoidreinventingthewheel.

Subsequently,wedescribehowourstrategyforLOJ&ROJ- to-Optionalworks.

4.2.1. LOJ-to-optional

Asdiscussedabove,thefirststepinourtranslationapproach istoparsethejoiningpartofinputSQLquerytoabinarytreeTas presentedinFigure7,(inthiscase,wesupposethatthejoining part containsLOJcommand(s))in ordertoglancethrough it andtreatitsdifferentnodesstartingwiththelastleftleafsoas topreservetheleftassociativityofOptionalpatternssemantics.

WeuseRiasarelation(table)ofrankiwithi∈[1,...,n]and nisthenumberofrelations inthe inputSQLqueryQSQL.In addition,LOJj denotesLeft Outer Joinclause of rankj with j∈[1, ...,m]andmisthe numberof LOJcommandsinthe wholeQSQL;wetalkaboutnestedLOJqueryifm>1.Infact, indicesiandjexpresstheexecutionorderofrelationsandLOJ respectively.

- Case1:SimpleLeftOuterJoin

Thiscaseisconsideredasthebasiconeaimingtotransform each component (node) of LOJ tree (table1 LOJ table2ON table1.key = table2.key) toan equivalentSPARQL pattern(s) usingasetofsemanticcorrespondencerulesdefinedasfollows:

• Rule1:JoinattributeintheONconditionof LOJqueryis equivalenttoSPARQLpattern’ssubject(gp1Opt{gp2}).

• Rule2:The namesof SQL joinrelations are equivalentto SPARQLpredicates.

• Rule3:SQL SELECTattribute(s)concatenatedwith‘?’is equivalenttoSPARQLobject(s)(exceptingtheattributecon- sideredassubject).

• Rule4:Thepatternconceivedfromthe rightrelationcorre- spondsperfectlytotheOptionalpattern.

- Case2:NestedLeftOuterJoin

InordertotransformnestedLOJdesignedas(((R1LOJR2) LOJ R3) ... LOJ Rn−1)LOJ Rn tonested Optional patterns defined as gp1OPT(gp2OPT(gp3OPT(...gpn−1OPT)gpn)),the inputSQLqueryhavetorespectsomesemanticrules.

• Rule1:Sharedvariablesbetweenjoinrelationsmustbebound tothesamevalues.WeconsiderforexampletheSQLquery presentedsubsequently;joinrelationsareR1(a,b),R2(a,c)and R3(a,c,d).Hence,thesharedvariablethatmustbeboundisc (Rres.c=R3.c).

SELECTRres.b,Rres.c

FROM(SELECTR1.a,R1.b,R2.c FROMR1LEFTOUTERJOINR2

ON(R1.a=R2.a)

)ASRresLEFTOUTERJOINR3

ON(Rres.a=R3.aANDRres.c=R3.c)

• Rule2:BeforetheevaluationofamainLOJclause,allcon- tainingLOJclauseshavesucceeded.Hence,theattributesof theirrightrelationsmustbeNOTNULL.Ifweconsiderfor exampletheSQLquerypresentedsubsequently;joinrelations areR1(a,b),R2(a,c)andR3(b,d).

SELECTRres.b,Rres.c,R3.d FROM(SELECTR1.a,R1.b,R2.c FROMR1LEFTOUTERJOINR2

ON(R1.a=R2.a)

)ASRresLEFTOUTERJOINR3

ON(Rres.b=R3.bANDRres.cISNOTNULL)

Hence,Rres=

R1.a, R1.b,R2.c (R1=R1.a=R2.a R2) mustsucceedbeforeevaluatingthemainjoinrepresentedas Rresult=

Rres.b,Rres.c,R3.d(Rres=Rres.b=R3.b∩Rres.cIS NOTNULLR3).

Afterensuring that theinputSQL queryhasrespected the previous rules,we use the sametranslation processfor each LOJcommand.

4.3. ROJ-to-LOJ

In order to avoid reinventing the wheel and developing anotheralgorithmtotransformROJpartinSQLqueriestoan optional pattern(s),wehaveaddedanewfunctionalitytoour strategyaimingtoconvertaROJpartrepresentedasatreetoa

(6)

1

ROJ_m LOJ_m

R_n R_n

R₂ R₁ R₁ R₂

R_n-1 R_n-1

ROJ_m-1 LOJ_m-1

ROJ₁ LOJ₁

1

1 1

r 1

r r

Fig.8.ROJtoLOJtreeconversion.

LOJtreeasillustratedinFigure8,andcontinuetheprocesswith thesamealgorithm.

5. Mappingdescription

In this section, we describe our main contribution by detailing all procedures used in our SQL-to-SPARQL algorithm allowing the semantic conversion of Left and Right Outer Join command(s) (in its simple and nested form) to SPARQL equivalent Optional pattern(s). Our algorithm is composedoffiveprocedures:QueryMapping,ParseROJ2LOJ, LOJ2Optional,CounterNbrLOJ and ConstructSPARQLSelect- Clause.

5.1. Querymappingprocedure

ThemainprocedureQueryMappingtakesas inputanSQL querywhichcontainLeftorRightOuterJoincommand(s)(qin) so as to return at the end a SPARQL equivalentquery with Optionalpattern(s).Firstly,weparseqintoabinarytreeinorder toextract eachcomponent ofSQLquery separately,andthen weparsealsotheFROMclause(containingLOJorROJcom- mand(s))toabinarytreenamedT;ifthetypeofFROMclause treeisROJtreethenweusethesub-procedureParseROJ2LOJ inordertousethesametreatmentforbothjointypes.Ourproce- dureglancesthroughtheleftsideofatreeTtilltheend,starting withtherootnode(representingthemainLOJclause)soasto carryoutthe LOJtoOptional translationwithLOJ2Optional sub-procedurewhenwereachtheTtree’sleaves(i=NbrLOJ), otherwise(ifi!=NbrLOJ)we storetherightrelationofeach LOJnodeandONconditioninrightRelStackandonCondRel- Stackstacksrespectivelyforfurtherprocessed.Aslongasthe previousstacksisnotempty,theconversionprocesscontinues in the WHILE loop via LOJ2Optional sub-procedure giving Rres that is concatenated in each iteration in order to form theSPARQLWHEREclause.RegardingSPARQLequivalent SELECTqueryisconstructedthrough ConstructSparqlSelect- Clausesub-procedure.Thecptvariableisincrementedaftereach callofthesub-procedureLOJ2Optionalinordertocomputethe numberofOPTIONALpatterns;thisvariableisusedlaterinthe conceptionofthefinalquerysoastoclosethebracesofeach OPTIONALcommand.

Input:SQLLOJquery,qin

Output:EquivalentSPARQLquery,qout

Begin

qout=“”,where=“WHERE{”,cptopt=0 StackrightRelStack,onCondRelStack=NULL ismainLOJ=False

Treetree=parse(qin)

qinSELECT=tree.getSelectClause() qinFROM=tree.getFromClause() TreeT=parse(qinFROM) if(T.getType()=ROJtree)then T=ParseROJ2LOJ(T) endif

NbrLOJ=CounterNbrLOJ(T) fori←1toNbrLOJdo if(i=1)then

LOJi=root(T) else

LOJi=LOJi−1.getLeftChild() endif

if(i=NbrLOJ)then ismainLOJ=True endif

RR=LOJi.getRightChild() RL=LOJi.getLeftChild() ONcond=LOJi.getOnCondition() if(RL.isLOJQuery()=True)then

rightRelStack.push(RR) onCondRelStack.push(ONCond) continue//gotothenextiteration else

Rres=LOJ2Optional(RL,RR,OnCond,ismainLOJ) where+=Rres

cptopt++

endif Endfor ismainLOJ=False

While(rightRelStack.isEmpty=False)do R=rightRelStack.pop()

OnCond=onCondRelStack.pop()

Rres=LOJ2Optional(Rres,R,OnCond,ismainLOJ) where+=Rres

cptopt++

Endwhile While(cpt!=0)do

where+=“}”

cpt=cpt−1 Endwhile

select=ConstructSparqlSelectClause(qinSELECT) qout=select+where+“}”

Returnqout

EndAlgorithm

(7)

5.2. ParseROJ2LOJsub-procedure

Thesub-procedureParseROJ2LOJtakesasinputaROJtree TROJsoastoglancethroughitandconstructtheLOJequivalent tree TLOJ by considering the correspondence rule (described previously)betweenthistwojointypes(T1ROJT2⇔T2LOJ T1).

Input:AtreeofRightOuterJoinQuery,TROJ Output:AtreeofLeftOuterJoinQuery,TLOJ Begin

Rl=“”,Rr=“”,n=getRootElement(TROJ) while(n!=NULL)do

Rl=n.getLeftChild() Rr=n.getRightChild()

TLOJ=Tree(“LOJ”)//InitializationofTLOJtreewiththerootelement“LOJ”

TLOJ.InsertRightChild(Rl) if(Rr=“ROJ”)then

TLOJ.InsertLeftChild(“LOJ”) n=Rr

else

TLOJ.InsertLeftChild(Rr) n=NULL

endif endwhile returnTLOJ EndAlgorithm

5.3. LOJ2optionalsub-procedure

TheLOJ2Optionalsub-proceduretakesasinputthedifferent componentsofLOJcommand:RL(leftrelation),RR(rightrela- tion),OnCond(LOJcondition)andismainLOJBooleanvariable, inordertoreturnattheendthesemanticequivalentOPTIONAL patternbasedonthesemanticcorrespondencebetweenLOJand Optional.

Input:RL,RR,OnCond,ismainLOJ Output:Optionalpatterns Begin

Subject,PredicateL,PredicateR,ObjectL,ObjectR, Result=“”

Subject=OnCond.getFirstCond().getCommunAttr() if(ismainLOJ=True)then

PredicateL=“:”+RL.getName()

ObjectL=“?”+RL[1]//Thesecondattribute BGPL=Subject+PredicateL+ObjectL

Result=BGPL

endif

PredicateR=“:”+RR.getName() ObjectR=“?”+RR[1]

BGPR=Subject+PredicateR+ObjectR

Result+=“OPTIONAL{”+BGPR

ReturnResult EndAlgorithm

5.4. CounterNbrLOJsub-procedure

TheCounterNbrLOJsub-proceduretakesasinputaLOJtree TLOJ aiming toglance through it and count all nodesunless leaves in order to return at the end the number of LOJ nodes.

Input:AtreeTLOJ

Output:AnumberofLEFTOUTERJOIN,NbrLOJ Begin

Node=“”,NbrLOJ=0 if(T!=NULL)then node=Root(TLOJ) NbrLOJ=1

while(node.hasChildren()=True)do

if(LeftChild(node)!=NULLANDLeftChild(node).isLeafNode()=false)then NbrLOJ=NbrLOJ+1

node=LeftChild(node) endif

endwhile endif returnNbrLOJ EndAlgorithm

5.5. ConstructSparqlSelectClausesub-procedure

The ConstructSparqlSelectClause sub-procedure takes as inputasetofSQLSELECTattributesinordertoglancethrough itandextracttheirnamesoastoconstructtheSPARQLequiv- alent SELECT clause which is returned at the end of this algorithm.

Input:SQLSelectClause,V Output:SPARQLSelectClause Begin

Select=“SELECT”

Fori←1toV.sizedo

Select+=“?”+V[i].getAttributeName()+“” Endfor

ReturnSelect EndAlgorithm

6. Implementation

In ordertoimplementour approach,we havedevelopeda javaapplication(inordertobeportableandeasytoevolve).Our toolischaracterizedbyitssimplicityandefficiencytoallowing RDBuserstoquerysemanticdatawithSQLquerylanguage.

TheexperimentswerecarriedoutonthePCwith2.4GHzCore i5CPUandMSWindowsSevenTitan.

WepresentbelowsomeexamplesofSQLqueriessupported by our system andits equivalent SPARQL queries. The first one treattheconversion of asimpleSQL query that join two relationsPhdStudentandAdvisorwithRightOuterJointypeto anequivalentSPARQLquerywithoneOptionalpattern(Fig.9), andthesecondoneillustratesthetranslationofacomplexSQL querywithnestedLeftOuterJoin(twoJoins)toanequivalent SPARQLquerywithtwoOptionalpatterns(Fig.10).

7. Conclusion

Wehavecontributedthroughthispaperintheenhancement ofSQL-to-SPARQLtranslationapproachessincetherearenot somuchworksrelatedtothislater,andallexistingonesdonot treattheequivalencebetweenRight/LeftOuterJoincommand(s) (simpleandnested)andOptionalpattern(s)(simpleandnested) intheirtransformationmechanismofrewritingSQLqueriesinto their semanticallyequivalentSPARQLqueries.Tothe bestof ourknowledge,thereisnoworktodatethatfillsthisgap.

(8)

Fig.9.ConversionexampleofSQLquerywithsimpleRightOuterJoin.

Fig.10.ConversionexampleofSQLquerywithnestedLeftOuterJoin.

One obvious extension of our research is to include the optimization strategies of SQL and SPARQL queries in our approach.Another promiseaboutourfutureworks istointe- gratethisconversiontechniquetoRDBMSaimingtoofferto relationalusers,aneasybridgeandanopenextensiontoward semanticworld.

Conﬂictofinterest

Theauthorshavenoconflictsofinteresttodeclare.

References

Alaoui,L.,Abatal,A.,Alaoui,K.,Bahaj,M.,&Cherti,I.(2015,July).SQL toSPARQLmappingforRDFqueryingbasedonanewEfficientSchema ConversionTechnique.InternationalJournalofEngineeringResearchand Technology,4(10).IJERT.

Antal,M.,&Anechitei,D.SQL2SPARQL[PDFdocument].Retrievedfrom LectureNotesOnlineWebSite:http://studylib.net/doc/7084652/sql2sparql.

Atre,M.(2015,May).Leftbitright:ForSPARQLjoinquerieswithOPTIONAL patterns(left-outer-joins).InProceedingsofthe2015ACMSIGMODinter- nationalconferenceonmanagementofdata(pp.1793–1808).ACM.

Chebotko,A.,Lu,S.,&Fotouhi,F.(2009).SemanticspreservingSPARQL-to- SQLtranslation.Data&KnowledgeEngineering,68(10),973–1000.

Harris, S., Seaborne, A., & Prud’hommeaux, E. (2013). SPARQL 1.1 query language. W3C recommendation. pp. 21. Retrieved from http://www.w3.org/TR/sparql11query/#sparqlGrammar

Rachapalli,J.,Khadilkar,V.,Kantarcioglu,M.,&Thuraisingham,B.(2009).

RETRO:AframeworkforsemanticspreservingSQL-to-SPARQLtransla- tion.800WestCampbellRoad,Richardson,TX75080-3021,USA:The UniversityofTexasatDallas.

Ramanujam,S.,Gupta,A.,Khan,L.,Seida,S.,&Thuraisingham,B.(2009a).

ArelationalwrapperforRDFreification.InIFIPinternationalconference ontrustmanagement(pp.196–214).Berlin,Heidelberg:Springer.

Ramanujam,S.,Gupta,A.,Khan,L.,Seida,S.,&Thuraisingham,B.(2009b).

R2D:Abridgebetweenthesemanticwebandrelationalvisualizationtools.

InIEEE internationalconference onsemanticcomputing ICSC’09(pp.

303–311).

(9)

Rodriguez-Muro, M.,& Rezk,M.(2015). EfficientSPARQL-to-SQLwith R2RMLmappings.WebSemantics:Science,ServicesandAgentsonthe WorldWideWeb,33,141–169.

Singh, M.,& Jain, P. (2014).Time based query comparison ofrelational databaseandresource descriptionframework(RDF).InternationalJour- nalofAdvancedResearchinComputerScienceandSoftwareEngineering, 4(12).ISSN:2277128X.

SQL Grammar. Retrieved from http://www.h2database.com/html/grammar.

html#select.

Vertan,C.,&Merkmale,R.F.(2004).Resourcedescriptionframework(rdf).

Kumar,A.P.,Kumar,A.,&Kumar,V.N.(2011).Acomprehensivecomparative studyofSPARQLandSQL.InternationalJournalofComputerScienceand InformationTechnologies,2(4),1706–1710.