Knowledge Graph — Patterns

Constrained extraction against a declared schema

Problem. Open extraction from prose produces a vocabulary nobody designed: dozens of relation types with overlapping meanings, attributes that are sometimes nodes, and entity types that appear once. Querying such a graph requires knowing all the variants, and no query ever finds them all.

Approach. Declare the entity types, relation types and required attributes first, pass that declaration to the extractor as the only permitted vocabulary, and validate every assertion against it before writing. Assertions that do not fit are not discarded silently — they are recorded in a rejected set that is reviewed, because a recurring rejection is evidence the schema is missing something.

Trade-off. The schema becomes a bottleneck: every new question that needs a type the schema lacks waits on a schema change and a re-extraction. A tight schema also discards genuine content, and the rejected set is a backlog that needs an owner or it is simply deletion with extra steps.

Resolution as a reversible, evidenced decision

Problem. Deciding that two mentions are the same entity is a judgement with two asymmetric errors. Failing to merge leaves a fragmented graph that traversal cannot cross; merging wrongly fabricates assertions and is, in most implementations, irreversible.

Approach. Keep mentions as distinct nodes and represent identity as an explicit same-as link carrying the evidence and the score that produced it, rather than by rewriting the graph. Queries traverse through identity links; a bad merge is undone by removing one link. Threshold the automatic links conservatively and route the ambiguous band to review rather than guessing.

Trade-off. Every traversal now resolves identity links as it goes, which costs query time and complicates query authoring. The review band is also where the volume is, and without staffing it the conservative threshold simply means a permanently fragmented graph.

Assertions with source, time and validity

Problem. An edge stated as a bare fact cannot be corrected, dated, disputed or removed. Real corpora contradict themselves across documents and across years, and a graph that stores only the winning value destroys the evidence that there was a conflict.

Approach. Make the unit of storage an assertion rather than a fact: the relation, the document and span that asserted it, the time the source was authored, the period the relation is claimed to hold for, and the extraction run that produced it. Current-state queries read a view over the assertions that applies a precedence rule; the underlying evidence stays.

Trade-off. The graph is several times larger and every query goes through a resolution view whose precedence rule is itself a modelling decision that will be wrong for some questions. Property-graph stores make this shape awkward, and RDF stores make it verbose, so the cost is paid in modelling complexity either way.

Separate the derived graph from the curated layer

Problem. Extraction is re-run as models improve, and a rebuild discards human corrections. Storing corrections in the same graph makes it unrebuildable; not storing them means the same error is corrected repeatedly, forever.

Approach. Keep the extracted graph strictly derived and disposable, and hold corrections — merges, rejections, overrides, added edges — as a separate, durable set of statements that is replayed over each new extraction. A rebuild then produces the latest extraction plus every correction ever made, and a correction that has become unnecessary can be detected because it no longer changes anything.

Trade-off. Replaying corrections onto a graph whose node identities have shifted is the hard part, and it only works if identities are derived from stable source attributes rather than from extraction output. The correction set also grows without bound and accumulates entries whose original justification nobody remembers.