Property Graph vs RDF (and Cypher vs SPARQL)

A labeled property graph (LPG) models data as nodes carrying labels and key-value properties, connected by directed edges that also carry a type and properties, while RDF models data as subject-predicate-object triples in which subjects and predicates are IRIs and objects are IRIs or literal values. Both are graph data models, and either can hold a knowledge graph. The LPG model is queried with Cypher (or the newer ISO GQL standard) and is native to Neo4j, Memgraph, and TigerGraph; RDF is a W3C standard queried with SPARQL and native to triple stores such as GraphDB, Stardog, and Apache Jena. The practical differences lie in identifiers, edge properties, schema, and interoperability.

The two data models

In a labeled property graph, the unit of data is a node or an edge, and each is a small record. A node has zero or more labels (Person, Scientist) and a map of properties (name: "Marie Curie", born: 1867). An edge has exactly one type (AWARDED), a direction, and its own property map (year: 1903). Properties are stored on the element they describe, so a fact about a relationship, such as when it began, sits on the edge itself. Nodes are identified by an internal ID that the database assigns; any external identifier is just another property.

In RDF, the unit of data is a triple: a subject, a predicate, and an object. wd:Q7186 wdt:P166 wd:Q38104 says that the entity Q7186 (Marie Curie) has the property P166 (award received) with value Q38104 (Nobel Prize in Physics). A graph is a set of such triples. Subjects and predicates are IRIs, which are global identifiers; objects are either IRIs or literals (strings, numbers, dates, each with a datatype). There is no separate node record: an entity is whatever appears as a subject or object, and its “properties” are more triples with the same subject. The mechanics are covered in triples: subject, predicate, object and RDF.

The one thing RDF cannot do natively is attach a property to an edge. A triple is atomic; there is nowhere to put “year: 1903” on the statement that Curie received the prize. The workarounds are reification (a node representing the award event, with the year hung on it, which is the pattern Wikidata uses for its statements and qualifiers) and RDF-star, an extension that lets a triple be the subject or object of another triple. RDF-star is being folded into the RDF 1.2 and SPARQL 1.2 specifications under development at the W3C, and several stores already support it.

Comparison table

Aspect	Labeled property graph (LPG)	RDF
Basic unit	Node records and edge records with property maps	Triples (subject, predicate, object)
Node identity	Database-internal ID; external identifiers are properties	IRI, globally unique and dereferenceable by design
Edge identity and properties	Edges are first-class with their own properties	Edges are triples with no properties; use reification or RDF-star
Labels and types	Zero or more labels per node; exactly one type per edge	`rdf:type` triples; an entity can have any number of types
Schema	Optional; labels, constraints, and indexes defined per database	Optional; RDFS and OWL for vocabulary and inference, SHACL for validation
Inference	None built in; some products add rules	RDFS and OWL entailment supported by many stores
Query language	Cypher, openCypher, Gremlin, GQL (ISO/IEC 39075:2024)	SPARQL 1.1 (W3C Recommendation, 2013)
Serialization	No standard interchange format; CSV, JSON, GraphML, vendor dumps	Turtle, N-Triples, JSON-LD, RDF/XML, TriG, N-Quads, all standardized
Standards body	ISO (GQL); openCypher is vendor-led	W3C
Federation	Not standardized	SPARQL 1.1 Federated Query (`SERVICE` keyword)
Typical databases	Neo4j, Memgraph, TigerGraph, Amazon Neptune (property graph mode), ArangoDB	GraphDB, Stardog, Apache Jena Fuseki, Virtuoso, Amazon Neptune (RDF mode), Oxigraph
Public datasets	Few large public LPG datasets	Wikidata, DBpedia, schema.org, thousands of linked open data sets

Identifiers

The identifier model is the deepest difference. In RDF, every entity and every predicate is an IRI, so two datasets that both use http://www.wikidata.org/entity/Q7186 are talking about the same Marie Curie without prior agreement, and merging them is a set union of triples. This is what makes linked data possible.

In an LPG, node identity is local to the database. A Person node with name: "Marie Curie" in one Neo4j instance has no built-in relationship to a similar node in another. Teams add a property such as wikidata: "Q7186" with a uniqueness constraint, which works inside one system but is a convention rather than part of the model. Merging two property graphs is an integration project.

Schema and validation

Both models are schema-optional, but they diverge in what schema means. An LPG schema is a set of database-level constraints (uniqueness, existence, property type) attached to labels in one database.

RDF separates vocabulary from validation. RDFS and OWL define what classes and properties mean and permit inference (if Physicist is a subclass of Scientist, every physicist is inferred to be a scientist). SHACL defines shapes that data must conform to and produces validation reports. Because the vocabulary is itself RDF and identified by IRIs, it is shareable: schema.org, FOAF, and Dublin Core are RDF vocabularies used across millions of documents. See knowledge graph vs ontology, OWL, and SHACL.

Standards

RDF has been a W3C Recommendation since 1999 (RDF 1.1 in 2014), SPARQL 1.1 since 2013, OWL 2 since 2009, and SHACL since 2017. The W3C specifies serializations, a query language, a protocol, and an update language.

The property graph model had no formal standard for most of its history. Cypher originated with Neo4j and was opened as openCypher in 2015; Gremlin comes from the Apache TinkerPop project. In April 2024, ISO published ISO/IEC 39075:2024, the GQL standard, the first new ISO database language since SQL. GQL draws heavily on Cypher, and vendors have begun aligning with it. SQL/PGQ, part of SQL:2023, adds property graph queries to SQL.

Worked example: the same fact both ways

The fact is that Marie Curie was awarded the Nobel Prize in Physics in 1903.

Writing it

In Cypher, for a labeled property graph:

CREATE (p:Person {name: "Marie Curie", wikidata: "Q7186"})
CREATE (a:Award {name: "Nobel Prize in Physics", wikidata: "Q38104"})
CREATE (p)-[:AWARDED {year: 1903}]->(a);

The year sits on the edge. Nothing else is needed.

In Turtle, for RDF, using an event node to carry the year, since a bare triple has no room for it:

@prefix wd:   <http://www.wikidata.org/entity/> .
@prefix wdt:  <http://www.wikidata.org/prop/direct/> .
@prefix ex:   <https://example.org/> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

wd:Q7186   wdt:P166    wd:Q38104 .

ex:curie_nobel_1903
           a           ex:AwardEvent ;
           ex:recipient wd:Q7186 ;
           ex:prize     wd:Q38104 ;
           ex:year      "1903"^^xsd:gYear .

The first triple is the direct statement, using Wikidata’s own IRIs so that it lines up with the public graph. The event node ex:curie_nobel_1903 is the reification that holds the year. With RDF-star the same information could be written as << wd:Q7186 wdt:P166 wd:Q38104 >> ex:year "1903"^^xsd:gYear ., which annotates the triple directly.

Reading it

In Cypher:

MATCH (p:Person {name: "Marie Curie"})-[r:AWARDED]->(a:Award)
RETURN a.name AS prize, r.year AS year;

In SPARQL, against the Turtle above:

PREFIX wd:  <http://www.wikidata.org/entity/>
PREFIX ex:  <https://example.org/>
SELECT ?prize ?year WHERE {
  ?event ex:recipient wd:Q7186 ;
         ex:prize     ?prize ;
         ex:year      ?year .
}

Both return one row: the Nobel Prize in Physics and 1903. Cypher has direct access to the edge’s year; SPARQL reaches it through the event node because that is where the RDF model put it. Against the live Wikidata Query Service the SPARQL would instead use Wikidata’s statement and qualifier IRIs (p:P166, ps:P166, pq:P585), the same reification pattern under Wikidata’s naming.

Cypher vs SPARQL

Cypher and SPARQL are both declarative pattern-matching languages. Cypher’s ASCII-art syntax for paths ((a)-[:KNOWS*1..3]->(b)) is concise for variable-length traversal and for reading and writing edge properties. SPARQL operates over a global data space: prefixes resolve to real IRIs, SERVICE clauses federate one query across several endpoints (for example, joining a local graph to Wikidata), and property paths (wdt:P31/wdt:P279*) handle variable-length traversal. SPARQL also has CONSTRUCT, which returns a graph rather than a table. Cypher’s write clauses (CREATE, MERGE, SET) are part of the same language; RDF splits writes into SPARQL Update. The SPARQL page covers the language in detail.

When to use which

Choose a labeled property graph when the graph belongs to one application, edge properties are common (timestamps, weights, confidence scores), and interoperability with external datasets is not a requirement. Operational graphs, recommendation engines, fraud detection, and network analysis usually land here.

Choose RDF when the graph must be shared, merged, or published; when it should link to Wikidata, DBpedia, or other public data; when an ontology, inference, or SHACL validation is part of the design; or when standards compliance matters. Public sector, scientific, and cultural heritage data, enterprise integration across many sources, and anything consumed by search engines as structured data land here.

Choose neither exclusively when both needs are present. Amazon Neptune supports both models, and Neo4j’s neosemantics plugin imports and exports RDF. A common arrangement is to model and exchange in RDF for identity and interoperability, and to load into an LPG store for application queries. Products are listed in graph databases.

For developers

If in doubt, mint IRIs for entities even in a property graph. Storing an iri property with a uniqueness constraint on every node costs little and keeps RDF export open. Conversely, if working in RDF and edge properties are everywhere, check that the chosen store supports RDF-star before building reification, because the query patterns are considerably simpler.

For SEOs

Search engines read structured data as RDF. JSON-LD is an RDF serialization, and every @type and property in a schema.org block is an IRI under the hood (https://schema.org/Person, https://schema.org/sameAs). That model is why sameAs links to Wikidata and Wikipedia work: they are IRIs pointing at IRIs, which a search engine’s knowledge graph can reconcile. Property graphs play no role in on-page markup. See JSON-LD and structured data.

Common misconceptions

RDF is often described as an XML format. RDF/XML was the original serialization; Turtle and JSON-LD are now the common ones, and the model is independent of syntax. A second misconception is that RDF cannot represent edge properties at all. It cannot with a single triple, but reification and RDF-star both handle the case, and Wikidata’s qualified statements demonstrate it at scale. A third is that property graphs have no standard; since 2024, they have GQL, though most production code is still Cypher. Finally, a triple store is a graph database. The choice is between two data models, not between graphs and something else.

FAQ

What is a labeled property graph?

A labeled property graph (LPG) is a data model in which nodes carry one or more labels and a set of key-value properties, and directed edges carry a single type plus their own properties. Neo4j, Memgraph, and TigerGraph use this model, and you query it with Cypher or GQL. Its main practical advantage over RDF is that relationship facts, such as a date or weight, sit directly on the edge.

Is RDF a property graph?

No. RDF is a triple-based model in which every statement is a subject, predicate, and object, all identified by IRIs except for literal values. The base model has no edge properties; attaching data to a relationship requires reification or the RDF-star extension. Some databases, including Amazon Neptune and GraphDB, support both RDF and property graph views, but the two models remain distinct.

What is the difference between Cypher and SPARQL?

Cypher is the query language for labeled property graphs, originally from Neo4j and now the basis of the ISO GQL standard, with an ASCII-art syntax for nodes and edges. SPARQL is the W3C query language for RDF, built from triple patterns that share variables, with federation across endpoints and graph-returning CONSTRUCT queries. Both are declarative pattern-matching languages and support variable-length paths.

Is there a standard for property graphs like SPARQL for RDF?

Yes, as of 2024. ISO/IEC 39075:2024, known as GQL, is the ISO standard graph query language for property graphs and is closely based on Cypher. Before GQL, openCypher and Apache TinkerPop’s Gremlin served as de facto standards without formal standing. SQL:2023 also added SQL/PGQ for property graph queries inside SQL. Vendor adoption of GQL is ongoing.

Sources and further reading

W3C, RDF 1.1 Concepts and Abstract Syntax: https://www.w3.org/TR/rdf11-concepts/
W3C, RDF 1.1 Turtle: https://www.w3.org/TR/turtle/
W3C, SPARQL 1.1 Query Language: https://www.w3.org/TR/sparql11-query/
W3C, RDF-star and SPARQL-star Community Group report: https://w3c.github.io/rdf-star/cg-spec/
Neo4j, Cypher Manual: https://neo4j.com/docs/cypher-manual/current/
ISO/IEC 39075:2024, Information technology, Database languages, GQL: https://www.iso.org/standard/76120.html