Advanced SPARQL

Concepts#

1. 1 Property Patha predicate position that matches a whole path (/, *), e.g. instances of all subclasses of a class start here
2. 2 Optional Graph PatternOPTIONAL { … } keeps rows where data is missing, and several of them give fallbacks
3. 3 SPARQL AggregationGROUP BY + COUNT/SUM/AVG, and sub-SELECTs to aggregate before joining
4. 4 SPARQL BINDBIND (expr AS ?v) adds a computed column
5. 5 Spatial JoinFILTER on geof:distance between WKT geometries

Basics from DBIS, used throughout: RDF Triple, SPARQL Query Structure (patterns, FILTER, LANG), Wikidata Prefix System, Ordering (ORDER BY, LIMIT).

How it fits together#

Every construct is an operation on the result table. A basic pattern produces one row per match (SPARQL Query Structure). Each construct then changes either the set of rows or the set of columns, and keeping track of that is what makes a query predictable:

¹ The SQL comparison in these rows goes beyond ADIS Lecture 1. p* would need a recursive query in SQL.

Filter placement decides the meaning. A FILTER restricts the group it is written in. Inside an OPTIONAL it only restricts the optional part, so the row survives. Outside, it removes rows. The same rule makes the order of several OPTIONALs a priority list (Hindi, else Arabic).

Duplicates come from paths and joins. A Property Path gives one result per path, so a node reachable in several ways appears several times, hence DISTINCT. Aggregation is the other way to collapse rows, but then every selected variable must be grouped or aggregated.

Efficiency: shrink before you join. The flat aggregation query joins every paper row with the venue label and then groups. The sub-SELECT groups first and joins the label only once per venue. Same result, fewer rows in the join. BIND goes one step further and drops the label join entirely by deriving the name from the IRI. The price is that the result is the IRI suffix, not the label stored in the KG.

Writing a query (ES1 workflow). Start from a small, correct pattern on the endpoint, check it, then add one construct at a time: a Property Path for class membership, an OPTIONAL for data that may be missing, FILTER for languages or distances, aggregation and ORDER BY/LIMIT at the end. The autocompletion of the QLever UI or exploratory queries find the right predicate and entity IDs (ADIS_VL01 > Hints for Exercise Sheet 1).

Key Formulas#

Query skeleton showing where each construct of this topic goes, in the required clause order (positions only, not a meaningful query):

PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT DISTINCT ?g (COUNT(?x) AS ?n) WHERE {    # aggregate: SPARQL Aggregation
  ?s wdt:P31/wdt:P279* ?class .                 # Property Path
  OPTIONAL { ?s rdfs:label ?l FILTER (LANG(?l) = "hi") }   # Optional Graph Pattern
  BIND (STR(?s) AS ?v)                          # SPARQL BIND
  { SELECT … WHERE { … } GROUP BY … }           # sub-SELECT
  FILTER (geof:distance(?w1, ?w2, unit:M) <= 500)          # Spatial Join
}
GROUP BY ?g
ORDER BY DESC(?n)
LIMIT 10                                        # LIMIT after ORDER BY

Lectures#

• ADIS_VL01 — More SPARQL by Example (slides 15–24), on Wikidata, DBLP and OpenStreetMap

Related Topics#

• SPARQL and Knowledge Graphs — DBIS basics this topic builds on: RDF, basic queries, reification, Wikidata prefixes, SPARQL to SQL
• SQL and Query Planning — DBIS: the relational counterparts (join, group-by, subqueries, ordering)