Skip to main content
Concept
A labeled property graph stores data as nodes and directed edges that carry labels (in many systems a node can have several, while an edge typically has one) and key-value properties, while RDF (Resource Description Framework) stores every fact as a subject-predicate-object triple and names resources with globally unique IRIs. A key practical difference is data about a relationship: a property graph puts it on the edge, while RDF needs an intermediate resource or a statement-level mechanism such as reification or RDF-star. Property graphs typically fit application workloads 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 the RDF building blocks: triples, IRIs, literals, and rdf:type
  • Compare property graphs and RDF on identity, typing, schema, and query languages
  • Explain how each model stores data about a relationship, including RDF-star
  • Choose a model for a workload and map 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.
  • 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 abbreviated with a prefix as ex:customerA. A blank node is a resource with no global name, local to the data that contains it. A literal is a 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, 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, but they differ in identity, typing, attributes, schema, and query language. The schema row hides a difference in meaning. RDFS and OWL follow an open-world assumption: a missing statement is unknown rather than false. Declaring that the domain of ex:email is ex:Customer makes a reasoner 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 with its own data as one edge with properties; RDF turns the purchase into its own resource with several triples. For example, a customer bought a lamp through the web store with a gift note. As a property graph:
In RDF, written in Turtle syntax, the purchase resource holds the channel and the note:
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:
A SPARQL query matches triple patterns around the purchase resource:
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).

​
How do you store data about a relationship?

In a property graph, data about a relationship goes on the edge, and each repeated relationship is its own edge. RDF has no edge properties. 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: Classic reification looks like this, with the original triple stated separately (prefix declarations omitted):
RDF-star is being standardized as triple terms in RDF 1.2, which is not yet a W3C Recommendation. The draft Turtle 1.2 syntax adds an annotation block that asserts the triple and describes it in one statement:
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?

A labeled property graph usually fits when:
  • The graph backs an application, and developers query it directly.
  • Relationships carry data, repeat, or change often.
  • Queries are traversal-heavy: paths, neighborhoods, and multi-hop filters.
RDF usually fits when:
  • You publish or consume linked data that other organizations reference.
  • 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. 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.

​
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.

​
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.

​
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.

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.