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

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:

in `TITLES`	measured	out of `TITLES`	measured
`baron`	`Baron Davis` → title=`Baron`, given=`''`	`earl`	`Earl Campbell` → given=`Earl` ✅
`count`	`Count Basie` → title=`Count`, given=`''`	`duke`	`Duke Snider` → given=`Duke` ✅
`prince`	`Prince Fielder` → title=`Prince`, given=`''`	`don`	`Don Cheadle` → given=`Don` ✅
`chief`	`Chief Keef` → title=`Chief`, given=`''`	`major`	`Major Harris` → given=`Major` ✅
`king`	`King Curtis` → title=`King`, given=`Curtis`	`dean`	`Dean Koontz` → given=`Dean` ✅

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:

field	narrowing signal	reported as
`suffix_acronyms_ambiguous`	punctuation — `Jack Ma` vs `Jack M.A.`	`SUFFIX_OR_NAME`
`particles_ambiguous`	position — a leading particle keeps its given name	`PARTICLE_OR_GIVEN`

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

Is the ambiguity report alone worth shipping, ahead of any signal that changes a parse?
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?
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.
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.
Is TITLE_OR_GIVEN the right kind name, given the word may equally shadow a family name in family-first order?

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

docs(design): record the vocabulary-collision criterion

feat(types): AmbiguityKind.TITLE_OR_NAME, reported where the title pe…

docs(design+release): the conventions are reported — #449 and #491 re…

fix(titles): prince and princess join the given-name titles

The surname half, under FAMILY_FIRST (found 2026-10-04):

ff = Parser(policy=Policy(name_order=FAMILY_FIRST))
ff.parse("Graf Steffi")   # title='Graf', family='Steffi', ambiguities=()
ff.parse("Herr Schmidt")  # title='Herr', family='Schmidt' (correct)

The two inputs have the same shape (H1: a title plus one name word gives the family), so only vocabulary separates them: graf is borne as a surname, and herr isn't. Under FAMILY_FIRST the leading position is where the surname stands, so a title-and-surname word collides exactly there. Any ambiguous-title subset this issue settles should cover surname bearers (graf, king, bishop, judge, and #606's greve/graaf/knight) as well as given-name bearers. The declared order is also a narrowing signal: under FAMILY_FIRST, an ambiguous title word followed by exactly one name word could take the name reading (Graf Steffi → family Graf, given Steffi). Dr. Kovács János and Herr Schmidt would keep their titles, since dr and herr aren't surnames.

Evidence for this question, from the title classification (#773, which listed these but left the question here).

Title words that are also borne as given names, by US SSA given-name births since 1880 (a lower bound: years under 5 births are not published), from tools/name_usage.py offline sources on 2026-10-20. 31 of the 609 ASCII title words of three or more letters have at least 1,000:

Title	SSA births	Census 2010 surname bearers
king	37,890	465,422
marquis	25,041	8,737
royal	24,394	15,755
prince	24,151	47,168
queen	16,123	18,557
princess	15,982	under 100
deacon	11,570	3,322
marquise	10,995	106
saint	7,476	1,897
bishop	7,091	116,618
baron	7,059	16,308
navy	6,717	346
sailor	4,290	2,412
general	4,025	778
judge	3,826	10,453
majesty	3,299	under 100
canon	2,792	2,644
rock	2,681	19,313
chancellor	2,648	4,147
sultan	2,396	3,363
sir	2,172	245
lady	2,068	1,070

(The rest of the 31: knowledge, mahdi, author, pharaoh, empress, ranger, colonel, burgess.)

Each of these reads as a title when it opens a name (Marquis Johnson, Royal Smith, Deacon Jones), as Baron Davis does above. decisions/vocabulary-model's decision 16 says a title that is also a given name is decided one word at a time, as decisions/salutation-titles did for the graf class; these counts are where those decisions would start. Phase 2 (#752) may change the shape of the question: a word with both a title reading and a given reading becomes a derived ambiguity.

Recompute:

uv run python -c "from nameparser import Lexicon; print('\n'.join(sorted(w for w in Lexicon.default().titles if w.isascii() and w.isalpha() and len(w) > 2)))" | xargs uv run python tools/name_usage.py --no-wikidata --json

Read King as a given name outside a title phrase (#752 phase 2j, #348) (

Read the given names Prince and Princess as names outside a title phr…

The question this issue asked, whether a word that is both a title and a given name needs a third state between "always a title" and "never a title", is decided. The rest is per-word work, which moves to #913.

The mechanism is rules/H9 (the title phrase), from #894: a title word that has a given-name reading is a title only inside a title phrase (a style or modifier before it, a title that attaches to it, or of after it), and a name word everywhere else. Where it stays a name and no comma has marked the given name, the parse reports title-or-name. Which words get a given reading is decided one word at a time, by their bearer counts (decisions/vocabulary-model's decision 16), each word's cost recorded in decisions/H9.

The open questions:

Is the report alone worth shipping? Both shipped together: the report, and a parse change for each word moved. Dean Koontz and Major Harris read given 'Dean' and 'Major' and report title-or-name. Grace, which is a title only in a phrase such as His Grace, reports nothing.
Do the excluded words come in? Yes, as phrase-only titles: Dean of Chemistry Robert Johns now gives title 'Dean of Chemistry', given 'Robert'. dean, justice, major, marshal and grace came in this way in Read a title that is also a given name as a title only inside a title phrase (#752, phase 2i) #894.
hon and do. do left the titles in Should parse("Smith, Jr.") put "Jr." in title rather than suffix? #296's audit, so Do Quang Minh reads given 'Do'. hon is unchanged and is listed in Should Baron, Bishop, Judge and the other title words borne as names read as names outside a title phrase? (Baron Davis → title 'Baron', no given name) #913.
Does FIRST_NAME_TITLES fold in? No. The given-name titles (addresses = "given") answer a different question, what follows a title, and they stay separate.
The kind's name. It shipped as title-or-name. The report names the field the word lands in, so family-first order is covered.

This issue's examples on master (7e00c2f, 2026-10-27):

Input	When filed	Now	PR
`Prince Fielder`	title 'Prince', family 'Fielder'	given 'Prince', family 'Fielder'	#908
`King Curtis`	title 'King', given 'Curtis'	given 'King', family 'Curtis'	#901
`Dean Koontz`	given 'Dean'	given 'Dean', reports `title-or-name`	#894
`Dean of Chemistry Robert Johns`	given 'Dean of Chemistry'	title 'Dean of Chemistry', given 'Robert'	#894
`Do Quang Minh`	title 'Do'	given 'Do'	#296
`Baron Davis`, `Count Basie`, `Chief Keef`, `Hon Solo`	title, no given name	unchanged	#913
`Duke of Wellington`	given 'Duke of Wellington'	unchanged (`duke` is not title vocabulary)	#913

The other words phase 2j moved, each with its cost recorded in decisions/H9 (a ruler or royal written with the bare title reads it as a name): wing (#896), mahdi and bard (#898), buddha, siddha and gyani (#900), sultan and sultana (#903), shaikh (#906), and sheikh, sheik, shekh, shaik and cheikh (#912). A v1 Constants().titles still lists every title 2.6.0 listed (#904).

Closing in favor of #913, which lists the title words still read as titles that are also borne as names.

Close #752's open questions in decisions/ and point the title words l…

Navigation Menu

Repository navigation

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

The two failure modes

Where the line currently falls

Why neither list can simply be extended

What the codebase already has for this

Candidate signals, none of them settled

Open questions

Related

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

The two failure modes

Where the line currently falls

Why neither list can simply be extended

What the codebase already has for this

Candidate signals, none of them settled

Open questions

Related

Activity

derek73 commented on Oct 4, 2026

derek73 commented on Oct 21, 2026

derek73 commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

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