Who was praetor in 150 BC?

The problem

The Digital Prosopography of the Roman Republic (DPRR) is a dataset of political figures in the Roman Republic: magistrates, priests, senators, their offices, dates, and family relationships. It's built from decades of scholarship, primarily Broughton's Magistrates of the Roman Republic (1951–1986). The data is available as RDF, queryable via SPARQL.

The problem: SPARQL is not something most people can write from scratch. The DPRR ontology has its own vocabulary, its own conventions, its own quirks. Even researchers who know the dataset well spend time wrangling queries. And the upstream site experiences frequent downtime.

I wanted to see if an LLM could bridge that gap by taking a natural language question about Roman Republican prosopography and turn it into a valid SPARQL query, execute it, and synthesize the results with appropriate scholarly caveats.

The approach

Projects like sparql-llm from the Swiss Institute of Bioinformatics have explored this space with a full retrieval pipeline of vector stores for query examples, schema indexing, and validation feedback loops. I wanted something lighter. Skip the retrieval infrastructure and give the LLM direct access to the schema and a query executor.

I built dprr-mcp, an MCP server that bundles the DPRR RDF dataset in a local Oxigraph store and exposes three tools:

• get_schema. Returns the DPRR ontology: prefixes, classes, properties, and query tips
• validate_sparql. Syntax check with auto-repair for missing PREFIX declarations, plus semantic validation against the ontology
• execute_sparql. Full validation + execution against the local store

The key design decision: don't try to answer questions directly from the data. Instead, give the LLM the tools to generate, validate, and execute structured queries. The LLM handles the natural language → SPARQL translation. The SPARQL engine handles correctness. The LLM then synthesizes the results.

This is retrieval-augmented generation in the literal sense. The model retrieves structured data through a formal query language, not a vector similarity search. No embeddings. No chunking. No fuzzy matching. The query either returns the right triples or it doesn't.

What works

Ask "Who held the office of praetor in 150 BC?" and the system generates a SPARQL query against the DPRR ontology, validates it, executes it, and returns a synthesized response with source citations. It correctly identifies C. Livius Drusus and P. Sextilius, notes the uncertainty flags on their dates, cites Broughton and Brennan, and, critically, explains why only two names appear when six praetors were elected annually.

The three-tool pipeline (schema → validate → execute) forces the LLM through a structured workflow. It can't hallucinate data because the data comes from SPARQL results. It can't write invalid queries because the validator catches them. The ontology schema grounds its understanding of what the data actually contains.

The pipeline in practice

Here's what actually happens when you ask "Who was praetor in 150 BC?", showing the three tool calls and their results.

Step 1, get_schema. The LLM calls this first to learn the ontology. It discovers that office-holding is modeled as PostAssertion linked to a Person via isAboutPerson and to an Office via hasOffice. Dates are integers (negative = BC). It also learns that uncertainty is modeled as boolean flags (isDateStartUncertain, isUncertain) and that scholarly notes live on PostAssertionNote entities.

Step 2, validate_sparql. The LLM drafts a query and submits it for validation. On the first attempt, it used hasPerson instead of isAboutPerson, a plausible guess, but wrong. The validator returned:

Unknown predicate 'hasPerson' for class 'PostAssertion'. Did you mean: isAboutPerson?

The LLM corrects the query and resubmits. This time it passes:

PREFIX vocab: <http://romanrepublic.ac.uk/rdf/ontology#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?person ?personName ?officeLabel ?dateStart
       ?dateStartUncertain ?dateEndUncertain
       ?noteText ?sourceLabel
WHERE {
  ?assertion a vocab:PostAssertion ;
             vocab:isAboutPerson ?person ;
             vocab:hasOffice ?office ;
             vocab:hasDateStart ?dateStart .
  ?person vocab:hasPersonName ?personName .
  ?office rdfs:label ?officeLabel .
  FILTER(STRSTARTS(?officeLabel, "Office: praetor"))
  FILTER(?dateStart = -150)
  OPTIONAL { ?assertion vocab:isDateStartUncertain ?dateStartUncertain }
  OPTIONAL { ?assertion vocab:isDateEndUncertain ?dateEndUncertain }
  OPTIONAL {
    ?assertion vocab:hasPostAssertionNote ?note .
    ?note vocab:hasNoteText ?noteText
  }
  OPTIONAL {
    ?assertion vocab:hasSecondarySource ?source .
    ?source rdfs:label ?sourceLabel
  }
}
ORDER BY ?personName

Step 3, execute_sparql. The validated query runs against the local Oxigraph store and returns four rows:

Three rows, two persons (deduplicated from four raw rows). The duplicates are by design. There are multiple PostAssertion triples per person (one per secondary source or note). The LLM synthesizes:

• C. Livius Drusus is attested without uncertainty flags, though Broughton notes this is "the latest possible date", a terminus ante quem rather than a fixed year. The date may be inferred rather than independently attested.
• P. Sextilius has both dates flagged uncertain. He's identified from a fragmentary senatorial decree found at Trikkala in Thessaly, "probably before the middle of the second century."
• Six praetors were elected annually by this period (Brennan 2000). Two results out of six is consistent with the documentation gap for the mid-second century. Livy's surviving narrative ends after 167 BC, and the richer sources of the late Republic haven't yet begun. But we can't distinguish missing records from genuine absences.

The LLM didn't invent any of this. The uncertainty flags, the source citations, the scholarly notes all came from the SPARQL results. The LLM's job was to translate the question into a query, then translate the structured results into a readable narrative with appropriate caveats.

More examples

SELECT DISTINCT ?personName ?officeLabel ?dateStart
WHERE {
  ?assertion a vocab:PostAssertion ;
             vocab:isAboutPerson ?person ;
             vocab:hasOffice ?office ;
             vocab:hasDateStart ?dateStart .
  ?person vocab:hasPersonName ?personName .
  ?office rdfs:label ?officeLabel .
  FILTER(CONTAINS(?personName, "Cicero"))
  FILTER NOT EXISTS { ?assertion vocab:isUncertain true }
}
ORDER BY ?dateStart

SELECT DISTINCT ?personName ?officeLabel ?dateStart
WHERE {
  ?assertion a vocab:PostAssertion ;
             vocab:isAboutPerson ?person ;
             vocab:hasOffice ?office ;
             vocab:hasDateStart ?dateStart .
  ?pap a vocab:PostAssertionProvince ;
       vocab:hasPostAssertion ?assertion ;
       vocab:hasProvince ?province .
  ?person vocab:hasPersonName ?personName .
  ?office rdfs:label ?officeLabel .
  ?province rdfs:label "Province: Sicilia" .
  FILTER NOT EXISTS { ?assertion vocab:isUncertain true }
}
ORDER BY ?dateStart
LIMIT 10

SELECT ?personName ?relLabel ?relatedName
WHERE {
  ?person a vocab:Person ;
          vocab:isSex <http://romanrepublic.ac.uk/rdf/entity/Sex/Female> ;
          vocab:hasPersonName ?personName .
  ?assertion a vocab:RelationshipAssertion ;
             vocab:isAboutPerson ?person ;
             vocab:hasRelatedPerson ?related ;
             vocab:hasRelationship ?rel .
  ?related vocab:hasPersonName ?relatedName .
  ?rel rdfs:label ?relLabel .
  FILTER(CONTAINS(?personName, "Cornelia") && CONTAINS(?personName, "407"))
}
ORDER BY ?relLabel

SELECT ?office ?dateStart ?dateEnd ?isUncertain ?isDateStartUncertain
       ?noteText ?source
WHERE {
  ?pa a vocab:PostAssertion ;
      vocab:isAboutPerson <http://romanrepublic.ac.uk/rdf/entity/Person/853> ;
      vocab:hasOffice/rdfs:label ?office .
  OPTIONAL { ?pa vocab:hasDateStart ?dateStart }
  OPTIONAL { ?pa vocab:hasDateEnd ?dateEnd }
  OPTIONAL { ?pa vocab:isUncertain ?isUncertain }
  OPTIONAL { ?pa vocab:isDateStartUncertain ?isDateStartUncertain }
  OPTIONAL { ?pa vocab:hasPostAssertionNote ?note .
             ?note vocab:hasNoteText ?noteText }
  OPTIONAL { ?pa vocab:hasSecondarySource/rdfs:label ?source }
}
ORDER BY ?dateStart

Interactive visualizations built from the same pipeline:

• Praetorships of the Middle to Late Republic, a stacked bar chart of 996 praetor records across 23 decades (264–31 BC), broken down by certainty category, with a searchable data table linking back to DPRR
• Family Trees, prosopographic family reconstructions rendered as SVG diagrams with sourced data tables, including the Fulvii Flacci & Calpurnii Pisones and the Atilii Reguli

What doesn't

The system inherits every limitation of its source data, and this is where it gets interesting.

DPRR is a database of secondary sources. It encodes what Broughton, Zmeskal, and Rüpke concluded about the ancient evidence, not the ancient evidence itself. Every query result should be understood as "according to Broughton, as digitized by the DPRR team," not "according to the ancient sources."

I wrote a Caveat Utilitor document that catalogs the risks:

• Elite bias. The dataset covers only the political upper strata. Women appear almost exclusively through family relationships to male office-holders.
• Argument from silence. Zero results for a query doesn't mean something didn't happen. The fasti are fragmentary. Broughton synthesized rather than exhausted.
• Nomenclatural ambiguity. Roman naming conventions create fundamental identification problems. A name that appears to indicate a family connection may reflect coincidence or conventions we don't fully understand.
• Temporal unevenness. The late Republic is densely documented. The early Republic rests on traditions of questionable historicity.

The LLM handles these caveats well when prompted. It includes uncertainty flags, cites the specific secondary sources behind each assertion, and explains gaps. But it wouldn't do this naturally. The system prompt and the Caveat Utilitor document do the heavy lifting. Left to its own devices, the model would present DPRR query results as facts rather than scholarly interpretations.

Why MCP

MCP made this project straightforward. The server runs as a standalone HTTP process. Claude Code or Claude Desktop connects to it over the network. No plugin architecture, no custom API integration, no SDK bindings. Define tools, implement handlers, deploy.

The three-tool design maps cleanly to MCP's tool model: each tool has a clear input/output contract, the LLM decides when and how to call them, and the server handles all the SPARQL and RDF complexity behind the interface.

Bundling the data locally (with auto-download from GitHub releases) solved the upstream reliability problem. The server initializes in seconds and doesn't depend on romanrepublic.ac.uk being up.

The meta-lesson

The interesting thing about this project isn't the Roman Republic. It's the pattern.

Structured data with a formal query language is a better RAG target than unstructured text. You don't need vector embeddings when you have a schema. You don't need fuzzy matching when you have SPARQL. The LLM's job becomes translation (natural language → query language) and synthesis (structured results → readable narrative), both of which it's good at.

But the hardest part wasn't the technical pipeline. It was the epistemological framing, making sure the system represents what it actually knows versus what it appears to know. A query that returns two praetors for 150 BC is only useful if the response explains that six were elected annually and the gap is consistent with source survival patterns for the mid-second century.

That's a human-in-the-loop problem. The system prompt, the Caveat Utilitor document, the uncertainty flags are all domain expertise encoded as guardrails. The LLM is good at following them. It's not good at inventing them.

The tools are ready. The question is whether the people using them know enough to set the right boundaries.

The code is on GitHub: gillisandrew/dprr-mcp