Property Graphs vs. Knowledge Graphs: What Actually Differs

“Should we use a knowledge graph or a graph database?” comes up constantly, and it’s a slightly confused question. Both are graphs. The real question is which data model: the labeled property graph (LPG) or RDF. Each one comes with very different assumptions about what your data means and who needs to understand it.

The 30-second version

• Property graphs (Neo4j, Memgraph, Amazon Neptune’s openCypher mode, and others) optimize for developers and traversals. Nodes and edges carry key-value properties, and you query with Cypher or GQL.
• RDF knowledge graphs (GraphDB, Stardog, Neptune’s SPARQL mode, and others) optimize for meaning and interoperability. Everything is a triple of globally identified resources, and you query with SPARQL and describe semantics with RDFS/OWL.

Same shape on a whiteboard. Very different philosophies.

The same fact, two ways

Say Ada works at Acme, and she started in 2021.

Property graph (Cypher):

CREATE (a:Person {name: 'Ada'})-[:WORKS_AT {since: 2021}]->(c:Company {name: 'Acme'})

The since property lives directly on the relationship. That’s natural and compact.

RDF (Turtle):

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

ex:ada  a ex:Person ;
        ex:name "Ada" ;
        ex:worksAt ex:acme .
ex:acme a ex:Company ;
        ex:name "Acme" .

Where does since: 2021 go? Classic RDF has no edge properties, so you’d either reify the relationship into an ex:Employment node or use RDF-star, which lets you make statements about statements:

<< ex:ada ex:worksAt ex:acme >> ex:since 2021 .

That small difference captures the whole debate: LPG makes modeling easy, and RDF makes meaning explicit.

Where they really differ

Identity is the underrated difference

In RDF, https://example.org/acme is Acme, everywhere. Two datasets that use the same IRI join automatically. That’s why RDF dominates in life sciences, government open data, and enterprise data integration: the hard problem there is agreeing on what things are, not traversing them quickly.

In an LPG, a node’s identity is local. Merging two graphs means writing entity resolution logic yourself.

Reasoning: explicit vs. inferred

Define ex:CEO rdfs:subClassOf ex:Employee in RDF, and a reasoner will infer that every CEO is an employee, so a query for employees returns CEOs too. In a property graph, you’d add both labels or encode that rule in the query. Neither approach is wrong. One puts knowledge in the data model, and the other puts it in code.

Why this matters for AI agents

This is where it gets interesting for me. LLM-powered agents increasingly use graphs as grounding and memory (GraphRAG, entity-centric retrieval, tool routing).

• LPGs are great for agent memory: fast, flexible, and easy to write to from code, and edge properties hold confidence scores and timestamps naturally.
• RDF is great for agent knowledge: shared ontologies give agents a common vocabulary, and provenance and inference reduce hallucination by making implicit facts explicit.

My working rule: if multiple systems (or multiple agents) need to agree on what things mean, lean RDF. If one application needs to move fast over connected data, lean LPG.

How I’d choose

Ask three questions:

1. Will this data be shared or merged with outside sources? If yes, RDF’s global identity pays for itself.
2. Do I need inference or formal validation? If yes, use RDF with OWL/SHACL.
3. Is the workload mostly traversals, paths, and graph algorithms inside one app? If yes, a property graph is usually the faster path to production.

And increasingly, the answer is both: an RDF layer for the shared semantic model, projected into a property graph for operational speed. The line between them is blurring, with RDF-star on one side and GQL on the other, but the philosophies remain distinct.

Got a strong opinion on LPG vs. RDF? I’d love to hear it. Get in touch.