All You Need Is CONSTRUCT

In SPARQL, the query forms SELECT and CONSTRUCT have been the subject of several studies, both theoretical and practical. However, the composition of such queries and their interweaving when forming involved nested queries has not yet received much interest in the literature. We mainly tackle the problem of composing such queries. For this purpose, we introduce a language close to SPARQL where queries can be nested at will, involving either CONSTRUCT or SELECT query forms and provide a formal semantics for it. This semantics is based on a uniform interpretation of queries. This uniformity is due to an extension of the notion of RDF graphs to include isolated items such as variables. As a key feature of this work, we show how classical SELECT queries can be easily encoded as a particular case of CONSTRUCT queries.

💡 Research Summary

The paper addresses a long‑standing inconsistency in SPARQL: SELECT queries return multisets of solution mappings, whereas CONSTRUCT queries return RDF graphs. This duality makes the composition of nested queries cumbersome, because the result of one query cannot be directly fed into another without ad‑hoc transformations such as the FROM clause. To overcome this, the authors propose a unified graph‑theoretic framework that treats both query forms uniformly.

First, they extend the classical definition of an RDF graph. In addition to the usual triples (subject, predicate, object), the extended graph may contain “isolated items” – variables and blank nodes – as first‑class nodes. Consequently, a mapping from a query graph to a data graph is no longer a simple variable assignment; it is a partial graph homomorphism that preserves nodes and triples while fixing all IRIs (the constant symbols). This perspective allows the authors to view mappings as structural morphisms rather than mere bindings.

Building on this foundation, the paper defines a suite of algebraic operations on sets of mappings: join, filter, restriction, extension, union, and projection. The extension operation is particularly important because it provides three systematic ways to enlarge a mapping’s domain: (1) Ext⊥ leaves newly introduced variables undefined, (2) ExtIB introduces fresh blank nodes for new blank identifiers, and (3) Ext var≈expr binds a single variable to the value of an expression evaluated on the current mapping. All extensions preserve the cardinality of the mapping set while aligning the domains of different mapping collections, which is essential for a uniform treatment of nested queries.

With these primitives, the authors introduce GrAL (Graph Algebraic Query Language), a SPARQL‑like language whose syntax is pattern‑centric. A pattern may be a basic query graph, or it may be built recursively using operators such as AND, UNION, OPTIONAL, FILTER, EXISTS, and NOT EXISTS. Expressions can be constants, variables, blanks, or sub‑pattern existence checks. The semantics of a pattern over a data graph is a set of mappings obtained via the previously defined algebraic operations.

The crucial step is the mapping from this set of mappings to the final query result, which depends on the query form:

• SELECT‑DISTINCT returns the set of mappings without duplicates.
• SELECT returns a multiset of mappings (preserving multiplicities).
• CONSTRUCT transforms the set of mappings into a graph by taking the union of the images of all mappings – essentially the “graph image” of the query graph under each mapping.

Because the CONSTRUCT result is derived directly from the same mapping set that underlies SELECT, the authors prove that any SELECT query can be encoded as a particular CONSTRUCT query. In practice, this means that the two query forms are interchangeable within the unified semantics, eliminating the need for separate handling in nested contexts.

The paper illustrates the approach with a concrete example: retrieving pairs of e‑mail addresses belonging to co‑authors. The example combines an inner CONSTRUCT that builds a co‑author relationship graph and an outer SELECT that extracts the corresponding e‑mail triples. The entire query is expressed as a single GrAL pattern without any FROM clause, demonstrating that nested SELECT and CONSTRUCT queries can be composed seamlessly using the uniform algebra.

In the discussion, the authors highlight three main contributions:

1. A generalized RDF graph model that incorporates variables and blanks as graph nodes, enabling mappings to be treated as graph homomorphisms.
2. A complete algebra of operations on sets of mappings that supports uniform composition of SELECT and CONSTRUCT queries.
3. The definition of GrAL, a language that leverages this algebra to express complex nested queries in a concise, semantically consistent manner.

The paper concludes by suggesting future work on implementing GrAL, benchmarking its performance against existing SPARQL engines, and exploring extensions such as property paths or federated queries. Overall, the work provides a solid theoretical foundation for unifying SPARQL’s query forms and simplifies the design of nested graph queries.