Evaluation semantics & performance

Writing correct SPARQL means knowing the evaluation model, not just the syntax. A query is a tree of algebra operators; the engine evaluates them in this logical order:

BGP join → OPTIONAL (LeftJoin) → UNION → FILTER → GROUP BY →
aggregates → HAVING → BIND/project → ORDER BY → DISTINCT → OFFSET → LIMIT

Three consequences professionals rely on:

1. A FILTER constrains its whole group, regardless of where you type it (from the FILTER lesson) — but the planner is free to push a selective filter down so it runs early. You write for clarity; the engine reorders for speed.
2. OPTIONAL and UNION block some optimisations. They produce unbound variables and larger intermediate results, so an over-used OPTIONAL is a common cause of slow queries. Ask whether you truly need the row kept when the part is missing.
3. Selectivity first. The cost of a join is driven by the size of intermediate bindings. Put the most selective pattern (a constant subject, a rare type) first so every later pattern joins against a small set.

The dataset, named graphs, and federation

• FROM / FROM NAMED define the active dataset: FROM merges graphs into the default graph; FROM NAMED makes them addressable via GRAPH ?g { ... }. Getting the dataset wrong is the #1 cause of empty-but-valid results.
• GRAPH ?g { ... } scopes a pattern to named graphs — the same mechanism Level 7 uses as an access-control boundary.
• SERVICE <endpoint> { ... } federates: part of the query runs on a remote SPARQL endpoint and the results join locally. Powerful, but the remote call dominates cost — send it the most constrained sub-pattern, and never a SERVICE inside a tight OPTIONAL loop.

A practical tuning checklist

1. Anchor patterns with constants; lead with the most selective triple.
2. Replace {...} UNION {...} on a shared variable with VALUES or a | path where possible.
3. Prefer FILTER NOT EXISTS over dragging rows through an OPTIONAL + !bound when you only need existence.
4. Add LIMIT while developing; add a total ORDER BY before relying on it.
5. Profile with the engine's EXPLAIN (most stores have one) and compare intermediate-result sizes, not just wall-clock.