RDF vs. Property Graphs: Which Model Fits Enterprise Knowledge

Two teams at the same company both say they are building a knowledge graph. One is working in RDF. The other is working in a property graph. Eighteen months later, neither model can read the other, and the thing both teams were asked to produce, one trustworthy account of what the business means by its own terms, does not exist in either.

The choice between these two models is not a preference. It decides whether the meaning you encode can leave the team that encoded it.

What is the difference between RDF and a property graph?

Both store data as nodes and the connections between them. The difference is where meaning lives.

In a property graph, a node carries labels and a bag of key-value properties, and an edge carries a type and its own properties. It is quick to model, quick to load, and quick to query. What a label means is decided by the team that chose it, and that decision usually lives in application code or in somebody's head.

In RDF, every statement is a triple: a subject, a predicate, and an object. Every one of those parts can be a globally resolvable identifier rather than a local string. The model is declared in the data itself using open standards, so a second system reading the same graph can interpret it the same way without asking the first team what they meant.

Is one of them an open standard?

Both are standardised. This is worth stating plainly, because the opposite is often claimed.

GQL, the Graph Query Language for property graphs, is an ISO standard. ISO/IEC 39075 was published in April 2024, developed through ISO/IEC JTC 1 with national standards bodies voting it through, and Neo4j originated the proposal that led to it. Anyone who tells you property graphs have no standard is working from information that is now out of date.

What matters is which layer got standardised.

What each standard actually covers

• GQL standardises how you ask. A query language, and a type system for graphs.
• RDF standardises what the data is. A data model where identity is global rather than local to one database.
• OWL standardises what follows. Formal semantics, so a system can derive facts nobody typed in.
• SHACL standardises what valid looks like. A separate declarative language for constraints, so rules are data rather than code.

The industry standardised the query layer first because querying is the tractable half. Agreeing what the labels mean across an entire organisation is the hard half, and that is the half RDF, OWL and SHACL were built for.

Why does identity matter more than it sounds like it should?

Because an enterprise is not one database.

A property graph gives nodes identifiers that mean something inside that graph. The counterparty in your trading system and the same counterparty in a regulatory filing are two unrelated nodes until someone writes code to reconcile them, and that code becomes a permanent maintenance obligation that nobody owns after the person who wrote it changes teams.

RDF gives every entity a globally unique identifier. The same legal entity referenced from three systems is recognisably the same thing, without a reconciliation layer, because identity was part of the model rather than an afterthought.

What can RDF do that a property graph cannot?

Derive facts that were never stated.

If your model declares that every SSRI is an antidepressant, and that sertraline is an SSRI, then a query for antidepressants returns sertraline. Nobody wrote that statement down. The model implies it, and a reasoner acts on the implication.

A property graph returns what was literally stored. To get the same behaviour you write the traversal yourself, in code, for each case, and you maintain it as the business changes. That works. It also means the logic of your domain lives in an application rather than in the model, which is exactly the condition that makes a model impossible to govern.

How does each one handle rules and data quality?

Property graphs are schema-optional by design. That is a feature when you are exploring and a liability when the answers start carrying risk, because nothing stops a malformed record from entering and nothing tells you it did.

SHACL lets you declare what valid data looks like: which properties are required, which values are allowed, how many of a thing may exist. Those shapes are themselves data, which means they can be versioned, reviewed and approved by the people accountable for being right. A rule that lives in a pull request is a rule only engineering can change.

When is a property graph the right answer?

Often, and we would rather say so than pretend otherwise.

Where property graphs are genuinely the better fit

• Fraud detection and network analysis. You need fast traversal over very large volumes, not a negotiated definition.
• Recommendations. The model changes constantly and no one needs to audit it.
• A single team shipping quickly. When the people who wrote the labels are the only people reading them, local meaning is sufficient.

The pattern is that property graphs do well where the graph serves one application. The friction appears when a second department needs the same concepts and discovers that the labels were never defined anywhere they can reach.

So which model fits enterprise knowledge?

If the graph is infrastructure for one application, the property graph is a reasonable and often better choice, and GQL now gives you a standard way to query it.

If the graph is supposed to hold what your organisation has agreed is true, so that an auditor, a regulator, an AI agent and three departments all get the same answer, then you need identity that survives leaving the database, semantics a machine can reason over, and constraints that domain experts can change without filing a ticket. That is what RDF, OWL and SHACL were designed to carry.

Most large enterprises end up with both, and that is a sound outcome rather than a failure. The mistake is assuming the first kind will grow into the second.

Where does TopQuadrant fit?

We work in open W3C standards because the point of agreed meaning is that it travels. A model that cannot leave the platform it was built in is not an enterprise asset, it is a dependency.

TQ Data Foundation is where the model gets defined with the subject matter experts who own it, validated with SHACL, and exposed to AI systems as authoritative context rather than a best guess. The graph underneath can be whatever your architecture already runs on. For the wider picture of how this fits together, see our overview of knowledge graphs.