Tracking an Individual's Names
Posted: 27 Jun 2021 11:01
I have long been troubled by the difficulty of managing/tracking/listing an individual's multiple names - whether name changes at marriage or other events, different preferred given names over time, surname spellings that morph with time or according to a scribe's taste, etc, etc.
It is not so much a problem on diagrams. This truly excellent facility is flexible enough to display multiple names with NAME[1+] and other variants through Given Name Used and so on.
The root of the problem, of course, is GEDCOM structure with such limits as a *single* Given, Nickname and Surname per individual. But it goes deeper, because the repeating Name fields are not treated as FACTS (attributes in this case).
If a Name was a Fact, a custom query could list every name instance with its fact owner (Individual) and provide a powerful way to make a sorted list of all givens or surnames you may wish to record for a person. For my money, that would be a great improvement over the current FH Individual records window.
Now my questions are:
(1) Am I missing something, and there is a better way?
(2) If not, is there any reason why FH/Simon could not *treat* NAME as a FACT and allow me to write the kind of query outlined above?
Many thanks.
It is not so much a problem on diagrams. This truly excellent facility is flexible enough to display multiple names with NAME[1+] and other variants through Given Name Used and so on.
The root of the problem, of course, is GEDCOM structure with such limits as a *single* Given, Nickname and Surname per individual. But it goes deeper, because the repeating Name fields are not treated as FACTS (attributes in this case).
If a Name was a Fact, a custom query could list every name instance with its fact owner (Individual) and provide a powerful way to make a sorted list of all givens or surnames you may wish to record for a person. For my money, that would be a great improvement over the current FH Individual records window.
Now my questions are:
(1) Am I missing something, and there is a better way?
(2) If not, is there any reason why FH/Simon could not *treat* NAME as a FACT and allow me to write the kind of query outlined above?
Many thanks.