Chapter 8. It Already Exists
I would definitely point to RDF as prior art in terms of thinking about properties, independent of aggregates.
— Rich Hickey, creator of Clojure (Cognicast, 2016)
Everything in Part II was derived from three RFC-level definitions (identifiers, requests, responses) and three requirements. No W3C recommendation has entered as a premise. Where AWWW is cited (Chapter 4’s good practices, Chapter 5’s transposition table), it is cited as corroborating evidence, never as a premise. No vocabulary from any data-model community has appeared. The standard names follow:
| Derived in Part II | Standardized as | Since |
|---|---|---|
Fact = I × I × (I ∪ V) |
RDF (Resource Description Framework) triple (subject, predicate, object) | 1999 / RDF 1.1 2014 |
State = 𝒫(Fact), merge = ∪ |
RDF graph; graph merge | 1999 / RDF 1.1 2014 |
| selection algebra (pattern, join, union, project) | SPARQL algebra, §18 (Basic Graph Pattern, Join, Union, Project) | 2013 |
delta (D⁻, D⁺) |
SPARQL Update (DELETE/INSERT) |
2013 |
dereferencing select results (S4) |
Linked Data; Graph Store Protocol (HTTP methods addressed to whole graphs) | 2006 / 2013 |
canon |
canonical RDF/XML; RDFC-1.0 (RDF Dataset Canonicalization) for the unnamed entities (blank nodes) | 2004 / 2024 |
⟦t⟧ : Tree → Tree after canon |
XSLT | 1999 / 3.0 2017 |
present |
CSS | 1996 |
Table 8.1. The correspondence.
Read the dates first. Every row predates this book, most by decades, and none appears anywhere in Parts I–II. There is one conceded exception: Chapter 3 turns CSS off by name, and turning it off is the act every reader knows it by. The derivation’s premises are the RFC layer only, so the match in this table is a check the reader performs, not a construction the author arranged. The columns are independent: the left side is forced by three requirements, and the right side was shipped by working groups. The table asserts they are the same objects.
Prop. 8.1 (Homomorphism). There is a translation φ, taking facts to RDF triples, states to graphs, and selection terms to SPARQL terms (write sparql(p) for that last translation), such that φ(select(p, S)) = ⟦sparql(p)⟧(φ(S)); on ground states φ is a bijection. The mapping is a homomorphism, not a coincidence of shapes: the operations commute with the translation.
How the check runs — clause by clause against a denotational spec.
The equation φ(select(p, S)) = ⟦sparql(p)⟧(φ(S)) is checkable clause by clause against the SPARQL algebra. The algebra is written denotationally (a rarity among web specs, shared mainly with XQuery’s Formal Semantics) and that denotational form is what makes the check possible. Full proof: Appendix B.7.
Prop. 8.1. Two paths give one result: translate then query, or query then translate (the standard calls the result a solution sequence). The square commutes.
You have already accepted RDF. You did it in Chapter 5, before I told you its name.
Whatever you believed about the semantic web when you opened this book (too academic, too complicated, died in the nineties), you derived it yourself. You derived it from three requirements, and you can reject each one only at the cost that requirement itself states. The technologies were not a committee’s enthusiasm in search of a problem. They occupy a position that was forced, and the people who standardized them in 1999 had already arrived there. What failed in the nineties was not the position. The tooling failed, and the timing was wrong, because the substrate is built for machine consumption and the machines that could consume it were twenty years away. Chapter 18 makes the demand-side case.
State = 𝒫(Fact) — (5.3)(⟨…#panel-14⟩, title, "Current Power") (⟨…#panel-14⟩, value, "15.5 kW") (⟨…#panel-7⟩, title, "Wind Speed") (⟨…#panel-7⟩, value, "8.2 m/s")
(?p, type, ⟨…#Panel⟩) (?p, title, ?t) (?p, value, ?v)
D⁻ = { (⟨…#panel-14⟩, value, "15.5 kW") }
D⁺ = { (⟨…#panel-14⟩, value, "16.1 kW") }Interactive exhibit (online edition): Chapter 5’s state, Chapter 5’s algebra, and Chapter 7’s delta sit under one switch. One side shows the derivation’s notation; the other shows Turtle (the standard’s text notation for triples), SPARQL, and SPARQL Update. Nothing is recomputed. Everything is renamed.
Theorem 8.2 (Synthesis). The stack realizes the proper factorizations whose select is a term of Chapter 5’s algebra and whose arrange is generic, invariant under URI renaming, singling out no particular URI. SPARQL carries those selections exactly (Prop. 8.1), XSLT-over-canon the arrangements, CSS the presentation, and S4 holds by construction because query results and graphs are dereferenceable resources. By Prop. 7.3’s symmetry, the write side inherits the result: SPARQL Update carries the deltas in the same pattern language, arguments swapped. Full proof: Appendix B.8, which states the genericity condition exactly.
The select-side condition restricts nothing new: it admits exactly the selections Chapter 5’s four operations build, and no more. The genericity condition is the claim’s deeper caveat, carried inside it: the completeness class for arrange excludes transforms that smuggle in knowledge of particular URIs. The exclusion has a reason: such a transform makes the document depend on how an entity is named rather than on what the facts say. A renaming, which asserts nothing, then changes the page, and the page carries meaning with no source in the state. Practitioners call a transform without such knowledge data-driven, and AWWW §2.5 calls the norm URI opacity; invariance under renaming is both, made exact. Analysis said every application has the form; Synthesis says the stack fills the form. The two halves of the argument meet, and that meeting is the book’s proof.