Should this become the official WikiTree policy Jr, Sr, I, II, III, IV etc

+2 votes
191 views
Name suffixes, such as Jr or Sr, I or IV, first or fifth, become meaningless and confusing. Using the date of birth as a suffix would be much more meaning full. Sorts would put the people in date order. Duplication from generation to generation would be eliminated. The need to determine if an individual is the first or forty first person with a given name would be solved. Jr's and Sr's in related and unrelated families would still be shown, but would be easier to determine which line they belong in. If an error in birth date is found it will automatically realign the persons with similar names. Determining who is really III and who should be IV is solved even if the birth dates change. The larger a tree becomes the more critical the current practice hinders generational alignment.
in Policy and Style by Ronald Guy Barnes G2G1 (1.5k points)
Given that a profile has birth date and place, that should help, but those without dates (naughty naughty) do pose a problem.

(another, better comment disappeared before I could finish it)
The trouble is, those suffixes meant different things to our ancestors, depending on when and where they lived or migrated.

I agree with your thinking, its logical to use the birth date to keep them sorted out, but I don't think we need to duplicate the birth date in another field. Its already there.
I hate those ordinals too.
Suffixes to names should never be used. It just cause confusion and searchability problems. That type of information should only be recorded in the biography.

3 Answers

+9 votes
No. WikiTree try to use what the person would have used not some arbitrary numbering system. Putting a date in the suffix field is such an arbitrary system.

My personal preference is to remove any suffix from profiles unless there is a source proving that the person used it. Census records are great for proving the fact that it was used. Birth, Death and Marriage records can also prove it.

There would be very slim chances that people used the year of birth to differentiate different people.
by Darren Kellett G2G6 Pilot (149k points)
I have seen numerous situations where suffixes have been created for people that did not use them. I descend from a line of John Atwater’s, where people have called them John Atwater I, John Atwater II, John Atwater III, and so on. These terms do not show up in the contemporary records.

I feel that any personal numbering system can safely be removed, with a public bulletin board comment that it was removed for lack of documentation. 

In the case of John Smith 1, 2, 3, etc., I think you might want to add a comment of why the number was removed (Suffix:  Preferably, this should only be used for the Suffix at Birth. For example, Jr. and III. https://www.wikitree.com/wiki/Help:Name_Fields#Suffix) and ask for documentation that the name included the number at the time of the person's birth. 

I agree with you Darren. I think these are wrongly used in many cases.
+3 votes
No. This is redundant as there is already a field for birthdate. If it is not part of the name, it does not belong in a name field.
by George Fulton G2G6 Pilot (346k points)
+1 vote
The trouble with using what they used is that they didn't care how confusable they were.  But we have to distinguish.  Vast numbers of mistakes of many kinds are made by confusing generations.  They're everywhere in the tree.  We shoot ourselves in the foot if we don't try to do anything to help.

If we want to attach a convenience label to people that they didn't use, we should put it in square brackets.  John Smith [sr] or Henry Brown [b 1779] would be fine.  But I don't know if that's even allowed now.
by RJ Horace G2G6 Pilot (565k points)
Mine did not use Senior, Junior or numbering. They were distinguished from each other by naming variants. e.g., William, Will, Willy, Bill, Billy, Big Bill, Little Bill.

Related questions

+6 votes
13 answers

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...