§ 04 of 05 — Stage Four · Connect
What does it touch?
Stage 3 ended with FAST hinting at the graph. Stage 4 walks it. An entity sits at the center; outward from it run labeled edges — works by, works about, influenced by, contemporaries, subjects in common. The lesson is not the rendering. It is that each kind of edge asserts something different, and the catalog is sparse or dense at each edge type for reasons worth knowing. This is the older institutional cousin of the knowledge-graph work that modern search engines, RAG pipelines, and entity-resolution systems quietly depend on.
One entity, labeled edges
Each block below is a kind of relationship — a Wikidata property, a curated set, or a derived overlap from Stage 3's FAST headings. Click any block to read what that edge type actually asserts and why the graph is sparse or dense there. Each neighbor with a Wikidata ID is itself a doorway: click to walk into that entity's neighborhood. Sparsely-edited authors will render sparser views — the sparsity is the lesson.
Or try one of these
Live · Wikidata SPARQL · notable-work, influenced-by, subject-of
Search and Destroy Operation of U.S. Army in Southeast Region, Vietnam in 1967
- Wikidata
- Q220882
- VIAF
- LC
- sh2005001105
This entity exists in Wikidata but has no notable-work, influenced-by, or subject-of edges yet. Sparsity is not an artifact of the technology — it is a signal that the editing community has not (yet) invested attention here. The catalog still names this identity; it just has not yet been connected outward.
What this page actually does, and what it doesn't.
- Live SPARQL against Wikidata's Query Service for any Q-identifier: notable works (P800), influenced by (P737), and works whose main subject is this entity (reverse-P921).
- Curated King fixture overrides live mode and adds two extra relationship blocks (contemporaries, shared subjects) that are not directly queryable as single Wikidata predicates.
- Per-edge-type editorial notes explaining what that relationship asserts and why the graph is sparse or dense at that edge.
- Graph-walk traversal: each Wikidata-bearing neighbor is a doorway to its own neighborhood, with the URL state preserved so the walk is shareable.
- A closing 'sparsity note' that ties Stage 4 to the larger lesson: knowledge graphs are dense where attention has been invested and sparse elsewhere — sparsity is a signal, not a flaw. Sparsely-edited entities now render visibly sparser views.
- That any entity's neighborhood is complete. It is what Wikidata has indexed — many influences exist in biographies that never made it into the graph because they were not confirmed by the person themselves.
- That live mode shows everything curated mode does. It does not — contemporaries and shared-subject overlaps are curated supplements unique to entities we have prepared (currently just King).
- That a generic 'graph explorer' would have been pedagogically equivalent. Generic force-directed graphs look impressive and obscure the meaning of edges; the labeled-edge-type framing is a deliberate constraint.
- The 'Contemporaries' block on the curated King record is hand-picked rather than derived from a Wikidata query. There is no single property that means 'contemporary'; the catalog has to construct that relationship from birth-year + nationality + field.
- The 'Subjects in common' block on the curated King record is illustrative — three high-signal overlaps, not a complete join. A real intersection of FAST headings would be tens of thousands of edges and would teach nothing about structure.
- Editorial notes per relationship are condensed for legibility, not generated from the raw Wikidata schema. The properties (P800, P737, P921) are accurate; the framing of what each one asserts is ours.
A graph is what the editors looked at.
The naive read of any knowledge graph is that the edges are facts about the world. The accurate read is that the edges are facts about what someone has bothered to record. The two are usually correlated, but they are not the same.
When Wikidata's edge from Stephen King to H. P. Lovecraft is dense — when King has said in interviews, essays, and his memoir that Lovecraft mattered to him — the edge is well-supported. When the edge to a less-canonized horror writer is missing, it does not mean the influence didn't exist. It means an editor with an interest in that lineage has not yet sat down to add it.
This is also why mixed-method retrieval systems — retrieval-augmented generation, the current generation of search-plus-LLM architectures — rely so heavily on these graphs as a backbone. The text in the corpus tells you what an author wrote. The graph tells you what they are connected to, and the connection is what makes the retrieval more than keyword matching. A graph that asserts "King ↔ Lovecraft (influenced by)" lets a query about cosmic horror find King through Lovecraft even when the query text never names him.
The graph you just walked was a snapshot. In a working catalog, the edges shift constantly — corrections, additions, splits, merges. The next room is about what it means for an identity system to stay true over time, and what a verifiable layer over all this would actually require.
Stage Five · Maintain — identity as stewardship
The graph you just walked was a snapshot. Cluster boundaries shift, edges get added, names get corrected, pseudonyms get linked decades after the fact. Stage 5 watches the catalog edit itself — and asks what a verifiable trust layer over all this looks like.
Enter the room