What RDF is, and why we use it
RDF has a reputation problem: XML-era baggage, ontology committees, a decade of unfulfilled promises. What we actually use is a very small core, and it earns its place.
RDF has a reputation problem: XML-era baggage, ontology committees, a decade of unfulfilled promises. What we actually use is a very small core, and it earns its place.
Resonator’s wire language is RDF. That choice needs defending, because RDF arrives carrying two decades of baggage — angle brackets, ontology committees, and a lot of promises that did not land. So it is worth being precise about which part of RDF we use, and why that part is the right tool.
RDF’s entire data model is the statement: a subject, a predicate, and an object. That is it. There is no table, no schema to declare first, no migrations.
Written in Turtle, the serialisation we use, a statement looks like this:
<ed25519:a1b2…> rsntr:lastSeen "2026-08-18T09:14:00Z"^^xsd:dateTime .
Subject, predicate, object, full stop. A graph is just a pile of these.
Three consequences follow, and all three are load-bearing for a peer-to-peer network:
Merging is concatenation. Two graphs combine by putting the statements together. There is no schema negotiation step, because there is no schema to negotiate.
Names are global. Predicates are URIs, so two parties can mean the same
thing without ever having coordinated. rsntr:lastSeen means what the document
at that namespace says it means.
Partial understanding is normal. A peer that recognises four of the eight predicates in a message can act on four and carry the rest. Nothing breaks.
That last one is the property a heterogeneous network lives or dies on. A binary struct is all-or-nothing: you either have the exact type definition or you have noise. A pile of statements degrades gracefully.
SPARQL is the query language for graphs of triples — pattern-matching over subject/predicate/object, in roughly the shape SQL has over rows.
The part we actually build on is stranger and more useful: a SPARQL query can itself be written as RDF. This is an old idea — SPIN expressed queries as RDF objects, a node typed as a select query carrying its text as a property.
Which means a message and a query about messages are the same kind of object. One parser. One dispatch rule: look at the type and act accordingly. That is what lets the envelope carry a SQL payload for one node and a SPARQL payload for another without the receiver needing a second protocol.
Almost all of it. We are not building an ontology, not doing reasoning, not running an inference engine, not writing OWL, and not shipping RDF/XML. There is no committee.
The working set is three things: triples as the model, Turtle as the syntax, and SPARQL as the query language. Everything else in the RDF world is available if someone wants it and irrelevant if they do not.
Being straight about the trade: RDF on the wire is larger than a packed binary struct carrying the same information. Turtle is text. Predicates are URIs, and URIs are long.
That cost is real and we pay it deliberately, because the alternative — a compact format that only nodes sharing our exact type definitions can read — buys bytes at the price of the one property we actually want, which is that an unfamiliar peer can still make sense of what it receives.
It does impose limits worth designing around. Gossip messages have a small default ceiling, on the order of a few kilobytes, so anything large travels as a reference rather than inline. Compact RDF serialisations exist and are worth revisiting; for now, legibility beats compression.
RDF is a good fit here for an unglamorous reason. A peer-to-peer network is a place where you cannot assume the other side runs your code, your version, or your database. The format that suits that is one where a message is a pile of self-describing statements, and understanding some of them is a valid outcome.