RDF vs. LPG: The Right Data Model for Sustainable Knowledge Graphs

Updated October 2026

RDF and labeled property graphs (LPG) are the two main ways to model a knowledge graph. RDF uses standard triples and global identifiers, which suits shared meaning across systems. LPG stores nodes and edges with properties inside one database, which suits application queries and graph algorithms. Many enterprises now keep RDF semantics at the core and use property graphs where speed matters.

What is the difference between RDF and LPG?

RDF describes knowledge as statements that any system can read, while LPG describes a graph that one database manages. That single difference drives most of the tradeoffs. It decides who owns identifiers, where the schema lives, and how easily data travels between tools.

How does RDF model data?

In RDF, every fact is a triple with a subject, a predicate, and an object. Subjects and predicates are IRIs, which are global web identifiers, so two systems that use the same IRI mean the same thing. The RDF 1.2 Concepts specification defines this model, and SPARQL is the standard way to query it.

Because identifiers are global, RDF graphs merge by design. Load two datasets that share IRIs and they connect without a mapping step. Vocabularies and ontologies in OWL sit on the same foundation, so the schema itself is data you can query, version, and share.

How does a labeled property graph model data?

A labeled property graph stores nodes and relationships, each with one or more labels and a set of key-value properties. A purchase edge can carry an amount and a timestamp directly. This shape maps neatly onto application objects, which is why developers find Cypher and Gremlin quick to learn.

The tradeoff is scope. Node IDs and label names mean something inside one database, and a second system has no built-in way to know that its Customer label matches yours. Integration across systems therefore needs extra mapping work, usually in application code.

What changed in graph standards between 2024 and 2026?

The biggest change is that both camps now have formal standards that close old gaps. RDF gained a standard way to describe statements, and property graphs gained an ISO query language. Relational databases also learned to query graphs directly, which changes the build or buy question.

Does RDF 1.2 close the edge property gap?

Largely, yes. The W3C published RDF 1.2 Concepts as a Candidate Recommendation on April 7, 2026. It adds triple terms, which let a triple be the object of another triple, and a reifies predicate that links a statement to the facts about it.

In practice you can now attach a source, a date, or a confidence score to one specific relationship in a standard way. The SPARQL 1.2 Working Draft from October 2026 adds nested triple patterns, an annotation syntax, and functions such as isTRIPLE to query them. This work grew out of the RDF-star community effort, and the working group still carries that name.

A triple term does not assert the inner statement by itself. That matters for provenance, because you can record that a source claims something without your graph claiming it is true. Property graphs have no direct equivalent of that distinction.

What is GQL?

GQL is the ISO standard query language for property graphs. ISO published it as ISO/IEC 39075 in April 2024, covering how to create, query, update, and control property graphs.

Neo4j's manual says GQL adopted much of Cypher's query style, and that Cypher already covers most mandatory GQL features while full conformance is still in progress. Spanner Graph offers an ISO GQL interface alongside SQL. A shared standard lowers lock-in for property graph users, which used to be one of RDF's clearest advantages.

What is SQL/PGQ?

SQL/PGQ lets a relational database expose tables as a property graph and query it with graph patterns. ISO published it in June 2023 as ISO/IEC 9075-16, Part 16 of the SQL standard. You define the graph once over existing tables and query it with a GRAPH_TABLE clause.

Adoption is spreading. Oracle AI Database 26ai supports SQL property graphs as defined in SQL 2023. The PostgreSQL 19 development docs include a CREATE PROPERTY GRAPH command that conforms to SQL/PGQ, though version 19 is not yet a supported release. For many teams, this means the first graph needs no new database at all.

How do schema and validation work in each model?

RDF validates data with SHACL shapes that live outside the database as portable data, while property graphs rely on constraints inside each engine. Both approaches can enforce quality. The difference is whether your rules can travel with your data.

SHACL, the Shapes Constraint Language, describes the structure that valid RDF data must follow. A shape can require a property, restrict its datatype, or cap the number of values. SHACL 1.2 Core reached Working Draft in September 2026. GraphDB and Stardog both validate with SHACL.

Neo4j enforces quality with database constraints. Uniqueness constraints are available in every edition, while existence, property type, and key constraints need Enterprise Edition. These rules work well inside Neo4j, but another system cannot read them as a shared contract.

Why does the data model matter for owning your knowledge?

Your knowledge graph encodes how the business defines customers, products, risks, and the links between them. That institutional knowledge is one of a company's most valuable assets. It should live in open formats on infrastructure you control, not in one vendor's internal schema.

RDF helps here because the vocabulary, the data, and the validation rules are all standard documents. You can move them between GraphDB, Stardog, Neptune, or a file in Git without losing meaning. Property graphs are catching up through GQL, but the schema and constraints still live mostly inside each engine.

Ownership also pays off for AI. In the data.world study, GPT-4 answered 16 percent of enterprise questions correctly over raw SQL and 54 percent over a knowledge graph. A follow-up that added an ontology check raised accuracy to 72.55 percent. The lift came from explicit, shared meaning, which is exactly what you want to keep portable.

Galaxy works with teams to build ontologies, semantic models, and entity resolution on the stack they already run, using internal tooling that gets this set up fast. It builds in the open with Filament, its open-source data movement engine, and plans to open source more of that tooling.

Can RDF and LPG work together?

Yes, and most mature teams run both. The common pattern keeps shared vocabularies and identifiers in RDF and projects them into a property graph wherever an application needs fast traversals. Several tools now support that bridge.

How does Neo4j handle RDF?

Neo4j handles RDF through neosemantics, also called n10s. The plugin imports and exports RDF in Turtle, JSON-LD, N-Triples, and other formats, validates graphs with SHACL, and runs basic inference with ontology vocabularies. It is a Neo4j Labs project with community support only, and it is not available in AuraDB.

How does Amazon Neptune handle both models?

Amazon Neptune supports both models in one managed service. Property graphs use Gremlin and openCypher, and RDF graphs use SPARQL. You still choose one model per graph, so Neptune Database does not let you query the same data both ways.

Neptune Analytics goes further. It loads RDF in N-Triples format, interprets it as property graph concepts, and lets you query it with openCypher. The Neptune team has also published the OneGraph vision, a research proposal for a single model that serves RDF and LPG queries over the same data.

What about relational data?

Relational data can feed both models without a full copy. SQL/PGQ exposes tables as a property graph, and W3C mapping languages such as R2RML publish the same tables as RDF. Our SQL to RDF mapping guide walks through that workflow and the tools that run it.

Which model should you choose?

Choose by the job the graph must do, not by the database you already know. If several teams or systems must agree on meaning, start with RDF. If one application needs fast traversals or graph algorithms, start with a property graph. When both are true, run both.

For a vendor view, our ranking of the best graph databases in 2026 compares engines by job, and the list of graph database use cases shows which workloads favor each model. For platforms built around ontologies and reasoning, see our guide to enterprise knowledge graph platforms.

What mistakes do teams make when picking a graph model?

The most common mistake is choosing on query speed alone. Speed depends on the engine, indexes, and query shape far more than on the data model. A graph that is fast but meaningless to the next system becomes another silo.

The second mistake is skipping the ontology. Whichever model you pick, someone must define what a customer, an account, or a supplier means and how they relate. Our explainer on how ontology powers AI analytics covers that layer in detail.

The third mistake is treating the choice as permanent. With RDF 1.2, GQL, SQL/PGQ, and bridges such as neosemantics and Neptune Analytics, data can move between models. Keep identifiers stable and definitions in open formats, and the storage engine becomes a choice you can revisit.

Frequently asked questions

What is the main difference between RDF and LPG?

RDF describes everything as triples of subject, predicate, and object, and names things with global web identifiers. A labeled property graph stores nodes and edges inside one database, each with labels and key-value properties. RDF is built for shared meaning across systems. LPG is built for fast application queries and graph algorithms inside one engine.

Is RDF slower than a property graph?

Not as a rule. Speed depends on the engine, the indexes, and the shape of the query far more than on the data model. Property graph engines are often tuned for deep traversals and graph algorithms, while RDF stores are tuned for joins over triples and inference. Benchmark your own queries on your own data before you decide.

Can RDF store properties on relationships?

Yes. RDF 1.2 adds triple terms, which let one triple be the object of another, so you can attach a source, a date, or a confidence score to a single statement. The W3C published RDF 1.2 Concepts as a Candidate Recommendation in April 2026, and SPARQL 1.2 adds matching query syntax.

What is GQL and how does it relate to Cypher?

GQL is the ISO standard query language for property graphs, published in April 2024 as ISO/IEC 39075. It adopted much of Cypher's pattern matching style. Neo4j says Cypher already covers most mandatory GQL features and is moving toward full conformance. Spanner Graph also offers a GQL interface.

What is SQL/PGQ?

SQL/PGQ is Part 16 of the ISO SQL standard, published in 2023. It lets you declare a property graph over existing relational tables and query it with graph patterns from plain SQL. Oracle AI Database 26ai supports it, and the PostgreSQL 19 development branch includes a conforming CREATE PROPERTY GRAPH command.

What is SHACL used for?

SHACL, the Shapes Constraint Language, describes what valid RDF data should look like. A shape can require a property, limit its datatype, cap how many values it has, or apply a SPARQL rule. Validators then report every violation. GraphDB and Stardog support SHACL, and Neo4j can run it through the neosemantics plugin.

Can I use RDF data in Neo4j?

Yes, on self-managed Neo4j. The neosemantics plugin, a Neo4j Labs project, imports and exports RDF in formats such as Turtle and JSON-LD, validates graphs with SHACL, and runs basic inference. It is not available in AuraDB, where Neo4j points users to the rdflib-neo4j library instead. Labs projects have community support only.

Does any database support both RDF and LPG?

Amazon Neptune supports both models in one managed service, with Gremlin and openCypher for property graphs and SPARQL for RDF. You pick one model per graph. Neptune Analytics can load RDF in N-Triples and query it with openCypher. The Neptune team has also published research on a unified model called OneGraph.

Which model is better for AI and GraphRAG?

Both can feed retrieval, so the deciding factor is meaning. Research from data.world found GPT-4 answered 16 percent of enterprise questions correctly over raw SQL and 54 percent over a knowledge graph with an ontology. Explicit, shared definitions help models more than any particular storage format. RDF makes those definitions portable.

Should I migrate from a property graph to RDF?

Rarely all at once. If an application graph works, keep it and add an RDF layer for shared vocabularies, identifiers, and validation where several teams or systems must agree. Tools such as neosemantics and R2RML mappings let you publish RDF views without rewriting the application. Migrate fully only when the shared model becomes the main product.