The finished system, the route to it, and how to read this book.
At the end of this book you will type a sentence into a small program on your laptop: "Who are our top spenders in Wisconsin?" A few seconds later it answers: Carolyn Inworth, of Milwaukee, who has spent $502,529.42. That answer won't come from a report, an export, or an ETL job. It is computed live from two databases that have never heard of each other: her name and address from Aurora PostgreSQL, her purchases from Amazon Redshift. This book is about the layer in the middle that makes that possible, and you are going to build it yourself, one piece at a time.
You already know databases well: foreign keys, why a JOIN across a network hurts, what an ETL pipeline costs to keep alive, how many definitions of "active customer" one company can accumulate. What you probably haven't met is the other tradition of data modeling: RDF, ontologies, SPARQL, reasoning. Its academic reputation is undeserved. Underneath the vocabulary are a handful of practical ideas, each mapping onto something you already do in SQL, sometimes neatly and sometimes with an important twist. We'll learn them in the order you need them to build a working system.
Here is the finished system. Press Play to follow one question through it. Every box is something you'll build or inspect, labeled with its chapter.
5. Rows come back from both engines, Stardog joins them on the customer's name, and the agent phrases the answer.
Read it from the top. The agent, a short Python program, hands your English question to a large language model (an OpenAI model, or any model reachable through OpenRouter, such as Claude). The model doesn't know your data, but it's given a compact description of your business vocabulary (what a Customer is, what an Order is, how they connect) and one tool, run_sparql(query). It writes a SPARQL query and calls the tool.
The query arrives at Stardog, the semantic layer. Stardog holds no copies of your customers or orders. It holds meaning: business definitions, a few rules (what counts as a "big spender"), security policies, and mappings that say how each concept corresponds to real tables. Stardog works out which parts of the query concern Aurora and which Redshift, rewrites each as SQL, runs both, joins the results itself, and sends back rows. The model turns rows into a sentence.
If you're a database person looking at Figure P.1, some questions are probably already nagging at you. They're the right ones, and each has a chapter.
| Your question | The short answer | Where |
|---|---|---|
| How does the agent know the ontology well enough to write SPARQL? | We tell it: the agent's prompt carries a compact summary of the ontology. Stardog's Voicebox does the same from the ontology stored in the database. | ch14, ch13 |
| Who knows which data lives in Aurora and which in Redshift? | Not the ontology: the mappings. Each virtual graph is bound to one data source, and its mapping says which tables produce which facts. | ch08, ch09 |
| Where is SPARQL converted to SQL, and how does Stardog decide which database to hit? | Inside Stardog's query engine, at query time, by matching each part of the query against the mappings. | ch09 |
| With no SQL JOIN across engines, where are the results joined and rolled up? | Each database returns partial results; Stardog joins, groups and sums them in its own engine. Nothing is written anywhere. | ch09 |
| What are RDF, RDFS, OWL, SPARQL, SHACL and rules, and why does each exist? | One line each in the next section; each gets its own chapter. | ch02–ch06, ch10, ch11 |
Every technology in the book, in one table. Don't memorize it; come back when a name stops making sense.
| Name | What it is | Why it exists | Ch. |
|---|---|---|---|
| RDF | A data model where every fact is a three-part sentence: subject, predicate, object (a "triple"). | Every database invents its own shape: tables and columns here, JSON there. Combining two of them normally means first reconciling their shapes, which is what ETL does. If every fact is written as one simple sentence (customer 225 lives in Milwaukee), facts from Aurora and Redshift already have the same shape and can simply sit side by side. | 2–3 |
| SPARQL | The query language for RDF: patterns of triples with placeholders (like ?city) that Stardog fills in from the data. | SQL asks "which rows in these tables match?" Triples have no tables, only sentences linked by shared names. So you need a language that asks "find things connected like this: customer → address → city". SPARQL is that language, and it's a W3C standard, like SQL is an ANSI one. | 4 |
| RDFS | A small vocabulary for describing classes and labels. | SQL splits the world in two: DDL (CREATE TABLE) defines the shape, DML (INSERT, SELECT) handles records, and you read the shape through DESCRIBE. In RDF there is no split. The shape is written as triples too ("Customer is a class"), so the same INSERT DATA creates the schema or a record, and the same SELECT reads either one, or both in one query. The catch: declaring a shape doesn't enforce anything (that's SHACL's job, Chapter 11). | 5 |
| OWL | A richer vocabulary on top of RDFS: property types, inverses, and more. | RDFS can say that a Customer exists, but not much about how things relate. OWL adds the detail: "purchasedBy links an Order to a Customer", "placedOrder is the same link read backwards (Customer → Order)". Stardog can then answer questions that the data doesn't state directly. | 6 |
| SMS2 / R2RML | Mapping languages that say "each row of this SQL table becomes these triples" (SMS2 is Stardog's; R2RML, short for RDB to RDF Mapping Language, is the W3C standard). | Your data sits in SQL tables, but the ontology speaks in sentences. A mapping is the translator: "each row of c360.customer is a Customer, and its first_name column is the Customer's firstName." Without one, Stardog doesn't know your tables exist. | 8 |
| Virtual graph | A named graph whose triples are produced on demand from SQL through a mapping. | Copying data into a new store (ETL) means duplicates, pipelines to maintain and answers that go stale. A virtual graph leaves the rows in Aurora and Redshift and turns your question into SQL at the moment you ask. | 7–9 |
| Stardog rules | IF-THEN statements that derive new facts at query time. | Otherwise every report, dashboard and AI prompt re-implements "big spender" slightly differently, and the numbers disagree. Write the definition once, in the model, and every query uses the same one. | 10 |
| SHACL | A W3C language for validation rules ("every Customer has exactly one email"). | RDFS and OWL describe data but never reject it: a customer with no email is simply accepted. SHACL is the checker. Like NOT NULL and CHECK constraints, it reports every record that breaks your rules. | 11 |
| Voicebox | Stardog's built-in assistant that turns questions into SPARQL using your ontology. | So people who don't know SPARQL, such as business users or an AI agent, can ask "who are our top spenders?" in plain English and still get an answer grounded in the ontology. | 13 |
| MCP | Model Context Protocol, an open standard connecting AI applications to tools and data. | Every AI app used to need custom glue code for every tool it called. MCP is a standard plug, so any agent can call Stardog (or any other service) the same way, like JDBC for AI tools. | 13–14 |
You could answer the Wisconsin question without any of this: export customers from Aurora, load them into Redshift, write the JOIN. For one question, that's the right call. The semantic layer earns its keep when there are many questions, systems and consumers, especially when one consumer is an AI model that has to write the query itself:
There are costs: federated queries are slower than local ones, an ontology is one more artifact to maintain, and heavy aggregation over billions of rows still belongs in the warehouse. Chapter 7 lays out the trade-offs.
"Building an ontology solution" is five layers of work, each on the one before: learn the data model (triples, names, SPARQL); write the vocabulary (the ontology); connect it to the real tables (mappings and virtual graphs); add meaning and control (rules, validation, security); and put the agent on top. Eight chapters leave something permanent in Stardog; we call them build steps. Everything else is explanation, or practice in a scratch area deleted at the end of the chapter.
| Step | Chapter | What you build, and where it lives |
|---|---|---|
| 1 | ch5 | The ten classes (Customer, Address, Order…) in the model graph <urn:stardog:training-c360:1.0:model> |
| 2 | ch6 | The properties, then the full kit ontology schema.ttl (161 triples) in the same graph; the reasoning.schemas setting |
| 3 | ch8 | Virtual graphs aurora_c360_safe and aurora_c360_pii over Aurora |
| 4 | ch9 | Virtual graph redshift_c360, and your first federated query: the top spenders |
| 5 | ch10 | Five business rules, including "big spender", in <urn:stardog:c360_extended_rules:1.0:model> |
| 6 | ch12 | Roles and users hr_user and marketing_user, with different views of personal data |
| 7 | ch14 | The agent: an OpenAI or OpenRouter model with a SPARQL tool, answering real questions |
| 8 | ch15 | askgraph, the agent as a chat app on your laptop: Stardog login, chat history, visible SPARQL and a model picker |
| 9 | ch16 | Answers you can trust: an online-orders source, a source registry in <urn:c360:registry>, and agent_v2.py, which reports partial answers instead of guessing |
The plumbing is in place and tested, so the book can spend its time on ideas instead of network settings:
c360, schema c360) with 500 customers, their addresses, credit cards and rewards accounts; Redshift Serverless (database dev, schema c360) with 2,500 purchases, 580 products, 31 categories and 418 vendors. Both cost next to nothing when idle (Aurora pauses after five idle minutes).kit-c360 and two data sources (saved JDBC connections), aurora_c360 and redshift_c360.And, deliberately, nothing else. kit-c360 is empty: zero triples, no virtual graphs, no ontology. An earlier session built the whole thing end to end (the $502,529.42 above comes from that run, and matches SQL to the cent), then took it back down to bare connectivity so you can build every piece yourself.
| Tool | Where | Used for |
|---|---|---|
| Stardog Studio | cloud.stardog.com → Studio, connected to https://<your-endpoint>.stardog.cloud:5820, database kit-c360 | Every "Try it" step |
| DBeaver | Your laptop, with the Aurora and Redshift connections | Checking Stardog's answers in SQL |
| Credentials | The native Stardog user stardog_admin and its password (not your portal email login) | Studio's connection to the endpoint, and later the agent |
Slowly, with your hands on the keyboard. Keep Studio open beside the page. When you reach a green "Try it in Studio" box, stop and do it: paste the query, run it, compare with what the box says to expect. The steps aren't done for you, on purpose. By Chapter 14 you'll have built every part of the system yourself, and you'll be able to rebuild or change it without this book.
The boxes each have one job. If you know SQL gives the nearest SQL idea and where the analogy breaks; If you know Java does the same for readers who think in objects. Mental model gives you a picture to keep. Try it in Studio is hands-on: practice steps use scratch graphs such as <urn:book:ch02> and clean up; build steps leave something permanent. Gotcha is a real pitfall in this exact setup, one you would hit if nobody warned you. In the AWS blog ties the chapter to the blog.
Every chapter ends with check-yourself questions and a recap. Ask Claude whenever something is unclear; there's no ceremony. The one exception is the build-step chapters: they end with a "Build step N done" button. Paste that to Claude with what you saw (the counts or results), so we can confirm your build matches before the next step relies on it. Studio's screens change between versions, so mention anything that looked different.
This book owes its shape to that post by the AWS and Stardog teams, which fit the whole system into one afternoon's reading; this is my attempt to fit it into one engineer's head. Let's build it.
Vinodh Thiagarajan
September 2026
At query time, in Stardog's engine: it rewrites the question as SQL for Redshift (purchases) and Aurora (name and state), runs both, and joins and sums the results. Nothing is copied ahead of time.
No customer rows at all. It stores meaning: the ontology, rules, security settings, and mappings to the tables in Aurora and Redshift.
The mappings. The ontology says what an Order is; the redshift_c360 mapping says rows of c360.purchase become Orders.
The build steps: ch5, ch6, ch8, ch9, ch10 and ch12, plus ch14 and ch15, whose agent and chat app live on your laptop, and ch16, which adds a third source, a registry and a checked agent. The rest is explanation or scratch practice.
The portal login (your email) doesn't work against the endpoint; Studio, the API and the agent need a native user with the cloud role.
kit-c360 is deliberately empty.