RDF Explained: Triples, IRIs and Serializations
Everything in the semantic stack, from billion-triple enterprise graphs to the ontology axioms of OWL itself, reduces to one three-part sentence shape: subject, predicate, object. Master that shape, the identifier discipline behind it, and the handful of file formats it travels in, and the rest of the stack stops being alien syntax and becomes variations on a theme. This lesson covers the RDF data model as it stands in 2026, which matters more than usual right now: after a quiet decade, RDF 1.2 is at Candidate Recommendation and brings the first real change to the model since 2014.
The triple: the atom of knowledge
RDF, the Resource Description Framework, models all knowledge as a set of triples. Each triple is one atomic statement: a subject (the thing you are talking about), a predicate (the property or relationship), and an object (the value or the other thing). In prose: ex:P101 ex:installedAt ex:Aberdeen2 says that pump P-101 is installed at site Aberdeen-2. A set of triples is a graph, in the strict mathematical sense: subjects and objects are nodes, each triple is a directed, labelled edge. There are no tables, no rows, no fixed columns; adding a brand-new kind of fact to an RDF dataset requires no schema migration, just another triple. That property, incremental extensibility without coordination, is why RDF remains the integration substrate of choice for data that outlives applications.
Three kinds of term can occupy the positions. IRIs (Internationalized Resource Identifiers, the Unicode-capable generalisation of URLs) name things globally: subjects and predicates must be IRIs, objects may be. Literals are data values: strings, numbers, dates, each carrying a datatype IRI (typically from XML Schema, such as xsd:date), and optionally a language tag on strings, so “London”@en and “Londres”@fr can coexist. Literals may only appear in the object position. Blank nodes are local, unnamed nodes: existential variables that say “something exists here with these properties” without giving it a global name. Blank nodes are useful for auxiliary structure (an address you never need to reference externally) and notorious in practice: they make graph merging, diffing and round-tripping harder, and most production style guides say to mint IRIs instead wherever the entity could ever be referenced twice. The authoritative model definition is the W3C RDF 1.2 Concepts specification; for a gentler on-ramp the RDF 1.1 Primer remains excellent, since 1.2 is a superset.
IRIs are a naming discipline, not a formality
The global identifier is RDF’s deepest design decision. Where a relational database’s customer_id 4711 means nothing outside its own tables, an IRI such as https://data.example.com/id/customer/4711 is unambiguous everywhere, mergeable with any other graph by simple set union, and dereferenceable: pointing an HTTP client at it can return more data about the resource. Good IRI practice is boring and valuable: use a domain you control, keep identifiers opaque (no encoding of mutable business attributes into the IRI), separate the identifier for the thing from the URL of the page about the thing, and never recycle IRIs. Namespace prefixes (writing ex:P101 for the full IRI) are pure notational convenience defined per document. When two graphs use different IRIs for the same entity, that is not an RDF problem but an entity resolution task, handled with owl:sameAs and the matching techniques of lesson 29, under the no-unique-names logic you met in lesson 4.
One graph, three notations
RDF is a data model, not a file format; the same graph serialises in several syntaxes with identical meaning. Three matter daily. Turtle is the human-friendly notation you will read and write most: prefixes, semicolons to share a subject, comfortable in code review. N-Triples is Turtle stripped of every convenience: one fully expanded triple per line, no prefixes. It is brutal to read and perfect for machines: streamable, splittable across processing nodes, and the standard interchange for bulk loads (its dataset-aware sibling N-Quads adds a fourth column for the graph name). JSON-LD embeds RDF in ordinary JSON via an @context that maps JSON keys to IRIs, which is why it dominates the web: developers ship JSON as usual, and schema.org structured data in JSON-LD is consumed by search engines and, increasingly, AI crawlers. RDF/XML, the original 2004 syntax, survives in legacy toolchains and OWL publishing; nobody starts new work in it.
| Serialization | Rendering of the same graph | Best used for |
|---|---|---|
| Turtle | ex:P101 a ex:Pump ; ex:ratedPowerKW “18.5”^^xsd:decimal ; ex:installedAt ex:Aberdeen2 . | Authoring, code review, documentation |
| N-Triples | Three separate lines, each a full statement ending in a full stop, for example: <https://ex.org/P101> <https://ex.org/installedAt> <https://ex.org/Aberdeen2> . | Bulk load, streaming, line-oriented diffing |
| JSON-LD | A JSON object with “@context” mapping keys to IRIs, “@id”: “https://ex.org/P101”, “@type”: “Pump”, “ratedPowerKW”: 18.5, “installedAt”: {“@id”: “https://ex.org/Aberdeen2”} | Web APIs, schema.org markup, developer handoff |
Note what the table implies: syntax choice is an engineering decision about audience and pipeline, never about meaning. A well-run project stores canonical data once and emits whichever serialization each consumer needs. The Turtle row also shows two idioms worth internalising: “a” is shorthand for rdf:type, and the semicolon continues the same subject, so dense entity descriptions stay readable.
Named graphs: the fourth element
Real deployments never manage one undifferentiated pile of triples. An RDF dataset comprises a default graph plus any number of named graphs, each a graph labelled by an IRI. The graph name becomes your unit of administration: one named graph per source system, per ingestion batch, per security compartment, or per ontology version. Provenance attaches naturally (“this graph came from the CRM extract of 29 July 2026, licensed thus”), access control can be enforced per graph, and retraction becomes “drop the graph and reload” rather than surgical triple deletion. SPARQL exposes the structure directly with GRAPH clauses. If you take one operational habit from this lesson: decide your named-graph strategy before you load your first million triples, because retrofitting one is miserable.
Worked example · the Aberdeen-2 asset register
Where we left it: open world inside, declared closed worlds at report boundaries. Time to write actual data.
The register’s first real triples, in TriG, the dataset-aware flavour of Turtle, with one named graph per source system, exactly as this lesson prescribes:
@prefix ex: <https://data.example.com/id/> .
ex:g-engineering {
ex:P101 a ex:Pump ;
rdfs:label "P-101" ;
ex:ratedPowerKW 18.5 ;
ex:installedAt ex:Aberdeen2 .
ex:V205 a ex:Valve ;
ex:installedAt ex:Aberdeen2 .
}
ex:g-maintenance {
ex:P101 ex:maintainedUnder ex:Contract42 .
}Three deliberate decisions are visible. The graph names make “which source said this?” an ordinary query, which is how the register will answer lesson 1’s three-different-counts problem source by source. The rated power is a typed decimal, not the string “18.5”, a discipline lesson 10 will show paying off in filters. And V-205’s missing inspection is now a visible, queryable absence rather than a NULL in somebody’s export. One honest caveat: ex:P101 is a teaching-friendly local name; the tag lives safely in the label, and the next block shows why you should never let the tag be the identifier in production.
State of the register: a real dataset exists, partitioned by source. Nothing yet says what ex:Pump means or what pumps may relate to: that is the next lesson’s schema layer.
What breaks · minting the IRI from the tag number
The engineering team proposes the obvious identifier scheme: the tag is unique on the P&ID, so use it. Then 2026 arrives: P-101 is decommissioned, and the maintenance system, as maintenance systems do, reassigns the tag to the replacement pump on the same position. Two physical machines now share one IRI, and the next set-union merge welds their histories:
ex:pump/P-101 ex:commissionedOn "2011-06-02"^^xsd:date ,
"2026-03-18"^^xsd:date ;
ex:hasImpeller ex:IMP77 , ex:IMP91 .Note what does not happen: no error. Under the no-unique-names logic of lesson 4, a pump with two commissioning dates and two impellers is merely a pump about which two facts are known, and the graph describes an impossible machine with perfect syntactic composure. The warranty query for IMP-77 now cites a pump commissioned three years after IMP-77 was scrapped. The repair is the lesson’s IRI discipline applied literally: the identifier names the physical thing and is opaque; the tag is a property, ex:tag “P-101”, free to be reused by the maintenance system without corrupting identity. Lesson 3 told you tags and things have different identity conditions; this is what happens when the IRI ignores that.
RDF 1.2 and RDF-star: statements about statements
The classic model has one famous gap: making statements about statements. “Wikipedia says the population of Rome is 2.75 million, as of 2023, with confidence 0.9” needs the triple itself as a subject. Old workarounds (reification with four bookkeeping triples, or single-purpose named graphs) were verbose and unqueryable at scale. The community’s answer, RDF-star, has now been mainstreamed into the standards track: the RDF and SPARQL Working Group, chartered from May 2025 to April 2027, has RDF 1.2 Concepts at Candidate Recommendation (snapshot April 2026). The headline feature is the triple term: a triple may itself appear in the object position of another triple, so you can assert, in Turtle 1.2 syntax, that the statement “ex:P101 ex:ratedPowerKW 18.5” was ex:reportedBy ex:SCADA with an ex:confidence of 0.98. That placement is RDF 1.2’s own restriction: a triple term may appear only as an object, never a subject. The original RDF-star syntax already implemented by Jena, GraphDB, Blazegraph, Oxigraph and Virtuoso is looser, allowing a quoted triple as either subject or object, and its idiomatic annotation form quotes the statement itself as subject: <<ex:P101 ex:ratedPowerKW 18.5>> ex:confidence 0.98 . Existing RDF-star data and tooling lean on that subject-position form; RDF 1.2 narrows it. The second notable 1.2 addition is directional language-tagged strings, carrying base direction for proper rendering of mixed right-to-left text. SPARQL 1.2 advances in step so the new terms are queryable, and an interoperability note covers RDF 1.1 to 1.2 migration. Practically, in 2026: triple stores are shipping support progressively (the Rust engine Oxigraph, for instance, exposes RDF 1.2 and SPARQL 1.2 behind feature flags), property-graph interop gets dramatically cleaner because edge properties finally have a natural RDF representation (lesson 17), and statement-level provenance, the thing every audit and agent-memory use case wants, becomes a first-class modelling tool rather than a hack.
Working habits that separate professionals
Five habits to adopt from day one. Validate syntax in your editor or CI rather than at load time; a missing full stop in Turtle should fail a pull request, not a production ingest. Keep one entity’s description together in Turtle files and sort deterministically, so version-control diffs mean something. Prefer IRIs over blank nodes for anything with independent existence. Type your literals explicitly; “42” the string and 42 the xsd:integer are different terms, and downstream SPARQL filters will punish sloppiness. And treat named graphs as part of your information architecture, not an afterthought. These habits are precisely what the ancient tutorials that still rank for “RDF tutorial” never teach, because most predate widespread production practice.
You now hold the atom (the triple), the naming discipline (IRIs), the transport (serializations), the container (datasets and named graphs) and the 2026 frontier (triple terms). What RDF alone lacks is vocabulary semantics: nothing yet says what ex:Pump means or how it relates to ex:Equipment. That is the job of RDFS and OWL 2, the subject of the next lesson.
Check yourself
The register needs an IRI for the physical pump currently tagged P-101. Which candidate survives production?
- https://data.example.com/id/pump/8f3e2c91
- https://data.example.com/id/pump/P-101
- https://data.example.com/api/pumps?site=aberdeen2&tag=P-101
- https://data.example.com/id/pump/P-101-18.5kW-aberdeen2
Show the answer, and why each wrong option is wrong
A is correct. A domain you control, an opaque local name, nothing encoded that can change. Boring, exactly as the lesson recommends; the human-friendly tag belongs in rdfs:label and ex:tag, where it can be reused, corrected and translated without touching identity.
B bakes in the tag, and tags are a mutable business attribute with their own lifecycle: the reuse scenario above corrupts every future merge. C is the URL of an API response, not the name of a pump: it conflates the identifier for the thing with the address of a page about the thing, and it dies with the next API redesign. D encodes rated power into the name of the pump, and the 2023 motor swap changed exactly that value; you then choose between an IRI that lies and an IRI that churns, and churn breaks every external system that ever referenced the old one, violating never-recycle from the other side.
Going deeper on RDF. If you want a long-form treatment rather than a single lesson, Harald Sack and the Information Service Engineering team at FIZ Karlsruhe publish their full lecture series free on the ISE FIZ Karlsruhe YouTube channel, and the companion openHPI courses on Semantic Web Technologies and Knowledge Graphs cover RDF, SPARQL and OWL from first principles. It is the most complete free RDF course material on the web.