Øivindogulbran wrote: ↑04 Nov 2022 16:02I was a TMG user earlier. The solution in that product was as I see it quit good. For every fact you could choose which name variant you wanted to connect it to. This name variant would then be used in the narratives. If no name variant was chosen the primary name would be used. That solved "all" my name problems…
Another approach could be to have dates steering the use of names. If name variants had start dates this could be incorporated in the sentence construction.
Those two approaches have attractions but I am not sure how much they are supported by GEDCOM 5.X.X.
I certainly find it strange that you can have dates on "Title" but not on "Name". Dates on names is the most convenient where there are "easy name transitions" - i.e. renaming on Adoption, Christening, Adult Baptism, Marriage or Deed Poll (what we call a legal change of name - apart from marriage - in the UK). Deed Polls tend to be Events in themselves, so would carry the new name - but not necessarily employing the GEDCOM name structure - which pushes us back towards "dated alternative names".
Any program would have to be able to look up the appropriate names in for instance reports. A new variable "current name" could be used in sentence templates - but the processing would be non-trivial.
We would have to make the case for a non-GEDCOM enhancement in FH - possibly with dates being exported in the Fact Note field.
The idea of associating Name Variants with specific Facts is more flexible (particularly if you had someone who went by a variety of names depending on situation rather than date) - particularly if it defaults to the name on the chronologically previous fact to enable fast data entry. How do these Name-Fact associations export from TMG?
But how would they work? In FH/GEDCOM you have Name[1], Name[2] etc - which is dependent on the position in the actual GEDCOM. Processing something dependent on its position in a database is bad practice - you want to process according to a persistent "key" and the Name index (Name[n]) is not persistent because you can change the order of names after setting a Name-Fact association. You also have to be careful that any edit to a name is still applicable to all the associated facts - which could be a nightmare to get your head around. Or is the Association just in the form of a free text representation of the applicable name at the time the association was made?
If the latter approach is used running reports is processable - as you say "This name variant would then be used in the narratives. If no name variant was chosen the primary name would be used." If the former process was used (i.e. trying to key back to the specific Name instance), processing is more complex.
Use of Name Type (V7) on gets you so far because as I understand it it is free text - like the Descriptor field on Title, so you could not enforce any date formats and validation if trying to use it as a "data applicable" field.
I cannot see an easy way to get this in current FH (certainly in V6) - I just tend to put any "non-standard" name in the fact note - but I don't use FH for publication where such an approach might be problematic.
Ideally we want some clear thinking in those who decide GEDCOM - and not too far into the future - we could wait years / decades for widespread adoption of GEDCOM 7 or 8! I can see how you might implement it in relational terms - a master table of Names internally tied to Primary Names and then a Table of Facts with a foreign key to the relevant name - although distinguishing the various names when setting that key would require an interface which filters by Primary Name.
