Fifteen ideas worth remembering, each linked to where it is taught.
Chapters 10–16 will add their key ideas as they are read.
Chapter 1 · One question, five systems
A semantic layer is a job, not a technology: an ETL-free business view over many databases, where the ontology supplies the meaning and the mappings supply the connections.
Example: This book builds it with a knowledge graph on Stardog; metrics layers, BI models and data virtualization are other ways. Read it in context →
Chapter 2 · The triple: the atom of knowledge
Every fact is one sentence: subject → predicate → object.
Example: customer:225 :firstName "Carolyn" Read it in context →
Things have IRIs and can have facts of their own; literals are plain values and are always dead ends.
Example: customer:225 :address location:b80e… points to a thing; "Milwaukee" is a literal. Read it in context →
Chapter 3 · Names, values and files
An IRI is a globally unique primary key, for things and for properties alike.
Example: customer:225 and product:225 never collide, while Aurora's and Redshift's cid 225 become the same node. Read it in context →
Money is xsd:decimal, never xsd:float.
Example: 502,529.42 stored as a float comes back as 502,529.40625. Read it in context →
Turtle punctuation: ; means "same subject, next predicate", . means "done with this subject", , means "same subject and predicate, another object". Indentation means nothing.
Example: customer:1 a :Customer ; :name "Jolynn Bithany" . is two triples, written out in full as customer:1 a :Customer . and customer:1 :name "Jolynn Bithany" . In SQL terms, ; is the next column of the same row and . ends the row. Read it in context →
Chapter 4 · SPARQL for people who know SQL
A variable is a placeholder, and a shared variable is a join.
Example: customer:225 :address ?addr . ?addr :city ?city joins on ?addr and returns "Milwaukee". Read it in context →
A missing triple is not a NULL: without OPTIONAL, the whole row disappears.
Example: Marlane has no :phone, so ?c :phone ?p drops her; OPTIONAL { ?c :phone ?p } keeps her. Read it in context →
Chapter 5 · The T-Box, part 1: classes (RDFS)
Schema and data are both triples: there is no DDL/DML split.
Example: :Customer a owl:Class (T-Box) and customer:225 a :Customer (A-Box) are written and queried the same way. Read it in context →
Missing means unknown, not false.
Example: no :phone triple for Marlane means "we don't know her phone", not "she has no phone". Read it in context →
Chapter 6 · The T-Box, part 2: properties and the c360 ontology (OWL)
Object properties point to things; datatype properties point to literals. Both are predicates, and both can have a domain and a range.
Example: :purchasedBy → a Customer; :firstName → a string. Read it in context →
rdfs:domain and rdfs:range label things; they never check. Checking is SHACL's job.
Example: one bad triple product:268 :purchasedBy customer:225 turns Wax Paper into an Order. Read it in context →
Chapter 7 · Where the data lives: materialized vs virtual
Materialized is a copy; virtual is a view that runs fresh SQL every time.
Example: like CREATE MATERIALIZED VIEW vs CREATE VIEW. Read it in context →
Chapter 8 · Mappings: teaching Stardog to read your tables
A mapping is written FROM SQL → TO → WHERE but runs FROM SQL → WHERE → TO. WHERE only names things (TEMPLATE) and types them (casts); compute everything else in the SQL.
Example: BIND(TEMPLATE("…customer:{cid}") AS ?c) turns cid 225 into customer:225. Read it in context →
The same template means the same node, and that is the join, even across databases.
Example: the customer and address mappings both build location:b80ea2ce…; Aurora and Redshift both build customer:225. Read it in context →
Chapter 9 · Federation: where the magic happens
Per database, Stardog sends one SQL query; across databases, Stardog joins the results itself.
Example: the Wisconsin query in Chapter 8 became one 3-table SQL JOIN on Aurora; top spenders needs a query to Aurora, one to Redshift, then a join in Stardog. Read it in context →