SPARQL UPDATE.

After running, switch to the Query tab and run:

SELECT ?name ?rank WHERE {
  naruto:JiraiyaSannin naruto:canonicalName ?name ;
                       naruto:hasRank ?rank .
}

If you get one row with "Jiraiya" and naruto:Jonin, the insert succeeded. If no rows: check that you ran it in the Update tab (not the Query tab) and that Fuseki shows a success message.

To undo: Run DELETE DATA { naruto:JiraiyaSannin naruto:canonicalName "Jiraiya" ; a naruto:Ninja ; ... } with all the same triples, or run u05 (CLEAR) and reload the original TTL.

1. INSERT DATA requires all values to be specified explicitly — no variables. What would you do if you wanted to insert Jiraiya with the same village as Kakashi (looked up dynamically)? That requires INSERT WHERE, not INSERT DATA.

2. Run the INSERT DATA twice without any changes. What happens? Does Fuseki create a duplicate node, a duplicate triple, or does it silently succeed with no change? What does this tell you about how RDF handles duplicate assertions?

After the update:

SELECT ?rank WHERE {
  naruto:NarutoUzumaki naruto:hasRank ?rank .
}

Should return exactly one row: naruto:Jonin. If you run the UPDATE twice, the second execution should be a no-op — the WHERE clause fails because Naruto is no longer Genin, so neither DELETE nor INSERT fires.

1. What would happen if you wrote this as two separate requests — a DELETE request followed by an INSERT request — instead of a combined DELETE … INSERT … WHERE? What could go wrong if another client reads the store between the two requests?

2. This update does not capture when the rank changed or who authorized it. How would you extend the update to add a provenance triple simultaneously (e.g., using the named graph pattern from Submodule 3.2)?

After the update, confirm the inverse triples exist:

SELECT ?student ?sensei WHERE {
  ?student naruto:studentOf ?sensei .
}

Should return the same pairs as querying senseiOf, with subject and object swapped: Naruto studentOf Kakashi, Sasuke studentOf Kakashi, Sakura studentOf Kakashi, Hinata studentOf Kurenai (and now Naruto studentOf Jiraiya if u01 ran first).

Run the UPDATE again. The FILTER NOT EXISTS guard means it is idempotent — no duplicate triples are added on the second run.

1. This operation does the same thing as the CONSTRUCT + materialization approach from Submodule 3.1. What is the operational difference? (CONSTRUCT produces a graph you load manually; INSERT WHERE writes directly into the store.)

2. If you later add new senseiOf triples, the materialized studentOf triples do not update automatically. How would you manage this in a production system that receives ongoing data updates?

After the update, query the named graph directly:

SELECT ?name WHERE {
  GRAPH naruto:ChunexamsCharacters {
    ?ninja naruto:canonicalName ?name .
  }
}
ORDER BY ?name

Should return all ninja who appear in the Chunin Exams arc. Compare to the plain dataset query (without GRAPH) — the arc information now exists in both the default graph and the named graph. The named graph can carry its own provenance metadata (dcterms:created, a prov:Entity, etc.).

1. Add provenance metadata to the named graph itself in the default graph: INSERT DATA { naruto:ChunexamsCharacters dcterms:created "2026-06-03"^^xsd:date . }. Now the graph has both data (inside it) and metadata (about it in the default graph) — the full named graph provenance pattern from Submodule 3.2.

2. If you later run this operation again after adding more characters with appearsInArc, what happens to the existing named graph content? Are old entries removed or does new data just accumulate?

COPY DEFAULT TO GRAPH naruto:SnapshotBeforeBulkUpdate copies all triples from the default graph into a named graph, preserving a rollback point. CLEAR DEFAULT removes all triples from the default graph (the named graph snapshot is unaffected). LOAD reads a file into the store.

This is the production workflow for bulk data refreshes: snapshot → verify → clear → reload. If the reload fails, the snapshot named graph still exists and can be recovered with COPY GRAPH naruto:SnapshotBeforeBulkUpdate TO DEFAULT.

The CLEAR and LOAD lines are commented out deliberately — uncomment them only after verifying the snapshot succeeded by counting triples in the named graph and confirming the count matches the default graph.

1. COPY + CLEAR is not atomic as two separate statements in Fuseki. Between the COPY and the CLEAR, another client could query the store and see data in both places. Chain them in a single UPDATE request (separated by semicolons) to minimize the window. What risks remain even with chaining?

2. Ontology versioning: if you increment owl:versionInfo from "starter" to "1.0.0" as part of a bulk update, how would you capture both the old and new version information in the graph metadata? What SPARQL Update operations would you need?