What Is an RDF Graph?

An RDF graph models data as a set of simple three-part statements, each naming a subject, a property, and a value. A statement like "Alice knows Bob" becomes one edge in a graph, and thousands of such statements interlock into a network where the meaning of the data travels with the data itself. Because every thing and every relationship is named with a global identifier, two datasets written independently can be merged without first agreeing on a schema, which is the property that turned RDF into the foundation of the semantic web, public knowledge graphs, and a growing share of the grounding that enterprise AI systems reason over.

This post explains what an RDF graph is, why it matters for modern data management, and how it works in practice: the triple model and the standards stack around it, the benefits and the honest costs, how RDF underpins linked data, concrete examples in Turtle and SPARQL, and the steps to build one. It also looks at where the RDF model fits relative to the property-graph alternative, so the choice between them is a deliberate one rather than a default.

What is an RDF graph?

RDF, the Resource Description Framework, is a World Wide Web Consortium (W3C) standard for representing information as a graph of statements. The atom of the model is the triple: a single statement with three parts, a subject, a predicate, and an object. The subject is the thing being described, the predicate is the property or relationship, and the object is the value or the related thing. "Alice knows Bob" is one triple; "Alice works for Acme" is another. An RDF graph is just a set of such triples taken together.

What makes the set a graph rather than a list is that objects can themselves be subjects of other triples. If "Alice knows Bob" and "Bob works for Globex" are both present, the two statements share the node Bob, and following the chain is a traversal through a directed, labeled graph. Each triple is a directed edge from subject to object, labeled by the predicate. There are no tables and no fixed columns; the structure emerges entirely from how the statements connect.

The identifiers are what give RDF its distinctive power. Subjects and predicates are written as IRIs (Internationalized Resource Identifiers, the Unicode-aware superset of URIs), so a resource has a globally unique name rather than a local primary key. Objects are either IRIs, when the value is another resource, or literals, when the value is a concrete datum such as a string, number, or date. Because https://example.org/alice means the same thing in every dataset that uses it, a statement about Alice made by one organization and a statement about the same Alice made by another can be combined directly, with no key mapping in between.

It helps to keep two things distinct. RDF is a data model, an abstract way of structuring information as triples. The software that stores and indexes triples and answers queries over them is a triplestore or RDF database (examples include Apache Jena, GraphDB, Amazon Neptune, and Virtuoso). The model is standardized; the stores are implementations of it. RDF 1.1 has been a stable W3C Recommendation since 2014, and a revision, RDF 1.2, reached W3C Candidate Recommendation in April 2026, adding the ability to use a triple itself as the object of another statement (the feature long known as RDF-star). The triple at the center has not changed since the model's semantic-web origins; what has grown is the surrounding stack of vocabularies, query tools, and public data built on top of it.

Why RDF graphs matter in modern data management

The hardest problem in data management is rarely storing data; it is connecting data that was produced separately. Most systems describe their own entities with their own keys, and joining a customer in a CRM to a user in an identity provider to a counterparty in a payments ledger means reconciling three different notions of the same person. RDF attacks this at the level of identity. When every entity carries a global IRI and every relationship is itself a named property, two datasets can be poured into the same graph and the shared identifiers do the joining. The merge is a property of the model, not a pipeline someone has to build.

RDF data is also self-describing. A row in a table means nothing without the schema that labels its columns; a triple carries its own predicate, so the statement is interpretable on its own terms. That trait pairs with shared vocabularies: communities publish agreed sets of IRIs for common concepts (a person, an organization, an author-of relationship), and any dataset that reuses them inherits a meaning other systems already understand. Two publishers that both use the same vocabulary for "creator" produce data that lines up without either having seen the other's design.

On top of identity and shared meaning sits a standardized query and reasoning layer. SPARQL is the W3C query language for RDF, so graphs from different sources are queryable through one interface. RDFS and OWL let a publisher state rules about the vocabulary itself, that every Employee is a Person, that "works for" is the inverse of "employs", and a reasoner can then infer facts that were never written down explicitly. This combination, global identity plus shared vocabularies plus standardized query and inference, is why RDF became the substrate of public knowledge graphs such as DBpedia and Wikidata, and why it is increasingly used to ground enterprise AI: a language model answering questions over company data is far more reliable when the entities and relationships it reasons about come from an explicit, machine-readable model rather than being guessed from unstructured text. The value RDF adds is not a faster store; it is data that means the same thing wherever it travels.

How RDF graphs work

The mechanics are easiest to see in a serialization. RDF is an abstract model, and the same triples can be written in several text formats: Turtle (the most human-readable), N-Triples, RDF/XML, JSON-LD (RDF embedded in JSON, common on the web), and TriG. Here is a small graph in Turtle:

@prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix foaf:   <http://xmlns.com/foaf/0.1/> .
@prefix schema: <https://schema.org/> .
@prefix ex:     <https://example.org/> .

ex:alice a foaf:Person ;
    foaf:name        "Alice Chen" ;
    foaf:knows       ex:bob ;
    schema:worksFor  ex:acme .

ex:bob a foaf:Person ;
    foaf:name        "Bob Diaz" ;
    schema:worksFor  ex:globex .

ex:acme   schema:name "Acme Corp" .
ex:globex schema:name "Globex" .

Several conventions are at work. The @prefix lines bind short labels to long IRI namespaces so foaf:name expands to the full http://xmlns.com/foaf/0.1/name. The keyword a is shorthand for the rdf:type predicate, so ex:alice a foaf:Person states that Alice is a Person. The semicolon repeats the same subject for several predicates, and each predicate-object pair is one triple. foaf:knows ex:bob has an IRI object (a link to another resource), while foaf:name "Alice Chen" has a literal object (a plain value). Spelled out, this block is nine triples, and because Alice's foaf:knows points at Bob, who has his own statements, the triples form a connected graph rather than two isolated records.

Querying that graph uses SPARQL, which works by matching patterns of triples. The query below finds the people Alice knows and the organizations they work for:

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
PREFIX schema: <https://schema.org/>
PREFIX ex:     <https://example.org/>

SELECT ?friendName ?orgName
WHERE {
  ex:alice foaf:knows      ?friend .
  ?friend  foaf:name       ?friendName .
  ?friend  schema:worksFor ?org .
  ?org     schema:name     ?orgName .
}

Each line in the WHERE clause is a triple pattern with variables (the ? terms). SPARQL finds every set of bindings that makes all the patterns true at once, here returning Bob Diaz at Globex. The query describes a shape to match in the graph rather than a sequence of joins to execute, which is the same expressive style graph query languages share.

Two further layers complete the picture. Schema and inference come from RDFS and OWL, vocabularies for describing the vocabulary: they let a modeler declare class hierarchies, domains and ranges for predicates, constraints, and (in OWL specifically) inverse and transitive relationships, after which a reasoner can derive entailed triples (if Acme is a Company and every Company is an Organization, then Acme is an Organization, with no one stating it directly). Named graphs let a triplestore group triples into separately identified subgraphs within one dataset, which is how systems track provenance, partition by source, or version data, by recording which named graph a statement came from. Together these give RDF a full stack: a model (triples), serializations to exchange it, a query language (SPARQL), schema and reasoning layers (RDFS, OWL), and partitioning (named graphs).

Benefits of using RDF graphs

The advantages of RDF follow directly from the model, and each comes with a trade-off worth naming so the picture stays honest.

Interoperability through global identifiers. Because resources are named with IRIs rather than local keys, data from independent sources merges on shared identifiers without a mapping layer. This is RDF's defining strength and the reason it anchors cross-organization data integration.

Self-describing, flexible structure. A triple carries its own predicate, so adding a new kind of fact means adding triples, not migrating a schema. RDF graphs accommodate sparse and irregular data gracefully, since there are no fixed columns to leave null.

Shared, standardized vocabularies. Reusing established vocabularies (schema.org, FOAF, Dublin Core, SKOS, and domain ontologies) gives a dataset meaning that other systems already recognize, and reduces the design work of modeling common concepts from scratch.

Inference and reasoning. RDFS and OWL bring formal semantics, so a reasoner can validate data against an ontology and derive implied facts. Few other data models offer standardized inference as a built-in property rather than application code.

Standardized query and a mature ecosystem. SPARQL is a W3C standard with broad triplestore support, and the surrounding tooling for validation (SHACL), serialization, and reasoning is well established after two decades of use.

The costs are real and should weigh on the decision. RDF is verbose: representing a fact as one or more triples with full IRIs produces more boilerplate than a row in a table, and the indirection has a learning curve. Attaching attributes to a relationship is awkward in classic RDF, since a triple has no place to hang properties of its own; modeling "Alice worked for Acme from 2019 to 2023" historically required reification (creating extra triples to describe the original triple), and RDF 1.2's triple terms (RDF-star) are the standard's answer to that friction. And the very generality that makes RDF mergeable can make high-throughput traversal analytics harder to optimize than in systems built specifically for that workload. RDF earns its keep when interoperability, shared meaning, and inference are the priority; it is a poorer fit when the job is fast traversal over data that already lives in one place under one schema.

How RDF graphs enable linked data

Linked data is the practice of publishing RDF on the open web so that datasets connect into a single global graph, and it is the setting RDF was designed for. The idea was articulated by Tim Berners-Lee in a 2006 design note that set out four principles: use URIs to name things; use HTTP URIs so those names can be looked up; when someone looks one up, return useful information using the standards (RDF, SPARQL); and include links to other URIs so they can discover more. The fourth principle is the one that builds the web of data, because a URI in one dataset can point straight into another.

The effect is that a dereferenceable IRI behaves like a web page for a thing rather than a document. Requesting http://dbpedia.org/resource/Berlin returns RDF statements about Berlin, several of which are IRIs into other datasets, and a client can follow those links the way a browser follows hyperlinks, except the destinations are machine-readable facts. The web stops being only a graph of documents and becomes, in parallel, a graph of data.

The canonical examples are public and large. DBpedia extracts structured facts from Wikipedia and publishes them as linked RDF with a SPARQL endpoint. Wikidata is a collaboratively edited knowledge base whose data is exported as RDF and widely linked, serving as a hub that other datasets point to for shared entity identifiers. Schema.org, a vocabulary backed by major search engines, is embedded in web pages (often as JSON-LD) so that search and other tools can read the entities a page describes; it is RDF vocabulary doing quiet work on a large fraction of the web. These rest on shared vocabularies (FOAF for people and social connections, Dublin Core for document metadata, schema.org for general web entities) that let independently published datasets describe the same kinds of things in the same terms, which is exactly what makes the links between them meaningful.

RDF graph examples

A concrete example makes the model tangible. Take three facts: Alice is a person named "Alice Chen"; Alice knows Bob; Bob works for an organization named "Globex". In triples (subject, predicate, object), that is:

Read as a graph, ex:alice, ex:bob, and ex:globex are nodes; foaf:knows and schema:worksFor are directed edges between them; and the literal values hang off their subjects as labeled attributes. Following foaf:knows from Alice to Bob and then schema:worksFor from Bob to Globex is a two-hop traversal, answerable by the SPARQL pattern shown earlier. The same shape scales: DBpedia and Wikidata are this structure with hundreds of millions of triples, and a markup snippet of schema.org JSON-LD in a web page is the same triples wearing a JSON syntax so a search engine can read the page's entities.

A natural question at this point is how an RDF graph differs from a property graph, the other widely used graph model (used by systems queried with openCypher or Gremlin). Both represent data as nodes and edges, but they make different choices, and neither is a flawed version of the other.

The table points at a single distinction underneath the rows. RDF optimizes for meaning that travels: global identifiers and formal semantics so data from anywhere can be combined and reasoned over. Property graphs optimize for modeling and traversal: properties sit directly on nodes and edges, which is ergonomic for developers and efficient for deep multi-hop queries within one dataset. The choice should follow the priority. When the goal is to integrate data across organizations, publish to the open web, or run inference over shared ontologies, RDF's design is the reason to use it. When the goal is fast traversal and analytics over data already consolidated under one schema, the property-graph model tends to be the more direct fit. Many mature systems use both, RDF at the integration and publishing layer and a property graph for traversal-heavy analytics.

How to build an RDF graph

Building an RDF graph is a sequence of modeling decisions more than a coding task. The steps below are the usual path from raw data to a queryable graph.

‍Define or reuse a vocabulary. Decide which entity types and relationships the graph needs, and prefer existing vocabularies over inventing IRIs: schema.org for general web entities, FOAF for people and social ties, Dublin Core for document metadata, SKOS for taxonomies, plus any domain ontology that fits. Reuse is what makes the result interoperable; minting a private predicate for a concept that schema.org already names isolates the data.

‍Mint IRIs for your resources. Give every entity a stable, ideally dereferenceable HTTP IRI under a namespace you control. Stability matters because these identifiers are the join keys other datasets and future versions will rely on.

‍Model the data as triples. Map each fact to a subject-predicate-object statement: entities and their relationships become IRI-to-IRI triples, and attributes become IRI-to-literal triples. Where a relationship needs its own properties (a date, a weight), plan for reification or RDF-star up front rather than discovering the gap later.

‍Choose a serialization. Write or export the triples in a format suited to the use: Turtle for human-edited files and documentation, JSON-LD for embedding in web pages and APIs, N-Triples for bulk loading, RDF/XML where legacy tooling requires it.

‍Load into a triplestore and query. Ingest the triples into an RDF database (Apache Jena, GraphDB, Amazon Neptune, Virtuoso, and others), optionally attach an RDFS or OWL ontology for validation and inference, and query the result with SPARQL. From here the graph can be linked outward to public datasets, served at its IRIs as linked data, or used to ground downstream applications.

This path assumes RDF is the right model, which it is when interoperability, shared vocabularies, or inference are the point. A common situation is the opposite one: the data already lives in relational tables, in a warehouse, lake, or open table format, and the goal is to query the relationships in it as a graph rather than to publish triples to the web. Converting that data into RDF and standing up a triplestore is a heavy step to take only for graph access, and it introduces a second copy to keep in sync.

For that case, a property-graph query engine is the more direct route, and PuppyGraph is one example. It maps existing tables in a warehouse, lakehouse, or open table format such as Apache Iceberg to a property graph through a user-defined schema, then runs openCypher and Gremlin queries (openCypher first, with Gremlin also supported) over them in place, with no ETL into a separate store. It is a property-graph engine, not an RDF triplestore, and it does not speak SPARQL or store triples; the right reasons to choose RDF instead are global IRIs, shared web vocabularies, and OWL or RDFS inference. What PuppyGraph removes is the conversion and duplication step for the relational case: because it is a query engine that reads the tables directly rather than a system that ingests a copy, the data stays where it lives and the graph is a view over it rather than a second system of record. It is used for graph workloads at companies including Coinbase, Dawn Capital, and Prevalent AI. The honest framing is that RDF and the property-graph approach solve adjacent problems: RDF when meaning has to travel across sources and the open web, a property graph over existing tables when the data is already consolidated and the need is traversal.

Conclusion

An RDF graph turns data into a set of triples in which identity and meaning are part of the data itself, carried by global IRIs and shared vocabularies rather than supplied by an external schema. That is what lets independently produced datasets merge into one graph, what lets SPARQL and OWL query and reason over them through standard interfaces, and what makes RDF the backbone of linked data, public knowledge graphs, and increasingly the grounded models that enterprise AI reasons over. The model has costs, verbosity and a learning curve among them, and it is not the only way to get a graph: when data already sits consolidated in tables and the need is fast traversal rather than open-web interoperability, a property-graph approach is often the better fit. The useful skill is knowing which problem you have, because the two models are built for different ones.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries run over warehouse and lakehouse tables, with no graph-specific ETL, when a property graph over your existing tables is the fit rather than a triplestore.