> ## Documentation Index
> Fetch the complete documentation index at: https://docs.helix-db.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/learn/graph-databases/what-is-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.
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](/learn/graph-databases/what-is-a-knowledge-graph). They differ in how
they identify things, attach types and attributes, define a schema, and run queries.
| | [Labeled property graph](/learn/graph-databases/what-is-a-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:
```text theme={"languages":{"custom":["languages/helixql.json"]}}
(:Customer {email: "buyer@example.com"})
-[: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:
```text theme={"languages":{"custom":["languages/helixql.json"]}}
@prefix ex: .
ex:customerA a ex:Customer ;
ex:email "buyer@example.com" .
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:
```text theme={"languages":{"custom":["languages/helixql.json"]}}
MATCH (c:Customer {email: 'buyer@example.com'})-[p:PURCHASED]->(prod:Product)
WHERE p.channel = 'web'
RETURN prod.sku
```
A SPARQL query matches triple patterns around the purchase resource:
```text theme={"languages":{"custom":["languages/helixql.json"]}}
PREFIX ex:
SELECT ?sku WHERE {
?customer a ex:Customer ;
ex:email "buyer@example.com" .
?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).
Store relationships as edges with their own typed properties in open-source HelixDB, a labeled property graph database.
## 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):
```text theme={"languages":{"custom":["languages/helixql.json"]}}
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:
```text theme={"languages":{"custom":["languages/helixql.json"]}}
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](/learn/ai-memory/what-is-ai-agent-memory).
* Queries are traversal-heavy: paths, neighborhoods, and multi-hop filters, as in
[GraphRAG](/learn/ai-memory/what-is-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](/learn/vector-search/what-is-vector-search) and
[BM25](/learn/full-text-search/what-is-bm25) full-text search in the same database, and
a traversal can
[narrow a search to the records it reaches](/learn/vector-search/filtered-vector-search).
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](/database/helix-db/core-concepts/data-model) and
[traversals](/database/helix-db/query-guides/traversals) guides, or
[why graph, vector, and text belong in one database](/learn/database-architecture/one-database-for-graph-vector-and-text).
## 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](/learn/graph-databases/what-is-a-graph-database).
### 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](/learn/graph-databases/graph-vs-relational-database) for
how traversals and joins differ.
### Can a property graph use an ontology?
Yes. Labels, properties, and constraints can encode an
[ontology's](/learn/graph-databases/what-is-a-knowledge-graph) 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
Labeled nodes and edges with typed properties on both.
Entities, relationships, and provenance for search and LLMs.
Nodes, edges, traversals, and when a graph is the right model.
How graphs and tables store relationships, and when each fits.
Labels, properties, multigraph edges, and indexes in HelixDB.
Follow edges between nodes with HelixDB queries.