Four Ways of Saying “Customer” (4/5): RDF or LPG
Part 4 of 5. Part 3 discussed content, context and accountability.
If meaning must be written down, it remains to decide in what form. Anyone approaching knowledge graphs soon meets two acronyms, RDF and LPG, which are not easy to tell apart precisely. A clear text on the subject is a white paper by Ben Kass from April 2025, summarized by Simrat Saini in September 2026 in an effective formula: RDF optimizes for meaning, validation and inference through formal semantic standards; LPG optimizes for graph traversal, speed and analytics.
It helps first to clarify what a graph is. A graph represents entities and relations. The entities are the nodes, the relations the edges that connect them. A family tree is a graph, as is a product's supply chain or a railway network. Graphs have returned to the center of attention because the most useful questions in a company concern relations, which tables represent poorly. Asking which second-tier suppliers depend on the same plant is a simple operation on a graph and a laborious one on a set of tables.
The first of the two models, RDF, Resource Description Framework, is a standard of the W3C, the consortium that maintains the web's specifications. Its minimal unit is the triple, made of subject, predicate and object, a structure close to that of a simple sentence. The triple (contract 4471, has counterparty, Acme Ltd) records a fact; millions of triples form a graph, kept in stores called, fittingly, triple stores. Around RDF a mature family of standards has grown: RDFS and OWL to define classes, hierarchies and logical rules; SHACL to check that data respect the model; SPARQL to query the graph.
Of the seven strengths Kass attributes to RDF, three matter for my argument. The graph contains both the data and the data model, like an archive that kept the files and the classification scheme on the same shelf. Every entity receives a global, resolvable identifier, which has made it possible to build shared models for general concepts, such as time and provenance, and for complex domains, such as process chemistry and finance. Reasoning, finally, is native: OWL makes it possible to infer new facts from declared ones.
OWL's class hierarchies closely recall the Porphyrian tree, with its genera and differences. They inherit its deductive power and, if Eco is right, its limit as well. A class tree holds up as long as it serves a bounded purpose, and begins to give way when it is extended to everything.
Kass also states the weaknesses. The mathematical and philosophical foundations impose a high cognitive load. The variants of OWL are numerous, and even expert modelers struggle to choose. Relations involving more than two parties require intermediate nodes, which weigh the graph down. Basic RDF does not allow properties to be attached to a relation. The extension that does, RDF*, was still in development in April 2025 and unevenly supported by vendors, and its current status should be checked before any choice.
The second model, LPG, Labeled Property Graph, is the graph in which nodes and edges carry properties in the form of key-value pairs. Its philosophy differs from that of RDF. RDF asks you first to define a conceptual model, apply it to the data and derive new information from it. The LPG was born to capture data as they come. It has slimmer theoretical foundations and a greater ability to traverse nodes and analyze them with mathematical tools. LPGs long lacked a common standard. GQL, the query language approved by ISO in April 2024, was created to fill the gap; being recent, it has not yet been adopted by all graph databases.
Kass lists five strengths: efficiency on large volumes and on frequently updated data; the traversal required by classic algorithms such as clustering, centrality and shortest path; open-source machine learning libraries; familiarity for developers; the native ability to attach properties to relations. The weaknesses are three. Without a formal schema there is no validation, and the correspondence between data, entities and connections becomes uncertain. Tools are often proprietary, and migrating from one database to another is costly. Logical reasoning, short of extensions, is not provided. The table below summarizes the comparison.
| Criterion | RDF | LPG |
|---|---|---|
| Optimizes for | meaning, validation, inference | traversal, speed, analytics |
| Standards | mature W3C standards (RDFS, OWL, SHACL, SPARQL) | GQL, ISO since April 2024, partial adoption |
| Model | declared and contained in the graph | optional, with no standard |
| Validation | SHACL | constraints specific to each product |
| Reasoning | native, via OWL | absent, short of extensions |
| Changing vendor | easy, widespread standards | hard, proprietary tools |
| Learning curve | steep | gentle at first |
| Best uses | aggregation, classification, schema alignment | large-volume analytics, graph algorithms |
Source: Kass (2025).
LPGs have a reputation for being simpler, because they do not require starting from a model: a graph can be up and running in a few days. Kass answers with the experience of someone who has seen many projects age. The data governance questions that initial modeling addresses arise anyway as the graph grows. The work RDF demands up front, an LPG demands later, spread across the graph's life. Kass is even-handed on the other side too. A knowledge graph can be built with either model, provided that a schema is imposed and enforced on the LPG. With RDF it is easier; with an LPG it remains possible.
The two models can also coexist, with some caution. Moving data from an LPG to an RDF graph generally entails a loss, because LPGs lack equivalent semantic standards. The reverse path is preferable. The RDF graph serves as the source of logical reasoning, with constructs such as inheritance between classes, and smaller portions, subgraphs, are exported to an LPG for traversal algorithms and machine learning. Kass cites architectures of this kind for entity resolution, that is, for establishing when two records with different names denote the same thing. Some hybrid databases, such as Amazon Neptune, accept either model and bind you to the choice made at storage time. Neptune allows queries both in SPARQL and in property graph languages, which narrows some of the distance. When Kass was writing, Neptune offered fewer features than specialized databases, such as GraphDB for RDF and Neo4j for LPGs.
For the choice, Kass proposes a method that starts from use. One defines the profiles of those who will use the graph, the use cases, the requirements and the competency questions, that is, the written list of questions the graph will have to answer. They work like a statement of requirements, and when they exist the shape of the graph almost chooses itself. In Eco's vocabulary, competency questions are a declaration of topic. They establish which objects the graph must describe, and therefore which distinctions it must draw and which it may ignore. A model built without them tries to cover everything and ends up answering every question badly.
Kass's summary is sober. LPGs lend themselves to large-volume analytics and to the study of graph structure; RDF to aggregating and classifying data. Both make it possible to build a knowledge graph and a semantic layer; what changes is how it is managed and which operations it supports.
Next: part 5, three theses and a caveat.
Sources for this part
- Kass, Ben (9 April 2025). Cutting Through the Noise: An Introduction to RDF & LPG Graphs (white paper). Enterprise Knowledge.
- Saini, Simrat (30 September 2026). Cutting Through the Noise: RDF & LPG (infographic). Enterprise Knowledge.