Submodule 1.2 workbook — SPARQL deeper · Naruto

01 · Prerequisites

This picks up where 1.1 left off.

The five query patterns here — DESCRIBE, UNION, property paths, FILTER NOT EXISTS, VALUES — build on the SELECT, GROUP BY, ASK, OPTIONAL, and CONSTRUCT patterns in the 1.1 workbook. If those patterns still feel uncertain, work through the 1.1 workbook before continuing here.

The dataset is the same as the 1.1 workbook: data/example.ttl — eight ninja, three teams, two villages, several jutsu, sensei–student and rival relationships. The sensemaking: prefix is bound to https://sensemaking-ai.com/ns/example#. If you are not sure what data is in the file, open it in a text editor before running queries — prediction before execution is the habit.

Loading the Naruto data

From the starter-kit root: fuseki-server --config=fuseki/config.ttl. In the Fuseki UI, load data/example.ttl into the mythology dataset (that is the dataset name the starter kit creates — it serves both the Naruto and mythology workbooks depending on which file you load). All five queries below use the sensemaking: prefix bound to https://sensemaking-ai.com/ns/example#; they will not return results if the mythology domain data is loaded instead of data/example.ttl.

02 · Core SPARQL concepts

The ideas behind these queries.

If you've worked through the Sub-module 1.2 synthesis doc, skip ahead — this section condenses that material for quick reference. If you haven't, expand below before running the query lab.

Core SPARQL concepts — expand to review

The endpoint model

A SPARQL endpoint is an HTTP service: you POST a query, you get results back. Two endpoints in this curriculum:

Local Fuseki at localhost:3030 — your data, no rate limits, no internet required.
Wikidata at query.wikidata.org — one of the largest open knowledge graphs, read-only, rate-limited, with Wikidata-specific extensions (SERVICE wikibase:label).

Query anatomy

① PREFIX declarations — short aliases for full IRIs
PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

② SELECT clause — which variables to project
SELECT ?name ?teamName

③ WHERE clause — graph pattern that must match
WHERE {
  ?ninja a sensemaking:Ninja ;
         schema:name ?name ;
         sensemaking:memberOfTeam ?team .
  ?team schema:name ?teamName .
}

④ Solution modifiers — ORDER BY, LIMIT, GROUP BY
ORDER BY ?teamName ?name

The four query forms

Form	Returns	Use when
`SELECT`	Table of variable bindings	You want a list of facts — the everyday form.
`ASK`	true / false	You only need to know whether a pattern exists.
`CONSTRUCT`	A new RDF graph	You want to derive or transform triples.
`DESCRIBE`	All known facts about a URI	You're exploring an unknown resource.

Three things that surprise people

The LANG tag trap. Multilingual literals multiply rows without a FILTER. Add FILTER (LANG(?label) = "en") whenever data has language-tagged values.
OPTIONAL is a left join. A node with two jutsu appears twice in results. Use GROUP_CONCAT or restructure to collapse to one row.
Plain SPARQL sees only what's in the store. OWL property declarations (symmetric, inverse) have no effect without a reasoner. This becomes Module 2's core topic.

Full detail, query anatomy diagrams, and three live Wikidata queries: Sub-module 1.2 synthesis doc.

03 · The data: three patterns to notice

Read the file before running queries.

Three patterns in example.ttl that become relevant in this workbook's queries. You saw them in the 1.1 workbook too — but the queries here ask them in new ways.

# senseiOf: directed, not declared symmetric
sensemaking:KakashiHatake
    sensemaking:senseiOf
        sensemaking:NarutoUzumaki ,
        sensemaking:SasukeUchiha ,
        sensemaking:SakuraHaruno .

sensemaking:KurenaiYuhi
    sensemaking:senseiOf
        sensemaking:HinataHyuga .

senseiOf is one-directional. The file states who teaches whom, but does not also state who is a student of whom. Query q02 uses UNION to find both sensei and students in a single result. Query q03 uses a property path to chain senseiOf into a team lookup in a single step.

# hasJutsu: only some ninja have it
sensemaking:KakashiHatake
    sensemaking:hasJutsu
        sensemaking:Sharingan ,
        sensemaking:ShadowClone .

sensemaking:NarutoUzumaki
    sensemaking:hasJutsu
        sensemaking:ShadowClone .

# Sakura and Rock Lee: no hasJutsu triple

Absence is not negation. Sakura and Rock Lee have no hasJutsu triple. That does not mean they have no jutsu — it means this dataset does not assert any. Query q04 uses FILTER NOT EXISTS to find exactly these ninja. The open-world assumption distinction matters: the query finds "no jutsu asserted here," not "provably no jutsu."

# rivalOf: asserted one direction only
sensemaking:NarutoUzumaki
    sensemaking:rivalOf
        sensemaking:SasukeUchiha .

sensemaking:Gaara
    sensemaking:rivalOf
        sensemaking:RockLee .

rivalOf is declared symmetric (owl:SymmetricProperty) in the ontology, but plain SPARQL sees only what's in the store. The reverse direction — Sasuke rivals Naruto — is not asserted. Query q02's UNION includes rivals in one direction only. Challenge C3 asks you to use a path to find the reverse.

04 · Query lab

Five patterns, five queries.

Each query introduces one pattern not covered in the 1.1 workbook. Read the pattern description, predict the output, copy the query into Fuseki, then open the "Think about this" panel after running it.

q01

Tell me everything the dataset knows about Kakashi.

Pattern: DESCRIBE · all outgoing triples for a named resource

Open Fuseki ↗

PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

DESCRIBE sensemaking:KakashiHatake

Expected output and how to read it

A small RDF graph in Turtle format — change the Fuseki result format to "Turtle (text/turtle)" in the dropdown. Expect: rdf:type, schema:name, memberOfVillage, memberOfTeam (if any), hasJutsu (×2), senseiOf (×3).

DESCRIBE does not return a table. It returns a graph — a set of triples. Fuseki's default format is JSON-LD or N-Triples; switch to Turtle to read it comfortably. Kakashi should appear as the subject of every triple (Fuseki's default DESCRIBE returns only outgoing triples).

Notice what is absent: triples where Kakashi is the object (e.g., "someone is a student of Kakashi") do not appear in Fuseki's default DESCRIBE. Some endpoints return both directions. This is implementation-defined — the SPARQL spec only says DESCRIBE should return "relevant" facts.

Think about this

1. DESCRIBE a different ninja — try sensemaking:RockLee. How many triples does Rock Lee have? Compare to Kakashi. Which properties are present for both? Which are unique to Kakashi?

2. Write a SELECT that returns the same predicates as the DESCRIBE output. Which is easier to write? Which is easier to read? When would you reach for DESCRIBE in practice?

3. DESCRIBE accepts a WHERE clause: DESCRIBE ?ninja WHERE { ?ninja sensemaking:senseiOf sensemaking:NarutoUzumaki . } — what does this return? How does it differ from DESCRIBE on a fixed IRI?

q02

Who plays a relational role — sensei OR rival of someone?

Pattern: UNION · merge two independent graph patterns · DISTINCT deduplication

Open Fuseki ↗

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT DISTINCT ?name ?role WHERE {
  {
    ?ninja sensemaking:senseiOf ?student .
    ?ninja schema:name ?name .
    BIND("sensei" AS ?role)
  }
  UNION
  {
    ?ninja sensemaking:rivalOf ?other .
    ?ninja schema:name ?name .
    BIND("rival" AS ?role)
  }
}
ORDER BY ?role ?name

Expected output

5 rows · rival: Gaara, Naruto Uzumaki · sensei: Kakashi Hatake, Kurenai Yuhi · (Kakashi appears only once despite having 3 students — DISTINCT collapses them)

UNION concatenates two independent result sets. Without DISTINCT, Kakashi appears three times in the "sensei" results — once for each student the pattern matches. DISTINCT collapses duplicate rows. BIND assigns a constant string to a variable — here it labels which branch of the UNION each row came from.

UNION does not deduplicate across the two branches automatically. If a ninja were both a sensei and a rival, they would appear twice — once per branch. DISTINCT in the SELECT clause handles that.

Think about this

1. Remove DISTINCT. How many rows now? Count the Kakashi rows. Why three?

2. Add a third UNION branch: UNION { ?ninja sensemaking:memberOfTeam ?t . ?ninja schema:name ?name . BIND("team member" AS ?role) }. How does the row count change? Does any ninja appear in all three branches?

3. rivalOf is only asserted in one direction (Naruto rivals Sasuke; Gaara rivals Rock Lee). If you add a branch that also looks for ninja who are the object of rivalOf — ?other sensemaking:rivalOf ?ninja — who appears that wasn't there before?

q03

Which sensei teaches students in which teams — in one step?

Pattern: property path · / (sequence) chains two predicates into one pattern

Open Fuseki ↗

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT DISTINCT ?senseiName ?teamName WHERE {
  ?sensei schema:name ?senseiName ;
          sensemaking:senseiOf/sensemaking:memberOfTeam ?team .
  ?team schema:name ?teamName .
}
ORDER BY ?senseiName

Expected output

2 rows · Kakashi Hatake / Team 7 · Kurenai Yuhi / Team 8

The path sensemaking:senseiOf/sensemaking:memberOfTeam is a sequence: traverse senseiOf to get a student, then traverse memberOfTeam from that student to get a team. This collapses what would otherwise be two triple patterns and an intermediate variable into one predicate expression. DISTINCT collapses Kakashi's three students into one row per team.

Without DISTINCT: Kakashi appears three times (once per student who is on Team 7). The path matches, the team is the same, but the intermediate student differs — and intermediate variables are not projected in path expressions, so the rows look identical.

Think about this

1. Rewrite this query without the property path — use two explicit triple patterns and an intermediate variable ?student. Do you get the same result? Which version is easier to read?

2. Try sensemaking:senseiOf+ (one-or-more). Does the result change with this dataset? Why or why not? When would + give a different result than a single hop?

3. Try ^sensemaking:senseiOf (inverse path) starting from a student: change the query to find which sensei teaches a specific ninja by going backwards. Example: who teaches sensemaking:NarutoUzumaki?

q04

Which ninja have no jutsu listed in the dataset?

Pattern: FILTER NOT EXISTS · closed-world query on an open-world dataset

Open Fuseki ↗

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT ?name WHERE {
  ?ninja a sensemaking:Ninja ;
         schema:name ?name .
  FILTER NOT EXISTS {
    ?ninja sensemaking:hasJutsu ?j .
  }
}
ORDER BY ?name

Expected output

3 rows · Kurenai Yuhi, Rock Lee, Sakura Haruno

FILTER NOT EXISTS keeps a row only if the inner pattern does not match. For Sakura: the engine tries to find any triple sensemaking:SakuraHaruno sensemaking:hasJutsu ?j — none exists, so the FILTER passes and Sakura stays in the result.

Critical distinction: this query answers "which ninja have no jutsu asserted in this dataset," not "which ninja have no jutsu." Under the open-world assumption, those are different claims. Sakura's jutsu may simply be missing from this slice of data. The result is a statement about the dataset, not about the Naruto universe.

Think about this

1. Replace FILTER NOT EXISTS with MINUS: } MINUS { ?ninja sensemaking:hasJutsu ?j . } — put MINUS outside the outer WHERE pattern. Do you get the same result? FILTER NOT EXISTS and MINUS are not identical for all inputs — can you construct a case where they differ?

2. Change the inner pattern to look for team membership instead of jutsu: find ninja with no team. Who appears? Compare to the output of Challenge C1 in the 1.1 workbook — should be the same characters.

3. Combine: find ninja with no jutsu AND no team — two FILTER NOT EXISTS blocks. Who survives both conditions?

q05

Show me the village and team for these three specific ninja.

Pattern: VALUES · inline data · parameterized lookup with OPTIONAL

Open Fuseki ↗

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT ?name ?villageName ?teamName WHERE {
  VALUES ?ninja {
    sensemaking:NarutoUzumaki
    sensemaking:SasukeUchiha
    sensemaking:Gaara
  }
  ?ninja schema:name ?name ;
         sensemaking:memberOfVillage ?village .
  ?village schema:name ?villageName .
  OPTIONAL {
    ?ninja sensemaking:memberOfTeam ?team .
    ?team schema:name ?teamName .
  }
}
ORDER BY ?name

Expected output

3 rows · Gaara / Sunagakure / (no team) · Naruto Uzumaki / Konohagakure / Team 7 · Sasuke Uchiha / Konohagakure / Team 7

VALUES injects a fixed set of bindings into the query — equivalent to an inline data table. The engine runs the WHERE pattern for each value in the VALUES block. Gaara has no team, so ?teamName is unbound for his row (OPTIONAL keeps him in the result).

VALUES is useful for parameterization: the query structure stays constant while the specific resources change. It is also how you replicate an IN(...) clause from SQL — instead of a FILTER with OR chains, use VALUES.

Think about this

1. Add sensemaking:KakashiHatake to the VALUES list. Does he have a team? Check example.ttl — is memberOfTeam asserted for sensei characters?

2. Remove the OPTIONAL block. What happens to Gaara's row? How does this change your understanding of how VALUES interacts with required triple patterns?

3. VALUES can bind multiple variables at once: VALUES (?ninja ?expectedVillage) { (sensemaking:Gaara sensemaking:Sunagakure) (sensemaking:NarutoUzumaki sensemaking:Konohagakure) }. Extend the query to FILTER for cases where the actual village matches the expected one — or doesn't.

05 · Modification challenges

Four things to build.

Each challenge extends or recombines patterns from the query lab. Write the query before opening the solution panel.

C1 Find all characters who are rivals of someone — in both directions

In the dataset, rivalOf is asserted one way: Naruto rivals Sasuke; Gaara rivals Rock Lee. But rivalry should be mutual. Use UNION to find all characters who appear on either side of a rivalOf triple. Return each character's name once (use DISTINCT).

Expected result and one approach

Expected: 4 rows — Gaara, Naruto Uzumaki, Rock Lee, Sasuke Uchiha. Rock Lee and Sasuke appear as objects of rivalOf triples, not subjects.

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT DISTINCT ?name WHERE {
  {
    ?n sensemaking:rivalOf ?other .
    ?n schema:name ?name .
  }
  UNION
  {
    ?other sensemaking:rivalOf ?n .
    ?n schema:name ?name .
  }
}
ORDER BY ?name

This is why rivalOf being owl:SymmetricProperty matters: with a reasoner, you would not need the UNION — the engine would derive the reverse triples automatically. Without a reasoner, UNION is how you query in both directions at once.

C2 Use an inverse path to find all students of a given sensei

The ^ operator inverts a property path: ?student ^sensemaking:senseiOf ?sensei traverses senseiOf backwards. Rewrite q03 to start from a fixed sensei IRI and find all their students using ^sensemaking:senseiOf. Return student names only.

Expected result and one approach

Expected for Kakashi: 3 rows — Naruto Uzumaki, Sakura Haruno, Sasuke Uchiha.

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT ?studentName WHERE {
  ?student ^sensemaking:senseiOf sensemaking:KakashiHatake ;
           schema:name ?studentName .
}
ORDER BY ?studentName

Equivalently: sensemaking:KakashiHatake sensemaking:senseiOf ?student — the inverse path is not strictly necessary here since the data has senseiOf asserted in the subject→object direction. But ^ is useful when you only have access to the object-side of a triple and want to "walk back."

C3 Find all jutsu that appear in the dataset, regardless of who has them

Write a SELECT that returns the label of every jutsu in the dataset — distinct values, sorted. Use skos:prefLabel if jutsu are typed as skos:Concept, or rdfs:label if they use that predicate. Check example.ttl to see how jutsu are modeled before writing the query.

Expected result and one approach

Expected: 4–5 rows — Byakugan, Sand Manipulation, Shadow Clone Jutsu, Sharingan (and any others in the file). The exact set depends on what's asserted in example.ttl.

PREFIX skos:        <http://www.w3.org/2004/02/skos/core#>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT DISTINCT ?jutsuLabel WHERE {
  ?jutsu a skos:Concept ;
         skos:prefLabel ?jutsuLabel .
  FILTER (LANG(?jutsuLabel) = "en" || LANG(?jutsuLabel) = "")
}
ORDER BY ?jutsuLabel

The LANG filter handles both the case where labels have no language tag (LANG returns "") and where they have @en explicitly. Without it, multilingual labels would produce duplicate rows per jutsu.

C4 Combine UNION and FILTER NOT EXISTS

Find all ninja who are "involved" — either a sensei of someone, or on a team — but who have NO jutsu listed. This combines the UNION pattern from q02 with the FILTER NOT EXISTS pattern from q04. Return names sorted alphabetically.

Expected result and one approach

Expected: 2 rows — Kurenai Yuhi (sensei, no jutsu) and Rock Lee (Team Guy, no jutsu). Sakura has no jutsu but is also a team member — she should appear too. Verify against your dataset.

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/example#>

SELECT DISTINCT ?name WHERE {
  ?ninja a sensemaking:Ninja ;
         schema:name ?name .
  {
    ?ninja sensemaking:senseiOf ?student .
  }
  UNION
  {
    ?ninja sensemaking:memberOfTeam ?team .
  }
  FILTER NOT EXISTS {
    ?ninja sensemaking:hasJutsu ?j .
  }
}
ORDER BY ?name

Note how FILTER NOT EXISTS operates on the full row from the outer WHERE block — it checks each matched ninja (from either UNION branch) for the absence of jutsu. The DISTINCT collapses duplicates from a ninja matching both branches.

06 · Curated resources

Five good next reads.

Query reference

Learning SPARQL

DuCharme. The curriculum's canonical SPARQL reference. Chapters 3–4 cover property paths, aggregation, and CONSTRUCT in depth — the natural next step from this workbook.

Synthesis doc

Sub-module 1.2 synthesis

The reading companion for this workbook. Covers the four query forms conceptually and has three runnable Wikidata queries if you haven't tried the public endpoint yet.

Public endpoint

Wikidata Query Service

Apply the property path and UNION patterns here on a dataset with millions of nodes. The helper UI provides example queries — modify them rather than starting from scratch.

W3C spec

SPARQL 1.1 specification

Authoritative on FILTER NOT EXISTS vs MINUS (section 8.3), property paths (section 9), and VALUES (section 10.3). Read the relevant sections when something surprising happens.

Domain variant

Mythology workbook

Same five patterns applied to Greek mythology data. Deities, realms, powers, and championed relationships. If Naruto is familiar ground, the mythology domain forces you to read the data rather than rely on domain knowledge.

Module context

Module 1 README

The exercise list and primary project. The SPARQL patterns in this workbook map directly to the three queries Exercise 1.3 asks you to write against your own resume data.

Cheatsheet

Module 1 SPARQL quick-reference (coming soon)

Prefix block, query anatomy, all five query patterns from this workbook — one-page reference card. Available when Module 1 materials are complete.