Family Historian User Group

ogulbran wrote: ↑

04 Nov 2022 16:02

I 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.

Øivind

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.

The GEDCOM 7 specification of PERSONAL_NAME_STRUCTURE has some more enhancements that add a Phrase sub-field to the Type sub-field and gives examples for NAME.TYPE that are time-related such as:
BIRTH ~ Name given at or near birth.
IMMIGRANT ~ Name assumed at the time of immigration.
MAIDEN ~ Maiden name, name before first marriage.
MARRIED ~ Married name, assumed as part of marriage.
PROFESSIONAL ~ Name used professionally (pen, screen, stage name).
OTHER ~ A value not listed here; should have a PHRASE substructure.
However, DATE is not a sub-field and I agree it would be a rational addition.
There is nothing to stop FH from adding a custom _DATE field as it has done elsewhere as a GEDCOM extension.

It would be feasible to identify a particular NAME instance by a structure such as NAME[type="IMMIGRANT"].
There are other uses of the TYPE field, particularly for Facts, where say MARR.TYPE identifies forms of ceremony such as Church Wedding, Registry Office, Civil Partnership, etc, and CENS.TYPE identifies National Census, UK Register, Electoral Roll.

Regarding waiting for years for GEDCOM 7 see GEDCOM 7.0 (18957) where it is claimed that Heredis 2023 now imports GEDCOM 7 files!

davidf wrote: ↑

04 Nov 2022 17:45

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?

A lot of years now since I dit the export, but I am quite sure that the associations were not exported in any way (the name variants were).

tatewise wrote: ↑

04 Nov 2022 18:55

There is nothing to stop FH from adding a custom _DATE field as it has done elsewhere as a GEDCOM extension.

This is a good idea! It is though very important that the sentence construction will use it. Also in John Cardinals GedSite software (which I use to produce my website).

tatewise wrote: ↑

04 Nov 2022 18:55

It would be feasible to identify a particular NAME instance by a structure such as NAME[type="IMMIGRANT"].

Good idea too.

I think it is important to have in mind why we are putting in names in FH - what should they be used for? For me this is most important:

• Easy to put in - and look up which names a person had
  Searching for persons while I work in FH
  Constructing a biography pr person on my website that is easy to read and use the relevant name for different events (because name can vary over time) - and the name he/she was mostly known for as the person heading (either the primary name or eventually possibility to choose a name by type).
  Constructing surname index on my website - preferably with all surnames registered for a person
  Updating websites, f.ex. DNA, for surname searching. The standard here is to use the persons first surname (ie the surname or the first farm name). Must therefore be able to take out this navn, either by date or type. (Today I use this name as the primary for this reason…).

Another point here can be which variants of the name should be registered. It was esentially no "correct" written name for a person before ca 1900 (at least not here in Norway). If you should register every variant that has been written down you would get a lot of alternative names because the priest and others spelled in a lot of ways. Therefore I think the best is to standardize on a normalized version of the names. Relevant for both given and surnames. In addition I think it is a good practice to take in the exact form used - but I think that is best solved by taking it in the source citation.

Summarized: A solution for dates on the names is high on my wish list!

It can be useful to see how other apps deal with this. RM permits date (and sort-date) fields for all names, as they have a different balance between strict GEDCOM compliance and their judge of useability compared with FH. One of the defined names has to be designated as the primary name, and is identified specifically as such in the SQLite database.

When an RM database is imported directly into FH, dates associated with the primary name are always relegated to notes, but there is the option to import alternative names as a custom attribute, which preserves the date fields. An "alternative name" fact is created in the project RM Import Fact Set. That could be the basis for a simple option that is useable in all versions of FH now - create your own "alternative name" attribute in your Custom Fact Set. That would at least keep the data in a structured format, so if a future version of FH allows dated names, they could be simply copied across.

That seems like a pragmatic way forward, but I can't actually find an existing wish list for Dated Names (may be a limitation of my use of search).

I have therefore raised a wish list request for:
1) Implementation of %INDI.NAME[1]._DATE% in a similar manner to %INDI.TITL[1].DATE%
2) Ability to associate a specific name with a specific fact. FH already does similar linking through the custom _ASID tag (as seen for instance in linking an area in an image to an individual's record - and probably elsewhere as well)

Reference in the Individual record: note the _ASID subfield to the Object tag (bottom line) Reference in the Object Record: note the corresponding _ASID subfield to a NOTE in the Object (Media) record). If an image (say a group image) has multiple image areas linking to different people, this structure is repeated with a different value for _ASID. The only difference would be that the "link" would be referring back to the same INDI record.

David, beware of being too specific. The _ASID tag has been replaced by the _SEQ tag in FH V7.

I was only pointing out that conceptually what I had in mind was possible given the previous use of the _ASID tag. Since it is "under the hood" it does not really matter what it is called until there is an official GEDCOM implementation.

I was highlighting it because someone may raise an objection that because it was referring back into the same record there was some reason why it would not work. Without such an objection, I wanted to make the point that what I was asking for was feasible - given commercial priorities etc.

_SEQ presumably "stands for something" (which helps with remembering) - Sequence?