Knowledge Graphs: How Machines Connect Facts About People

Ask an AI about a well-documented person and you get a crisp, factual answer. Ask about someone equally accomplished but poorly structured and you get hedging, blanks, or borrowed facts. The difference is rarely talent. It is usually the graph.

What is a knowledge graph, in plain terms?

A knowledge graph is a database shaped like a web instead of a table. Entities, meaning people, companies, books, cities, are nodes. Facts are edges connecting them, each edge carrying a type. Machines store these facts as triples: a subject, a predicate, an object. Every clean fact about a person decomposes into rows like these:

A simplified subject-predicate-object view of the same facts a graph stores as typed edges around one person node.

The graph's power comes from traversal. Once you exist as a node, a machine can walk the edges: this person wrote that book, that book covers this topic, therefore this person is a candidate answer for questions on this topic. That chain of hops is how an engine converts "who wrote about X" into a name. No node, no hops, no name.

Notice also what the edge types buy you. Because every edge is typed, the graph distinguishes relationships a keyword index collapses: the difference between wrote the book, edited the book, and was mentioned in the book is invisible to a page of matching text and explicit in a graph. For a professional, that typing is the difference between being associated with a topic and being credited for it. Engines answering "who is the authority on X" walk authored-by and cited-by edges, not vague textual proximity, which is why two people with similar word clouds around their names can get radically different treatment in answers.

It is worth stating what a knowledge graph is not: it is not how a language model stores information. Models hold statistical associations in parameters, not discrete facts, and the two systems fail differently. We unpack that split in Training Data vs Retrieval: The Two Doors Into an AI Answer. Graphs matter because they sit behind the retrieval door, grounding answers with facts that were explicitly resolved rather than statistically dreamed.

How does Google build a knowledge graph entry about a person?

Google has operated its Knowledge Graph since 2012, and it even exposes a public window into it: the Knowledge Graph Search API lets anyone query an entity name and see whether an entry exists, with an ID, a type and a short description. Run your own name through it. The result, or the absence of one, is your current standing.

The assembly line behind an entry has three stages:

1. Extraction. Crawlers read the web and pull candidate facts: names, titles, employers, works, places. Structured data gets parsed directly. Unstructured text gets mined with entity recognition, which is noisier.
2. Resolution. The system decides which extracted mentions refer to the same real-world person. This is the merge step, and it is where most professionals silently fail: their evidence exists but never coheres into one node.
3. Corroboration. Facts that appear consistently across independent, trusted sources get promoted into the entry. Facts that appear once, or conflict, get held back. A graph is conservative by design, because a wrong fact served confidently is worse than a blank.

Entity resolution: the merge step where people fail

Consider what the resolver sees for a typical consultant: a personal site under a full name, a LinkedIn under a short name, three guest posts under inconsistent bylines, a stale agency bio with an old title, and a conference page that spells the surname wrong. A human recognizes one person instantly. A resolver computing confidence across name forms, bios and links may produce two or three weak part-entities instead of one strong node, and every signal earned gets split among them.

The countermeasures are the identity disciplines this site keeps returning to: one canonical name form everywhere, aligned bios, interlinked properties, and explicit markup. The consolidation playbook is in Structure Your Identity for Machines, and the single most leveraged property in that playbook, the declared identity link, gets a full teardown in sameAs: The Most Underrated Line in Your Markup. Both exist to make the merge step trivial.

Where do graphs get their facts about people? The five feeds

1. Your own structured claims. A schema.org Person entity on your site, with jobTitle, worksFor, alumniOf, author relationships and sameAs links, is the one feed you fully control. Treat it as your primary submission to the graph, because functionally it is.
2. Open structured databases. Wikidata is the load-bearing one: a public, machine-readable registry of entities that search and AI systems consume directly. It has notability standards, so not everyone qualifies, but if you have independent coverage, a correct Wikidata item is one of the strongest graph feeds available.
3. Authoritative third-party pages. University faculty pages, company leadership pages, publisher author pages, professional registers, conference speaker rosters. These carry weight precisely because you do not control them.
4. The unstructured web. Press mentions, interviews, podcast notes, reviews. Individually weak, collectively decisive, because corroboration is what promotes a candidate fact into an accepted one. Consistent co-occurrence of your name with your field and your works is the pattern extractors are built to find.
5. Curated correction channels. Where a knowledge panel exists, Google lets the entity claim it and suggest corrections. This is the narrowest feed, but it is the only one that resembles a direct line.

Wikidata claims: the exact shape notability requires

The five feeds section above names Wikidata as the load-bearing open database, and it is worth opening up because its structure is the clearest public window into how any graph stores a person. Wikidata does not store prose. It stores statements, and every statement has the same shape: an item, meaning the entity the statement is about, a property, meaning the type of fact, a value, and optionally one or more qualifiers and references. A person becomes an item with a Q-number, and each fact about them becomes a statement attached to a property with a P-number, such as occupation, employer, educated at, or notable work.

What separates a statement Wikidata will keep from one it will strip out is the reference. Wikidata's notability guideline does not ask whether you are impressive. It asks whether independent, published, reliable sources have already covered you, or whether you meet a specific structural criterion, holding a defined notable position, having created a notable work, or the equivalent. A statement with no citation is a claim an editor can remove on sight, because unreferenced claims about living people are exactly what community policy exists to catch. This is why a personal LinkedIn bio, however accurate, does nothing for your Wikidata standing on its own: it is not independent of you.

Stated in the simplified shape Wikidata actually uses, a real entry looks like this:

Item: Q_your_item ("Your Name")
Statement: occupation (P106) -> management consultant
  Reference: "Council Profile," Forbes, 2024, https://yoursite.com/press/forbes-profile

Statement: employer (P108) -> Your Firm
  Reference: "Leadership," Your Firm, https://yourfirm.com/team

Statement: notable work (P800) -> "Your Book Title"
  Reference: Publisher catalog entry, https://publisher.com/your-book

A simplified, illustrative view of the statement shape Wikidata stores, not real data. Every line that survives review carries its own independent reference.

Notice what this structure rewards: independent coverage that already exists, cited precisely, rather than self-description. If you do not yet have independent coverage, the honest move is to earn it first, through the kind of digital PR and citation work covered in Build a Knowledge Base AI Will Cite, rather than attempting to write your own Wikidata item and hoping it survives review.

Connecting your schema.org Person markup to the graph

Your own site is the one feed you fully control, and the connection between what you publish there and what a graph stores is direct: a schema.org Person block is written in almost the same subject-predicate-object shape a graph uses internally, which is exactly why it is so easily consumed. A complete, minimal example for a personal about page:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Your Name",
  "jobTitle": "Management Consultant",
  "worksFor": {
    "@type": "Organization",
    "name": "Your Firm"
  },
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Your University"
  },
  "knowsAbout": ["Operations strategy", "Supply chain risk"],
  "sameAs": [
    "https://www.linkedin.com/in/yourname",
    "https://yoursite.com/about"
  ]
}

A minimal Person schema block. Every property here maps to a specific edge type a graph can traverse.

Each property earns its keep as an edge. The name field supplies the canonical label a resolver matches against every other mention of you on the web. jobTitle and worksFor supply occupation and employment edges, the same shape as the Wikidata statements above. alumniOf supplies an education edge, useful for disambiguation when a name is common. knowsAbout supplies topical edges, which is how an engine later traverses from a subject to your name when someone asks who is credible on that subject. And sameAs is the merge key: it is the line that tells a resolver your about page, your LinkedIn, and any Wikidata item that exists all describe the same node, rather than three unconnected mentions. Get this property wrong, or leave it out, and you have built a well-labeled island instead of a connected node.

Are knowledge panels the same as the knowledge graph?

No. The panel, that box on the right of a results page, is just the visible tip: a rendered summary of a graph entry that crossed a confidence threshold. Plenty of entities live in the graph without earning a panel. The panel is nice, and claimable, but the strategic asset is the entry underneath, because that entry travels. It grounds search features, feeds answer boxes, and increasingly supplies the factual skeleton for AI-generated summaries about you.

Why do accomplished people still have no entity?

Run enough names through the Knowledge Graph Search API and a pattern emerges: plenty of genuinely accomplished professionals return nothing, while thinner resumes with better structure return clean entries. Three causes account for most of it.

Fragmentation. The evidence exists but never merges, for the reasons covered above: name variants, disconnected profiles, contradictory bios. The resolver holds three 30-percent-confidence part-entities instead of one node it can publish. This is the most common cause and the most fixable, because the raw material is already earned.

Unstructured excellence. The person's reputation lives in places extractors read poorly: private client work, conference rooms, paywalled trade press, PDFs with no markup. Twenty years of brilliant work that generated four crawlable pages produces less graph evidence than two years of work documented properly. Graphs do not measure merit. They measure legible, corroborated documentation of merit.

Collision. The name is shared, and someone else's documentation dominates it. The evidence merges, just not into you. Shared names need deliberate separation work, which is its own playbook and lives in Name Collisions: PEO When You Share a Name With Someone Famous.

Timing expectations belong here too. Graph entries update on crawl and corroboration cycles, not publishing schedules. New evidence typically takes weeks to months to surface in entity results, which is why the checklist below ends with quarterly measurement rather than daily refreshing. The work compounds slowly and then holds, which is the opposite temperament of a social feed, and the reason so few people bother. That scarcity is the opportunity.

What does this mean for AI answers?

Modern assistants blend two sources: what the model absorbed in training, and what a retrieval layer fetches at answer time. Graph-resolved facts strengthen both. The same consistent, corroborated web that builds your graph entry is the corpus models train on, so a clean entity produces cleaner parametric memory. And when the assistant retrieves, the search indexes it queries are entity-aware, built by the same systems that run the graph. A person with a strong node gets precise, attributable answers. A person without one gets whatever the statistics cough up. The full recommendation mechanism, including the signals beyond identity, is mapped in The 3 Signals AI Uses to Recommend a Person.

The practical path to a resolvable node: a stage ladder

Put the whole mechanism together and most people occupy one of five stages, and the honest news is that movement between them is mostly mechanical, not a matter of becoming more accomplished.

Most professionals can name their current stage in under a minute. The fixes at each stage are mechanical, not reputational.

How to feed the graph deliberately: a working checklist

• Publish a complete Person schema on your about page, sameAs array included, and validate it.
• Standardize one name form across every profile, byline and bio, then hunt down the variants.
• Query the Knowledge Graph Search API for your name and record the result as your baseline.
• If you have independent press or publications, create or correct your Wikidata item, citing sources for every statement.
• Get yourself onto institutional pages you legitimately belong on: employer, alma mater, associations, event sites.
• Publish a citable body of work under your canonical name, the approach covered in Build a Knowledge Base AI Will Cite.
• Re-run the API query and your test prompts quarterly. Graphs update on crawl cycles, not on your publishing schedule, so measure in months.

None of this is glamorous, which is exactly why it is available. Most of your competitors are producing content into an identity vacuum. Structure the entity first and every future signal lands somewhere. If you want the entity work done properly, end to end, that is what our services cover.