arX

iv:1

910.

0311

8v1

[cs

.DB

] 7

Oct

201

9

The Query Translation Landscape: a Survey

Mohamed Nadjib Mami1, Damien Graux2,1, Harsh Thakkar3, Simon Scerri1, Sren Auer4,5, andJens Lehmann1,3

1Enterprise Information Systems, Fraunhofer IAIS, St. Augustin & Dresden, Germany2ADAPT Centre, Trinity College of Dublin, Ireland

3Smart Data Analytics group, University of Bonn, Germany4TIB Leibniz Information Centre for Science and Technology, Germany

5L3S Research Center, Leibniz University of Hannover, Germany

October 2019

Abstract

Whereas the availability of data has seen a manyfold increase in past years, its value can be only shownif the data variety is effectively tackled —one of the prominent Big Data challenges. The lack of datainteroperability limits the potential of its collective use for novel applications. Achieving interoperabilitythrough the full transformation and integration of diverse data structures remains an ideal that is hard, if notimpossible, to achieve. Instead, methods that can simultaneously interpret different types of data availablein different data structures and formats have been explored. On the other hand, many query languages havebeen designed to enable users to interact with the data, from relational, to object-oriented, to hierarchical,to the multitude emerging NoSQL languages. Therefore, the interoperability issue could be solved not byenforcing physical data transformation, but by looking at techniques that are able to query heterogeneoussources using one uniform language. Both industry and research communities have been keen to developsuch techniques, which require the translation of a chosen ’universal’ query language to the various datamodel specific query languages that make the underlying data accessible.

In this article, we survey more than forty query translation methods and tools for popular query languages,and classify them according to eight criteria. In particular, we study which query language is a most suitablecandidate for that ’universal’ query language. Further, the results enable us to discover the weakly addressedand unexplored translation paths, to discover gaps and to learn lessons that can benefit future research inthe area.

Introduction

Query languages have come a long way during the last few decades. The first database query language, SQL,was formally introduced in the early seventies [14] following the earlier proposed and well-received relationalmodel [17]. SQL has influenced the design of dozens query languages, from several SQL dialects, to object-oriented, graph, columnar, and the various NoSQL languages. These query languages are implemented andused in an unprecedented variety of storage and data management systems. In order to leverage the advantagesof these solutions, companies and institutions are choosing to store their data in different representations, aphenomenon known as Polyglot Persistence [74]. As a result, large data repositories with heterogeneous datasources are being generated (also known as Data Lakes [19]), exposing various query interfaces to the user.Integrating this heterogeneous data (Big Data Variety [44]) into a unified format and system, as has historicallybeen the case with e.g., data warehouses, is nowadays becoming irrelevant. This is because (1) data is very largein size (Big Data Volume), (2) companies are less likely to sacrifice data freshness especially with the advancesin streaming and IoT technologies (Big Data Velocity).

On the other hand, while computer scientists were looking for the holy grail of data representation andquerying in the last decades, it is meanwhile accepted that no optimal data storage and query paradigm exist.

1

Instead, different storage and query paradigms have different characteristics especially in terms of representationand query expressivity and scalability. Different approaches balance differently between expresivity and scala-bility in this regard. While SQL, for example, comprises a sophisticated data structuring and very expressivequery language, NoSQL trades schema and query expressivity for scalability. As a result, since no optimalrepresentation exists, different storage and query paradigms have their right to exist based on the requirementsof various usecases.

With the resulted high variety, the challenge is how can the collected data sources be accessed in a uniform adhoc way. Learning the syntax of their respective query languages is counterproductive as these query languagesmay substantially differ in both their syntax and semantics. A plausible approach is to develop means to mapand translate between different storage and query paradigms. One way to achieve this is by leveraging theexisting query translators, and building wrappers that allow the conversion of a query in a unique language tothe various query languages of the underlying data sources. This has stressed the need for a better understandingof the translation methods between the query languages.

The topic covered in this survey, namely Query Translation, is horizontal to and directly concerns manyComputer Science domains, from Information Retrieval, Databases, Data Integration, Data Analytics, PolyglotPersistence to Data Publishing and Archiving. Thus, the topic can be of interest to a broad audience; from asspecific as researchers in Query Translation topics, to as general as users who solely interact with an existingsystem using those query languages and needing to transition from one language to another.

Related Surveys. Several studies investigating query translation methods exist in the literature. Theytypically tackle pair-wise translation methods between two specific types of query languages, e.g., [41] surveysXML languages-to-SQL query translations, [51, 75, 78] surveys SPARQL-to-SQL query translations. However,to the best of our knowledge, no survey has tackled the problem of universal translation across several querylanguages.

Contributions. In this survey article we take a broader view over the query translation landscape. Weconsider existing query translation methods that target many widely-used and standardized query languages.Those include query languages that have withstood the test of time and recent ones experiencing rapid adoption.The contributions of this article can be summarised as follows:

• We propose eight criteria shaping what we call a Query Translation Identity Card ; each criterion representsan aspect of the translation method.

• We review the translation methods that exist between the most popular query languages, whereby pop-ularity is judged based on a set of defined measures. We then categorize them based on the definedcriteria.

• We provide a set of graphical representations of the various criteria in order to facilitate informationreading, including a historical timeline of the query translation evolution.

• We discuss our findings, including the weakly addressed query translation paths or the unexplored ones,and report on some identified gaps and lessons learned.

Considered Query Languages

We chose the most popular query languages in four database categories: relational, graph, hierarchical anddocument-oriented databases. We look at the standardization effort, number of citations to relevant publications,categorizations found in recently published works and technologies using the query languages. Subsequently,we introduce our chosen query languages and motivate the choice. We provide a query example for these querylanguages. Our example query corresponds to the following natural language query: ”Find the city of residenceof all persons named Max”.

2

Relational Query Languages

SQL is the de facto relational query language first described in [14]. It has been an ANSI/ISO standard since1986/1987 and is continually receiving updates [33], latest of which was published in 2016.Example: SELECT place FROM Person WHERE name = "Max"

Graph Query Languages

The recently published work at the ACM Computing Surveys [1] features three query languages: SPARQL,Cypher and Gremlin. A blogpost [48] published by IBM Developer in 2017 sees those query languages as mostpopular; GraphQL is also mentioned, but it has far less scientific and technological adoption.

SPARQL is the de facto language for querying RDF data. Of the three surveyed graph query languages,only SPARQL became a standard (by W3C in 2008), and is still receiving updates [32, 63], latest of which isSPARQL 1.1 [28] 2013. Research articles on SPARQL foundations [56, 57, 61] are among the most cited acrossall graph query languages.Example: SELECT ?c WHERE {?p :type :Person . ?p :name "Max" . ?p :city ?c }

Cypher is Neo4j’s query language developed in 2011, which has been open-sourced in 2015 under the Open-Cypher project [30]. Cypher has been recently formally described in a scientific article published [27]. At thetime of writing, Neo4j tops DB engine ranking [68] of Graph DBMS.Example: MATCH (p:Person) WHERE p.name = "Max" RETURN p.city

Gremlin [70] is the traversal query language of Apache TinkerPop [70]. It first appeared in 2009 and predatesCypher. It also covers wider range of graph query processing: declarative (pattern matching) and imperative(graph traversal). Thus, it has a larger technological adoption. For example, it has libraries in more querylanguages: Java, Groovy, Python, Scala, Clojure, PHP, and JavaScript; and is integrated in more renowneddata processing technologies e.g., Hadoop, Spark, and graph databases, e.g., Amazon Neptune, Azure Cosmos,OrientDB, etc.Example (declarative): g.V().match(.as(’a’).hasLabel(’Person’).has(’name’,’Max’).as(’p’), .as(’p’)

.out(’city’).values().as(’c’)).select(’c’)

Example (imperative): g.V().hasLabel(’Person’).has(’name’,’Max’).out(’city’).values()

Hierarchical Query Languages

This family is dominantly represented by XML query languages. XML appeared more than two decades agoand has been standardized in 2006 by W3C [12]; it is used mainly for data exchange between applications. W3Crecommended XML query languages are XPath and XQuery.

XPath allows to define path expressions that navigate XML trees from a root parent to descendent children.XPath has been standardized by W3C in 1999, and is continually receiving updates [5, 10, 16] with the latestone in 2017 [22].Example: //person[./name=’Max’]/city]

XQuery is the XML de facto query language. XQuery is also considered a functional programming language,as it allows calling and writeing functions to interact with XML documents. XQuery uses XPath for pathexpressions, and can perform insert, update and delete operations. It has been initially suggested in 2002 [10],standardized by W3C in 2007 and recently updated in 2017 [39].Example: for $x in doc("persons.xml")/person where $x/name=’Max’ return $x/city

3

Document Query Languages

The representative document database that we choose is MongoDB. MongoDB (first released in 2009) is thedocument database that attracted the most attention both from academia and industry. At the time of writing,MongoDB tops the DB engine ranking [68] for document stores.

MongoDB operations. MongoDB does not have a proper query language like SQL or SPARQL, but ratherinteracts with documents by means of query operations in a JSON-like format.Example: db.product.find({name: "Max"}, {city: 1})

Query Translation Paths

In this section, we introduce the various translation paths between the selected query languages. Figure 1shows a visual representation, where the nodes correspond to the considered query languages and the directedarrows correspond to the translation direction; the thickness of the arrows reflects the number of works on therespective query translation path.

SQL <> XML languages

The interest in using a relational database as a backbone for storing and querying XML has appeared as earlyas 1999 [36]. Even though XML model differs substantially from the relation model, e.g., multi-level nesting ofdata, cycles, recursive graph traversals, etc., storing XML data in RDBMSs was sought to benefit from theirquery efficiency and storage scalability.

XPath/XQuery-to-SQL: XML documents have to be flattened, or shredded, into relations so they can beloaded into or mapped to relational tables. The ultimate goal is to hide the specificity of the back-end store,and make users feel as if they are directly dealing with the original XML documents. In parallel, there areefforts to provide an XML view on top of relational databases. The rational is to unify the access, using XML,and also to benefit from XML querying capabilities, e.g., expressing path traversals and recursion.

SQL-to-XPath/XQuery: This covers approaches for storing XML in native XML stores, but adding anSQL interface to enable the querying of XML by SQL users. Metadata about how XML data is mapped to therelational model is required.

SQL <> SPARQL

SPARQL-to-SQL: Similarly to XML, the interest in bridging the gap between RDF data model and therelational model emerged as early as RDF. This was motivated by multiple and various use-cases. For example,RDBMS were suggested to store RDF data [50, 62], even before SPARQL standardization. Also, the SemanticWeb community suggested a well-received data integration proposal, whereby disparate relational data sourcesare mapped to a unified ontology model and then queried uniformly [55, 62]. The concept evolved to becomethe popular OBDA, Ontology-Based Data Access [58], empowering a lot of applications today.

SQL-to-SPARQL: The other direction received less attention. The main two motivations presented wereenhancing interoperability between the two worlds in general, and enabling reusability of the wealth of existingrelational-oriented tools over RDF data, e.g, reporting and visualization.

SQL-to-Document-based

The main motivation behind exploring this path was to enable SQL users and legacy systems to access the newclass of NoSQL document databases with their sole SQL knowledge.

4

SPARQL-to-Document: The rational here is identical to that of SPARQL-to-SQL, with one extra consid-eration: scalability. Native triple stores become prone to scalability issues when storing and querying significantamounts of RDF data. Users resorted to more scalable solutions to store and query the data [35]. The moststudied database solution by the research community, we found, was MongoDB.

SQL <> Graph-based

SQL-to-Cypher: This path is considered for the same reasons as the SQL-to-Document, which is mainlyattempting to help users with SQL knowledge to approach graph data stored in Neo4j.

Cypher-to-SQL: The rational is to allow running graph queries over relational databases. It has also beenadvocated that using relational databases to store graph data can be beneficial in certain cases, benefiting fromthe efficient index-based retrieval RDBMSs offer.

Gremlin-to-SQL: The aim here is to allow executing Gremlin traversals (without side effect steps) on topof relation databases, in order to leverage the optimization techniques built into RDBMSs. In order to do so,the property graph data is represented and stored as relational tables.

SQL-to-Gremlin: The main motivation is to enable relational database users to migrate to graph databasesin order to leverage the advantages of graph-based functions (e.g., depth-first search, shortest paths, etc.) anddata analytical applications that require distributed graph data processing.

SPARQL <> XML languages

SPARQL-to-XPath/XQuery: Similarly to SQL-to-XML paths, this path seeks to build interoperabilityenvironments between semantic and XML database systems, to enable ontology-based data access to XMLdata, and to add a semantic layer on top XML data and services for integration purposes.

SPARQL <> Graph-based

XPath/XQuery-to-SPARQL: Enabling XPath traversal or XQuery functional programming styles on topof RDF data can be an interesting feature to equip native RDF stores with, in order to embark adopters fromthe XML world into the Semantic Web world.

SPARQL-to-Gremlin: This path aims to bridge the gap between the Semantic Web and Graph databasecommunities by enabling SPARQL querying of property graph databases. Users well versed in SPARQL querylanguage can avoid learning another query language, as Gremlin supports both OLTP and OLAP graph pro-cessors, covering a wide variety of graph databases.

Survey Methodology

Our study of the literature revealed a set of generic query translation patterns and common aspects that canbe used to classify the surveyed query translation methods and tools. We refer to them as translation criteriaand organize them in three categories, forming what we call the Query Translation Identity Card.

I. Translation Properties

1. Translation type: Describes how the target query is obtained.(a) Direct: the translation generates the destination query starting from and by analyzing only the

original query.(b) Intermediate/meta query language-based: the translation generates the destination query by

passing by an intermediate (meta-)language.

5

SPARQL

SQL

XPathXQuery

Gremlin

Documentbased

Cypher

[65, 66, 67]

[15, 23, 40,47, 60, 71,77, 80, 87]

[6, 7, 9, 26, 31]

[21]

[24, 29, 37, 43, 49, 53]

[34, 38, 89, 90]

[84, 85]

[92]

[82]

[13, 81]

[64, 69, 88]

[3, 11, 52, 54, 86]

Figure 1: Query translation paths found and studied.

(c) Storage scheme-aware: the translation generates queries depending on how data is internallystructured or partitioned.

(d) Schema information-aware: the translation depends mainly on the schema information of theunderlying data.

(e) Mapping language-based: the translation generates the destination query using a set of mappingrules expressed in an established/standardized third-party mapping language, e.g., R2RML [18].

2. Translation coverage: Describes how much of the origin query language syntax is covered. For example,projection and filtering preserved, joining and update dropped.

II. Translation Optimization

3. Optimization strategies: Describes any optimization techniques applied during query translation, e.g.,reordering joins in a query plan to reduce intermediate results.

4. Translation relationship: Describes how many destination queries can be generated starting from theinput query: one-to-one, one-to-many. Generally, it is desirable to reduce the number of destination queriesto one, so we consider this an optimization aspect. We separate it from the previous point, however, as ithas separate (discrete) value range.

III. Community Factors

5. Availability: Describes whether the translation method implementation or prototype is openly available.That can be known, for example, by checking if the reference to the source code repository or downloadpage is still available.

6. Adoption: Describes the degree of acceptance of the translation method by the community by, forexample, enumerating the research publications citing it.

7. Evaluation: Assesses whether the translation method has been empirically evaluated. For example [34]evaluates the various schema options and their effect on query execution, using the TPC-H benchmark.

6

8. Metadata: Provides some related information about the presented translation method, such as date offirst and last release/update. For example, this helps to obtain an indication about whether the solutionis still maintained.

Criteria-based Classification

Scope definition. Given the broad scope tackled in this survey, it is important to limit the search space.Therefore, we take measures as to favor quality, high-influence and completeness, as well as preserve certainlevel of novelty–at least in paths with the highest number of works. The measures are as follows:

• We do not consider work that describes the query translation very marginally or that has a broad scopewith little focus on the query translation aspects.

• We only consider works proposed during the last fifteen years, i.e., after 2003. This applies in particularto XML-related translations; however, interested readers may refer to an existing survey covering olderXML translation works [41].

It is also important to explicitly prune the scope in terms of what is not considered for the study:• We do not address post-query translation steps, e.g., results format and representation.• As the aim of this survey is to explore the methods and capacities, we do not comment on the resultsof empirical evaluations of the individual works. This is also due to the vast heterogeneity between thelanguages, their underlying data and use-cases.

• The translation method is summarized, which may entail that certain details are omitted. The goal is toallow the reader to discover the literature; interested readers are encouraged to reach to the individualpublications for the full details.

In the following, we refer to the articles and tools by citation and, when applicable, by name, and directlydescribe the query translation methods they present. Further, it should not be inferred that the article or toolpresents solely translation methods, but often, other aspects are also tackled, e.g., data migration, which areconsidered out-of-scope of the current study. Finally, in order to give the survey a temporal context, works arelisted in a chronological order.

I. Translation Properties

1. Translation type:

(a) Direct:

SQL-to-XPath/XQuery: ROX [34] aims at directly querying native XML stores using a SQL inter-face. The method consists of creating relational views, called NICKNAMEs, over a native XML store. TheNICKNAME contains schema descriptions of the rows that would be returned starting from XML input data,including mappings between those rows and XML elements expressed in form of XPath calls. Nested parent-child XML elements are caught, in the NICKNAME definition, by expressing primary and foreign keys betweenthe corresponding NICKNAMEs. [89, 90] propose a set of algorithms enabling direct logical translations ofsimple SQL INSERT, UPDATE, DELETE and RENAME queries to statements in the XUpdate language1. Incase of the INSERT, SQL query has to be slightly extended to instruct in which position related to the contextnode, preceding/following, the new node has to be inserted.

SPARQL-to-SQL: [15] defines a set of primitives that allow to (a) extract the relation where triplesmatching a triple pattern are stored, (b) extract the relational attribute whose value may match a given triplepattern in a certain position (s,p,o), (c) generate a distinct name from a triple pattern variable or URI, (d)generate SQL conditions (WHERE) given a triple pattern and the latter primitive, and (e) generate SQLprojections (SELECT) given a triple pattern and the latter three primitives. A translation function returns aSQL query by fusing and building up the previous primitives given a graph pattern. The translation functiongenerates SQL joins from UNIONs and OPTIONALs between sub-graph patters. FSparql2Sql [47] is an earlywork focusing on the various cases of filter in SPARQL queries. While RDF objects can take many forms like

1XUpdate is an extension of XPath allowing to manipulate XML documents.

7

IRIs (Internationalized Resource Identifier), literals with and without language and/or datatype tags, valuesstored in RDBMS are generally atomic textual or numeral values. Therefore, the various cases of RDF objectsare affected primitive data types, called ’facets ’, e.g., facets for IRIs, datatype tags and language tags are ofprimitive type String. This way, filter operands become complex, so they need to be bound dynamically. Toachieve that, CASE WHEN ... THEN expressions part of SQL-92 are exploited. [23] proposes several translationSQL model -algorithms implementing different operators of a SPARQL query (algebra). In contrast to manyexisting works, this work aims to generate flat/un-nested SQL queries, instead of multi-level nested-queries,so SQL query optimizers can achieve better performance. This is done via SQL augmentations, i.e., SPARQLoperators gradually augment the SQL query instead of creating a new nested one. The algorithms implementfunctions which each generates a part of the final SQL query.

SQL-to-Document-based: QueryMongo [64] is a Web-based translator that accepts a SQL query andgenerates an equivalent MongoDB query. The translation is based solely on SQL query syntax, i.e., not consid-ering any data or schema. No explanation about the translation approach is provided. [73] is a library providingan API to translate SQL to MongoDB queries. The translation is based on SQL query syntax only.

SPARQL-to-XPath/XQuery: [31] does not provide a direct translation of SPARQL, but SPARQLembedded inside XQuery. The method involves firstly representing SPARQL in form of tree of operators. Thereare operators for projection, filtering, joining, optional and union; they declare how the output (XQuery) ofthe corresponding operations are represented. The translation involves data translation, from RDF to XML,and the translation of the operators to XQuery queries accordingly. An XML element with three sub-elementsare created for each triple for each triple term (s, p and o). The translation from an operator into XQueryconstructs is based on transformation rules, which replace the embedded SPARQL constructs with XQueryconstructs. The translation from an operator into an XQuery constructs is based on transformation rules,which replace the embedded SPARQL constructs with XQuery constructs. In XQL2Xquery [26], variablesof the basic graph patter (BGP) are mapped to XQuery values. A for loop and a path expression is usedto retrieve subjects and bind any variables encountered, then nested under every variable, iterate over thepredicates and bind their variables. In a similar way, nestedly iterate over objects. Next, BGP constants andfilters are mapped to XQuery where. OPTIONAL is mapped to an XQuery function implementing a left outerjoin. For filters, XQuery value comparison are employed (e.g., eq, neq). ORDER BY is mapped to order by in aFLWOR expression. LIMIT and OFFSET are handled using position on the results. REDUCED is translatedinto a NO-OP.

XPath/XQuery-to-SPARQL: [21] presents a translation method that includes data transformation fromXML to RDF. During the data transformation process, XML nodes are annotated with information used tosupport all XPath axes. For example, type information, attributes, namespaces, parent-child relationships,information necessary for recursive XPath, etc. The above annotations conform to the structure of the generatedRDF and are used to generate the final SPARQL query.

Gremlin-to-SQL [82] propose a direct mapping approach for translating Gremlin queries (without theside effect step) to SQL queries. The authors propose a generic technique to translate a subset of Gremlinqueries (queries without side effect steps) into SQL leveraging the relational query optimizers. They proposetechniques that make use of a novel schema which exploits both relational and non-relational storage for propertygraph data by combining relational storage with JSON storage for adjacency information and vertex and edgeattributes respectively.

SPARQL-to-Gremlin: Gremlinator [84, 85] proposes a direct translation of SPARQL queries to Grem-lin pattern matching traversals, by mapping each triple pattern within a SPARQL query to a correspondingsingle step in the Gremlin traversal language. This is made possible by the match()-step in Gremlin which offersa SPARQL-style of declarative construct. Within a single match()-step, multiple single step traversals can becombined forming a complex traversal, analogous to how multiple basic graph patterns constitute a complexSPARQL query [83].

8

(b) Intermediate/meta query language-based:

Type-ARQuE [40] uses an intermediate query language called AQL, Abstract Query Language. AQL isdesigned to stand between SQL and SPARQL, it extends from the relational algebra (in particular the join) andaccommodates both SQL and SPARQL semantics. It is represented as a tree of expressions and joins betweenthem, containing selects and orders. The translation process consists of three stages: (1) SPARQL query parsedand translated to AQL query, (2) AQL query undergoes a series of transformations (simplification) preparingit for SQL transformation, and (3) AQL query translated to the target SQL dialect, transforming AQL jointree to SQL join tree, along the other selects and orders expressions. Example of stage 2 simplifications: typeinference, nested join flattening, join inner joins with parents, etc. In [71], Datalog is used as an intermediatelanguage between SPARQL and SQL. SPARQL query is translated into a semantics-similar Datalog program.First phase is translating SPARQL query to a set of Datalog rules. The translation adopts a syntactic variationof the method presented in [59] by incorporating built-in predicates available in SQL and avoid negation, e.g.,LeftJoin, isNull, isNotNul, NOT. Second phase is generating an SQL query starting from Datalog rules. Datalogatoms, ans, triple, Join, Filter, LeftJoin, are mapped to equivalent relational algebra operators. ans andtriple are mapped to a projection, while filter and joins to equivalent relational filter and joins, respectively.

SPARQL-to-Document: In [52] a generic two-step SPARQL-to-X approach is suggested, with a showcaseusing MongoDB. The article proposes to convert a SPARQL query to a pivot intermediate query language calledAbstract Query Language (AQL). The translation uses a set of mappings in xR2RML mapping language, whichdescribe how data in target databases are mapped into RDF model, without converting data to RDF. AQLhas a grammar that is similar to SQL both syntactically and semantically. The BGP part of a SPARQLquery, is decomposed into a set of expressions in AQL. Next, xR2RML mappings are checked for any mapsmatching the containing triple patterns. Those detected matching maps are used to translate individual triplepatterns to atomic abstract queries. Queries in AQL are translated to the query language of the target database.Unsupported operations like JOIN in MongoDB are assumed left to a higher-lever query engine.

(c) Storage scheme-aware:

XPath/XQuery-to-SQL: In [53] XTRON, a relational XML management system is presented. Thearticle suggests a schema-oblivious way of storing and querying XML data. XML documents are stored uniformlyin identical relational tables using a fixed predefined relational model. Generated queries then have to abide bythis fixed relational schema scheme.

SPARQL-to-Document: D-SPARQ [54] focuses on the efficient processing of join operation betweentriple patterns of a SPARQL query. RDF data is physically materialized in a cluster of MongoDB stores,following a specific graph partitioning scheme. SPARQL queries are converted to MongoDB queries followingthe same.

Cypher-to-SQL: Cyp2sql [13] is a tool for the automatic transformation of both data and queries fromNeo4j to a relational database. During the transformation, the following tables are created: Nodes, Edges,Labels, Relationship types, plus materialized views to store the adjacency list of the nodes. Cypher queries arethen translated to SQL queries tailored to that data storage scheme.

SQL-to-Gremlin: SQL-Gremlin [92] is a proof-of-concept SQL-to-Gremlin translator. The translationrequires that the underlying graph data is given a relational schema, where elements from the graph are mappedto tables and attributes. However, there is no reported scientific study that discusses the translation approach.SQL2Gremlin [79] is a tool for converting SQL queries to Gremlin queries. They show how to reproduce theeffect of SQL queries using Gremlin traversals. A pre-defined graph model is used during the translation; as anexample, Northwind relational data was loaded as a graph inside Gremlin.

(d) Schema information-aware:

9

XPath/XQuery-to-SQL: [43] The process uses summary information on the relational integrity con-straints pre-computed in a pre-processing phase. An XML view is constructed by mapping elements from theXML schema to elements from the relational schema. The XML view is a tree where the nodes map to tablenames and the leaves to column names. An SQL query is built by going from the root to the leaves of this tree,a traversal from a node to a node is a join between the two corresponding tables. In [24] XML data is shreddedinto relations based on an XML schema (DTD) and saved in a RDBMS. The article extends XPath expressionsto allow capturing recursive queries against a recursive schema. XPath queries with the extended expressionscan, next, be translated into an equivalent sequence of SQL queries using a common RDBMS operator (LFP:Simple Least Fixpoint). Whereas [49] builds a virtual XML view on top of relational databases using XQuery,the focus of the article is on the optimization of the intermediate relational algebra.

SQL-to-SPARQL: R2D [66, 67] propose to create a relational virtual normalized schema (view) on topof RDF data. Schema elements are extracted from RDF schema; if schema is missing or incomplete, schemainformation is extracted by thoroughly exploring the data. r2d:TableMap, r2d:keyField, r2d:refersToTableMapdenote a relational table, its primary key, and foreign key, respectively. A relational view is created using thoseschema constructs, against which SQL queries are posed. SQL queries are translated into SPARQL queries.For every SQL projected, filtered or aggregated (with GROUP BY) variable, a variable is added to SPARQLSELECT. SQL WHERE conditions are added to SPARQL FILTER, LIKE mapped to a regex(), and blanknodes are used in a number of cases. In RETRO [65] RDF data is exhaustively parsed to extract domain-specific relational schema. The schema corresponds to the so-called vertical partitioning, i.e., one table for everyextracted predicate, each table is composed of <subject object> attributes. Then, the translation algorithmparses the SQL query posed against the extracted relational schema and iteratively builds the SPARQL query.

SQL-to-Document-based: [69] requires the user to provide a MongoDB schema, expressed in a rela-tional form using tables, procedures, and functions. [88] provides a JDBC access to MongoDB documents bybuilding a representative schema, which is, in turn, constructed by sampling MongoDB data and fitting theleast-general type representing the data.

SQL-to-XPath/XQuery: AquaLogic Data Services Platform [38] builds an XML-based layer ontop of heterogeneous data sources and services. To allow SQL access to relational data, relational schema ismapped to AquaLogic DSP artifacts (internal data organization), e.g., service function to relational tables.

SPARQL-to-Document: [11], in the context of OBDA, suggests a two-step approach, whereby the rela-tional model is used as an intermediate model between SPARQL and MongoDB queries. Notions of MongoDBtype constrains (schema) and mapping assertions are imposed on MongoDB data, both of which are used duringthe first phase of query translation to create relational views. The schema is extracted from the data stored inMongoDB. MongoDB mappings relate MongoDB paths (e.g., student.name) to ontology properties. A SPARQLquery is first decomposed into a set of translatable sub-queries. Using MongoDB mappings, MongoDB queriesare created. OntoMongo [3] proposes an OBDA on top of NoSQL stores, applied to MongoDB. An ontology,conceptual layer, and mapping between the ontology and conceptual layer are involved. The conceptual layeradopts the object-oriented programming model, i.e., classes and hierarchy of classes. Data is accessed via ODM,Document-Relational Mapping, calls. SPARQL triple patterns are grouped by their shared subject variable(star-shaped). Each group of triples is assumed to be of one class defined in the mappings, the class name isdenoted by the variable of the shared subject. MongoDB query can be created by mapping query classes toclasses in the conceptual model, which then is used to call MongoDB terms via the ODM. The lack of JOINoperation in MongoDB is substituted with a combination of two unwind commands each concerning one side(class) of the join.

Cypher-to-SQL: Cytosm [81] presents a middleware allowing to execute graph queries directly on non-graph databases. The application relies on gTop (graph Topology) to build a form of schema on top of graph data.gTop consists of two components: (1) Abstract Property Graph model and (2) a mapping to the relational model.It captures the structure of property graphs, i.e., node and edge types and their properties, and provides mappingbetween graph query language and the relational query language, mapping nodes to rows of tables, and edges to

10

either fields of rows or a sequence of table-join operations. Query translation is twofold. (1) Using gTop abstractmodel, Cypher path expressions (from MATCH keyword) are visited and a set of restricted OpenCypher [27]queries not containing multi-hop edges and anonymous entities (which are not possible to translate to SQL)are generated, denoted rOCQ. (2) rOCQ are parsed and an intermediate SQL-like representation is generated,having one SELECT and WITH SELECT for each MATCH. SELECT variables are checked if they requireinformation from the RDBMS, and if they inter-depend. Then, the mapping part of gTop is used to map nodesto relational tables. Finally, edges are resolved into JOINs, also basing on gTop mappings.

SPARQL-to-XPath/XQuery: SPARQL2XQuery is described in a couple of publications [6, 7, 9].The translation is based on a mapping model between OWL ontology (existing or user-defined) and XMLSchema. Mappings can either be automatically extracted by analyzing the ontology and XML schema, ormanually curated by a domain expert. SPARQL queries are posed against the ontology without knowledge ofthe XML schema. The BGP (Basic Graph Pattern) of SPARQL query is normalized into a form where eachGP is UNION-free, so each GP can be processed independently and more efficiently. XPaths are bound to GPvariables, there are various forms of binding for various types of variables. Next, GPs are translated into anequivalent XQuery expression using the mappings; for each variable of a triple, a For or Let clause using thevariable binding is created. Ultrawrap [77] implements an RDF2RDB mapping, allowing to execute SPARQLqueries on top of existing RDBMSs. It creates an RDF ontology from the SQL schema, based on which it nextcreates a set of logical RDF views over the RDBMS. The views, called Tripleviews, are an extension of thefamous triple tables (subject,predicate,object) with two additional columns: subject and object primary keys.Four Tripleviews are created: types —stores subjects along their types in the DB, varchar(size) —stores onlytextual attributes, int —stores only numeral attributes, and object properties —stores join links between DBtables. Given a SPARQL query, each triple pattern maps to a Tripleview.

(e) Mapping language-based:

SPARQL-to-SQL: In SparqlMap [87] triple patterns of a SPARQL query are individually examined toextract R2RML triple maps. Methods are applied to find the candidate set of triple maps, and then to prune thisto produce a set that prepares for the subsequent query translation. Given a SPARQL query, a recursive querygeneration process is devised yielding a single but nested SQL query. Sub-queries are created for individualmapped triple patterns and for reconciling those via JOIN or UNION. Nested subqueries querying the RDBMStables extract not only the columns but also structural information like term type (resource, literal, etc.),concatenates multiple columns to form IRIs, etc. To generalize the technique of [71] (Datalog as intermediatelanguage) to arbitrary relational schema, R2RML is incorporated. For every R2RML triple map a set of Datalogrules are generated reflecting the same semantics. A triple atom is created for every combination of subjectmap, property map and object map on a translated logical table. Finally, the translation process from Datalogto SQL is extended to deal with the new rules introduced by R2RML mappings. [60] extends a previouslypublished translation method [15] to involve user-defined R2RML mappings. In particular, it incorporatesR2RML mappings in α and β mappings as well as genCondSQL(), genPRSQL() and trans() functions. Foreach, an algorithm is devised, considering the various situations found in R2RML mappings like the absence ofReference Object Map. SparqlMap-M [86] enables querying document stores using SPARQL without RDFdata materialization. It is based on a previous SPARQL-to-SQL translator, SparqlMap [87], so it adopts arelational model to virtually represent the data. Documents are mapped to relations using an extension ofR2RML allowing to capture duplicate demoralized data, which is common characteristic of document data.The lack of union and join capabilities support is mitigated by a multi-level query execution, producing andreusing intermediate results. Selection parts are pushed to the document store, while the union and join areexecuted using an internal RDF store.

2. Translation coverage:

We note the following before starting our review of the works:• The coverage is extracted not only from the core of the articles, but also from the evaluation sections andfrom the online page of the implementations (when available). For example, [77, 86] evaluate using all 12

11

BSBM benchmark queries, which cover more scope than that of the article; the corresponding Web pageof [77] mention features that are both beyond the core and the evaluation section of the article.

• We mention the supported query feature but we do not assume its completeness, e.g., [3] supports filtersbut only for equality condition. Interested users are encouraged to seek details from the correspondingarticles/tools.

• Table 2 shows that some works [3, 15] support only one feature. This does not necessarily imply insignifi-cance, but reflects a choice to reserve the full study to covering that particular feature, e.g., various shapesof graph patters or different cases of OPTIONAL.

SQL-to-X and SPARQL-to-X: See Table 1 and Table 2 for translation methods and tools from SQLto SPARQL respectively. For SQL, the WHERE clause is an essential part of most useful queries, hence, it issupported by all methods. GROUP BY is the next commonly supported feature, as it enables a significant classof SQL queries: analytical and aggregational queries. To a lower extent supported is the sorting operationORDER BY. UNION and especially JOIN are operations of typically high cost; they are among the least supportedfeatures. As most researched query categories are of retrieval nature, modification queries such as INSERT,UPDATE and DELETE are very weakly addressed. DISTINCT and nested queries are rarely supported, which mightalso be attributed to their typical expensiveness, e.g., DISTINCT requires sorting, and nested-queries generatelarge intermediate results. EXCEPT, UPSERT, and CREATE are only supported by individual works. For SPARQL,query operation support is more prominent across the reviewed works. FILTER, UNION and OPTIONAL are themost commonly supported query operations with up to 60% of the surveyed works. To less extent, DISTINCT,LIMIT and ORDER BY are supported by about half of the works. The rest query operations are all supported bya few works , e.g., DESCRIBE, CONSTRUCT, ASK, blank nodes, datatype(), bound(), isLiteral(), isURI(), etc.GRAPH, SUB-GRAPH, BIND are examples of interesting query operations but only supported by individual works.In general, DESCRIBE, CONSTRUCT and ASK are far less prominent SPARQL query constructs in comparison toSELECT, which is present in all the works. isURI() and isLiteral() are SPARQL-specific functions with nodirect equivalent in other languages.

XPath/XQuery-to-SQL: The queries [43] focuses on are simple path expressions, including descendentaxis traversal, i.e., //. [24] enables XPath recursive queries against a recursive schema. [49] focuses on optimizingrelational algebra, only a simple XPath query is used for the example. [29] covers simple, ancestor, following,parent, following-sibling, descendant-or-self XPath queries. In [37], the supported queries are XPath queries withdescendent/child axes with simple conditions. [53] translates XQuery queries with path expressions includingdecedent axis // XQuery queries, dereference operator => and FLWR expressions.

XPath/XQuery-to-SPARQL: [21] mentions support for recursive XPath queries, with descendent, fol-lowing and preceding axes as well as for filters.

Cypher-to-SQL: [81] experiments with queries containing MATCH, WITH, WHERE, RETURN, DISTINCT, CASE,ORDER BY, LIMIT, and with patters: simple patterns with known nodes and relationships, and − > and < −directions, variable-length relationship. [13] is able to translate MATCH, WITH, WHERE, RETURN, DISTINCT, ORDERBY, LIMIT, SKIP, UNION, count(), collect(), exists(), label(), id(), and rich pattern cases, e.g., (a or empty)–()–(bor empty), [a or empty]-[b]-(c or empty), − > and < −, (a) −− > (b).

II. Translation Optimization

3. Optimization strategies

In this section, we use the terms previously introduced in Transformation type (1); in order to avoid repetitions.

XPath/XQuery-to-SQL: [43] suggests to eliminate joins by eliminating unnecessary prefix traversals,i.e. first traversals from the root. [49] proposes a set of rewrite rules meant to detect and eliminate unnecessarilyredundant joins in the relational algebra of SQL queries resulted from the translation of XML queries. Duringquery translation, [24] suggests an algorithm leveraging the structure of XML schema: pushing selections and

12

Work DISTINCTWHERE/REGEX

JOIN UNIONGROUP BY

/HAVINGORDER BY

LIMIT/OFFSET

INSERT/UPDATE

DELETE/DROP

Nested

queriesOthers

SQL-to-XPath/XQuery

[34] ? "/ ? ? "/ " ? ? "/ ?[38] ? "/ " " ? " ? ? ? "

[89, 90] ? "/ ? ? ? ? ? "/" "/ ? RENAME

SQL-to-SPARQL

[65] ? "/ " " ? ? ? ? ? EXCEPT

[66, 67] ? "/" ? ? "/ ? ? ? ? ?SQL-to-Document-based

[64] " "/" % % "/" " "/ % % %

[69] " "/ ? ? "/" " "/" "/ "/ ?[88] ? "/" " ? "/ ? "/" "/" /" ? CREATE, DROP,

UPSERT, date,string, mathfncts

[73] ? "/" ? ? "/ " ? ? "/ ? some Booleanfilters

[91] ? "/ " ? "/ " ? ? ? ?SQL-to-Gremlin

[92] " "/" ? " "/ " ? ? ? "

Table

1:SQLfea

tures

supported

inSQL-to

-Xquery

transla

tions."

issupported

,%

isnotsupported

,?not

(clearly

)mentio

ned

supported

.Others

are

features

prov

ided

only

byindividualworks.

13

WorkDISTINCT/REDUCED

FILTER/regex()

OPTIONAL UNION ORDER BYLIMIT/OFFSET

Blank

nodes

datatype()/lang()

isURI()isLiteral()

DESCRIBE/bound()

CONSTRUCT/ASK

Others

SPARQL-to-SQL

[40] "/ ? ? " % "/ ? ? ? ? ?[60] ? ? ? ? ? ? ? ? ? ? ?[23] "/ ? " " " "/ " "/ " "/ "/" GRAPH,

FROM

NAMED,is-Blank()

[87] ?/ ? " ? " ? ? ? ? ? ?[84, 85] "/% "/" " " " "/" " ? ? %/% %/% GROUP

BY,SUB-GRAPH,REMOTE

[47] ? " " " ? ? ? "/ /" /" ?[77] "/ "/" " " " "/" ? /" ? "/" ? BIND

[71] "/ "/ " " " "/" ? /" ? ? ?[15] ? ? " ? ? ? ? ? ? ? ?

SPARQL-to-Document

[3] ? "/ ? ? ? ? ? ? ? ? ?[86] "/ "/" " " " "/" ? /" ? "/" "/

[54] ? % % ? % ? ? ? ? ?[11] ? "/ % ? % ? ? ? ? ? ?

SPARQL-to-XPath/XQuery

[6, 7, 8, 9] "/" "/" " " " "/" " ? ? "/ "/" DELETE,INSERT

[26] "/" "/ " " " "/" ? ? ? ? ?[31] ? "/" " " " ? ? ? ? ? ?

Table

2:SPARQLfea

tures

supported

inSPARQL-to

-Xquery

transla

tions.

See

Table

1for"%?.Others

are

features

prov

ided

only

byindividualworks.

14

projections into the LFP operator (Simple Least Fixpoint). PPFS+ [29] mainly seeks to leverage RDBMSstorage of shredded XML data. Based on an empirical evaluation, nested loop join was chosen to apply mergequeries over the shredded XML. They try to improve query performance by generating pipelined plans reducingtime to ”first results”. To ensure XPath results follow the order of the original XML document and have as fewduplicates as possible, redundant orders (ORDER BY) are eliminated, and ordering operations are pushed downthe query plan tree. As a physical optimization, the article resorts to indexed file organization for the shreddedrelations. Even though [53] XTRON is schema-oblivious by nature, some schema/structural information isused to speed up query response. That is by encoding simple paths of XML elements into intervals of realnumbers using a specific algorithm (Reverse Arithmetic Encoder). The latter reduces the number of self-joinsin the generated SQL queries.

SQL-to-XPath/XQuery: ROX [34] suggests a cost-based optimization to generate optimal query plans,and physical indexes for quick node look-up; however, no details are given.

SPARQL-to-SQL: The method in [60] optimizes certain SQL query cases that negatively impact (some)RDBMSs. In particular, sub-query elimination and self-join elimination query rewriting techniques are applied.The former removes non-correlated subqueries from the query by pushing down projections and selections, thelatter removes self-joins occurring in the former queries. [23] implements an optimization technique called ”earlyproject simplification”, which skips variables that are not needed during query processing from the SELECT clause.In SparqlMap [87], filter expressions are pushed to the graph patters, and nested SQL queries are flattenedto minimize self-joins. In FSparql2Sql [47], the translation method may generate an abnormal SQL querywith a lot of CASE expressions and constants. The query is optimized by replacing complex expressions bysimpler ones, e.g., by manipulating different logical orders, or removing useless ones. The translation approachin Ultrawrap [77] is expected to generate a view of a very large union of many SELECT-FROM-WHEREstatements. To mitigate this, two strategies are applied: detection of unsatisfiable conditions, and self-joinelimination. The former detects whether a query would yield empty results, even before executing it, due to thepresence of contradictions e.g., WHERE predicate equals two opposite values; it also prunes unnecessary UNION

sub-tree, e.g., by removing an empty argument from the UNION, in case two attributes of the same table areprojected or filtered individually then joined. The generated SQL query in [71] may be sub-optimal due to thepresence of e.g., joins of UNION-subqueries, redundant joins with respect to keys, unsatisfiable conditions. Usingtechniques from Logical Programming, Partial evaluation is used to optimize Datalog rules dealing with ans

and triple atoms, by iteratively filtering out options that would not generate valid answers; Goal Derivationin Nested Atoms and Partial SDL-tree with JOIN and LEFT JOIN dealing with join atoms. Techniques fromSemantic Query Optimizations are applied to detect unsatisfiable queries, e.g., joins when equating two differentconstants, simplification of trivially satisfiable conditions like x = x. The generated query in [15] is optimizedusing simplifications, e.g., removing redundant projections that do not contribute to a join or conditions insubqueries, removing True values from some conditions, reducing join conditions based on logical evaluations,omitting left outer joins in case of SPARQL UNION when union’ed relations have identical schema, pushing downprojection into SELECT subqueries, etc.

SPARQL-to-Document: Query optimization in D-SPARQ [54] is based on a ”divide and conquer”-likeprinciple. It groups triple patterns into independent blocks of triples, which can run more efficiently in parallel.For example, a star-shaped pattern groups are considered as indivisible blocks. Within one star pattern group,for each predicate triple patterns are ordered by number of triples involving that predicate. This boosts queryprocessing by reducing the selectivity of the individual patter groups. In the relational-based OBDA of [11], theintermediate relational query is simplified by applying structural optimization, e.g., replacing join of unions byunion of joins, and semantic optimization, e.g., redundant self-join elimination. In [52], the generated MongoDBquery is optimized by pushing filters to the level of triple patters, and by self-join elimination through mergingatomic queries that share the same FROM part, and by self-union elimination through merging UNIONs of atomicqueries that share the same FROM part.

Cypher-to-SQL: Cyp2sql [13] stores graph data following a specific tables scheme, which is designedto optimize specific queries. For example, Label table is created to overcome the problem of prevalent NULL

15

Work One-to-one One-to-manySQL-to-XPath/XQuery:

[34] ROX "

SPARQL-to-SQL:

[40] Type-ARQuE "

[47] FSparql2Sql "

SQL-to-SPARQL:

[66, 67] R2D SQL-to-SPARQL: "

SQL-to-Document-based:

[64] QueryMongo "

Gremlin-to-SQL:

[82] SQLGraph "

Table 3: Query Translation relationship.values in the Nodes table. Query translator decides, on query-time, which relationship to use to obtain nodeinformation. Relationship data is stored in the Edges table (storing all relationships) as well as in their separatetables (duplicate). Further optimization is gained from using a couple of metafiles populated during schemaconversion, e.g., a nodes property list per label type used to narrow down the search for nodes.

SPARQL-to-XPath/XQuery: In [31], a logical optimization is applied to the operator tree in order togenerate a reorganized equivalent tree with faster translation time (no more details given). Next, a physicaloptimization aims to find the algorithm that implements the operator with the best estimated performance.

Gremlin-to-SQL SQLGraph [82] proposes a translation optimization whereby a sequence of the nonselective pipe g.V (retrieve all vertices in g) or g.E (retrieve all edges in g) are replaced by a sequence ofattribute-based filter pipes (filter pipes that select graph elements based on specific values). For example, thenon selective first pipe g.V is explicitly merged with the more selective filter filterit.tag == ’w’ in thetranslation. For the query evaluation, optimization strategies of the RDBMS are leveraged.

4. Translation relationship

This information is not always explicitly stated, and we cannot make assumptions based on the architectures orthe algorithms, so we only report when there is a clear statement about the type of relationship. Informationis collected in Table 3.

III. Community Factors

For a better readability and structuring, we collect the information in Table 4. The last column rates thecommunity effect using stars (8), which are to be interpreted as follows. 8: ‘Implemented’,88: ‘Implemented

and Evaluated’ or ‘Implemented and Available (for download)’, ‘888: ‘Implemented, Evaluated and Available(for download)’.

Discussions and Conclusion

Weakly addressed paths. Although one would presume that SQL-to-Document-based translation is a well-supported path given the popularity of SQL and document databases, there is still a modest literature in thisregard. Most of the efforts provide marginal contributions in addition to the more general SQL-to-NoSQLtranslation. Furthermore, the translation of this path in all cases is far from being complete, and does notfollow the systematic methodology observed by other efforts in this study. Some of these works are [20, 45, 76].Similarly, despite the popularity of SQL and Gremlin, the Gremlin-to-SQL translation has also attracted littleattention. That may be due to the large difference in the semantics of the Gremlin graph traversal modeland SQL’s relational model. In general, the work on translating between SQL and MongoDB and Gremlin

16

Paper/tool YFR YLR nR nC Implementation Reference Community

XPath/XQuery-to-SQL

[43] 57 8

[24] 2005 37 88

[49] 2006 1 88

[29] PPFS+ 40 88

[37] 5 88

[53] XTRON 23 88

SQL-to-XPath/XQuery

[89, 90] 1, 5

[38] AquaLogic 2006 2008 22 Acquired by Oracle and merged in its products 88

[34] 65 88

SPARQL-to-SQL

[80] Sparqlify 2013 2018 30 2 https://github.com/SmartDataAnalytics/Sparqlify 888

[40] Type-ARQuE 2010 6 http://www.cs.hut.fi/~skiminki/type-arque/index.html 88

[60] Morph translator 2014 2018 37 74 Part of Morph-RDB: https://github.com/oeg-upm/morph-rdb 888

[15] 151 88

[47] 28 88

[23] 78 888

[87] SPARQLMap 22 888

[77] Ultrawrap 99 https://capsenta.com/ultrawrap 88

[71] 52 Part of Ontop: https://github.com/ontop/ontop 88

SQL-to-SPARQL

[66, 67] R2D 19, 15 88

[65] 14

SQL-to-Document-based

[64] Query Mongo

[69] MongoDB Transla-tor

8

[88] UnityJDBC 8

SPARQL-to-Document-based

[54] D-SPARQ 11 88

[86] SparqlMap-M 2015 2017 12 2 https://github.com/tomatophantastico/sparqlmap 888

[11] 19 Extends Ontop but no reference found 8

[3] OntoMongo 2017 1 https://github.com/thdaraujo/onto-mongo 88

[52] 2014 2015 6 5 https://github.com/frmichel/morph-xr2rml/tree/query_rewrite 88

Cypher-to-SQL

[81] Cytosm 2017 1 2 https://github.com/cytosm/cytosm 888

[13] Cyp2sql 2017 2017 1 https://github.com/DTG-FRESCO/cyp2sql 88

Gremlin-to-SQL

[82] SQLGraph 2015 44 88

SQL-to-Gremlin

[92] SQL-Gremlin 2015 2016 1 https://github.com/twilmes/sql-gremlin 8

SPARQL-to-XPath/XQuery

[6, 7, 9]SPARQL2XQuery

29, 11, 21 http://www.dblab.ntua.gr/~bikakis/SPARQL2XQuery.html 888

[31] 45 88

[26] XQL2Xquery 6 88

XPath/XQuery-to-SPARQL

[21] 21 88

SPARQL-to-Gremlin

[84, 85] Gremlinator 2018 6 https://github.com/apache/tinkerpop/tree/master/sparql-gremlin 888

Table 4: Community Factors. YFR year of first release, YLR year of last release, nR number of releases, nC

number of citations (from Google Scholar). If nR = 1 it is the first release and last release is last update.

17

languages is still in an relatively early stage, partially because of the lack of a strong formal foundation of thesemantics and complexity of MongoDB’s document language as well as Gremlin. On the other hand, the pathXPath/XQuery-to-SPARQL has much fewer works than its reverse. This is possibly because SPARQL is morefrequently used for solving integration problems as part of the OBDA framework, which involves translatingvarious queries into SPARQL.

Missing paths. We have not found any articles or software/tools for the following paths SQL-to-Cypher,Gremlin-to-SPARQL, XPath/XQuery-to-Cypher and vice versa, XPath/XQuery-to-Gremlin and vice versa,Cypher-to-Document-based and vice versa. We see opportunities in tackling those translation paths with ratio-nals similar to those of the previously tackled translation paths. For example, although SPARQL and Gremlinfundamentally differ in their approaches to query graph data, one based on graph pattern matching one ongraph traversals, they are both graph query languages. A transition from one to the other not only allows theinteroperability between systems supporting those languages, but also makes data from one world available tothe other without requiring to learn the other respective query language [2]. Similarly, XML languages have arooted notion of traversals, a conversion to and from Gremlin is natural. In fact, according to [46], the earlyprototype of Gremlin used XPath for querying graph data.

Gaps and Lessons Learned. The survey has also allowed us to identify gaps and learn lessons, which wesummarize in the following points:

• We noticed that the optimizations that are applied during the query translation process have more po-tential to improve the overall translation performance than the optimization applied on the generatedquery. This is because at query translation-time, optimizations from the system of the original query, e.g.,statistics, can be leveraged to impact the resulted target query. This opportunity is not present once thequery in the target language has been generated.

• Looking at the language scope coverage, there seems to still be a lack in covering the more sophisticatedoperations of query languages, e.g., more join types and temporal functions in SQL; blank nodes, groupingand binding in SPARQL. Such functions are motivated by and are at the core of many modern analyticaland real-time applications. Indeed, some of those features are newly-introduced and some of the needs areonly recently exposed, in which case we make the call to both update the existing works and build newsolutions to embrace the new features and address the new needs.

• Certain works present a well-founded and defined query translation frameworks, from the query translationprocess to the various optimization strategies. However, the example queries effectively worked on aresimple and would hardly represent real-world queries. Use-case-driven translation methods would be morehelpful to reveal the useful query patterns and fragments, and to evaluate the translation methods andoptimizations on real-world data.

• There is a wide variety in the evaluation frameworks used by each of the query translation methods.Following a unique standardized benchmark specialized in evaluating and assessing query translationaspects is paramount. Such a dedicated benchmark unfortunately does not exist at the time of writing.

Candidates for a ’universal’ query language. After discovering and exploring the various query transla-tion methods, it appears that SQL and SPARQL are the most suitable languages to act as a ’universal’ languagefor realizing the heterogeneous data integration. They both have the most number of translations to other lan-guages (see outgoing edges in Figure 1). SQL is the oldest query language with ever-continued developmentcycles and adoption. SPARQL is the stable query language of the so-called ontology-based data integration andaccess, which specializes specifically in integrating data coming from heterogeneous sources.

Query Translation History. We project the surveyed works into a vertical timeline shown in Table 5. Thevisualization allows us to draw some remarks. SPARQL was very quickly recognized by the community, asworks translating to and from SPARQL started to emerge the same year it was suggested. We cannot makea similar judgment about the adoption of SQL, XPath and XQuery as they were introduced earlier than thetimeframe we consider in this study, 2003-2019. Works on translating to and from SPARQL have continued toattract research efforts to date. Works translating to and from SQL is present in all the years of the timeline,except 2013. With less regularity, works translating to and from XML languages have also been continually

18

1974 · · ·• Chamberlin and Boyce. SQL introduced.

2002 · · ·• Boag et al.. XQuery introduced.

2003 · · ·• Berglund et al.. XPath introduced.

2004 · · ·•Halverson et al. ROX[42, 43].

SQL-to-XPath/XQueryXPath/XQuery-to-SQL.

2005 · · ·• Fan et al.. XPath-to-SQL.

2006 · · ·• Mani et al.. XQuery-to-SQL.

2007 · · ·•Droop et al.Georgiadis and Vassalos.

XPath/XQuery-to-SPARQLXPath/XQuery-to-SQL.

2008 · · ·•

PrudhommeauxHu and ChenLu et al.Min et al. XTRON.

SPARQL introducedXML-to-SQLSPARQL-to-SQLXQuery-to-SQL.

2009 · · ·•

Fan et al.Vidhya and SamuelElliott et al.Bikakis et al., Bikakis et al.Ramanujam et al..

XPath-to-SQLSQL-to-XPathSPARQL-to-SQLSPARQL-to-XQuerySQL-to-SPARQL.

2010 · · ·•Vidhya and SamuelKiminki et al. Type-ARQuE.

SQL-to-XQuerySPARQL-to-SQL.

2011 · · ·•

Das R2RMLAtay and ChebotkoFischer et al.Rachapalli et al. RETRO.

SQL-to-SPARQLXML-to-SQLSQL- and SPARQL-to-XQuerySQL-to-SPARQL.

2012 · · ·•Rodrıguez-Muro et al. QuestUnbehauen et al.SPARQLMap.

SPARQL-to-SQLSPARQL-to-SQL.

2013 · · ·•dos Santos Ferreira et al.Sequeda and MirankerUltrawrap.

SQL-to-Document basedSPARQL-to-SQL.

2014 · · ·•Bikakis et al.Priyatna et al. MorphLawrence.

SPARQL-to-XQuerySPARQL-to-SQLSQL-to-Document-based.

2015 · · ·•Sun et al. SQLGraphBikakis et al..

Gremlin-to-SQLSPARQL-to-XQuery.

2016 · · ·•Unbehauen and MartinSparqlMap-M.

SQL-to-Document-based.

2017 · · ·• Steer et al. Cytosm. Cypher-to-SQL.

2018 · · ·•Thakkar et al., Thakkar et al.Gremlinator.

SPARQL-to-Gremlin.

Table 5: Timeline recording publication years of the considered query languages and methods.

19

published. Despite their latest updates in 2017, we have not found any works (at least complying with ourcriteria) published since 2015.

In this article, we have surveyed more than forty articles and tools around query translation between sevenpopular query languages. Although organizing the information was a complicated and sensitive task, the studyallowed us to extract eight common criteria according to which we categorized the surveyed works. It alsoallowed us to discover which translation paths are not sufficiently addressed and which ones are not addressedyet, as well as to observe gaps and learn lessons for future research on the topic. We hope that reporting thisknowledge opens new doors for research and development on the topic of query translation, and serves usersof applications like polyglot persistence and data lakes to exploit more data value by tackling the data varietyissue.

References

[1] Renzo Angles, Marcelo Arenas, Pablo Barcelo, Aidan Hogan, Juan Reutter, and Domagoj Vrgoc. Foun-dations of modern query languages for graph databases. ACM Computing Surveys (CSUR), 50(5):68,2017.

[2] Renzo Angles, Harsh Thakkar, and Dominik Tomaszuk. RDF and Property Graphs Interoper-ability: Status and Issues. In Proceedings of the 13th Alberto Mendelzon International Work-shop on Foundations of Data Management, Asuncion, Paraguay, June 3-7, 2019., 2019. URLhttp://ceur-ws.org/Vol-2369/paper01.pdf.

[3] Thiago Henrique Dias Araujo, Barbara Tieko Agena, Kelly Rosa Braghetto, and Renata Wassermann.Ontomongo- ontology-based data access for nosql. In Mara Abel, Sandro Rama Fiorini, and Christiano Pes-sanha, editors, ONTOBRAS, volume 1908 of CEUR Workshop Proceedings, pages 55–66. CEUR-WS.org,2017. URL http://dblp.uni-trier.de/db/conf/ontobras/ontobras2017.html#AraujoABW17.

[4] Mustafa Atay and Artem Chebotko. Schema-based xml-to-sql query translation using interval encoding.In Information Technology: New Generations (ITNG), 2011 Eighth International Conference on, pages84–89. IEEE, 2011.

[5] Anders Berglund, Scott Boag, Don Chamberlin, Mary F Fernandez, Michael Kay, Jonathan Robie, andJerome Simeon. Xml path language (xpath). World Wide Web Consortium (W3C), 2003.

[6] Nikos Bikakis, Nektarios Gioldasis, Chrisa Tsinaraki, and Stavros Christodoulakis. Querying xml datawith sparql. In International Conference on Database and Expert Systems Applications, pages 372–381.Springer, 2009.

[7] Nikos Bikakis, Nektarios Gioldasis, Chrisa Tsinaraki, and Stavros Christodoulakis. Semantic based accessover xml data. In World Summit on Knowledge Society, pages 259–267. Springer, 2009.

[8] Nikos Bikakis, Chrisa Tsinaraki, Ioannis Stavrakantonakis, and Stavros Christodoulakis. Supporting sparqlupdate queries in rdf-xml integration. arXiv preprint arXiv:1408.2800, 2014.

[9] Nikos Bikakis, Chrisa Tsinaraki, Ioannis Stavrakantonakis, Nektarios Gioldasis, and StavrosChristodoulakis. The sparql2xquery interoperability framework. World Wide Web, 18(2):403–490, 2015.

[10] Scott Boag, Don Chamberlin, Mary F Fernandez, Daniela Florescu, Jonathan Robie, Jerome Simeon, andMugur Stefanescu. Xquery 1.0: An xml query language. 2002.

[11] Elena Botoeva, Diego Calvanese, Benjamin Cogrel, Martin Rezk, and Guohui Xiao. Obda beyond relationaldbs: A study for mongodb. CEUR Workshop Proceedings, 2016.

[12] Tim Bray, Jean Paoli, C Michael Sperberg-McQueen, Eve Maler, and Francois Yergeau. Extensible markuplanguage (xml). World Wide Web Journal, 2(4):27–66, 1997.

[13] Lucian Carata. Cyp2sql: Cypher to sql translation, 2017. URLhttps://github.com/DTG-FRESCO/cyp2sql. Accessed: 06-08-2019.

20

[14] Donald D Chamberlin and Raymond F Boyce. Sequel: A structured english query language. In Proceedingsof the 1974 ACM SIGFIDET (now SIGMOD) workshop on Data description, access and control, pages249–264. ACM, 1974.

[15] Artem Chebotko, Shiyong Lu, Hasan M. Jamil, and Farshad Fotouhi. Semantics preserving sparql-to-sqlquery translation for optional graph patterns. Technical report, 2006.

[16] James Clark, Steve DeRose, et al. Xml path language (xpath) version 1.0, 1999.

[17] Edgar F Codd. A relational model of data for large shared data banks. Communications of the ACM, 13(6):377–387, 1970.

[18] Souripriya Das. R2rml: Rdb to rdf mapping language. http://www. w3. org/TR/r2rml/, 2011.

[19] James Dixon. Pentaho, Hadoop, and Data Lakes, 2010. URLhttps://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes. Online; ac-cessed 27-January-2019.

[20] Gabriel dos Santos Ferreira, Andre Calil, and Ronaldo dos Santos Mello. On providing ddl support for arelational layer over a document nosql database. In Proceedings of International Conference on InformationIntegration and Web-based Applications & Services, page 125. ACM, 2013.

[21] Matthias Droop, Markus Flarer, Jinghua Groppe, Sven Groppe, Volker Linnemann, Jakob Pinggera, FlorianSantner, Michael Schier, Felix Schopf, Hannes Staffler, et al. Translating xpath queries into sparql queries.In OTM Confederated International Conferences” On the Move to Meaningful Internet Systems”, pages9–10. Springer, 2007.

[22] Michael Dyck, J Robie, J Snelson, and D Chamberlin. Xml path language (xpath) 3.1, 2017. URLhttps://www.w3.org/TR/xpath-31/. Accessed: 06-08-2019.

[23] Brendan Elliott, En Cheng, Chimezie Thomas-Ogbuji, and Z Meral Ozsoyoglu. A complete translationfrom sparql into efficient sql. In Proceedings of the 2009 International Database Engineering & ApplicationsSymposium, pages 31–42. ACM, 2009.

[24] Wenfei Fan, Jeffrey Xu Yu, Hongjun Lu, Jianhua Lu, and Rajeev Rastogi. Query translation from xpathto sql in the presence of recursive dtds. In Proceedings of the 31st international conference on Very largedata bases, pages 337–348. VLDB Endowment, 2005.

[25] Wenfei Fan, Jeffrey Xu Yu, Jianzhong Li, Bolin Ding, and Lu Qin. Query translation from xpath to sql inthe presence of recursive dtds. The VLDB Journal, 18(4):857–883, 2009.

[26] Peter M Fischer, Dana Florescu, Martin Kaufmann, and Donald Kossmann. Translating sparql and sql toxquery. XML Prague, pages 81–98, 2011.

[27] Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault,Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andres Taylor. Cypher: An evolving query languagefor property graphs. In Proceedings of the 2018 International Conference on Management of Data, pages1433–1445. ACM, 2018.

[28] Paul Gearon, Alexandre Passant, and Axel Polleres. Sparql 1.1 update. W3C recommendation, 21, 2013.

[29] Haris Georgiadis and Vasilis Vassalos. Xpath on steroids: exploiting relational engines for xpath perfor-mance. In Proceedings of the 2007 ACM SIGMOD international conference on Management of data, pages317–328. ACM, 2007.

[30] Alastair Green, Martin Junghanns, Max Kiessling, Tobias Lindaaker, Stefan Plantikow, and Petra Selmer.opencypher: New directions in property graph querying. 2018.

21

[31] Sven Groppe, Jinghua Groppe, Volker Linnemann, Dirk Kukulenz, Nils Hoeller, and Christoph Reinke.Embedding sparql into xquery/xslt. In Proceedings of the 2008 ACM symposium on Applied computing,pages 2271–2278. ACM, 2008.

[32] W3C SPARQL Working Group et al. SPARQL 1.1 overview. W3C Recommendation. W3C, 2013.http://www.w3.org/TR/sparql11-overview/.

[33] Peter Gulutzan and Trudy Pelzer. SQL-99 complete, really. R & D Books, 1999.

[34] Alan Halverson, Vanja Josifovski, Guy Lohman, Hamid Pirahesh, and Mathias Morschel. Rox: relationalover xml. In Proceedings of the Thirtieth international conference on Very large data bases-Volume 30,pages 264–275. VLDB Endowment, 2004.

[35] Michael Hausenblas, Robert Grossman, Andreas Harth, and Philippe Cudre-Mauroux. Large-scale linkeddata processing-cloud computing to the rescue?. CLOSER, 20(2):246–251, 2012.

[36] Jayavel Shanmugasundaram Kristin Tufte Gang He and Chun Zhang David DeWitt Jeffrey Naughton.Relational databases for querying xml documents: Limitations and opportunities. Very Large Data Bases:Proceedings, 25:302, 1999.

[37] Tian-lei Hu and Gang Chen. Adaptive xml to relational mapping: an integrated approach. Journal ofZhejiang University-SCIENCE A, 9(6):758–769, 2008.

[38] Sunil Jigyasu, Sujeet Banerjee, Vinayak Borkar, Michael Carey, Kanad Dixit, Anil Malkani, and SachinThatte. Sql to xquery translation in the aqualogic data services platform. In Data Engineering, 2006.ICDE’06. Proceedings of the 22nd International Conference on, pages 97–97. IEEE, 2006.

[39] Josh Spiegel Jonathan Robie, Michael Dyck. Xquery 3.1: An xml query language, 2017. URLhttps://www.w3.org/TR/xquery-31/. Accessed: 06-08-2019.

[40] Sami Kiminki, Jussi Knuuttila, and Vesa Hirvisalo. Sparql to sql translation based on an intermediatequery language. In The 6th International Workshop on Scalable Semantic Web Knowledge Base Systems(SSWS2010), page 32, 2010.

[41] Rajasekar Krishnamurthy, Raghav Kaushik, and Jeffrey F Naughton. Xml-to-sql query translation liter-ature: The state of the art and open problems. In International XML Database Symposium, pages 1–18.Springer, 2003.

[42] Rajasekar Krishnamurthy, Venkatesan T Chakaravarthy, Raghav Kaushik, and Jeffrey F Naughton. Re-cursive xml schemas, recursive xml queries, and relational storage: Xml-to-sql query translation. In null,page 42. IEEE, 2004.

[43] Rajasekar Krishnamurthy, Raghav Kaushik, and Jeffrey F Naughton. Efficient xml-to-sql query translation:Where to add the intelligence? In Proceedings of the Thirtieth international conference on Very large databases-Volume 30, pages 144–155. VLDB Endowment, 2004.

[44] Doug Laney. Deja vvvu: others claiming gartners construct for big data. Gartner Blog, Jan, 14, 2012.

[45] Ramon Lawrence. Integration and virtualization of relational sql and nosql systems including mysql andmongodb. In Computational Science and Computational Intelligence (CSCI), 2014 International Confer-ence on, volume 1, pages 285–290. IEEE, 2014.

[46] Tobias Lindaaker. An overview of the recent history of graph query languages, 2018.

[47] Jing Lu, Feng Cao, Li Ma, Yong Yu, and Yue Pan. An effective sparql support over relational databases.In Semantic web, ontologies and databases, pages 57–76. Springer, 2008.

[48] Alaa Mahmoud. No more joins: An overview of graph database query language, 2017. URLhttps://developer.ibm.com/dwblog/2017/overview-graph-database-query-languages/. Accessed:06-08-2019.

22

[49] Murali Mani, Song Wang, Dan Dougherty, and Elke A Rundensteiner. Join minimization in xml-to-sqltranslation: an algebraic approach. ACM SIGMOD Record, 35(1):20–25, 2006.

[50] Sergey Melnik. Storing rdf in a relational database, 2001.

[51] Franck Michel, Johan Montagnat, and Catherine Faron Zucker. A survey of RDB to RDF translationapproaches and tools. PhD thesis, I3S, 2014.

[52] Franck Michel, Catherine Faron Zucker, and Johan Montagnat. A generic mapping-based query transla-tion from sparql to various target database query languages. In 12th International Conference on WebInformation Systems and Technologies (WEBIST’16), 2016.

[53] Jun-Ki Min, Chun-Hee Lee, and Chin-Wan Chung. Xtron: An xml data management system using rela-tional databases. Information and Software Technology, 50(5):462–479, 2008.

[54] Raghava Mutharaju, Sherif Sakr, Alessandra Sala, and Pascal Hitzler. D-sparq: distributed, scalable andefficient rdf query engine. 2013.

[55] Natalya F Noy. Semantic integration: a survey of ontology-based approaches. ACM Sigmod Record, 33(4):65–70, 2004.

[56] Jorge Perez, Marcelo Arenas, and Claudio Gutierrez. Semantics and complexity of sparql. In Internationalsemantic web conference, pages 30–43. Springer, 2006.

[57] Jorge Perez, Marcelo Arenas, and Claudio Gutierrez. Semantics and complexity of sparql. ACM Transac-tions on Database Systems (TODS), 34(3):16, 2009.

[58] Antonella Poggi, Domenico Lembo, Diego Calvanese, Giuseppe De Giacomo, Maurizio Lenzerini, andRiccardo Rosati. Linking data to ontologies. In Journal on data semantics X, pages 133–173. Springer,2008.

[59] Axel Polleres and Johannes Peter Wallner. On the relation between sparql1. 1 and answer set programming.Journal of Applied Non-Classical Logics, 23(1-2):159–212, 2013.

[60] Freddy Priyatna, Oscar Corcho, and Juan Sequeda. Formalisation and experiences of r2rml-based sparqlto sql query translation using morph. In Proceedings of the 23rd international conference on World wideweb, pages 479–490. ACM, 2014.

[61] Eric Prudhommeaux. Sparql query language for rdf. http://www. w3. org/TR/rdf-sparql-query/, 2008.

[62] Eric Prudhommeaux. Optimal rdf access to relational databases, 2004.

[63] Eric PrudHommeaux, Andy Seaborne, et al. SPARQL query language for RDF. W3C recommendation,15, 2008. www.w3.org/TR/rdf-sparql-query/.

[64] QueryMongo. Query mongo: Mysql to mongodb query translator, 2019. URLhttp://www.querymongo.com. Accessed: 06-08-2019.

[65] Jyothsna Rachapalli, Vaibhav Khadilkar, Murat Kantarcioglu, and Bhavani Thuraisingham. Retro: aframework for semantics preserving sql-to-sparql translation. The University of Texas at Dallas, 800:75080–3021, 2011.

[66] Sunitha Ramanujam, Anubha Gupta, Latifur Khan, Steven Seida, and Bhavani Thuraisingham. R2d: Abridge between the semantic web and relational visualization tools. In 2009 IEEE International Conferenceon Semantic Computing, pages 303–311. IEEE, 2009.

[67] Sunitha Ramanujam, Anubha Gupta, Latifur Khan, Steven Seida, and Bhavani Thuraisingham. R2d:Extracting relational structure from rdf stores. In Proceedings of the 2009 IEEE/WIC/ACM InternationalJoint Conference on Web Intelligence and Intelligent Agent Technology-Volume 01, pages 361–366. IEEEComputer Society, 2009.

23

[68] DB-Engines Ranking. Db-engines ranking, 2019. URL https://db-engines.com/en/ranking. Accessed:06-08-2019.

[69] Ramesh Reddy. Mongodb translator - teiid 9.0 (draft), 2015. URLhttps://docs.jboss.org/author/display/TEIID/MongoDB+Translator. Accessed: 06-08-2019.

[70] Marko A Rodriguez. The gremlin graph traversal machine and language (invited talk). In Proceedings ofthe 15th Symposium on Database Programming Languages, pages 1–10. ACM, 2015.

[71] Mariano Rodriguez-Muro and Martn Rezk. Efficient sparql-to-sql with r2rml mappings. J. Web Sem., 33:141–169, 2015. URL http://dblp.uni-trier.de/db/journals/ws/ws33.html#Rodriguez-MuroR15.

[72] Mariano Rodrıguez-Muro, Josef Hardi, and Diego Calvanese. Quest: efficient sparql-to-sql for rdf and owl.In 11th International Semantic Web Conference ISWC, page 53. Citeseer, 2012.

[73] Vincent Russell. sql-to-mongo-db-query-converter, 2016. URL https://github.com/vincentrussell/sql-to-mongo-db-query-converter.Accessed: 15-10-2018.

[74] Pramod J Sadalage and Martin Fowler. NoSQL distilled: a brief guide to the emerging world of polyglotpersistence. Pearson Education, 2013.

[75] Satya S Sahoo, Wolfgang Halb, Sebastian Hellmann, Kingsley Idehen, Ted Thibodeau Jr, Soren Auer, JuanSequeda, and Ahmed Ezzat. A survey of current approaches for mapping of relational databases to rdf.W3C RDB2RDF Incubator Group Report, 1:113–130, 2009.

[76] Geomar A Schreiner, Denio Duarte, and Ronaldo dos Santos Mello. Sqltokeynosql: a layer for relationalto key-based nosql database mapping. In Proceedings of the 17th International Conference on InformationIntegration and Web-based Applications & Services, page 74. ACM, 2015.

[77] Juan F Sequeda and Daniel P Miranker. Ultrawrap: Sparql execution on relational data. Web Semantics:Science, Services and Agents on the World Wide Web, 22:19–39, 2013.

[78] Dimitrios-Emmanuel Spanos, Periklis Stavrou, and Nikolas Mitrou. Bringing relational databases into thesemantic web: A survey. Semantic Web, 3(2):169–209, 2012.

[79] SQL2Gremlin. Sql2gremlin, 2018. URL http://sql2gremlin.com. Accessed: 06-08-2019.

[80] Claus Stadler, Jorg Unbehauen, Jens Lehmann, and Soren Auer. Connecting crowdsourced spatial infor-mation to the data web with sparqlify. Technical report, Technical Report, University of Leipzig, Leipzig,2013. Available at http://sparqlify.org/downloads/documents/2013-Sparqlify-Technical-Report.pdf, 2013.

[81] Benjamin A Steer, Alhamza Alnaimi, Marco ABFG Lotz, Felix Cuadrado, Luis M Vaquero, and JoanVarvenne. Cytosm: Declarative property graph queries without data migration. In Proceedings of the FifthInternational Workshop on Graph Data-management Experiences & Systems, page 4. ACM, 2017.

[82] Wen Sun, Achille Fokoue, Kavitha Srinivas, Anastasios Kementsietsidis, Gang Hu, and Guotong Xie.Sqlgraph: an efficient relational-based property graph store. In Proceedings of the 2015 ACM SIGMODInternational Conference on Management of Data, pages 1887–1901. ACM, 2015.

[83] Harsh Thakkar, Dharmen Punjani, Soren Auer, and Maria-Esther Vidal. Towards an Integrated GraphAlgebra for Graph Pattern Matching with Gremlin. In International Conference on Database and ExpertSystems Applications, pages 81–91. Springer, 2017.

[84] Harsh Thakkar, Dharmen Punjani, Yashwant Keswani, Jens Lehmann, and Soren Auer. A Stitch inTime Saves Nine–SPARQL Querying of Property Graphs using Gremlin Traversals. arXiv preprintarXiv:1801.02911, 2018.

[85] Harsh Thakkar, Dharmen Punjani, Jens Lehmann, and Soren Auer. Two for One: Querying Property GraphDatabases using SPARQL via Gremlinator. In Proceedings of the 1st ACM SIGMOD Joint InternationalWorkshop on Graph Data Management Experiences & Systems (GRADES) and Network Data Analytics(NDA), page 12. ACM, 2018.

24

[86] Jorg Unbehauen and Michael Martin. Executing sparql queries over mapped document stores withsparqlmap-m. In 12th International Conference on Semantic Systems Proceedings (SEMANTiCS 2016),SEMANTiCS ’16, Leipzig, Germany, September 2016.

[87] Jorg Unbehauen, Claus Stadler, and Soren Auer. Accessing relational data on the web with sparqlmap. InJoint International Semantic Technology Conference, pages 65–80. Springer, 2012.

[88] UnityJDBC. Unityjdbc - jdbc driver for mongodb, 2017. URLhttp://unityjdbc.com/mongojdbc/mongo_jdbc.php. Accessed: 06-08-2019.

[89] PM Vidhya and Philip Samuel. Query translation from sql to xpath. In Nature & Biologically InspiredComputing, 2009. NaBIC 2009. World Congress on, pages 1749–1752. IEEE, 2009.

[90] PM Vidhya and Philip Samuel. Insert queries in xml database. In Computer Science and InformationTechnology (ICCSIT), 2010 3rd IEEE International Conference on, volume 1, pages 9–13. IEEE, 2010.

[91] Neo4j Website. For relational database developers: A sql to cypher guide, 2019. URLhttps://neo4j.com/developer/guide-sql-to-cypher. Accessed: 06-08-2019.

[92] Ted Wilmes. Sql-gremlin, 2016. URL https://github.com/twilmes/sql-gremlin. Accessed: 06-08-2019.

25