Should a word that is both a title and a given name report an ambiguity? (Baron Davis → title 'Baron', no given name) #348

Words that are both a title and an ordinary given name are decided once, in the vocabulary file, for everybody. A word is either in TITLES — in which case it is always a title and shadows the given name — or it is kept out, in which case it is never a title no matter how much surrounding text says otherwise. There is no third state, and neither outcome reports anything: ambiguities is empty in every example below.

The two failure modes

In the list. The title reading wins even where the person's given name is the word:

parse("Baron Davis")    # title='Baron'  given=''       family='Davis'
parse("Prince Fielder") # title='Prince' given=''       family='Fielder'
parse("Hon Solo")       # title='Hon'    given=''       family='Solo'
parse("Do Quang Minh")  # title='Do'     given='Quang'  family='Minh'

Baron and Prince are the given names of both athletes. Đỗ is one of the most common Vietnamese surnames, so Do leads a great many real names.

Out of the list. The name reading wins even where the title reading is unambiguous from context:

parse("Dean of Chemistry Robert Johns")  # given='Dean of Chemistry' middle='Robert' family='Johns'
parse("Duke of Wellington")              # given='Duke of Wellington' family=''

The conjunction-chain machinery that recognizes Deputy Secretary of State runs correctly here and assembles the whole phrase — it just delivers it to given, because dean and duke are not title vocabulary.

Where the line currently falls

The doctrine is stated in nameparser/config/titles.py:

Cannot include things that could also be first names, e.g. "dean".

and repeated in docs/customize.rst:

That conservatism is why dean above isn't in the default vocabulary in the first place: "Dean" is also a common given name, and a default that swallowed it as a title would misparse "Dean Martin" for everyone.

Applied by hand across 711 entries, it lands in different places for structurally identical words. All ten below are peerage or rank words that are also established English given names:

king behaves better than its four neighbours only because it is also in FIRST_NAME_TITLES, which routes the following word to given instead of family. That is a third mechanism, and it grades the damage rather than removing it — the given name is still gone.

The census of which of the 711 entries collide this way has never been taken. The table above is hand-picked, not exhaustive, and sizing it is part of the work this issue asks for.

Why neither list can simply be extended

Moving dean and duke in misparses Dean Martin and Duke Ellington for every caller — the reason they were kept out. Taking prince and baron out loses Prince Charles and every genuine honorific use. The vocabulary decision is being asked to answer a question the vocabulary cannot see, because the answer depends on the individual name, not the word.

What the codebase already has for this

The 2.0 core solved this shape twice, for other vocabularies. Both mechanisms are subsets of an existing set — they add no words, they narrow how a word already present is read — and both pair with an AmbiguityKind:

Titles have no counterpart, and there is no TITLE_OR_GIVEN kind. Adding one is API-legal in a minor release; AmbiguityKind documents that new kinds may be added in minor releases, and ORDER is already reserved-but-unemitted on the same terms.

So the missing piece is not the reporting machinery — that exists and has a well-worn pattern. It is the narrowing signal: suffix acronyms had punctuation to key on and particles had position, and it is not obvious what titles have.

Candidate signals, none of them settled

• A period. Already works, by accident of the pre-nominal abbreviation inference described in Should a title written after the name still be a title? ("John Smith Prof." → family Prof.) #316: parse("Dean. Robert Johns") gives title=Dean. today, while Dean Robert Johns does not. Cheap and safe, but bare Dean Smith is the common written form and stays undecided.
• A title chain or connective. Dean of Chemistry, Assoc Dean, The Hon — a second title word or an of makes the title reading near-certain. Handles the excluded-word cases well; does nothing for the two-word Baron Davis shape.
• Letter case. The signal Use letter case to disambiguate suffix vs. surname: "Jack MA" vs "Jack Ma" #289 proposes for Jack MA vs Jack Ma. Whether it generalizes to titles is unclear, and it is unavailable on all-caps and all-lowercase input.
• Arity. Whether a viable given name remains once the word is taken as a title. This is the signal that would actually decide Baron Davis, and also the one most likely to change existing parses.
• Report and don't decide. Keep whichever reading is more likely and emit TITLE_OR_GIVEN so callers who care can branch. Weakest behavior change; may be the right first step regardless of which signal is chosen later.

Open questions

1. Is the ambiguity report alone worth shipping, ahead of any signal that changes a parse?
2. Do the currently-excluded words (dean, duke, earl, don, major) come into the vocabulary as ambiguous entries, or does this only narrow the ones already shipped?
3. hon and do currently produce a title on every input. Any narrowing changes that, and do in particular affects a large class of Vietnamese names. Blast radius needs measuring on the differential harness before a rule is picked, not after.
4. Does FIRST_NAME_TITLES fold into this, or stay a separate mechanism? It answers a different question (what follows a title) but overlaps in effect.
5. Is TITLE_OR_GIVEN the right kind name, given the word may equally shadow a family name in family-first order?

Related

• Should a title written after the name still be a title? ("John Smith Prof." → family Prof.) #316 — the pre-nominal period inference these candidates would build on, and the same TITLES-collides-with-surnames hazard read from the trailing end
• Use letter case to disambiguate suffix vs. surname: "Jack MA" vs "Jack Ma" #289 — letter case as a disambiguation signal, for the suffix vocabulary
• Renunciate honorifics (Swami, Guru, Baba) put the monastic name in last #346 — Swami/Guru/Baba, the adjacent FIRST_NAME_TITLES membership question