Federation and deployment.

One query, two endpoints.

SPARQL 1.1 defines the SERVICE keyword for federated queries: send part of a query to a remote SPARQL endpoint and join the results with local data. The promise is compelling — your local Naruto graph joins seamlessly with Wikidata's 100 million items. The reality involves latency, rate limits, and fragility that production systems mostly avoid.

The basic pattern:

PREFIX wd:  <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX bd:  <http://www.bigdata.com/rdf#>
PREFIX naruto: <https://sensemaking-ai.com/ns/naruto#>

# Local data: characters who appear in the Pain's Assault arc
# Wikidata: the arc's Wikipedia article metadata
SELECT ?characterName ?articleTitle WHERE {
  # Local graph pattern
  ?ninja naruto:canonicalName ?characterName ;
         naruto:appearsInArc   naruto:PainAssaultArc .

  # Federated pattern — sent to Wikidata's endpoint
  SERVICE <https://query.wikidata.org/sparql> {
    wd:Q26530693 wdt:P18 ?image .  # Naruto series Wikidata item
    BIND("Pain's Assault arc" AS ?articleTitle)
    SERVICE wikibase:label {
      bd:serviceParam wikibase:language "en" .
    }
  }
}

The Fuseki endpoint receives the full query, executes the local pattern against local data, sends the SERVICE subquery to Wikidata, and joins the results. Latency is cumulative — local query time plus Wikidata round-trip time, which can be 2–15 seconds on a cold Wikidata query.

The SILENT modifier

If the remote endpoint is unavailable or times out, a plain SERVICE clause fails the entire query. SERVICE SILENT treats failure as returning no rows from the remote endpoint — the rest of the query continues with the local data:

# SILENT: if Wikidata is down, return local results only
SERVICE SILENT <https://query.wikidata.org/sparql> {
  SELECT ?label WHERE {
    wd:Q2009573 rdfs:label ?label .
    FILTER (LANG(?label) = "en")
  }
}

Use SILENT for any remote endpoint you do not control. Wikidata's query service goes down several times per year and rate-limits heavy queries aggressively.

Why production systems mostly avoid it.

• Latency is cumulative. A local query that runs in 50ms can take 5 seconds with a Wikidata SERVICE clause because the remote endpoint has its own query execution time plus network round-trip. If the federated query runs at user request time, users notice.
• Endpoint availability is not guaranteed. Wikidata times out on queries that take more than 60 seconds. It rate-limits clients. It occasionally goes fully offline for maintenance. Any production feature that requires Wikidata to be up will sometimes fail.
• Remote schema changes break queries silently. Wikidata can add, rename, or deprecate properties. A query using wdt:P18 (image) that runs today may return nothing next month if the property mapping changes. Federated queries have no schema contract.
• The alternative production pattern. Most systems that depend on external data materialize it locally: a scheduled job fetches the needed triples from Wikidata, stores them in the local triplestore, and queries are entirely local. Refresh frequency depends on how stale the data can be. This is faster, more reliable, and easier to debug.

Five viable options, each with rough edges.

The Module 4 README names this as a pain point: "no Postgres-equivalent." Choosing a triplestore means accepting specific tradeoffs. Here are the five most relevant for a solo practitioner or small team deploying on EC2:

For Exercise 4.1, the Module 4 README recommends Oxigraph for first deployment: single binary, no JVM, simple systemd service file, RDF-star support out of the box. Fuseki is the fallback if you prefer the reference implementation you have been using throughout the curriculum.

Semver doesn't quite map.

The Module 4 README calls ontology versioning "unsolved." Standard software version semantics (major.minor.patch) do not map cleanly onto ontology changes:

• Adding a new class or property is usually non-breaking — existing data still validates.
• Adding a required restriction is potentially breaking — data that was valid before may now fail SHACL validation.
• Removing a class or property is breaking — any data using the removed term is now untyped.
• Changing a property's domain or range is breaking — existing data may violate the new constraint.

OWL 2 provides three annotation properties for versioning:

@prefix owl: <http://www.w3.org/2002/07/owl#> .

<https://sensemaking-ai.com/ns/naruto>
    owl:versionInfo           "1.0.0" ;
    owl:priorVersion          <https://sensemaking-ai.com/ns/naruto/starter> ;
    owl:backwardCompatibleWith <https://sensemaking-ai.com/ns/naruto/starter> .

# Declare incompatibility explicitly when breaking changes are made
# owl:incompatibleWith <...prior-version>

The practical recommendation: use `owl:versionInfo` for display purposes and commit-level version tracking. Treat the Git history as your actual version control — every commit is a point in time you can diff and restore. OWL versioning annotations are supplementary metadata, not a substitute for version control on the file.

Add a triplestore to your existing EC2 infrastructure.

These steps assume you already have an EC2 instance with nginx and systemd, following the same pattern as your existing services. Expand each step when ready to execute it.

curl -LO https://github.com/oxigraph/oxigraph/releases/latest/download/oxigraph_linux_x86_64
chmod +x oxigraph_linux_x86_64
sudo mv oxigraph_linux_x86_64 /usr/local/bin/oxigraph
oxigraph --version

sudo mkdir -p /var/lib/oxigraph/naruto
sudo chown www-data:www-data /var/lib/oxigraph/naruto

[Unit]
Description=Oxigraph SPARQL endpoint — Naruto KG
After=network.target

[Service]
Type=simple
User=www-data
ExecStart=/usr/local/bin/oxigraph serve \
  --location /var/lib/oxigraph/naruto \
  --bind 127.0.0.1:7878
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable oxigraph
sudo systemctl start oxigraph
sudo systemctl status oxigraph

server {
    server_name sparql.barbhs.com;

    location / {
        proxy_pass http://127.0.0.1:7878;
        proxy_set_header Host $host;

        # CORS for browser SPARQL clients
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers'
            'Accept, Content-Type, Authorization' always;

        if ($request_method = OPTIONS) {
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain charset=UTF-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }

    # SSL — certbot will add this block automatically
}

sudo ln -s /etc/nginx/sites-available/sparql.barbhs.com \
           /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d sparql.barbhs.com

scp modules/02-modeling/artifacts/naruto-ontology/naruto-ontology-1.0.0.ttl \
    ec2-user@your-instance:/tmp/

# Load via HTTP
curl -X PUT https://sparql.barbhs.com/store \
  -H "Content-Type: text/turtle" \
  --data-binary @/tmp/naruto-ontology-1.0.0.ttl

# Verify with a test query
curl "https://sparql.barbhs.com/query?query=SELECT+%2A+WHERE+%7B+%3Fs+%3Fp+%3Fo+%7D+LIMIT+10" \
  -H "Accept: application/sparql-results+json"

Three queries — Exercise 4.2 patterns.

Run these from your local Fuseki against the public Wikidata endpoint. They demonstrate the federation patterns for Exercise 4.2 and directly expose the failure modes described in Section 2.

PREFIX wd:      <http://www.wikidata.org/entity/>
PREFIX wdt:     <http://www.wikidata.org/prop/direct/>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX bd:      <http://www.bigdata.com/rdf#>
PREFIX schema:  <https://schema.org/>
PREFIX naruto:  <https://sensemaking-ai.com/ns/naruto#>

# Local: which arcs are in the Naruto ontology?
# Remote: look up the Naruto series item on Wikidata for metadata
SELECT ?arcName ?wikidataLabel WHERE {
  ?arc a naruto:Arc ;
       schema:name ?arcName .
  FILTER (LANG(?arcName) = "en")

  SERVICE SILENT <https://query.wikidata.org/sparql> {
    SELECT ?wikidataLabel WHERE {
      wd:Q2009573 rdfs:label ?wikidataLabel .
      FILTER (LANG(?wikidataLabel) = "en")
    }
  }
}
ORDER BY ?arcName

PREFIX wd:      <http://www.wikidata.org/entity/>
PREFIX wdt:     <http://www.wikidata.org/prop/direct/>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX bd:      <http://www.bigdata.com/rdf#>

# Exercise 4.2 specifies using your father's published patents
# as an example of real federated data retrieval.
# Replace Q_ID with the actual Wikidata ID for the person.
# Search at wikidata.org to find the Q-number first.

SELECT ?patent ?patentLabel ?date WHERE {
  SERVICE <https://query.wikidata.org/sparql> {
    ?patent wdt:P31  wd:Q253623 ;  # instance of: patent
            wdt:P178 wd:REPLACE_WITH_INVENTOR_Q_ID .
    OPTIONAL { ?patent wdt:P577 ?date . }
    SERVICE wikibase:label {
      bd:serviceParam wikibase:language "en" .
    }
  }
}
ORDER BY DESC(?date)

PREFIX wd:      <http://www.wikidata.org/entity/>
PREFIX wdt:     <http://www.wikidata.org/prop/direct/>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX bd:      <http://www.bigdata.com/rdf#>
PREFIX schema:  <https://schema.org/>

# Query Wikidata for items tagged as Naruto characters.
# This is what a nightly materialization job would run to
# prefetch metadata rather than federating at query time.
SELECT ?character ?characterLabel ?gender ?voiceActor WHERE {
  SERVICE <https://query.wikidata.org/sparql> {
    ?character wdt:P31    wd:Q15711870 .  # instance of: fictional character
    ?character wdt:P1080  wd:Q2009573 .   # from fictional universe: Naruto
    OPTIONAL { ?character wdt:P21 ?gender . }
    OPTIONAL { ?character wdt:P725 ?voiceActor . }
    SERVICE wikibase:label {
      bd:serviceParam wikibase:language "en" .
    }
  }
}
ORDER BY ?characterLabel
LIMIT 20

Reading, tools, and next steps.