What Makes a Good Knowledge Graph? Six Properties That Separate Useful from Useless

The 'pile of triples' anti-pattern

Most failed knowledge-graph projects fail in the same way. A team learns about graphs, runs an extraction model over a corpus, dumps every (subject, predicate, object) triple it produces into a graph database, and then nobody can query the result usefully. They have hundreds of thousands of edges and zero answers.

The graph in their database is technically a knowledge graph by every formal definition: typed nodes, typed edges, explicit schema. But it has none of the properties that make a knowledge graph useful in practice. Heiko Paulheim's 2017 survey on knowledge-graph refinement starts from this exact observation — that real-world graphs need ongoing investment in completeness, correctness, and integration, not just ingestion.

The six properties below are what separate the small graphs that change how a team works from the large ones that gather dust.

1. Schema discipline

A useful graph commits to a small, named set of node types and edge types up front and then refuses to drift. Three node types and seven edge types is a fine starting schema; thirty of each is usually a sign nobody is editing the spec.

Schema discipline pays off at query time. When you ask 'show me every Person who AUTHORED a Document that CITES a Regulation issued by an Agency', every type in that path is a real schema element you committed to. Without that commitment you are doing string-matching against extraction output, which works for a demo and breaks the moment the corpus changes.

2. Entity resolution

Apple Inc. is not the fruit apple. 'Dr. Smith' from one paper and 'John Smith, MD' from another are likely the same person. Without entity resolution your graph has a copy of the same person for every document they appear in, and the cross-document edges that make graphs valuable simply do not exist.

Most teams underestimate this. Cleaning the input does not solve it — the same human is referred to differently in every source by design. You need explicit identity logic: a deterministic match on stable IDs (DOI, ORCID, LEI), a probabilistic match on attribute clusters (name + affiliation + co-authors), and a manual-review queue for the long tail. The good news is that 80% of the value comes from getting the top 100 entities by frequency right.

3. Provenance

Every edge needs to know where it came from. Source document, extraction method (rule, NER model, LLM), extraction confidence, and the human or system that approved it. Without provenance you cannot debug a wrong answer; you cannot honour a takedown request; you cannot even decide whether to trust a query result.

In KnodeGraph, every edge written from a document carries a back-reference to the source doc and the extraction job that produced it. When a downstream user disagrees with an answer they can click through to the exact paragraph that justified the edge. That single property — 'why does this edge exist' being a one-click question — is the thing that turns a graph from a curiosity into something a team relies on.

4. Query latency at the user-facing tier

If a user-facing graph query takes more than 500ms at p95, nobody uses the graph. They go back to grepping documents.

Latency is decided by index design and query shape, not by the size of the graph. A well-indexed property graph with 50 million edges can answer a 3-hop traversal in single-digit milliseconds; a poorly-indexed graph with 5,000 edges can take 8 seconds. The discipline here is to know which queries your users will actually run, build covering indexes for them, and reject queries with no path to an index.

5. Refresh cadence and explicit decay

Knowledge changes. A regulation is amended; a person changes role; a company is acquired. A graph that ingested its content a year ago and has not been touched since is misleading by default. Either refresh cadence is built into the pipeline (re-extract sources on a schedule, diff against the prior state, write only deltas) or every edge needs an `effective_date` and a `confidence_decay` that the renderer can use to fade old answers.

In practice most teams choose one or the other; the bad outcome is choosing neither and ending up with a graph that appears authoritative but is two years stale.

6. Licensing and downstream redistribution

If your graph contains facts extracted from third-party documents, the facts themselves are usually fine to redistribute (facts are not copyrightable in most jurisdictions). The verbatim sentences that produced them are not. A useful graph stores enough provenance to show a user where an edge came from without reproducing the underlying source verbatim — and refuses to display the source verbatim until it has confirmed the user has access to it.

This is a property because users will absolutely try to use the graph as a way around their licensing. A well-built graph anticipates that and bakes the access check into the renderer, not into a downstream policy doc that nobody reads.

Related reading

• KnodeGraph vs Neo4j — Property-graph engineering tradeoffs and where each shape wins.
• Knowledge graphs for research synthesis — Concrete entity-resolution and provenance workflow on a literature corpus.
• PDF to knowledge graph — Provenance trails are the difference between a queryable graph and a black-box extraction.
• Knowledge graphs in pharma — Regulatory provenance is non-optional in pharma; a useful blueprint for any compliance-adjacent graph.

Frequently Asked Questions

Source

Paulheim, H. 'Knowledge Graph Refinement: A Survey of Approaches and Evaluation Methods' (Semantic Web Journal, vol. 8 no. 3, 2017). [link]