rocket_launchForward edge — what's next

The entire SPARQL surface — read, write, CONSTRUCT, DESCRIBE, property paths, named graphs — is shipped on the tagged, Latest v0.6.14 release. This page records the SPARQL pillar's forward edge; for the broader v0.6 plan across every pillar see the Roadmap.

check_circleShipped (tagged releases)

The SPARQL surface graduated in phases through the v0.4 cut and has been stable across the v0.5 → v0.6 line:

• check_circleGraph lifecycle UDFs — drop_graph, clear_graph, copy_graph, move_graph.
• check_circleFull SPARQL UPDATE surface — INSERT/DELETE DATA, pattern-driven INSERT/DELETE WHERE, atomic DELETE+INSERT/WHERE, WITH + inline GRAPH scoping, DROP/CLEAR/CREATE lifecycle algebra.
• check_circleCONSTRUCT — constant-only + variable + blank-node + multi-triple templates, GRAPH-scoped WHERE, WHERE-shorthand, round-trip ingest, sparql_parse shape analysis.
• check_circleProperty paths — ^ + * ? | with cycle-safe recursive CTEs, the pgrdf.path_max_depth guard, W3C §9.3 zero-length semantics, and the materialised-closure no-CTE fast path.
• check_circleThe residual read surface — DESCRIBE (W3C §16.4 CBD via pgrdf.describe), VALUES inline bindings, downstream BIND (after the BGP block), aggregates over UNION, type-aware ORDER BY, multi-triple OPTIONAL, TriG + N-Quads ingest (pgrdf.parse_trig / pgrdf.parse_nquads), BIGINT and IRI overloads on every lifecycle UDF (drop_graph / clear_graph / copy_graph / move_graph), the pgrdf.materialize(g, profile) selector ('owl-rl' + 'rdfs'), W3C SHACL Core 25/25 plus the wired W3C SHACL manifest runner, and the native SHACL-SPARQL engine (pgrdf.validate(…, mode => 'pgrdf')) — the shipped, authoritative SHACL-SPARQL gate evaluating sh:sparql / sh:select / sh:ask constraints directly against the hexastore (see SHACL-SPARQL).

The SPARQL read and write surface, named graphs, lifecycle, CONSTRUCT, DESCRIBE, VALUES, and property paths are all on the tagged, Latest v0.6.14 release. The whole surface is exercised by the test bar (294 pgrx + 93 pg_regress + 51 W3C-SPARQL + 25 W3C SHACL Core + 3 LUBM).

rocket_launchStill ahead — the forward backlog

The SPARQL pillar is feature-complete for its scope. The forward backlog in the v0.6-FUTURE spec is performance and depth work, not missing pillar surface:

• rocket_launchexecutor.rs core-BGP carve — restructure the BGP translator core for clarity and reuse.
• rocket_launchFederated SERVICE — query across remote SPARQL endpoints.
• rocket_launchIncremental materialisation — re-materialise only the affected closure on graph delta.
• rocket_launchRDF 1.2 triple terms — see the upstream gate below.

The bulk-ingest line (the staged loader and big-RAM tuning) is the other major thread of the v0.6 line — covered in full on the Roadmap and the Storage pillar.

scheduleDocumented upstream gates (not pgRDF defects)

Two items are blocked on a third-party crate. They are documented upstream dependencies — the pgRDF side is built and shipped; the upstream side is the gate:

Erratum	What	Upstream gate
E-011	RDF 1.2 triple terms and the crates.io publish	Both wait on gtfierro/reasonable#50. The crates.io publish is deliberately held until that lands — the tarball / OCI bundle are the consumption path meanwhile.
E-014	rudof 'sparql' mode returns the wrong verdict on common SHACL-SPARQL topologies	Engine reachability (E-012) is resolved in shacl 0.3.2 — mode => 'sparql' now reaches the rudof SparqlEngine. But the engine returns conforms=true / 0 violations where the W3C answer is non-conforming. SHACL-SPARQL constraint execution itself is shipped: the authoritative pgrdf.validate(…, mode => 'pgrdf') gate returns the correct verdict (3 violations on node-sparql-001). The open item is purely the rudof verdict bug, tracked on rudof. See SHACL-SPARQL.

Spec-permitted gaps (by design, not "coming soon")

These are explicitly out of scope per the LLD — pgRDF rejects them with a stable prefix rather than silently mis-answering:

• Negated property sets ?s !(p) ?o — panics with a stable prefix.
• Explicit sequence path-expressions ?s p1/p2 ?o — use the equivalent multi-pattern BGP { ?s p1 ?m . ?m p2 ?o }; the explicit Sequence path-expr is rejected with a pointer to the BGP form.
• The gated path remainder — an alternation arm that is itself a sequence/recursive path ((a/b|c), (a+|b)), or a recursive operator whose inner box is a sequence ((p1/p2)+). Folding these would compose a recursive CTE inside an alternation arm; the LLD explicitly permits gating them. They preview-panic with a stable nested-recursive prefix. sparql_parse does not panic — it flags only the gated remainder in unsupported_algebra.