SPARQL-to-SPARQL Query Translation

• SPARQL-to-SPARQL Translation is the process of converting a source SPARQL query into an equivalent query or extension to optimize performance, preserve answers, or adapt to different schemas.
• It employs algebraic rewriting, normalization, and semantic reformulation techniques to maintain multiset semantics and correctly handle constructs like OPTIONAL and FILTER.
• The approach underpins schema interoperability across diverse knowledge graphs such as DBpedia and Wikidata, addressing both query optimization and cross-graph translation challenges.

Searching arXiv for recent and foundational work on SPARQL-to-SPARQL translation, query rewriting, and related interoperability. SPARQL-to-SPARQL translation is the transformation of a source SPARQL query into another SPARQL query, or into a strict SPARQL extension, in order to preserve answers, expose optimization opportunities, adapt the query to a different entailment regime, or retarget it to a different knowledge-graph schema. In the literature, the topic includes algebraic rewriting for optimization, conservative elimination of language extensions, lazy reformulation for RDFS-aware answering, and cross-knowledge-graph translation between schemas such as DBpedia and Wikidata (0812.3788, Troumpoukis et al., 2017, Alkhateeb et al., 2013, Bartels et al., 14 Jul 2025).

1. Problem space and task variants

Published work treats several distinct forms of SPARQL-to-SPARQL translation. One line studies equivalence-preserving rewriting inside standard SPARQL, typically for optimization or normalization. Another studies extension elimination, where a richer language is compiled back to standard SPARQL without increasing expressive power. A third studies semantic reformulation, where a standard SPARQL query is rewritten into a path-capable extension so that evaluation over an RDF graph yields the answers of the original query under RDFS semantics. A fourth studies schema translation, where a SPARQL query written for one knowledge graph is rewritten so that it produces the corresponding answers over another knowledge graph with a different ontology, identifier system, or modeling style (Troumpoukis et al., 2017, Alkhateeb et al., 2013, Bartels et al., 14 Jul 2025).

The distinctions are substantive rather than terminological. In SPREFQL, the translation target is equivalent standard SPARQL over the same dataset and solution space (Troumpoukis et al., 2017). In RDFS-aware answering, the target is PSPARQL, and the objective is equivalence to SPARQL evaluated modulo RDFS, not plain RDF evaluation (Alkhateeb et al., 2013). In cross-knowledge-graph translation, the target remains SPARQL, but the translation must bridge ontology, entity, and property mismatches between graphs such as DBpedia and Wikidata (Bartels et al., 14 Jul 2025).

The literature also marks the boundary of the topic. Work on SPARQL pattern composition with sequence-to-sequence models is explicitly not primarily direct SPARQL-to-SPARQL translation; its main setup is natural-language question to SPARQL query (Panchbhai et al., 2020). Likewise, pipelines from grounded intermediate representations to SPARQL are transpilation into SPARQL rather than SPARQL-to-SPARQL rewriting (Saparina et al., 2021). Cross-language translators such as Gremlinator and S2CTrans are interoperability systems, but their targets are Gremlin and Cypher rather than SPARQL (Thakkar et al., 2018, Zhao et al., 2023).

2. Algebraic foundations and normal forms

A central foundation for SPARQL-to-SPARQL translation is the multiset semantics of SPARQL graph patterns. For the fragment involving AND, UNION, FILTER, EXCEPT, and SELECT, SPARQL has the same expressive power as non-recursive multiset Datalog with safe negation and as a multiset relational algebra comprising projection, selection, natural join, arithmetic union, and except (Angles et al., 1 May 2026). This equivalence is not merely classificatory: it provides a route for rewriting a SPARQL query by translating it into Datalog or multiset relational algebra, simplifying it there, and translating it back.

Normalization is required because bag semantics is structurally stricter than set semantics. Every query in the fragment can be rewritten as an equivalent normalized SPARQL query such that every FILTER only mentions variables already in scope, and both sides of UNION and EXCEPT have the same in-scope variables (Angles et al., 1 May 2026). This condition is directly relevant to any SPARQL-to-SPARQL compiler that aligns schemas, projects variables, or inserts auxiliary subqueries.

The same work shows that bag-correct rewriting is more delicate than standard set-theoretic intuition suggests. The identities

$$\sigma_{\varphi_1 \lor \varphi_2}(R)=\sigma_{\varphi_1}(R)\cup \sigma_{\varphi_2}(R)$$

and

$$\sigma_{\neg \varphi}(R)=R\setminus \sigma_\varphi(R)$$

do not hold under bags and SPARQL’s three-valued filter logic (Angles et al., 1 May 2026). To repair this, the paper introduces an Error formula characterizing when a filter evaluates to error, and proves bag-correct rewritings for conjunction, disjunction, and negation. In particular, disjunction must be rewritten as a UNION of disjoint cases, and negation must remove both true and error cases.

An earlier provenance-oriented line already established that substantial fragments of SPARQL 1.1 can be translated into relational algebra over Graphs and Quads, with exact preservation of bag semantics and one tuple per solution mapping for the translated query (Damásio et al., 2012). That translation handles AND, UNION, MINUS, OPTIONAL, FILTER, and GRAPH, and gives explicit algebraic constructions for OPTIONAL, EXISTS, and [NOT](https://www.emergentmind.com/topics/neural-organ-transplantation-not) EXISTS. Although this is not itself a direct SPARQL-to-SPARQL rewrite system, it supplies a semantic normal form from which SPARQL rewritings can be justified (Damásio et al., 2012).

3. Rewriting within standard SPARQL for optimization

The foundational optimization study of SPARQL develops a rewriting theory over SPARQL Algebra and identifies OPTIONAL as the main source of complexity in SPARQL evaluation (0812.3788). Its contribution to SPARQL-to-SPARQL translation is twofold: a comprehensive set of algebraic rewriting rules, and a semantic optimization framework based on translation to conjunctive queries, chase/backchase minimization, and translation back to SPARQL.

The algebraic rules include idempotence, associativity, commutativity, distributivity, filter decomposition, and filter pushing, but only under SPARQL-specific safety conditions (0812.3788). A key concept is safeVars(A): variables in safeVars(A) are guaranteed to be bound in every mapping produced by A. Under the precondition $vars(R)\subseteq safeVars(A_1)$, the paper gives safe filter-pushing rules for join, difference, and left outer join. This is the SPARQL analogue of relational selection pushdown, but it depends on guaranteed boundness because unbound variables are semantically active in SPARQL.

The same paper gives specialized rewrites for implicit negation. In restricted fragments, OPTIONAL plus FILTER(!bnd(?x)) can be translated into explicit difference. It also proves that several plausible laws do not hold in general, including associativity or commutativity for difference and OPTIONAL, and it corrects an earlier claimed distributive equivalence. This negative result is important encyclopedically: SPARQL-to-SPARQL translation is not the straightforward application of relational rewrite folklore (0812.3788).

For constraint-based optimization, the paper translates basic graph patterns or And-blocks into conjunctive queries, applies the Chase Backchase algorithm under TGDs and EGDs, and translates the minimized result back into SPARQL (0812.3788). It introduces two SPARQL-to-CQ translation schemes, C1 and C2, and two new chase termination conditions, safe and safely restricted, which subsume the strongest conditions known so far and do not increase the complexity of the recognition problem. In this regime, SPARQL-to-SPARQL translation is semantic minimization under constraints rather than surface rewriting.

4. Translation for extended semantics: preferences and RDFS entailment

A distinct family of work treats SPARQL-to-SPARQL translation as compilation of richer semantics into executable query forms. SPREFQL is a conservative extension of SPARQL 1.1 that adds a PREFER clause for soft preferences over solutions (Troumpoukis et al., 2017). Its semantics is expressed through a binary preference relation over tuples and a winnow operator

$$w_P(r)=\{\, t\in r \mid \nexists t' \in r \text{ such that } t' >_P t \,\}.$$

The crucial translation result is that SPREFQL does not add expressivity: any SPREFQL query can be transformed to an equivalent standard SPARQL query (Troumpoukis et al., 2017).

For a query of the form:

SELECT L WHERE { P } PREFER L1 TO L2 IF C

the equivalent standard SPARQL query is:

SELECT L WHERE { P FILTER NOT EXISTS { P{L/L1} FILTER C{L2/L} } }

This rewrite implements winnow by an anti-join pattern: the outer query enumerates candidate solutions, and the FILTER NOT EXISTS subquery removes a candidate whenever a dominating solution exists (Troumpoukis et al., 2017). The paper also shows that the dedicated PREFER operator is still operationally useful, because a generic optimizer may not recognize the rewrite as pairwise dominance testing; direct algorithms such as NL and BNL can therefore outperform the rewritten form in some settings (Troumpoukis et al., 2017).

A different semantic extension arises in answering SPARQL queries modulo RDF Schema. Here the paper rewrites SPARQL into PSPARQL, a strict extension of SPARQL with path expressions, so that evaluation on the original RDF graph yields exactly the RDFS answers of the original query (Alkhateeb et al., 2013). The translation function $\tau$ rewrites triple patterns by encoding subclass, subproperty, type, domain, and range reasoning into path structure; for example, sc and sp become transitive-closure paths, ordinary properties are matched through sp*, and rdf:type is expanded into direct type, domain-based, and range-based alternatives (Alkhateeb et al., 2013).

The main correctness statement is:

$$\mathcal{A}^{\#}(\vec{B}, G, P)=\mathcal{A}^{\star}(\vec{B}, G, \tau(P)).$$

This makes the translation both sound and complete for query answering modulo RDFS (Alkhateeb et al., 2013). The same paper proves that PSPARQL answer checking remains PSPACE-complete, matching the complexity of SPARQL, and compares this approach with nSPARQL and CPSPARQL/cpSPARQL. In that comparison, cpSPARQL is strictly more expressive than nSPARQL while retaining the same complexity (Alkhateeb et al., 2013).

5. Cross-knowledge-graph SPARQL translation

Recent work studies SPARQL-to-SPARQL translation as a schema-interoperability problem between heterogeneous knowledge graphs. The most explicit formulation is the translation of SPARQL between DBpedia and Wikidata, later extended to DBLP and OpenAlex (Bartels et al., 14 Jul 2025). The motivation is that SPARQL is tightly coupled to a graph’s schema, so a query crafted for DBpedia will usually not run on Wikidata without substantial manual adaptation (Bartels et al., 14 Jul 2025).

The benchmark design is exacting. For DBpedia and Wikidata, the study derives a benchmark from QALD-9-Plus and selects 100 English questions from the training split that successfully executed on both graphs and returned non-empty, comparable results (Bartels et al., 14 Jul 2025). It also performs a schema-term alignment procedure: DBpedia prefixes are expanded to full URIs, unique DBpedia entities and relations are extracted with regex, mappings are sought through owl:sameAs, owl:equivalentProperty, and owl:equivalentClass, and only valid Wikidata URI mappings are retained. Out of 637 unique DBpedia terms, 493 were mapped and 144 remained unmapped (Bartels et al., 14 Jul 2025).

Evaluation is execution-based rather than syntactic. The translated SPARQL is executed and its result set is compared with a gold answer; a translation is correct only if the result set exactly matches the gold answer, ignoring ordering unless the query’s semantics depend on order (Bartels et al., 14 Jul 2025). The study tests Llama-3.1-8B Instruct, DeepSeek-R1-Distill-Llama-70B, and Mistral-Large-Instruct-2407 under zero-shot, zero-shot plus entity-relation mapping, few-shot plus entity-relation mapping, chain-of-thought, and chain-of-thought with > tags (Bartels et al., 14 Jul 2025).

Setting	Best configuration	Best exact result
DBpedia → Wikidata	Mistral-Large-Instruct-2407, few-shot + ER mapping	57%
Wikidata → DBpedia	Mistral-Large-Instruct-2407, few-shot + ER mapping	86%
DBLP → OpenAlex	Mistral-Large-Instruct-2407, few-shot + ER mapping	86%

The headline empirical fact is asymmetry: Wikidata to DBpedia works far better than DBpedia to Wikidata (Bartels et al., 14 Jul 2025). The paper attributes this to DBpedia’s human-readable IRIs and to Wikidata’s numeric identifiers and richer statement model. Schema guidance and in-context examples improve performance substantially, but do not remove the asymmetry (Bartels et al., 14 Jul 2025).

The error analysis is unusually detailed. The paper defines eight error categories: Unadapted Dataset Patterns; Query Bad Formed Error; Ontology Treated as Resource / Property Treated as Entity; Resource Treated as Ontology / Entity Treated as Property; Missing P31 / Missing rdf:type; Wrong or Missing Ontology / Wrong or Missing Property; Wrong or Missing Resource / Wrong or Missing Entity; and Structural Error (Bartels et al., 14 Jul 2025). Structural Error is by far the most common category in both directions, and missing typing information almost always co-occurs with Structural Error, with 97–98% co-occurrence. The study therefore treats cross-KG SPARQL translation as a structural preservation problem as much as a symbol-mapping problem (Bartels et al., 14 Jul 2025).

6. Boundaries, misconceptions, and persistent difficulties

A recurrent misconception is that all “SPARQL translation” work is SPARQL-to-SPARQL. Sequence-to-sequence models for SPARQL pattern composition are relevant to compositional query structure, but the task there is natural-language question to SPARQL, and the paper explicitly states that it does not present a standalone pipeline where one SPARQL query is translated into another SPARQL query (Panchbhai et al., 2020). The same is true of grounded intermediate-representation pipelines, in which a non-trainable transpiler converts grounded QDMR logical forms to SPARQL after relational databases have been converted to RDF (Saparina et al., 2021).

Another boundary concerns target language. Gremlinator translates a subset of SPARQL 1.0 SELECT queries into Gremlin path traversals, and S2CTrans translates most SELECT queries in SPARQL 1.1 into type-safe Cypher statements using graph relational algebra (Thakkar et al., 2018, Zhao et al., 2023). These systems are methodologically adjacent to SPARQL-to-SPARQL translation because they rely on ASTs, graph-pattern mappings, and solution-modifier correspondences, but they are not SPARQL-to-SPARQL systems.

The persistent technical difficulties of direct SPARQL-to-SPARQL translation are also well characterized. Under multiset semantics, apparently obvious rewrites can be unsound because UNION, projection, and filter negation interact with multiplicities and error propagation (Angles et al., 1 May 2026). Under optimization-oriented rewriting, OPTIONAL is the main source of complexity, and many attractive algebraic laws fail outside restricted fragments (0812.3788). Under schema translation, errors cluster: wrong entity mapping, wrong property mapping, missing typing information, and malformed queries frequently coincide with structural corruption of the whole query (Bartels et al., 14 Jul 2025).

This suggests a stable division within the field. One regime seeks logical equivalence under a fixed dataset or entailment regime; another seeks schema-mediated answer preservation across different graphs. Both are genuinely SPARQL-to-SPARQL, but their correctness criteria, intermediate representations, and failure modes differ substantially.