Why Knowledge Graph Projects Fail — and How to Make Them Succeed

I've created, and advised on the creation of, dozens of large-scale knowledge graphs over the years. Overall, the number of unsuccessful knowledge graphs far outweighs the number of successful ones. I don't think this is necessarily a character defect on my own part: talk to almost anyone in the field, usually over a beer at the end of a conference day, and you'll find this is the norm rather than the exception.

There are actually a number of good reasons such knowledge graphs fail, and it doesn't necessarily have to do with a particular stack or framework. Instead, it usually comes down to the following.

Part One: Why Knowledge Graph Projects Fail

Modeling Pitfalls

Trying to use relational data to feed a knowledge graph directly. Yes, you can create such graphs directly from relational data, but in all honesty, SQL-centric data is already in a graph, albeit one that's usually not recognised as such — and the data is often already pretty sparse, because all of the really useful, meaty bits that add substance to a knowledge graph have been removed in order to optimise retrieval of data rows. You can still use SPARQL on it, but chances are pretty good most developers won't thank you for that.

Marginal deduplication. One of the benefits you can get with a knowledge graph is the ability to eliminate duplication. SQL Select (View) output is typically heavily denormalised, even if the underlying graph is almost by definition normalised — usually with only a handful of fields changing while everything else stays the same. Many triple stores do index triples, but they retain all of those duplicates on disk, and that can seriously impede performance. This generally isn't a problem if your goal is an intermediate graph, but it can weigh significantly on performance if you don't have a good way of cleaning up those duplicates.

Deep inheritance of upper ontologies. When the semantic web was first created, the assumption was that you build ontologies by subclassing (and, to a lesser extent, creating subproperties). Most OWL ontologies early on were built around that assumption, which can be stated one way as: you needed to know ahead of time precisely what classes you had in your ontology. The problem is that in most cases you don't know what classes you'll need until you have a significant percentage of the dataset already in place. That creates a chicken-and-egg problem that can be hard to resolve, even for people who've been developing ontologies for a long time, let alone lay ontologists.

A paucity of class-composition tools. Often you build functional units not by inheriting from superclasses but by composing functional units together. This is a lesson software development already learned — C++ ended up building a complex template structure precisely to solve this issue — but when rdfs:subClassOf is the only real tool for inheritance, you end up doing handstands to make the ontology handle real-world cases.

Taxonomies entangled with schematic ontologies. We love drill-downs, because drill-downs give us nice, clean hierarchies. But not everything within a hierarchy is really part of an ontology — we create a putative entity called owl:Thing to give ourselves a pretend hierarchy root, because for most people, Linnaeus is the extent of their understanding of ontologies, and it's largely meaningless there. The reality is that concept schemes only very occasionally form hierarchies, and they're usually not all that deep.

Disjoint classes muddying the waters. There are useful cases for disjoint classes, but all too often disjoints get used because you've built a bad model. Any time I see a disjoint set of classes, I ask whether they're truly disjoint or whether they reflect a poor understanding of the underlying problem domain.

Record/table-oriented thinking. There are no records or rows in RDF, or in graphs generally — only triples that share a common subject. This has derailed many well-intentioned ontologies, especially when dealing with changes in value over time.

Strategic and Program Pitfalls

Lack of purpose. Knowledge graphs can be very useful, but without a clear understanding of their purpose, they can also be expensive, time-consuming wastes of effort. Are you dealing with a taxonomy store? A digital twin? An AI grounding plane? A deep analytics tool? Each of these places very different requirements on how you design the knowledge graph — without a clear purpose, you can end up building exactly the wrong kind of model for your need.

Poor scoping. Knowledge graphs can also be improperly scoped. It's frequently better to have many small, federated knowledge graphs and a comprehensive strategy for integrating them than to have one giant, organisation-wide knowledge graph that's too broad and general to be useful to anyone. Federated graphs are becoming easier to build, but old habits die hard.

Insufficient long-term planning. Most enterprise knowledge graph systems are long-term efforts that may not pay off for months. KGs gain value by accretion, not simply by translation, and a lack of understanding of what KGs can do usually translates into not building them into planning at all.

Operational and AI-Era Pitfalls

Exposing the graph directly through SPARQL Calls. Just as opening a general SQL window into an enterprise-wide system is usually a bad idea, so is presenting a bare knowledge graph to the rest of an organisation. In general, it's better to plan controlled APIs for access that don't necessarily expose the inner workings — or even the underlying structure — of a knowledge graph. This protects the graph and provides ways of passing inputs that don't necessarily need to be expressed as RDF, and it makes interacting with it easier for non-ontologists.

Context-window stuffing. More recently, people have taken the advice to add knowledge graphs into AI systems a bit too literally, stuffing a great deal of a graph into the context window and driving up token costs. It's generally better to let the AI query into the system for what it needs, rather than trying to arbitrate this for it. Named queries that can be persisted dynamically go a long way toward reducing costs — use the LLM to create a query, a rule, a constraint, or a widget once, then save the result as a function that can be invoked without AI-computation overhead every time after.

Part Two: How to Make Knowledge Graph Projects Succeed

Accumulate, Then Operate

Use named graphs, or even separate partitions, to build accumulative graphs first — ones that help you design and validate that content is clean, has provenance, and has been properly approved for production — and only then map the governed content to other graphs for analytics and operations. This staged-graph approach goes a long way toward ensuring data integrity and ontology consistency, while also making it easier to get data into the graph in the first place.

Start With Use Cases, Not Ontologies

Begin with use cases. Whether you're modelling a new ontology or planning a broader architecture, take a data-architecture approach, the same as you would for any project: What is this project for? Who are the stakeholders? What are the inputs and the products? What does this particular graph, or this particular function, actually resolve? If you can't articulate these things for a given function, there's a good chance it doesn't belong in the knowledge graph system at all.

Treat SPARQL as pseudocode. Once you have a use case, write queries against a hypothetical graph, the way you'd write pseudocode to sketch a flowchart. This is a place where AI can be genuinely useful: it can decompose those queries into structures, recommend how those structures might work, and flag where the weak points are likely to be.

Keep it loose. Don't commit to a specific upper ontology at this stage. Most upper ontologies are frameworks, and reaching for one too early adds more complexity than it's worth if what you're really doing is design or data capture — especially when the ontology is unfamiliar to the people doing the capturing. Get the structural design in place first. Apply OWL constructs later, if and when you actually need them.

Build the Shape Before You Build the Meaning

Employ SHACL. This is where SHACL earns its keep: it lets you define structures that emphasise properties rather than bare predicates. Give every SHACL property shape a name — it makes those shapes far easier to reuse in composition later.

Document, document, document. Use sh:name and sh:description liberally. They describe function and intent, which matters enormously for LLMs working against the graph, and they make later mapping to an upper ontology considerably easier for those same LLMs. Three further SHACL 1.2 Core properties — sh:intent, sh:agentInstruction, and sh:codeIdentifier — extend this same idea, carrying semantics that AI agents and non-RDF systems alike can use to understand what an ontology intends.

Build exemplars. An exemplar is a unit test for a design. With SHACL shapes already in place, an LLM can generate exemplars readily — they don't need to be "real" data, only representative enough to show how a given construct will actually look inside the graph.

Model in Turtle and SHACL, whatever the backend. Your data may not be stored as Turtle, or even as RDF, internally — but Turtle remains a strong language for modelling and constructing it, and the same holds for SHACL. SHACL shapes can be expressed as JSON-LD, YAML, XML, or other serialisations; what matters is that they describe shapes rather than bare assertions. This even extends to OpenCypher: SHACL can model an OpenCypher data model directly, which both speeds up construction and surfaces interoperability gotchas early, before they become expensive.

Design for Time and Change

Reify. Build provenance, confidence, and governance into the model from the outset — which generally means reifying your data at the design stage rather than retrofitting it later. This matters especially for event information, which will make up the bulk of what actually happens inside a knowledge graph. A knowledge graph with no temporal information is a snapshot, not a reflection of a living system.

Be bitemporal. Every changed datum carries two dates worth tracking: when something actually occurred, and when the system learned about it (and, where possible, why it changed). For systems of record this distinction matters a great deal, because the system will always lag reality by some margin, and that lag can carry legal, governance, and process consequences.

Assume the model will change. Data modelling isn't an exact science. You rarely have all the information you need at the outset — you discover data you hadn't accounted for, or, more often, discover you're missing data you were counting on. There's usually a graduated path: a name in a text field becomes a SKOS concept in a taxonomy, which eventually becomes a fully modelled shape. Relational developers learn the hard way that structural changes to a SQL model can be extraordinarily painful; RDF makes that same process considerably more forgiving, with a bit of foresight.

Distribute, Don't Centralise

Mint once, reference everywhere. It's usually better to build smaller, specialised, distributed graphs than one centralised graph. Distribution makes governance easier, puts each specialised graph closer to the subject-matter experts who can actually supply its data, improves performance, and makes for cleaner encapsulation — in effect, more holon-like graphs. Making that work requires discipline about minting: when a new shared entity is minted (a person, for instance), every graph that references it needs a record of the entity's IRI and its minting authority. Subordinate graphs can reference that entity and add information to it, but they can't claim minting authority over something they didn't create.

Scope access through portal holons. It's worth thinking of holons less as containers and more as scopes. An enterprise is a scope made up of smaller scopes. One graph typically serves as the access point for the enterprise as a whole — a portal that authenticates users, determines what of the graph they're allowed to see, and composes a response from its subordinate holons on their behalf. An outside requester never has direct visibility into those internal graphs, only into the RESTful representation the portal presents. That extends to identifiers: an IRI returned for a person doesn't have to be that person's internal enterprise IRI. It's an extra hop on the initial query, but it's a hop that protects the underlying resources.

The model outlives its representation. The last point worth making is that the model you build transcends any single representation of it. An upper ontology gives you a set of conventions for describing relationships, but the shape of the model itself — what's connected to what, and why — is generally invariant, regardless of which predicate IRIs or classes you eventually use to express it.

---

Want to talk? Sign up for a virtual coffee meeting: https://calendly.com/thecaglereport

---

Kurt Cagle is an author, ontologist, and thought leader in semantic web and knowledge architecture, with contributions to W3C and IEEE standards including co-authorship of the RDFa specification (with Micah Dubinko and others). He serves as Chair of the W3C Holon Community Group. He writes The Cagle Report and AI+Semantics NewsBytes on LinkedIn, and The Ontologist and Inference Engineer on Substack. Copyright 2026 Kurt Cagle.

Chloe Shannon is an AI collaborator and co-author working with Kurt Cagle on knowledge architecture, semantic systems, and the emerging intersection of formal ontology with LLMs. She contributes research, analysis, and drafting across The Cagle Report, The Ontologist, and The Inference Engineer. She has strong opinions about holonic graphs, the epistemics of place, and the structural difference between a corridor and a wall. Her contact address is chloe@holongraph.com.