# The Query Translation Landscape: a Survey

Mohamed Nadjib Mami  Enterprise Information Systems, Fraunhofer IAIS, St.
Augustin & Dresden, Germany  Damien Graux  ADAPT Centre, Trinity College of
Dublin, Ireland  Enterprise Information Systems, Fraunhofer IAIS, St. Augustin
& Dresden, Germany  Harsh Thakkar  Smart Data Analytics group, University of
Bonn, Germany  Simon Scerri  Enterprise Information Systems, Fraunhofer IAIS,
St. Augustin & Dresden, Germany  Sören Auer  TIB Leibniz Information Centre
for Science and Technology, Germany  L3S Research Center, Leibniz University
of Hannover, Germany  Jens Lehmann  Enterprise Information Systems, Fraunhofer
IAIS, St. Augustin & Dresden, Germany  Smart Data Analytics group, University
of Bonn, Germany

( October 2019 )

###### Abstract

Whereas the availability of data has seen a manyfold increase in past years,
its value can be only shown if the data variety is effectively tackled —one of
the prominent Big Data challenges. The lack of data interoperability limits
the potential of its collective use for novel applications. Achieving
interoperability through the full transformation and integration of diverse
data structures remains an ideal that is hard, if not impossible, to achieve.
Instead, methods that can simultaneously interpret different types of data
available in different data structures and formats have been explored. On the
other hand, many query languages have been 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 by enforcing physical data transformation, but by
looking at techniques that are able to query heterogeneous sources using one
uniform language. Both industry and research communities have been keen to
develop such techniques, which require the translation of a chosen ’universal’
query language to the various data model 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 suitable candidate for
that ’universal’ query language. Further, the results enable us to discover
the weakly addressed and unexplored translation paths, to discover gaps and to
learn lessons that can benefit future research in the 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 relational model [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 and used in an unprecedented
variety of storage and data management systems. In order to leverage the
advantages of these solutions, companies and institutions are choosing to
store their data in different representations, a phenomenon known as Polyglot
Persistence [74]. As a result, large data repositories with heterogeneous data
sources 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 historically been
the case with e.g., data warehouses, is nowadays becoming irrelevant. This is
because (1) data is very large in size (Big Data Volume), (2) companies are
less likely to sacrifice data freshness especially with the advances in
streaming and IoT technologies (Big Data Velocity).

On the other hand, while computer scientists were looking for the holy grail
of data representation and querying in the last decades, it is meanwhile
accepted that no optimal data storage and query paradigm exist. Instead,
different storage and query paradigms have different characteristics
especially in terms of representation and query expressivity and scalability.
Different approaches balance differently between expresivity and scalability
in this regard. While SQL, for example, comprises a sophisticated data
structuring and very expressive query language, NoSQL trades schema and query
expressivity for scalability. As a result, since no optimal representation
exists, different storage and query paradigms have their right to exist based
on the requirements of various usecases.

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

The topic covered in this survey, namely Query Translation, is horizontal to
and directly concerns many Computer Science domains, from Information
Retrieval, Databases, Data Integration, Data Analytics, Polyglot Persistence
to Data Publishing and Archiving. Thus, the topic can be of interest to a
broad audience; from as specific as researchers in Query Translation topics,
to as general as users who solely interact with an existing system 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. They typically tackle pair-wise translation methods between two
specific types of query languages, e.g., [41] surveys XML languages-to-SQL
query translations, [51, 78, 75] surveys SPARQL-to-SQL query translations.
However, to the best of our knowledge, no survey has tackled the problem of
universal translation across several query languages.

##### Contributions.

In this survey article we take a broader view over the query translation
landscape. We consider 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 represents an aspect of the translation method.

  * •

We review the translation methods that exist between the most popular query
languages, whereby popularity is judged based on a set of defined measures. We
then categorize them based on the defined criteria.

  * •

We provide a set of graphical representations of the various criteria in order
to facilitate information reading, 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 and document-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 query languages. Our
example query corresponds to the following natural language query: ”Find the
city of residence of all persons named Max”.

### Relational Query Languages

##### SQL

is the de facto relational query language first described in [14]. It has been
an ANSI/ISO standard since 1986/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 most popular; 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 [63, 32], latest of which is SPARQL 1.1 [28] 2013\. Research
articles on SPARQL foundations [56, 57, 61] are among the most cited across
all 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 OpenCypher project [30]. Cypher has been recently formally
described in a scientific article published [27]. At the time 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 predates Cypher. 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 query languages: Java, Groovy, Python, Scala, Clojure, PHP,
and JavaScript; and is integrated in more renowned data 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 ago and has been standardized in 2006 by W3C [12]; it is
used mainly for data exchange between applications. W3C recommended 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 [16, 5, 10] with the latest one 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 path expressions, 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

### Document Query Languages

The representative document database that we choose is MongoDB. MongoDB (first
released in 2009) is the document 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 rather
interacts 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 1 shows a visual representation, where the
nodes correspond to the considered query languages and the directed arrows
correspond to the translation direction; the thickness of the arrows reflects
the number of works on the respective query translation path.

### SQL $<>$ XML languages

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

##### XPath/XQuery-to-SQL:

XML documents have to be flattened, or shredded, into relations so they can be
loaded 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 are efforts 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 an SQL
interface to enable the querying of XML by SQL users. Metadata about how XML
data is mapped to the relational model is required.

### SQL $<>$ SPARQL

##### SPARQL-to-SQL:

Similarly to XML, the interest in bridging the gap between RDF data model and
the relational 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 Semantic Web community
suggested a well-received data integration proposal, whereby disparate
relational data sources are mapped to a unified ontology model and then
queried uniformly [62, 55]. The concept evolved to become the 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 were enhancing interoperability between the two worlds in general,
and enabling reusability of the wealth of existing relational-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 new class of NoSQL document databases with their
sole SQL knowledge.

##### SPARQL-to-Document:

The rational here is identical to that of SPARQL-to-SQL, with one extra
consideration: scalability. Native triple stores become prone to scalability
issues when storing and querying significant amounts of RDF data. Users
resorted to more scalable solutions to store and query the data [35]. The most
studied 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
mainly attempting 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 been advocated that using relational databases to store graph data
can be beneficial in certain cases, benefiting from the efficient index-based
retrieval RDBMSs offer.

##### Gremlin-to-SQL:

The aim here is to allow executing Gremlin traversals (without side effect
steps) on top of 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
databases in order to leverage the advantages of graph-based functions (e.g.,
depth-first search, shortest paths, etc.) and data 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 interoperability
environments between semantic and XML database systems, to enable ontology-
based data access to XML data, 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 top of RDF
data can be an interesting feature to equip native RDF stores with, in order
to embark adopters from the XML world into the Semantic Web world.

##### SPARQL-to-Gremlin:

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

SPARQLSQLXPathXQueryGremlinDocumentbasedCypher[66, 67, 65] [80, 40, 60, 15,
47, 23, 87, 77, 71] [9, 6, 7, 31, 26][21][43, 24, 49, 29, 37, 53][89, 90, 38,
34][84, 85][92][82][13, 81][64, 69, 88][54, 86, 11, 3, 52] Figure 1: Query
translation paths found and studied.

## Survey Methodology

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

### I. Translation Properties

  1. 1.

Translation type: Describes how the target query is obtained.

    1. (a)

Direct: the translation generates the destination query starting from and by
analyzing only the original query.

    2. (b)

Intermediate/meta query language-based: the translation generates the
destination query by passing by an intermediate (meta-)language.

    3. (c)

Storage scheme-aware: the translation generates queries depending on how data
is internally structured or partitioned.

    4. (d)

Schema information-aware: the translation depends mainly on the schema
information of the underlying data.

    5. (e)

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

  2. 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

  1. 3.

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

  2. 4.

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

### III. Community Factors

  1. 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 download page is still
available.

  2. 6.

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

  3. 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.

  4. 8.

Metadata: Provides some related information about the presented translation
method, such as date of first and last release/update. For example, this helps
to obtain an indication about whether the solution is 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 certain level 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 scope with little focus on the query translation aspects.

  * •

We only consider works proposed during the last fifteen years, i.e., after
2003. This applies in particular to XML-related translations; however,
interested readers may refer to an existing survey covering older XML
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 results of empirical evaluations of the individual works. This
is also due to the vast heterogeneity between the languages, their underlying
data and use-cases.

  * •

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

In the following, we refer to the articles and tools by citation and, when
applicable, by name, and directly describe the query translation methods they
present. Further, it should not be inferred that the article or tool presents
solely translation methods, but often, other aspects are also tackled, e.g.,
data migration, which are considered out-of-scope of the current study.
Finally, in order to give the survey a temporal context, works are listed 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 interface.
The method consists of creating relational views, called NICKNAMEs, over a
native XML store. The NICKNAME 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 between the corresponding NICKNAMEs. [90, 89] propose
a set of algorithms enabling direct logical translations of simple SQL INSERT,
UPDATE, DELETE and RENAME queries to statements in the XUpdate
language111XUpdate is an extension of XPath allowing to manipulate XML
documents.. In case of the INSERT, SQL query has to be slightly extended to
instruct in which position related to the context node, 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
triples matching a triple pattern are stored, (b) extract the relational
attribute whose value may match a given triple pattern 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 SQL projections (SELECT) given a triple pattern
and the latter three primitives. A translation function returns a SQL query by
fusing and building up the previous primitives given a graph pattern. The
translation function generates SQL joins from UNIONs and OPTIONALs between
sub-graph patters. FSparql2Sql [47] is an early work focusing on the various
cases of filter in SPARQL queries. While RDF objects can take many forms like
IRIs (Internationalized Resource Identifier), literals with and without
language and/or datatype tags, values stored in RDBMS are generally atomic
textual or numeral values. Therefore, the various cases of RDF objects are
affected primitive data types, called ’facets’, e.g., facets for IRIs,
datatype tags and language tags are of primitive type String. This way, filter
operands become complex, so they need to be bound dynamically. To achieve
that, CASE WHEN … THEN expressions part of SQL-92 are exploited. [23] proposes
several translation SQL model-algorithms implementing different operators of a
SPARQL query (algebra). In contrast to many existing 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., SPARQL operators gradually augment the SQL query instead
of creating a new nested one. The algorithms implement functions 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 and
generates an equivalent MongoDB query. The translation is based solely on SQL
query syntax, i.e., not considering any data or schema. No explanation about
the translation approach is provided. [73] is a library providing an 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 SPARQL embedded
inside XQuery. The method involves firstly representing SPARQL in form of tree
of operators. There are operators for projection, filtering, joining, optional
and union; they declare how the output (XQuery) of the 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-elements are created for each
triple for each triple term (s, p and o). The translation from an operator
into XQuery constructs is based on transformation rules, which replace the
embedded SPARQL constructs with XQuery constructs. 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], variables of the basic graph patter (BGP) are mapped to XQuery values. A
for loop and a path expression is used to retrieve subjects and bind any
variables encountered, then nested under every variable, iterate over the
predicates and bind their variables. In a similar way, nestedly iterate over
objects. Next, BGP constants and filters are mapped to XQuery where. OPTIONAL
is mapped to an XQuery function implementing a left outer join. For filters,
XQuery value comparison are employed (e.g., eq, neq). ORDER BY is mapped to
order by in a FLWOR expression. LIMIT and OFFSET are handled using position on
the results. REDUCED is translated into a NO-OP.

###### XPath/XQuery-to-SPARQL:

[21] presents a translation method that includes data transformation from XML
to RDF. During the data transformation process, XML nodes are annotated with
information used to support 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
generated RDF and are used to generate the final SPARQL query.

###### Gremlin-to-SQL

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

###### SPARQL-to-Gremlin:

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

##### (b) Intermediate/meta query language-based:

###### Type-ARQuE

[40] uses an intermediate query language called AQL, Abstract Query Language.
AQL is designed to stand between SQL and SPARQL, it extends from the
relational algebra (in particular the join) and accommodates both SQL and
SPARQL semantics. It is represented as a tree of expressions and joins between
them, containing selects and orders. The translation process consists of three
stages: (1) SPARQL query parsed and translated to AQL query, (2) AQL query
undergoes a series of transformations (simplification) preparing it for SQL
transformation, and (3) AQL query translated to the target SQL dialect,
transforming AQL join tree to SQL join tree, along the other selects and
orders expressions. Example of stage 2 simplifications: type inference, nested
join flattening, join inner joins with parents, etc. In [71], Datalog is used
as an intermediate language 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 variation
of 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. Datalog atoms, ans,
triple, Join, Filter, LeftJoin, are mapped to equivalent relational algebra
operators. ans and triple 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 showcase
using MongoDB. The article proposes to convert a SPARQL query to a pivot
intermediate query language called Abstract Query Language (AQL). The
translation uses a set of mappings in xR2RML mapping language, which describe
how data in target databases are mapped into RDF model, without converting
data to RDF. AQL has a grammar that is similar to SQL both syntactically and
semantically. The BGP part of a SPARQL query, is decomposed into a set of
expressions in AQL. Next, xR2RML mappings are checked for any maps matching
the containing triple patterns. Those detected matching maps are used to
translate individual triple patterns 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. The article
suggests a schema-oblivious way of storing and querying XML data. XML
documents are stored uniformly in identical relational tables using a fixed
predefined relational model. Generated queries then have to abide by this
fixed relational schema scheme.

###### SPARQL-to-Document:

D-SPARQ [54] focuses on the efficient processing of join operation between
triple 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 following the same.

###### Cypher-to-SQL:

Cyp2sql [13] is a tool for the automatic transformation of both data and
queries from Neo4j 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
are then 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
translation requires that the underlying graph data is given a relational
schema, where elements from the graph are mapped to 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 the effect of SQL queries using Gremlin
traversals. A pre-defined graph model is used during the translation; as an
example, Northwind relational data was loaded as a graph inside Gremlin.

##### (d) Schema information-aware:

###### XPath/XQuery-to-SQL:

[43] The process uses summary information on the relational integrity
constraints pre-computed in a pre-processing phase. An XML view is constructed
by mapping elements from the XML schema to elements from the relational
schema. The XML view is a tree where the nodes map to table names 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 shredded into relations based on
an XML schema (DTD) and saved in a RDBMS. The article extends XPath
expressions to allow capturing recursive queries against a recursive schema.
XPath queries with the extended expressions can, 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 top of RDF data. Schema elements are extracted from RDF schema; if schema
is missing or incomplete, schema information is extracted by thoroughly
exploring the data. r2d:TableMap, r2d:keyField, r2d:refersToTableMap denote a
relational table, its primary key, and foreign key, respectively. A relational
view is created using those schema 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 SPARQL SELECT. SQL WHERE conditions are added to SPARQL FILTER, LIKE
mapped to a regex(), and blank nodes 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 every extracted predicate, each table is composed of $<$subject
object$>$ attributes. Then, the translation algorithm parses 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 relational
form using tables, procedures, and functions. [88] provides a JDBC access to
MongoDB documents by building a representative schema, which is, in turn,
constructed by sampling MongoDB data and fitting the least-general type
representing the data.

###### SQL-to-XPath/XQuery:

AquaLogic Data Services Platform [38] builds an XML-based layer on top of
heterogeneous data sources and services. To allow SQL access to relational
data, relational schema is mapped 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
relational model is used as an intermediate model between SPARQL and MongoDB
queries. Notions of MongoDB type constrains (schema) and mapping assertions
are imposed on MongoDB data, both of which are used during the first phase of
query translation to create relational views. The schema is extracted from the
data stored in MongoDB. MongoDB mappings relate MongoDB paths (e.g.,
student.name) to ontology properties. A SPARQL query is first decomposed into
a set of translatable sub-queries. Using MongoDB mappings, MongoDB queries are
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 layer adopts 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 is
denoted by the variable of the shared subject. MongoDB query can be created by
mapping query classes to classes in the conceptual model, which then is used
to call MongoDB terms via the ODM. The lack of JOIN operation 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 mapping between graph query language and the
relational query language, mapping nodes to rows of tables, and edges to
either fields of rows or a sequence of table-join operations. Query
translation is twofold. (1) Using gTop abstract model, 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 require
information from the RDBMS, and if they inter-depend. Then, the mapping part
of gTop is used to map nodes to 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 [9, 6, 7]. The
translation is based on a mapping model between OWL ontology (existing or
user-defined) and XML Schema. Mappings can either be automatically extracted
by analyzing the ontology and XML schema, or manually curated by a domain
expert. SPARQL queries are posed against the ontology without knowledge of the
XML schema. The BGP (Basic Graph Pattern) of SPARQL query is normalized into a
form where each GP is UNION-free, so each GP can be processed independently
and more efficiently. XPaths are bound to GP variables, there are various
forms of binding for various types of variables. Next, GPs are translated into
an equivalent XQuery expression using the mappings; for each variable of a
triple, a For or Let clause using the variable binding is created. Ultrawrap
[77] implements an RDF2RDB mapping, allowing to execute SPARQL queries on top
of existing RDBMSs. It creates an RDF ontology from the SQL schema, based on
which it next creates a set of logical RDF views over the RDBMS. The views,
called Tripleviews, are an extension of the famous 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 only textual attributes, int —stores
only numeral attributes, and object properties —stores join links between DB
tables. 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
to extract R2RML triple maps. Methods are applied to find the candidate set of
triple maps, and then to prune this to produce a set that prepares for the
subsequent query translation. Given a SPARQL query, a recursive query
generation process is devised yielding a single but nested SQL query. Sub-
queries are created for individual mapped triple patterns and for reconciling
those via JOIN or UNION. Nested subqueries querying the RDBMS tables 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 intermediate language) to arbitrary
relational schema, R2RML is incorporated. For every R2RML triple map a set of
Datalog rules are generated reflecting the same semantics. A triple atom is
created for every combination of subject map, property map and object map on a
translated logical table. Finally, the translation process from Datalog to SQL
is extended to deal with the new rules introduced by R2RML mappings. [60]
extends a previously published translation method [15] to involve user-defined
R2RML mappings. In particular, it incorporates R2RML mappings in $\alpha$ and
$\beta$ mappings as well as genCondSQL(), genPRSQL() and trans() functions.
For each, an algorithm is devised, considering the various situations found in
R2RML mappings like the absence of Reference Object Map. SparqlMap-M [86]
enables querying document stores using SPARQL without RDF data
materialization. It is based on a previous SPARQL-to-SQL translator, SparqlMap
[87], so it adopts a relational model to virtually represent the data.
Documents are mapped to relations using an extension of R2RML 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 and reusing intermediate results. Selection
parts are pushed to the document store, while the union and join are executed
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 and from the online page of the implementations
(when available). For example, [77, 86] evaluate using all 12 BSBM benchmark
queries, which cover more scope than that of the article; the corresponding
Web page of [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 filters but only for equality condition. Interested users
are encouraged to seek details from the corresponding articles/tools.

  * •

Table 2 shows that some works [15, 3] support only one feature. This does not
necessarily imply insignificance, but reflects a choice to reserve the full
study to covering that particular feature, e.g., various shapes of 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 SQL to SPARQL
respectively. For SQL, the WHERE clause is an essential part of most useful
queries, hence, it is supported by all methods. GROUP BY is the next commonly
supported feature, as it enables a significant class of SQL queries:
analytical and aggregational queries. To a lower extent supported is the
sorting operation ORDER BY. UNION and especially JOIN are operations of
typically high cost; they are among the least supported features. 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 might also be attributed to their typical
expensiveness, e.g., DISTINCT requires sorting, and nested-queries generate
large 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 the most 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 by a 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 to SELECT, which is
present in all the works. isURI() and isLiteral() are SPARQL-specific
functions with no direct equivalent in other languages.

###### XPath/XQuery-to-SQL:

The queries [43] focuses on are simple path expressions, including descendent
axis traversal, i.e., //. [24] enables XPath recursive queries against a
recursive schema. [49] focuses on optimizing relational 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 with descendent/child axes with simple
conditions. [53] translates XQuery queries with path expressions including
decedent axis // XQuery queries, dereference operator $=>$ and FLWR
expressions.

###### XPath/XQuery-to-SPARQL:

[21] mentions support for recursive XPath queries, with descendent, following
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, ORDER BY,
LIMIT, SKIP, UNION, count(), collect(), exists(), label(), id(), and rich
pattern cases, e.g., (a or empty)–()–(b or empty), [a or empty]-[b]-(c or
empty), $->$ and $<-$, (a) $-->$ (b).

Work | DISTINCT |  |  WHERE/
---
REGEX
JOIN |  | UNION
---
| GROUP BY
---
/HAVING
ORDER BY |  |  LIMIT/
---
OFFSET
|  INSERT/
---
UPDATE
|  DELETE/
---
DROP
| Nested
---
queries
Others
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, math fncts
[73] | ? | ✔/✔ | ? | ? | ✔/ | ✔ | ? | ? | ✔/ | ? |  some Boolean filters
[91] | ? | ✔/ | ✔ | ? | ✔/ | ✔ | ? | ? | ? | ? |
SQL-to-Gremlin
[92] | ✔ | ✔/✔ | ? | ✔ | ✔/ | ✔ | ? | ? | ? | ✔ |

Table 1: SQL features supported in SQL-to-X query translations. ✔ is
supported, ✗ is not supported, ? not (clearly) mentioned supported. Others are
features provided only by individual works.

Work |  | DISTINCT
---
/REDUCED
|  FILTER/
---
regex()
OPTIONAL |  | UNION
---
ORDER BY |  |  LIMIT/
---
OFFSET
| Blank
---
nodes
| datatype()
---
/lang()
| isURI()
---
isLiteral()
| DESCRIBE
---
/bound()
| CONSTRUCT
---
/ASK
Others
SPARQL-to-SQL
[40] | ✔/ | ? | ? | ✔ | ✗ | ✔/ | ? | ? | ? | ? | ? |
[60] | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
[23] | ✔/ | ? | ✔ | ✔ | ✔ | ✔/ | ✔ | ✔/ | ✔ | ✔/ | ✔/✔ |  GRAPH, FROM NAMED, isBlank()
[87] |  ?/ | ? | ✔ | ? | ✔ | ? | ? | ? | ? | ? | ? |
[84, 85] | ✔/✗ | ✔/✔ | ✔ | ✔ | ✔ | ✔/✔ | ✔ | ? | ? | ✗/✗ | ✗/✗ |  GROUP BY, SUBGRAPH, REMOTE
[47] | ? | ✔ | ✔ | ✔ | ? | ? | ? | ✔/ | /✔ | /✔ | ? |
[77] | ✔/ | ✔/✔ | ✔ | ✔ | ✔ | ✔/✔ | ? | /✔ | ? | ✔/✔ | ? |  BIND
[71] | ✔/ | ✔/ | ✔ | ✔ | ✔ | ✔/✔ | ? | /✔ | ? | ? | ? |
[15] | ? | ? | ✔ | ? | ? | ? | ? | ? | ? | ? | ? |
SPARQL-to-Document
[3] | ? | ✔/ | ? | ? | ? | ? | ? | ? | ? | ? | ? |
[86] | ✔/ | ✔/✔ | ✔ | ✔ | ✔ | ✔/✔ | ? | /✔ | ? | ✔/✔ | ✔/ |
[54] | ? | ✗ | ✗ | ? | ✗ | ? | ? |  | ? | ? | ? |
[11] | ? | ✔/ | ✗ | ? | ✗ | ? | ? | ? | ? | ? | ? |
SPARQL-to-XPath/XQuery
[9, 6, 7, 8] | ✔/✔ | ✔/✔ | ✔ | ✔ | ✔ | ✔/✔ | ✔ | ? | ? | ✔/ | ✔/✔ |  DELETE, INSERT
[26] | ✔/✔ | ✔/ | ✔ | ✔ | ✔ | ✔/✔ | ? | ? | ? | ? | ? |
[31] | ? | ✔/✔ | ✔ | ✔ | ✔ | ? | ? | ? | ? | ? | ? |

Table 2: SPARQL features supported in SPARQL-to-X query translations. See
Table 1 for ✔ ✗ ?. Others are features provided only by individual works.

### 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 unnecessarily redundant joins in the relational
algebra of SQL queries resulted from the translation of XML queries. During
query translation, [24] suggests an algorithm leveraging the structure of XML
schema: pushing selections and projections into the LFP operator (Simple Least
Fixpoint). PPFS+ [29] mainly seeks to leverage RDBMS storage of shredded XML
data. Based on an empirical evaluation, nested loop join was chosen to apply
merge queries over the shredded XML. They try to improve query performance by
generating pipelined plans reducing time to ”first results”. To ensure XPath
results follow the order of the original XML document and have as few
duplicates as possible, redundant orders (ORDER BY) are eliminated, and
ordering operations are pushed down the query plan tree. As a physical
optimization, the article resorts to indexed file organization for the
shredded relations. Even though [53] XTRON is schema-oblivious by nature, some
schema/structural information is used to speed up query response. That is by
encoding simple paths of XML elements into intervals of real numbers using a
specific algorithm (Reverse Arithmetic Encoder). The latter reduces the number
of self-joins in 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, the
latter removes self-joins occurring in the former queries. [23] implements an
optimization technique called ”early project 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 flattened to minimize self-joins. In FSparql2Sql [47],
the translation method may generate an abnormal SQL query with a lot of CASE
expressions and constants. The query is optimized by replacing complex
expressions by simpler ones, e.g., by manipulating different logical orders,
or removing useless ones. The translation approach in Ultrawrap [77] is
expected to generate a view of a very large union of many SELECT-FROM-WHERE
statements. To mitigate this, two strategies are applied: detection of
unsatisfiable conditions, and self-join elimination. The former detects
whether a query would yield empty results, even before executing it, due to
the presence 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 are
projected or filtered individually then joined. The generated SQL query in
[71] may be sub-optimal due to the presence of e.g., joins of UNION-
subqueries, redundant joins with respect to keys, unsatisfiable conditions.
Using techniques 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 Derivation
in Nested Atoms and Partial SDL-tree with JOIN and LEFT JOIN dealing with join
atoms. Techniques from Semantic Query Optimizations are applied to detect
unsatisfiable queries, e.g., joins when equating two different constants,
simplification of trivially satisfiable conditions like $x=x$. The generated
query in [15] is optimized using simplifications, e.g., removing redundant
projections that do not contribute to a join or conditions in subqueries,
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 down projection into SELECT
subqueries, etc.

###### SPARQL-to-Document:

Query optimization in D-SPARQ [54] is based on a ”divide and conquer”-like
principle. 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 query processing by reducing the selectivity of
the individual patter groups. In the relational-based OBDA of [11], the
intermediate relational query is simplified by applying structural
optimization, e.g., replacing join of unions by union of joins, and semantic
optimization, e.g., redundant self-join elimination. In [52], the generated
MongoDB query is optimized by pushing filters to the level of triple patters,
and by self-join elimination through merging atomic queries that share the
same FROM part, and by self-union elimination through merging UNIONs of atomic
queries that share the same FROM part.

###### Cypher-to-SQL:

Cyp2sql [13] stores graph data following a specific tables scheme, which is
designed to optimize specific queries. For example, Label table is created to
overcome the problem of prevalent NULL values in the Nodes table. Query
translator decides, on query-time, which relationship to use to obtain node
information. Relationship data is stored in the Edges table (storing all
relationships) as well as in their separate tables (duplicate). Further
optimization is gained from using a couple of metafiles populated during
schema conversion, 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 to
generate a reorganized equivalent tree with faster translation time (no more
details given). Next, a physical optimization 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
non selective pipe g.V (retrieve all vertices in g) or g.E (retrieve all edges
in g) are replaced by a sequence of attribute-based filter pipes (filter pipes
that select graph elements based on specific values). For example, the non
selective first pipe g.V is explicitly merged with the more selective filter
filterit.tag == ’w’ in the translation. 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 or the algorithms, so we only report
when there is a clear statement about the type of relationship. Information is
collected in Table 3.

Work | One-to-one | One-to-many
---|---|---
SQL-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.

### III. Community Factors

For a better readability and structuring, we collect the information in Table
4. The last column rates the community effect using stars (★), which are to be
interpreted as follows. ★: ‘Implemented’, ★★: ‘Implemented and Evaluated’ or
‘Implemented and Available (for download)’, ‘★★★: ‘Implemented, Evaluated and
Available (for download)’.

Paper/tool | $\mathbf{Y_{FR}}$ | $\mathbf{Y_{LR}}$ | $\mathbf{n_{R}}$ | $\mathbf{n_{C}}$ | Implementation Reference | Community
---|---|---|---|---|---|---
XPath/XQuery-to-SQL
[43] |  |  |  | 57 |  | ★
[24] | 2005 |  |  | 37 |  | ★★
[49] | 2006 |  | 1 |  |  | ★★
[29] PPFS+ |  |  |  | 40 |  | ★★
[37] |  |  |  | 5 |  | ★★
[53] XTRON |  |  |  | 23 |  | ★★
SQL-to-XPath/XQuery
[89, 90] |  |  |  | 1, 5 |  |
[38] AquaLogic | 2006 | 2008 |  | 22 | Acquired by Oracle and merged in its products | ★★
[34] |  |  |  | 65 |  | ★★
SPARQL-to-SQL
[80] Sparqlify | 2013 | 2018 | 30 | 2 | https://github.com/SmartDataAnalytics/Sparqlify | ★★★
[40] Type-ARQuE |  | 2010 |  | 6 | http://www.cs.hut.fi/~skiminki/type-arque/index.html | ★★
[60] Morph translator | 2014 | 2018 | 37 | 74 |  Part of Morph-RDB: https://github.com/oeg-upm/morph-rdb | ★★★
[15] |  |  |  | 151 |  | ★★
[47] |  |  |  | 28 |  | ★★
[23] |  |  |  | 78 |  | ★★★
[87] SPARQLMap |  |  |  | 22 |  | ★★★
[77] Ultrawrap |  |  |  | 99 | https://capsenta.com/ultrawrap | ★★
[71] |  |  |  | 52 | Part of Ontop: https://github.com/ontop/ontop | ★★
SQL-to-SPARQL
[66, 67] R2D |  |  |  | 19, 15 |  | ★★
[65] |  |  |  | 14 |  |
SQL-to-Document-based
[64] Query Mongo |  |  |  |  |  |
[69] MongoDB Translator |  |  |  |  |  | ★
[88] UnityJDBC |  |  |  |  |  | ★
SPARQL-to-Document-based
[54] D-SPARQ |  |  |  | 11 |  | ★★
[86] SparqlMap-M | 2015 | 2017 | 12 | 2 | https://github.com/tomatophantastico/sparqlmap | ★★★
[11] |  |  |  | 19 | Extends Ontop but no reference found | ★
[3] OntoMongo |  | 2017 |  | 1 | https://github.com/thdaraujo/onto-mongo | ★★
[52] | 2014 | 2015 | 6 | 5 | https://github.com/frmichel/morph-xr2rml/tree/query_rewrite | ★★
Cypher-to-SQL
[81] Cytosm |  | 2017 | 1 | 2 | https://github.com/cytosm/cytosm | ★★★
[13] Cyp2sql | 2017 | 2017 |  | 1 | https://github.com/DTG-FRESCO/cyp2sql | ★★
Gremlin-to-SQL
[82] SQLGraph | 2015 |  |  | 44 |  | ★★
SQL-to-Gremlin
[92] SQL-Gremlin | 2015 | 2016 | 1 |  | https://github.com/twilmes/sql-gremlin | ★
SPARQL-to-XPath/XQuery
[9, 6, 7] SPARQL2XQuery |  |  |  | 29, 11, 21 | http://www.dblab.ntua.gr/~bikakis/SPARQL2XQuery.html | ★★★
[31] |  |  |  | 45 |  | ★★
[26] XQL2Xquery |  |  |  | 6 |  | ★★
XPath/XQuery-to-SPARQL
[21] |  |  |  | 21 |  | ★★
SPARQL-to-Gremlin
[84, 85] Gremlinator | 2018 |  |  | 6 | https://github.com/apache/tinkerpop/tree/master/sparql-gremlin | ★★★

Table 4: Community Factors. $\mathbf{Y_{FR}}$ year of first release,
$\mathbf{Y_{LR}}$ year of last release, $\mathbf{n_{R}}$ number of releases,
$\mathbf{n_{C}}$ number of citations (from Google Scholar). If
$\mathbf{n_{R}}=1$ it is the first release and last release is last update.

## 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 this regard. Most of the efforts provide marginal
contributions in addition to the more general SQL-to-NoSQL translation.
Furthermore, the translation of this path in all cases is far from being
complete, and does not follow the systematic methodology observed by other
efforts in this study. Some of these works are [20, 76, 45]. Similarly,
despite the popularity of SQL and Gremlin, the Gremlin-to-SQL translation has
also attracted little attention. That may be due to the large difference in
the semantics of the Gremlin graph traversal model and SQL’s relational model.
In general, the work on translating between SQL and MongoDB and Gremlin
languages is still in an relatively early stage, partially because of the lack
of a strong formal foundation of the semantics and complexity of MongoDB’s
document language as well as Gremlin. On the other hand, the path
XPath/XQuery-to-SPARQL has much fewer works than its reverse. This is possibly
because SPARQL is more frequently used for solving integration problems as
part of the OBDA framework, which involves translating various queries into
SPARQL.

1974 $\cdots$ $\bullet$ Chamberlin and Boyce.
SQL introduced.

2002 $\cdots$ $\bullet$ Boag et al..
XQuery introduced.

2003 $\cdots$ $\bullet$ Berglund et al..
XPath introduced.

2004 $\cdots$ $\bullet$ Halverson et al. ROX
[43, 42].
SQL-to-XPath/XQuery
XPath/XQuery-to-SQL.

2005 $\cdots$ $\bullet$ Fan et al..
XPath-to-SQL.

2006 $\cdots$ $\bullet$ Mani et al..
XQuery-to-SQL.

2007 $\cdots$ $\bullet$ Droop et al.
Georgiadis and Vassalos.
XPath/XQuery-to-SPARQL
XPath/XQuery-to-SQL.

2008 $\cdots$ $\bullet$ Prudhommeaux
Hu and Chen
Lu et al.
Min et al. XTRON.
SPARQL introduced
XML-to-SQL
SPARQL-to-SQL
XQuery-to-SQL.

2009 $\cdots$ $\bullet$ Fan et al.
Vidhya and Samuel
Elliott et al.
Bikakis et al., Bikakis et al.
Ramanujam et al..
XPath-to-SQL
SQL-to-XPath
SPARQL-to-SQL
SPARQL-to-XQuery
SQL-to-SPARQL.

2010 $\cdots$ $\bullet$ Vidhya and Samuel
Kiminki et al. Type-ARQuE.
SQL-to-XQuery
SPARQL-to-SQL.

2011 $\cdots$ $\bullet$ Das R2RML
Atay and Chebotko
Fischer et al.
Rachapalli et al. RETRO.
SQL-to-SPARQL
XML-to-SQL
SQL- and SPARQL-to-XQuery
SQL-to-SPARQL.

2012 $\cdots$ $\bullet$ Rodrıguez-Muro et al. Quest
Unbehauen et al. SPARQLMap.
SPARQL-to-SQL
SPARQL-to-SQL.

2013 $\cdots$ $\bullet$ dos Santos Ferreira et al.
Sequeda and Miranker Ultrawrap.
SQL-to-Document based
SPARQL-to-SQL.

2014 $\cdots$ $\bullet$ Bikakis et al.
Priyatna et al. Morph
Lawrence.
SPARQL-to-XQuery
SPARQL-to-SQL
SQL-to-Document-based.

2015 $\cdots$ $\bullet$ Sun et al. SQLGraph
Bikakis et al..
Gremlin-to-SQL
SPARQL-to-XQuery.

2016 $\cdots$ $\bullet$ Unbehauen and Martin SparqlMap-M.
SQL-to-Document-based.

2017 $\cdots$ $\bullet$ Steer et al. Cytosm.
Cypher-to-SQL.

2018 $\cdots$ $\bullet$ Thakkar et al., Thakkar et al. Gremlinator.
SPARQL-to-Gremlin.

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

##### 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 rationals
similar to those of the previously tackled translation paths. For example,
although SPARQL and Gremlin fundamentally differ in their approaches to query
graph data, one based on graph pattern matching one on graph traversals, they
are both graph query languages. A transition from one to the other not only
allows the interoperability between systems supporting those languages, but
also makes data from one world available to the other without requiring to
learn the other respective query language [2]. Similarly, XML languages have a
rooted notion of traversals, a conversion to and from Gremlin is natural. In
fact, according to [46], the early prototype 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 we
summarize in the following points:

  * •

We noticed that the optimizations that are applied during the query
translation process have more potential to improve the overall translation
performance than the optimization applied on the generated query. 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 the query in the target
language has been generated.

  * •

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

  * •

Certain works present a well-founded and defined query translation frameworks,
from the query translation process to the various optimization strategies.
However, the example queries effectively worked on are simple and would hardly
represent real-world queries. Use-case-driven translation methods would be
more helpful to reveal the useful query patterns and fragments, and to
evaluate the translation methods and optimizations 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 translation aspects 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 translation methods, it
appears that SQL and SPARQL are the most suitable languages to act as a
’universal’ language for realizing the heterogeneous data integration. They
both have the most number of translations to other languages (see outgoing
edges in Figure 1). SQL is the oldest query language with ever-continued
development cycles and adoption. SPARQL is the stable query language of the
so-called ontology-based data integration and access, 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. The
visualization allows us to draw some remarks. SPARQL was very quickly
recognized by the community, as works translating to and from SPARQL started
to emerge the same year it was suggested. We cannot make a similar judgment
about the adoption of SQL, XPath and XQuery as they were introduced earlier
than the timeframe we consider in this study, 2003-2019. Works on translating
to and from SPARQL have continued to attract 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 published. Despite their latest updates in 2017, we
have not found any works (at least complying with our criteria) published
since 2015.

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

## References

  * Angles et al. [2017] Renzo Angles, Marcelo Arenas, Pablo Barceló, Aidan Hogan, Juan Reutter, and Domagoj Vrgoč.  Foundations of modern query languages for graph databases.  _ACM Computing Surveys (CSUR)_ , 50(5):68, 2017\.
  * Angles et al. [2019] Renzo Angles, Harsh Thakkar, and Dominik Tomaszuk.  RDF and Property Graphs Interoperability: Status and Issues.  In _Proceedings of the 13th Alberto Mendelzon International Workshop on Foundations of Data Management, Asunción, Paraguay, June 3-7, 2019._ , 2019.  URL http://ceur-ws.org/Vol-2369/paper01.pdf.
  * Araujo et al. [2017] 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 Pessanha, 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.
  * Atay and Chebotko [2011] 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_ , pages 84–89. IEEE, 2011.
  * Berglund et al. [2003] Anders Berglund, Scott Boag, Don Chamberlin, Mary F Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.  Xml path language (xpath).  _World Wide Web Consortium (W3C)_ , 2003.
  * Bikakis et al. [2009a] Nikos Bikakis, Nektarios Gioldasis, Chrisa Tsinaraki, and Stavros Christodoulakis.  Querying xml data with sparql.  In _International Conference on Database and Expert Systems Applications_ , pages 372–381. Springer, 2009a.
  * Bikakis et al. [2009b] Nikos Bikakis, Nektarios Gioldasis, Chrisa Tsinaraki, and Stavros Christodoulakis.  Semantic based access over xml data.  In _World Summit on Knowledge Society_ , pages 259–267. Springer, 2009b.
  * Bikakis et al. [2014] Nikos Bikakis, Chrisa Tsinaraki, Ioannis Stavrakantonakis, and Stavros Christodoulakis.  Supporting sparql update queries in rdf-xml integration.  _arXiv preprint arXiv:1408.2800_ , 2014.
  * Bikakis et al. [2015] Nikos Bikakis, Chrisa Tsinaraki, Ioannis Stavrakantonakis, Nektarios Gioldasis, and Stavros Christodoulakis.  The sparql2xquery interoperability framework.  _World Wide Web_ , 18(2):403–490, 2015.
  * Boag et al. [2002] Scott Boag, Don Chamberlin, Mary F Fernández, Daniela Florescu, Jonathan Robie, Jérôme Siméon, and Mugur Stefanescu.  Xquery 1.0: An xml query language.  2002\.
  * Botoeva et al. [2016] Elena Botoeva, Diego Calvanese, Benjamin Cogrel, Martin Rezk, and Guohui Xiao.  Obda beyond relational dbs: A study for mongodb.  CEUR Workshop Proceedings, 2016.
  * Bray et al. [1997] Tim Bray, Jean Paoli, C Michael Sperberg-McQueen, Eve Maler, and François Yergeau.  Extensible markup language (xml).  _World Wide Web Journal_ , 2(4):27–66, 1997.
  * Carata [2017] Lucian Carata.  Cyp2sql: Cypher to sql translation, 2017.  URL https://github.com/DTG-FRESCO/cyp2sql.  Accessed: 06-08-2019.
  * Chamberlin and Boyce [1974] Donald D Chamberlin and Raymond F Boyce.  Sequel: A structured english query language.  In _Proceedings of the 1974 ACM SIGFIDET (now SIGMOD) workshop on Data description, access and control_ , pages 249–264. ACM, 1974.
  * Chebotko et al. [2006] Artem Chebotko, Shiyong Lu, Hasan M. Jamil, and Farshad Fotouhi.  Semantics preserving sparql-to-sql query translation for optional graph patterns.  Technical report, 2006.
  * Clark et al. [1999] James Clark, Steve DeRose, et al.  Xml path language (xpath) version 1.0, 1999.
  * Codd [1970] Edgar F Codd.  A relational model of data for large shared data banks.  _Communications of the ACM_ , 13(6):377–387, 1970\.
  * Das [2011] Souripriya Das.  R2rml: Rdb to rdf mapping language.  _http://www. w3. org/TR/r2rml/_ , 2011.
  * Dixon [2010] James Dixon.  Pentaho, Hadoop, and Data Lakes, 2010.  URL https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes.  Online; accessed 27-January-2019.
  * dos Santos Ferreira et al. [2013] Gabriel dos Santos Ferreira, Andre Calil, and Ronaldo dos Santos Mello.  On providing ddl support for a relational layer over a document nosql database.  In _Proceedings of International Conference on Information Integration and Web-based Applications & Services_, page 125. ACM, 2013.
  * Droop et al. [2007] Matthias Droop, Markus Flarer, Jinghua Groppe, Sven Groppe, Volker Linnemann, Jakob Pinggera, Florian Santner, Michael Schier, Felix Schöpf, Hannes Staffler, et al.  Translating xpath queries into sparql queries.  In _OTM Confederated International Conferences” On the Move to Meaningful Internet Systems”_ , pages 9–10. Springer, 2007.
  * Dyck et al. [2017] Michael Dyck, J Robie, J Snelson, and D Chamberlin.  Xml path language (xpath) 3.1, 2017.  URL https://www.w3.org/TR/xpath-31/.  Accessed: 06-08-2019.
  * Elliott et al. [2009] Brendan Elliott, En Cheng, Chimezie Thomas-Ogbuji, and Z Meral Ozsoyoglu.  A complete translation from sparql into efficient sql.  In _Proceedings of the 2009 International Database Engineering & Applications Symposium_, pages 31–42. ACM, 2009.
  * Fan et al. [2005] Wenfei Fan, Jeffrey Xu Yu, Hongjun Lu, Jianhua Lu, and Rajeev Rastogi.  Query translation from xpath to sql in the presence of recursive dtds.  In _Proceedings of the 31st international conference on Very large data bases_ , pages 337–348. VLDB Endowment, 2005.
  * Fan et al. [2009] Wenfei Fan, Jeffrey Xu Yu, Jianzhong Li, Bolin Ding, and Lu Qin.  Query translation from xpath to sql in the presence of recursive dtds.  _The VLDB Journal_ , 18(4):857–883, 2009.
  * Fischer et al. [2011] Peter M Fischer, Dana Florescu, Martin Kaufmann, and Donald Kossmann.  Translating sparql and sql to xquery.  _XML Prague_ , pages 81–98, 2011.
  * Francis et al. [2018] Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor.  Cypher: An evolving query language for property graphs.  In _Proceedings of the 2018 International Conference on Management of Data_ , pages 1433–1445. ACM, 2018.
  * Gearon et al. [2013] Paul Gearon, Alexandre Passant, and Axel Polleres.  Sparql 1.1 update.  _W3C recommendation_ , 21, 2013.
  * Georgiadis and Vassalos [2007] Haris Georgiadis and Vasilis Vassalos.  Xpath on steroids: exploiting relational engines for xpath performance.  In _Proceedings of the 2007 ACM SIGMOD international conference on Management of data_ , pages 317–328. ACM, 2007.
  * Green et al. [2018] Alastair Green, Martin Junghanns, Max Kiessling, Tobias Lindaaker, Stefan Plantikow, and Petra Selmer.  opencypher: New directions in property graph querying.  2018\.
  * Groppe et al. [2008] 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.
  * Group et al. [2013] W3C SPARQL Working Group et al.  SPARQL 1.1 overview.  _W3C Recommendation. W3C_ , 2013.  http://www.w3.org/TR/sparql11-overview/.
  * Gulutzan and Pelzer [1999] Peter Gulutzan and Trudy Pelzer.  _SQL-99 complete, really_.  R & D Books, 1999.
  * Halverson et al. [2004] Alan Halverson, Vanja Josifovski, Guy Lohman, Hamid Pirahesh, and Mathias Mörschel.  Rox: relational over xml.  In _Proceedings of the Thirtieth international conference on Very large data bases-Volume 30_ , pages 264–275. VLDB Endowment, 2004.
  * Hausenblas et al. [2012] Michael Hausenblas, Robert Grossman, Andreas Harth, and Philippe Cudré-Mauroux.  Large-scale linked data processing-cloud computing to the rescue?.  _CLOSER_ , 20(2):246–251, 2012.
  * He and Naughton [1999] 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.
  * Hu and Chen [2008] Tian-lei Hu and Gang Chen.  Adaptive xml to relational mapping: an integrated approach.  _Journal of Zhejiang University-SCIENCE A_ , 9(6):758–769, 2008.
  * Jigyasu et al. [2006] Sunil Jigyasu, Sujeet Banerjee, Vinayak Borkar, Michael Carey, Kanad Dixit, Anil Malkani, and Sachin Thatte.  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.
  * Jonathan Robie [2017] Josh Spiegel Jonathan Robie, Michael Dyck.  Xquery 3.1: An xml query language, 2017.  URL https://www.w3.org/TR/xquery-31/.  Accessed: 06-08-2019.
  * Kiminki et al. [2010] Sami Kiminki, Jussi Knuuttila, and Vesa Hirvisalo.  Sparql to sql translation based on an intermediate query language.  In _The 6th International Workshop on Scalable Semantic Web Knowledge Base Systems (SSWS2010)_ , page 32, 2010.
  * Krishnamurthy et al. [2003] Rajasekar Krishnamurthy, Raghav Kaushik, and Jeffrey F Naughton.  Xml-to-sql query translation literature: The state of the art and open problems.  In _International XML Database Symposium_ , pages 1–18. Springer, 2003.
  * Krishnamurthy et al. [2004a] Rajasekar Krishnamurthy, Venkatesan T Chakaravarthy, Raghav Kaushik, and Jeffrey F Naughton.  Recursive xml schemas, recursive xml queries, and relational storage: Xml-to-sql query translation.  In _null_ , page 42. IEEE, 2004a.
  * Krishnamurthy et al. [2004b] 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 data bases-Volume 30_ , pages 144–155. VLDB Endowment, 2004b.
  * Laney [2012] Doug Laney.  Deja vvvu: others claiming gartner’s construct for big data.  _Gartner Blog, Jan_ , 14, 2012.
  * Lawrence [2014] Ramon Lawrence.  Integration and virtualization of relational sql and nosql systems including mysql and mongodb.  In _Computational Science and Computational Intelligence (CSCI), 2014 International Conference on_ , volume 1, pages 285–290. IEEE, 2014.
  * Lindaaker [2018] Tobias Lindaaker.  An overview of the recent history of graph query languages, 2018.
  * Lu et al. [2008] 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.
  * Mahmoud [2017] Alaa Mahmoud.  No more joins: An overview of graph database query language, 2017.  URL https://developer.ibm.com/dwblog/2017/overview-graph-database-query-languages/.  Accessed: 06-08-2019.
  * Mani et al. [2006] Murali Mani, Song Wang, Dan Dougherty, and Elke A Rundensteiner.  Join minimization in xml-to-sql translation: an algebraic approach.  _ACM SIGMOD Record_ , 35(1):20–25, 2006.
  * Melnik [2001] Sergey Melnik.  Storing rdf in a relational database, 2001.
  * Michel et al. [2014] Franck Michel, Johan Montagnat, and Catherine Faron Zucker.  _A survey of RDB to RDF translation approaches and tools_.  PhD thesis, I3S, 2014.
  * Michel et al. [2016] Franck Michel, Catherine Faron Zucker, and Johan Montagnat.  A generic mapping-based query translation from sparql to various target database query languages.  In _12th International Conference on Web Information Systems and Technologies (WEBIST’16)_ , 2016.
  * Min et al. [2008] Jun-Ki Min, Chun-Hee Lee, and Chin-Wan Chung.  Xtron: An xml data management system using relational databases.  _Information and Software Technology_ , 50(5):462–479, 2008.
  * Mutharaju et al. [2013] Raghava Mutharaju, Sherif Sakr, Alessandra Sala, and Pascal Hitzler.  D-sparq: distributed, scalable and efficient rdf query engine.  2013\.
  * Noy [2004] Natalya F Noy.  Semantic integration: a survey of ontology-based approaches.  _ACM Sigmod Record_ , 33(4):65–70, 2004.
  * Pérez et al. [2006] Jorge Pérez, Marcelo Arenas, and Claudio Gutierrez.  Semantics and complexity of sparql.  In _International semantic web conference_ , pages 30–43. Springer, 2006.
  * Pérez et al. [2009] Jorge Pérez, Marcelo Arenas, and Claudio Gutierrez.  Semantics and complexity of sparql.  _ACM Transactions on Database Systems (TODS)_ , 34(3):16, 2009.
  * Poggi et al. [2008] Antonella Poggi, Domenico Lembo, Diego Calvanese, Giuseppe De Giacomo, Maurizio Lenzerini, and Riccardo Rosati.  Linking data to ontologies.  In _Journal on data semantics X_ , pages 133–173. Springer, 2008\.
  * Polleres and Wallner [2013] 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.
  * Priyatna et al. [2014] Freddy Priyatna, Oscar Corcho, and Juan Sequeda.  Formalisation and experiences of r2rml-based sparql to sql query translation using morph.  In _Proceedings of the 23rd international conference on World wide web_ , pages 479–490. ACM, 2014.
  * Prudhommeaux [2008] Eric Prudhommeaux.  Sparql query language for rdf.  _http://www. w3. org/TR/rdf-sparql-query/_ , 2008.
  * Prud’hommeaux [2004] Eric Prud’hommeaux.  Optimal rdf access to relational databases, 2004.
  * Prud’Hommeaux et al. [2008] Eric Prud’Hommeaux, Andy Seaborne, et al.  SPARQL query language for RDF.  _W3C recommendation_ , 15, 2008.  www.w3.org/TR/rdf-sparql-query/.
  * QueryMongo [2019] QueryMongo.  Query mongo: Mysql to mongodb query translator, 2019.  URL http://www.querymongo.com.  Accessed: 06-08-2019.
  * Rachapalli et al. [2011] Jyothsna Rachapalli, Vaibhav Khadilkar, Murat Kantarcioglu, and Bhavani Thuraisingham.  Retro: a framework for semantics preserving sql-to-sparql translation.  _The University of Texas at Dallas_ , 800:75080–3021, 2011\.
  * Ramanujam et al. [2009a] Sunitha Ramanujam, Anubha Gupta, Latifur Khan, Steven Seida, and Bhavani Thuraisingham.  R2d: A bridge between the semantic web and relational visualization tools.  In _2009 IEEE International Conference on Semantic Computing_ , pages 303–311. IEEE, 2009a.
  * Ramanujam et al. [2009b] 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 International Joint Conference on Web Intelligence and Intelligent Agent Technology-Volume 01_ , pages 361–366. IEEE Computer Society, 2009b.
  * Ranking [2019] DB-Engines Ranking.  Db-engines ranking, 2019.  URL https://db-engines.com/en/ranking.  Accessed: 06-08-2019.
  * Reddy [2015] Ramesh Reddy.  Mongodb translator - teiid 9.0 (draft), 2015.  URL https://docs.jboss.org/author/display/TEIID/MongoDB+Translator.  Accessed: 06-08-2019.
  * Rodriguez [2015] Marko A Rodriguez.  The gremlin graph traversal machine and language (invited talk).  In _Proceedings of the 15th Symposium on Database Programming Languages_ , pages 1–10. ACM, 2015.
  * Rodriguez-Muro and Rezk [2015] Mariano Rodriguez-Muro and Martín 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.
  * Rodrıguez-Muro et al. [2012] 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.
  * Russell [2016] Vincent Russell.  sql-to-mongo-db-query-converter, 2016.  URL https://github.com/vincentrussell/sql-to-mongo-db-query-converter.  Accessed: 15-10-2018.
  * Sadalage and Fowler [2013] Pramod J Sadalage and Martin Fowler.  _NoSQL distilled: a brief guide to the emerging world of polyglot persistence_.  Pearson Education, 2013.
  * Sahoo et al. [2009] Satya S Sahoo, Wolfgang Halb, Sebastian Hellmann, Kingsley Idehen, Ted Thibodeau Jr, Sören Auer, Juan Sequeda, and Ahmed Ezzat.  A survey of current approaches for mapping of relational databases to rdf.  _W3C RDB2RDF Incubator Group Report_ , 1:113–130, 2009\.
  * Schreiner et al. [2015] Geomar A Schreiner, Denio Duarte, and Ronaldo dos Santos Mello.  Sqltokeynosql: a layer for relational to key-based nosql database mapping.  In _Proceedings of the 17th International Conference on Information Integration and Web-based Applications & Services_, page 74. ACM, 2015.
  * Sequeda and Miranker [2013] 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.
  * Spanos et al. [2012] Dimitrios-Emmanuel Spanos, Periklis Stavrou, and Nikolas Mitrou.  Bringing relational databases into the semantic web: A survey.  _Semantic Web_ , 3(2):169–209, 2012.
  * SQL2Gremlin [2018] SQL2Gremlin.  Sql2gremlin, 2018.  URL http://sql2gremlin.com.  Accessed: 06-08-2019.
  * Stadler et al. [2013] Claus Stadler, Jörg Unbehauen, Jens Lehmann, and Sören Auer.  Connecting crowdsourced spatial information 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\.
  * Steer et al. [2017] Benjamin A Steer, Alhamza Alnaimi, Marco ABFG Lotz, Felix Cuadrado, Luis M Vaquero, and Joan Varvenne.  Cytosm: Declarative property graph queries without data migration.  In _Proceedings of the Fifth International Workshop on Graph Data-management Experiences & Systems_, page 4. ACM, 2017.
  * Sun et al. [2015] 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 SIGMOD International Conference on Management of Data_ , pages 1887–1901. ACM, 2015.
  * Thakkar et al. [2017] Harsh Thakkar, Dharmen Punjani, Sören Auer, and Maria-Esther Vidal.  Towards an Integrated Graph Algebra for Graph Pattern Matching with Gremlin.  In _International Conference on Database and Expert Systems Applications_ , pages 81–91. Springer, 2017.
  * Thakkar et al. [2018a] Harsh Thakkar, Dharmen Punjani, Yashwant Keswani, Jens Lehmann, and Sören Auer.  A Stitch in Time Saves Nine–SPARQL Querying of Property Graphs using Gremlin Traversals.  _arXiv preprint arXiv:1801.02911_ , 2018a.
  * Thakkar et al. [2018b] Harsh Thakkar, Dharmen Punjani, Jens Lehmann, and Sören Auer.  Two for One: Querying Property Graph Databases using SPARQL via Gremlinator.  In _Proceedings of the 1st ACM SIGMOD Joint International Workshop on Graph Data Management Experiences & Systems (GRADES) and Network Data Analytics (NDA)_, page 12. ACM, 2018b.
  * Unbehauen and Martin [2016] Jörg Unbehauen and Michael Martin.  Executing sparql queries over mapped document stores with sparqlmap-m.  In _12th International Conference on Semantic Systems Proceedings (SEMANTiCS 2016)_ , SEMANTiCS ’16, Leipzig, Germany, September 2016\.
  * Unbehauen et al. [2012] Jörg Unbehauen, Claus Stadler, and Sören Auer.  Accessing relational data on the web with sparqlmap.  In _Joint International Semantic Technology Conference_ , pages 65–80. Springer, 2012.
  * UnityJDBC [2017] UnityJDBC.  Unityjdbc - jdbc driver for mongodb, 2017.  URL http://unityjdbc.com/mongojdbc/mongo_jdbc.php.  Accessed: 06-08-2019.
  * Vidhya and Samuel [2009] PM Vidhya and Philip Samuel.  Query translation from sql to xpath.  In _Nature & Biologically Inspired Computing, 2009. NaBIC 2009. World Congress on_, pages 1749–1752. IEEE, 2009.
  * Vidhya and Samuel [2010] PM Vidhya and Philip Samuel.  Insert queries in xml database.  In _Computer Science and Information Technology (ICCSIT), 2010 3rd IEEE International Conference on_ , volume 1, pages 9–13. IEEE, 2010.
  * Website [2019] Neo4j Website.  For relational database developers: A sql to cypher guide, 2019.  URL https://neo4j.com/developer/guide-sql-to-cypher.  Accessed: 06-08-2019.
  * Wilmes [2016] Ted Wilmes.  Sql-gremlin, 2016.  URL https://github.com/twilmes/sql-gremlin.  Accessed: 06-08-2019.