What is the difference between a property graph and RDF?

A property graph stores nodes and edges that carry their own properties; RDF stores every fact as a three-part triple named by global IDs.

Concept

A property graph stores things and connections that carry their own details, while RDF (Resource Description Framework) stores every fact as a three-part statement. Think of a property graph as a whiteboard of boxes and arrows with notes pinned to both, and RDF as a long list of short sentences, such as “customer A bought lamp A,” that anyone can merge with their own list. A key practical difference is where details about a relationship go: a property graph puts them on the edge, while RDF needs extra statements or an extension such as RDF-star. Property graphs typically fit applications built on traversal, and RDF typically fits linked data, shared vocabularies, and merging data from many sources.

Learning objectives

After reading this article you will be able to:

• Describe RDF’s building blocks: triples, IRIs, literals, and rdf:type
• Compare property graphs and RDF on identity, types, schema, and query languages
• Explain how each model stores details about a relationship, including RDF-star
• Choose a model for a workload and convert data from one model to the other

What are the building blocks of RDF?

RDF has one building block, the triple: a statement with a subject, a predicate, and an object, much like a simple sentence with a subject, a verb, and an object.

• Subject: the resource the statement is about, an IRI or a blank node.
• Predicate: the relationship or attribute, always an IRI.
• Object: the value, which is an IRI, a blank node, or a literal.

An IRI (Internationalized Resource Identifier) is a web-style global identifier such as https://example.com/customerA, usually shortened with a prefix to ex:customerA. A blank node is a resource with no global name, local to the data that contains it. A literal is a plain value with a datatype, such as xsd:integer or xsd:dateTime, and a string literal can also carry a language tag, such as "lamp"@en.

Types are ordinary triples too: rdf:type, written a in Turtle (a common text format for RDF), links a resource to a class, and one resource can have several types. A set of triples forms a graph: subjects and objects are the nodes, and predicates are the edges. Because an RDF graph is a set, each distinct triple appears once.

How do property graphs and RDF compare?

Both models are directed graphs, and both can hold a knowledge graph. They differ in how they identify things, attach types and attributes, define a schema, and run queries.

	Labeled property graph	RDF
Basic unit	Nodes and edges, each with properties	Triples: subject, predicate, object
Identity	IDs typically assigned by the database	Global IRIs; blank nodes for local resources
Types	Labels on nodes and edges (in many systems a node can have several; an edge typically has one)	rdf:type triples, several per resource
Attributes	Key-value properties on nodes and edges	Triples whose object is a literal
Multiple values	An array property	Several triples with the same subject and predicate
Schema	Often optional or system-specific constraints	RDFS and OWL for inference; SHACL for validation
Query language	GQL (ISO/IEC 39075:2024), openCypher, Gremlin, SQL/PGQ	SPARQL (SPARQL 1.1 is a W3C Recommendation)

The schema row hides a difference in meaning. RDFS and OWL, the W3C schema and ontology languages, follow an open-world assumption: a missing statement is unknown rather than false. For example, declaring that the domain of ex:email is ex:Customer makes a reasoner, software that derives new facts from rules, infer that anything with an email is a customer. It does not reject data. SHACL adds closed-world validation, closer to how property graph constraints typically reject writes.

How does the same fact look in each model?

A property graph stores a purchase and its details as one edge with properties. RDF turns the purchase into its own resource described by several triples. For example, an online store records that a customer bought a lamp through the web store with a gift note. As a property graph:

(:Customer {email: "[e-mail]"})
  -[:PURCHASED {channel: "web", giftNote: "Happy birthday"}]->
(:Product {sku: "LAMP-A"})

In RDF, written in Turtle syntax, the purchase resource holds the channel and the note:

@prefix ex: <https://example.com/> .

ex:customerA  a  ex:Customer ;
    ex:email  "[e-mail]" .

ex:productA  a  ex:Product ;
    ex:sku  "LAMP-A" .

ex:purchaseA  a  ex:Purchase ;
    ex:buyer     ex:customerA ;
    ex:item      ex:productA ;
    ex:channel   "web" ;
    ex:giftNote  "Happy birthday" .

Queries follow the same shapes. To find what this customer bought on the web, a GQL or openCypher query matches one edge and filters on its property:

MATCH (c:Customer {email: '[e-mail]'})-[p:PURCHASED]->(prod:Product)
WHERE p.channel = 'web'
RETURN prod.sku

A SPARQL query matches triple patterns around the purchase resource:

PREFIX ex: <https://example.com/>

SELECT ?sku WHERE {
  ?customer  a           ex:Customer ;
             ex:email    "[e-mail]" .
  ?purchase  a           ex:Purchase ;
             ex:buyer    ?customer ;
             ex:item     ?product ;
             ex:channel  "web" .
  ?product   a           ex:Product ;
             ex:sku      ?sku .
}

In other words, the property graph keeps the relationship compact and makes traversal the natural operation. RDF names resources with global IRIs, so datasets that share IRIs merge by combining their triples (blank nodes are kept distinct during a merge).

Try HelixDB

Store relationships as edges with their own typed properties in open-source HelixDB, a labeled property graph database.

Get started

How do you store data about a relationship?

In a property graph, you put it on the edge, and each repeated relationship is its own edge. RDF has no edge properties, so it needs a workaround. A plain triple such as ex:customerA ex:purchased ex:productA records only that the relationship exists, and a second identical purchase adds nothing. RDF has four common ways to say more:

Approach	How it works	Trade-off
Intermediate resource	The relationship becomes a resource, like ex:purchaseA	Portable; adds a hop to queries through the relationship
Reification	An rdf:Statement resource describes one triple	Four extra triples; does not assert the triple
Named graphs	Triples are grouped under a graph IRI that other triples describe	Suits batch provenance; one graph per triple is awkward
RDF-star	A reifier, linked by rdf:reifies to a triple term (object position only), holds the data	Compact; needs tool support

Classic reification looks like this, with the original triple stated separately (prefix declarations omitted):

ex:customerA  ex:purchased  ex:productA .

ex:statementA  a  rdf:Statement ;
    rdf:subject    ex:customerA ;
    rdf:predicate  ex:purchased ;
    rdf:object     ex:productA ;
    ex:channel     "web" .

RDF-star is being standardized as triple terms in RDF 1.2, which was a W3C Candidate Recommendation as of April 2026, not yet a final Recommendation. The draft Turtle 1.2 syntax adds an annotation block that asserts the triple and describes it in one statement:

ex:customerA  ex:purchased  ex:productA  {| ex:channel "web" |} .

The annotation creates a reifier, a resource linked to the triple term by rdf:reifies, that carries ex:channel. Giving each repeated purchase its own reifier keeps their data separate.

When should you use a property graph or RDF?

Put simply, use a property graph for an application’s own data and RDF for data you share and merge with others. A labeled property graph usually fits when:

• The graph backs an application, such as an online store’s recommendations, and developers query it directly.
• Relationships carry data, repeat, or change often, as in a purchase history or an AI agent’s memory.
• Queries are traversal-heavy: paths, neighborhoods, and multi-hop filters, as in GraphRAG retrieval.

RDF usually fits when:

• You publish or consume linked data that other organizations reference, such as a shared catalog across a group of libraries.
• Data from many independent sources must merge on shared global identifiers.
• You rely on standard vocabularies, formal ontologies, or OWL-based inference.

The two can also coexist: an application can run on a property graph and export RDF for publishing.

How do you convert between RDF and a property graph?

Map resources to nodes, rdf:type to labels, literal-valued predicates to properties, and resource-valued predicates to edges. From RDF to a property graph:

• Resources become nodes, each keeping its IRI in a property such as iri.
• rdf:type becomes the label. When a resource has more types than the target allows labels, store the rest as a property or as edges to class nodes.
• Literal-valued predicates become properties. Collect repeated values into an array, and choose a convention for language tags, such as one property per language.
• Resource-valued predicates become edges, labeled with the predicate’s local name.
• Blank nodes become nodes with generated IDs.
• Relationship resources collapse into edges. An intermediate resource, reified statement, or RDF-star annotation for one binary relationship can become one edge with properties.

Conversion tools differ in the details, so document the conventions you choose.

From a property graph to RDF, mint an IRI for each node, typically from its ID, and turn labels into rdf:type triples and properties into literal triples. Edge properties and parallel edges need an intermediate resource, reification, or one reifier per edge. Without one, two identical edges collapse into one triple, and their properties have nowhere to go.

How does HelixDB model graph data?

HelixDB stores all data as one labeled property graph, with native vector search and BM25 full-text search in the same database, and a traversal can narrow a search to the records it reaches. To load RDF data, an application converts it with the rules above:

• Exactly one label on every node and edge, so extra rdf:type values become a property or edges to category nodes.
• Typed properties: null, boolean, integer, float, date-time, string, bytes, arrays, and nested objects. Datatyped literals map to these where a matching type exists; datatypes without one, such as xsd:decimal or xsd:duration, and language tags need a convention.
• Directed edges in a multigraph. Several edges can connect the same pair of nodes, and self-loops are allowed, so each relationship keeps its own data.
• Separate ID spaces. Node and edge IDs come from separate 64-bit sequences. Store each source IRI as a top-level property, since only top-level properties can be indexed.

See the data model and traversals guides, or why graph, vector, and text belong in one database.

Frequently asked questions

Is RDF a database?

No. RDF is a data model with W3C-standardized formats such as Turtle, N-Triples, and JSON-LD. Databases that store RDF natively are usually called triple stores or RDF stores and are queried with SPARQL. Databases built on property graphs are often called property graph databases, or simply graph databases.

Is a property graph faster than RDF?

Not inherently. Speed depends on the storage engine, indexes, and query planner more than on the data model. Property graph systems commonly optimize multi-hop edge traversal, and RDF stores commonly optimize joins across many triple patterns. See graph vs relational databases for how traversals and joins differ.

Can a property graph use an ontology?

Yes. Labels, properties, and constraints can encode an ontology’s classes and relationships, or classes can be nodes linked by edges. The property graph model has no standard reasoning language like OWL, so inference typically runs in the application or in separate tooling.

Related topics

What is a property graph?

Labeled nodes and edges with typed properties on both.

What is a knowledge graph?

Entities, relationships, and provenance for search and LLMs.

What is a graph database?

Nodes, edges, traversals, and when a graph is the right model.

Graph vs relational database

How graphs and tables store relationships, and when each fits.

HelixDB data model

Labels, properties, multigraph edges, and indexes in HelixDB.

Traversals

Follow edges between nodes with HelixDB queries.