Disambiguation

The problem

Name disambiguation (often called entity linking when it is done on text) maps a mention such as "Lena Marlowe" to one specific person. It fails in two directions: two people merged into one, so one inherits the other's job, books or controversies; and one person split into several, so their record looks thinner than it is. The better-documented namesake usually absorbs the other, because more pages agree about them.

The signals

1. Identifiers

The strongest signal. If two records carry the same ORCID iD, ISNI or Wikidata QID, they describe the same person; if they carry different ones, they describe different people. Identifiers turn a guess into a lookup. See Person identifiers compared.

2. Linked accounts

A page that lists a person's accounts in sameAs, especially accounts that link back, ties the person to records that already have their own context. SeesameAs.

3. Context that travels with the name

Employer, job title, city, field and time period. "Lena Marlowe, head of product at Brightfield Analytics, London" and "Lena Marlowe, novelist, Leeds" can be told apart by any one of these. Matching systems compare these attributes pairwise; the more of them a page states, the more confident the match.

4. A disambiguating description

schema.org defines disambiguatingDescription as a sub property of description: a short description of the item used to disambiguate it from other, similar items. It is the same idea as the description line on a Wikidata item or a Wikipedia disambiguation page entry: short, factual, and focused on what separates this person from the others.

5. Name variants

alternateName, givenName, familyName and additionalName let a matcher recognise "L. Marlowe" and a transliterated spelling as the same person, without merging everyone who shares a surname.

In markup

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://lenamarlowe.example/#person",
  "name": "Lena Marlowe",
  "alternateName": ["L. Marlowe", "Lena J. Marlowe"],
  "disambiguatingDescription": "Head of Product at Brightfield Analytics in London; not the novelist Lena Marlowe of Leeds.",
  "jobTitle": "Head of Product",
  "worksFor": { "@id": "https://brightfield.example/#organization" },
  "workLocation": { "@type": "Place", "name": "London, United Kingdom" },
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "ORCID",
    "value": "0000-0002-1825-0097"
  },
  "sameAs": ["https://github.com/lena-marlowe-example"]
}

Writing a good disambiguating description

• Lead with what distinguishes: role, organization, place, field. "Head of Product at Brightfield Analytics in London."
• Name the confusion when there is a well-known namesake: "not the novelist of the same name".
• Keep it short and factual: a phrase, not a biography or a slogan.
• Keep it current: an old employer here is worse than none.

When the wrong person is described

When a search engine or an AI assistant attaches a namesake's facts to someone, the cause is almost always in the sources it reads, not in the model: a page that mixes the two, an account listed under the wrong person, or no page that states the distinguishing facts at all. The durable fixes are the ones above: one open page with the person's identifiers, linked accounts, context and a disambiguating description, linked from the person's other pages. Corrections to third-party pages are made with their publishers.

How SelfBadge handles it

Each profile has a "to tell them apart" line, published as disambiguatingDescription, and shows it near the top of the page and in the Markdown version. The lookup API and the MCP server's find_person tool take a job title, an organization and a location next to the name, and return every candidate with their distinguishing facts, so an agent can choose rather than guess.