Is Everything Unfolding? Classical Data Integration for RDF

Introduction

RDF models data as a set of triples, and a frequent requirement is to make statements about those triples, e.g., to record who inserted a triple, during which interval it was held to be true, or under what confidence it holds. The RDF 1.1 data model [1] provides no direct support for this. A triple is not a first-class citizen of the data model, and so cannot appear in the subject or object position of another triple. Practitioners have consequently developed a family of encodings – sometimes called reification patterns – that simulate statement-level metadata by introducing a proxy resource standing for the triple. Well-known reification patterns are: RDF reification [2], singleton properties [3], named graphs [4], and $n$-ary relations [5]. Each is a convention shared between the data publisher and consumer, and each pattern requires specific knowledge in order to write queries.

The RDF 1.2 and SPARQL 1.2 [6] specifications are currently being finalized, and address this by introducing the (nested) triple term: a triple that may occur in the object position of another triple, and hence it is properly part of the data model. Triple terms make reification native instead of relying on encodings, and allow for arbitrary nesting. SPARQL 1.2 consequently adds support for such triple terms: queries can match and construct triple terms directly. Triple terms descend from RDF-star and SPARQL-star [7], proposed over a decade ago, and narrow the gap between RDF and property graphs [8].

Standardization, however, does not mean that there will be immediate adoption. A data consumer therefore has to deal with a landscape in which the same statement-level metadata is expressed in several mutually incompatible ways. The difficulty arises most clearly in the setting of SPARQL federation [9], where one query is evaluated across several RDF data sources (SPARQL endpoints): a query phrased in terms of triple terms might unexpectedly return no answers from a source that uses the singleton properties [3] encoding, and conversely, some mediation between the encodings is warranted; currently, it is up to the user.

Our starting observation is that this is a data integration problem in the classical sense [10]. Fix a reasonable global schema that represents RDF 1.2 data (e.g. a ternary relation allowing nested tuples), and specify mappings between the reification patterns used in source schemata and your global schema. Query answering over the global schema can be achieved through query rewriting against the mappings.

We adopt Global-as-View (GAV), which defines the global schema as a view over the sources and answers queries by unfolding each reference to the global schema with its defining view. What makes RDF particularly suitable for GAV is its schemalessness: in relational terms, an RDF dataset is a single ternary relation. A GAV mapping is therefore a single rule, and unfolding reduces to substituting one view definition for every triple pattern of the user query. This is a simplification over the relational-to-RDF setting, where a mapping is a collection of view definitions and unfolding must match each query atom against the appropriate view. Query rewriting from relational sources to RDF has been studied extensively [11, 12]. Yet, the RDF-to-RDF case remains comparatively underexplored, and triple terms further expose this gap.

Through the GAV lens, many RDF data management tasks (handling reification patterns, translating vocabularies, view-based access [13], reasoning-through-rewriting [11, 12], and federation under automatic source selection [14]) turn out to instantiate the same conceptual construction. The recognition of this shared model allows cross-pollination between these research topics by lifting them to this shared lens.

The next section reviews related work on RDF mappings, data integration, and SPARQL rewriting. Section 3 describes our naive rewriting approach and its limitations, and Section 4 concludes the paper.

Related work

We review the data integration foundations, RDF mapping languages, ontology-based access, and federation in turn.

Global- and Local-as-View.   Data integration is classically framed as mappings between a global schema and a set of sources, either as Global-as-View (GAV), defining the global schema as a view over the sources, or Local-as-View (LAV), defining each source as a view over the global schema [10]. RDF blurs the two in practice. Because a dataset is a single ternary relation and datasets compose by union, GAV mappings over RDF are rarely written as one global view; authors write one rule per source and let the union combine them. This per-source style resembles LAV, but here describing a source is a convenience rather than the defining act. LAV proper has been applied to SPARQL by Montoya et al. [15], who avoid rewriting altogether and instead materialize sources in order of estimated relevance to build a partial instance of the global schema. Their mappings are limited to conjunctive queries whose variables are all distinguished (appearing in both head and body) which lets an inverse-rules construction [16] proceed without existential quantifiers [17]. These restrictions exclude the nesting and structural operators that the RDF 1.2 setting requires. GAV rewriting for SPARQL was studied by Le et al. [18] for SPARQL 1.0, and is correspondingly confined to unions of conjunctive queries: it omits subqueries, federation, aggregation, and paths, restricts mapping heads to a constant predicate, and cannot express triple terms, whose heads carry a variable number of terms.

RDF Mapping Languages.   (R2)RML [19, 20] are languages for specifying mappings into RDF, one mapping per source, where the global dataset is then defined simply as the union of the output of “executing” each mapping. The RML Logical Views module [21, 22] additionally adds views over a source, optionally joined with others, but stays aligned with knowledge-graph construction: it does not support structural redefinitions using other operators such as UNION or MINUS. POD-QUERY [13] declares RDF-to-RDF mappings in RML, pairing sources with a SPARQL 1.1 query, and answers user queries by GAV unfolding. However, it does not support RDF 1.2 which requires separate treatment during unfolding.

Ontology-Based Data Access.   OBDA places an ontology between users and sources, with GAV mappings linking each (typically relational) source to the ontology as global schema [11, 12, 23]. A user query is first reformulated against the ontology, compiling TBox knowledge into the query, then unfolded against the mappings. Only reformulation expresses reasoning; the unfolding step is ordinary GAV rewriting. When the sources are already RDF, that unfolding step is exactly our concern and can likewise express the reformulation.

SPARQL Federation.   SPARQL’s SERVICE operator runs part of a query at a remote source. Written explicitly, SERVICE is the user performing GAV-style data integration by hand. Under automatic source selection [14, 24], the user instead writes a source-agnostic query and the engine distributes it. Indeed, this corresponds to a GAV mapping defining the global schema as a union over the triples in the sources. Federation can also reach non-RDF sources by transforming them into RDF on demand [25, 26], extending the same rewriting mechanisms beyond RDF.

Query rewriting

This section uses the following concepts. RDF terms include IRIs, literals, and triple terms. An RDF dataset is a set of triples, each consisting of a subject, predicate, and object, all of which are RDF terms. A query can consist of many operations, in particular triple patterns: triples whose positions hold either terms or variables, matched against the dataset to produce solution mappings, which map each variable to an RDF term.

A SPARQL 1.2 CONSTRUCT query produces an RDF dataset by instantiating a triple template once for each solution mapping of its WHERE clause. This is exactly the shape of a GAV mapping: the template is the mapping head, defining a triple of the global schema, and the WHERE clause is the body, a query over the sources. GAV allows one mapping per relation of the global schema; since RDF has a single relation (the triple relation, extended in RDF 1.2 with triple terms in the object position), a GAV mapping over RDF is a single mapping whose head is, most generically, the ?s ?p ?o pattern and whose body is an SPARQL-algebraic combination of sources by identifying the sources using SERVICE. As syntactical shortcut for the UNION, one may write a separate CONSTRUCT per source and take the union of their outputs. An author can therefore add one source at a time – matching the per-source mapping style common in RDF practice – while conceptually staying within a single GAV mapping. Because the mapping language is SPARQL itself, the rewritten query is again SPARQL, so the approach stays engine-agnostic and lets practitioners reuse a language they already know. Our approach answers a query over the global schema in two steps: we unfold it against the mapping, then optimize the result.

A single mapping can serve several purposes at once. The body in Fig. 1 is a union of four graph patterns, which together produce three things: 1. the structural rewriting that reconciles source A’s RDF reification [2] with RDF 1.2 triple terms (first pattern); 2. automatic source selection, by passing the facts of A and B through unchanged (second and fourth patterns); and 3. partial RDFS reasoning, by materializing rdfs:subClassOf entailments over B (third pattern). A single query over this virtual global graph then benefits from interoperability, source selection, and reasoning-through-rewriting at once. These are three directions that our unfold-then-optimize approach unifies but that have so far been studied in isolation; a more holistic view would let a finding in one direction carry over to the others.

CONSTRUCT { ?s ?p ?o } WHERE { {
    SERVICE <ex://A> {
      ?s a rdf:Statement ; rdf:subject ?reifS ;
         rdf:predicate ?predP ; rdf:object ?reifO .
    }  
    BIND(TRIPLE(?reifS ?reifP ?reifO) AS ?o) . BIND(rdf:reifies AS ?p) .
  } UNION { SERVICE <ex://A> {
      ?s ?p ?o .
  } } UNION {
    SERVICE <ex://B> {
      ?s a ?class .
      ?class a rdfs:Class ;
             rdfs:subClassOf+ ?o .
     BIND(rdf:type AS ?p)
    }
  } UNION { SERVICE <ex://B> {
      ?s ?p ?o
} } }

Unfolding.   Unfolding rewrites a query over the global schema into one over the sources by replacing each triple pattern with the mapping body specialized to that pattern. In our approach, the pattern’s subject, predicate, and object are equated with the head’s, and the resulting equalities are pushed into the body as filters and bindings (Listing 1). What distinguishes this setting from classical rewriting is unifying a query pattern against a (nested) triple term that the body constructs, and vice versa. SPARQL 1.2’s TRIPLE(s, p, o) builds a triple term from three terms and so acts as a ternary function symbol. Matching, for instance, the triple pattern ?x rdf:reifies <<( ?a ?b ?c )>> against a body that constructs such a nested term is unification under this function symbol. Additionally, because triple terms nest, against functional terms of unbounded depth, rewriting over (function-free) unions of conjunctive queries cannot express this [18]; it is precisely triple terms that make the problem interesting again.

Optimization.   Unfolding produces a large query since each triple pattern is expanded to the complete body of the mapping. However, such blow-up is not as bad as it seems: most branches are unsatisfiable, and this can often be statically detected (e.g., a pattern with predicate rdf:type cannot be served by a branch that only ever produces rdf:reifies). This pruning also occurs when handling exclusive groups in SPARQL federation literature [14], one of several points where an optimization studied in one community reappears here. We expect an unfolded query to exhibit at least the following, some already studied in isolation: distributing joins over unions to expose a union of conjunctive queries; pruning branches shown unsatisfiable by static analysis of filters and VALUES; eliminating projections by renaming variables not returned to the user; pushing UNION and JOIN into SERVICE groups over a common endpoint; and pruning exclusive groups across SERVICE operations [14]. Identifying, formalizing, and evaluating the optimizations specific to unfolded queries is the core of our ongoing work, and is where we expect results to transfer between the fields the pipeline unifies.

\begin{algorithmic}
\REQUIRE mapping $M$ with head $h$ and body $B$; query $Q$ without recursive paths
\ENSURE $Q$ rewritten over the sources
\STATE replace every property path in $Q$ by triple patterns
\FOR{each triple pattern $t$ in $Q$}
    \STATE unify $t$ with the head $h$
    \IF{unification fails} \COMMENT{e.g., an IRI position forced to a literal}
        \STATE replace $t$ by an operation returning no results
    \ELSE
        \STATE $B' \gets$ a fresh copy of $B$
        \STATE add to $B'$, as filters and bindings, the equalities from the unification
        \STATE project $B'$ onto the variables of $t$
        \STATE replace $t$ by $B'$
    \ENDIF
\ENDFOR
\RETURN $Q$
\end{algorithmic}

Further challenges.   The open challenges are gaps in SPARQL as a mapping language. Recursive property paths (*, +) in the user query are unsupported in our current framework, mirroring the restriction in SPARQL entailment (§10.1) [27]; lifting it may require a recursive extension to SPARQL. This restricts paths in the query being rewritten, not in mapping bodies. Indeed, the entailment pattern of Fig. 1 uses rdfs:subClassOf+ freely, because that path is evaluated at the source. For the same absence of recursion, arbitrary nesting of triple terms is out of reach: transforming an unbounded structure such as a list into a triple-term encoding would need one mapping per nesting depth.

Conclusion

We presented ongoing work on SPARQL 1.2 query rewriting over views, and argued for its potential to unify several research directions that have so far been pursued separately: 1. SPARQL 1.1-1.2 interoperability, 2. federation under automatic source selection, and 3. reasoning-through-rewriting. Our approach expresses GAV mappings as SPARQL CONSTRUCT queries, unfolds a user query against them, and optimizes the result. Casting these three problems as one unfolding pipeline lets us position our work against the data integration literature – GAV in particular – and makes findings in any one direction applicable to the others. Because the mappings are explicit and written in SPARQL, the approach is extensible to reification schemes, source mappings, and ontology constructs not foreseen at design time; while being immediately usable, building on practitioners already have.

This paper establishes that positioning and setting. The complete formalization of the rewriting and optimization, as well as further discovery of optimizations and benchmarking thereof is the focus of our ongoing effort. To this end, we will construct a benchmark covering the 1.1-1.2 interoperability use-case, facilitating the development of incremental optimization steps and reporting their effectiveness in future contributions. In our next steps, we concentrate on engine-agnostic optimizations by optimizing the query in serializable form – optimizing for many engines at once rather than one.

Declaration on Generative AI

During the preparation of this work, the author(s) used Claude Opus 4.7 and 4.8 in order to: Paraphrase and reword, improve writing style, perform grammar and spelling checks, and critically review the text written by the authors to highlight essential information. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s)full responsibility for the publication’s content.