Multiple names versus variations of names

[hartenthaler]

There are transliterated and transcripted versions of names. Should they be stored in subtags of a NAME or should they be stored in multiple NAME tags?

This is also relevant regarding selecting a name to be displayed or sorting the names. For example, there is a name in the Latin alphabet and in the Greek alphabet: if the user's language is set to "English" he/she will prefer the name in Latin; if the user's language is set to "Greek" he/she will prefer to see the name in the Greek alphabet.

[fisharebest]

Should they be stored in subtags of a NAME or should they be stored in multiple NAME tags?

GEDCOM 7 provides NAME.TRAN. This extends the NAME.ROMN and NAME.FONE from GEDCOM 5.5.1.

It would seem (to me) obvious that the translated/transliterated names should be stored in these name subtags.

[hartenthaler]

GEDCOM 7.0 says about TRAN:

The name may be translated or transliterated into different languages or scripts using the TRAN substructure. It is recommended, but not required, that if the name pieces are used, the same pieces are used in each translation and transliteration.

TRAN (Translation) g7:NAME-TRAN
A type of TRAN substructure specific to Personal Names. Each NAME.TRAN must have a LANG substructure. See also INDI.NAME.

The following presents a name in Mandarin, transliterated using Pinyin

1 NAME /孔/德庸
2 GIVN 德庸
2 SURN 孔
2 TRAN /Kǒng/ Déyōng
3 GIVN Déyōng
3 SURN Kǒng
3 LANG zh-pinyin

I think that the standard is not precise in using TRAN for "translation" and then saying in the headline of the example "Mandarin, transliterated using Pinyin". Wikipedia says: "pinyin, is the official romanization system for Standard Mandarin Chinese in China". For me "romanization" is a type of transcription, not transliteration - but maybe I'm wrong. The standard should be precise in using those terms.

Greg, you said

It would seem (to me) obvious that the translated/transliterated names should be stored in these name subtags.

To put all the "translated" names in subtags using TRAN is ok and already part of GEDCOM 7.0. But regarding sorting/selecting a name as preferred is more complicated if there are multiple NAME versions and inside a NAME multiple TRAN versions. Maybe use a hierarchical approach for selecting a preferred version:

• first, select the preferred NAME tag (for example the first one in the GEDCOM file)
• then select the preferred TRAN subtag (if the user language is Greek, then select the TRAN using the greek alphabet; if the user language is English, then select the TRAN using the latin alphabet)

But maybe this is implementation and not part of the standard.

For "sorting" and "searching" I would suggest extracting all name versions out of all NAME tags and all inside TRAN subtags and using them in parallel to build up a search index or a sorted name list. But again, this is maybe implementation and not standardisation.

[fisharebest]

But maybe this is implementation and not part of the standard.

Exactly. The standard should enable functionality, not specify it.

[hartenthaler]

The standard should enable functionality, not specify it.

That would mean that your tasks number 3 and 4 are implementation and not part of the standard. They could be addressed in an example but not in the standard text.

[Norwegian-Sardines]

That would mean that your tasks number 3 and 4 are implementation and not part of the standard. They could be addressed in an example but not in the standard text.

3. For individuals with multiple NAME records, consider how we might sort them, for example using NAME.DATE.

While we can't require a date be used to sort. NAME.DATE needs to be added to the specification so that it can be included in a transmission and that if included a receiving program can sort the data by date or use the name at the correct time in a report.

4. For individuals with multiple NAME records, consider how to identify a "preferred" name, for example by selecting the first one to occur in the GEDCOM record.

Again while we can't require the use of a preferred name, the specification should have a mechanism to determine the preferred name.

I struggle with the concept of a standard for interchange not requiring specific information and how it is provided (specifying) to be included. I understand the idea of "Enabling", but I don't understand where "Specifying" starts! If a common understanding of the transmitted data, (just like a common understanding of a word/term in a spoken language) is not used, then the data (just like the verbal communication) will be misinterpreted.

[hartenthaler]

Maybe the standard can say:

The sequence of NAME tags is important (ie. they should not be shuffled around by import and export). If there is a need to select the most important name, the first one should be used.

I'm not sure if the following would be ok

If there are several TRAN tags in a NAME, their sequence is important. They are all less important than the NAME tag itself.

[WGroleau]

Many names have variants not always handled by Miracode. They aren't translations.

For example, my name is Groleau, but in the past, it has been misspelled Grolo, Grosleau, Groslot, Groleaux, Grolot, etc. In 5.5.1, the closest qualifier is AKA but that isn't really accurate for frequent misspellings of what is considered the person's actual name. Or for a Groleau whose brother's family consistently used Groslot. (One relative decided to anglicize it "Bigelow")

A Polish immigrant named Nędza—one branch of descendants are Nedza and another are Nendza.

And today I read:
"She married John Millbone. (Note: The name Millbone appears to be a variant spelling of Millburn)"

5.5.1 does allow "user-defined" but it might be useful to have "variant" as a standardized option.

[hartenthaler]

@WGroleau - I think you are addressing another topic! All variants of your name are different names. They should be stored in different NAME tags if there are sources where one person is using different names (maybe at the same time or maybe during separate phases in life.
The topic here is about the same name but using different transliteration/transcription systems (i.e. for example different alphabets), but it is the same name not a variant of a name. So it is correct to use subtags like TRAN in this case.

[WGroleau]

They are neither translations nor transliterations And nobody used Nedza and Nendza at different times. They are variants, just as my brother-in-law's name "Tillapaugh" is a variant of that of his ancestor Dällenbach. There are still relatives using Dällenbach, but Tom and his siblings and parents have never used that.

As far as I know, people who went by all the variants of Groleau I listed were illiterate, but for most of them, one of the variants was consistently used by the priest in their parish, while the priest in the next parish may have used a different spelling for the people he dealt with.

[Norwegian-Sardines]

The NAME tag for an individual must represent the name used by the specific instance of the INDI tag. The TRAN tag is for translating that name into another language or script.

Variations of the name that are associated with a population, but not with a specific instance of an individual have no place in the NAME tag. For example: if cousins spelled their surname differently (Grosleau vs Groleaux) but the individual never used both spellings, then the NAME tag can not be used to record the variation (making the use of AKA in a NAME.TYPE tag incorrect).

In previous releases of the GEDCOM specification, the optional SURN tag was defined to indicate that it was used (or could be used) to index (?group, or sort?) surnames. In the GEDCOM v7 specification of this tag it has been defined to allow gender specific variations of the surname. However, since this tag is optional, not all transmissions will contain this tag, nor will all recipients use this tag to build their database.

THEREFORE, at present, the GEDCOM v7 specification does not enable a good solution to the “organization of surname variations” across transmissions, (due to the ‘NAME.SURN’ being optional and not specifically defined as a way to group together surnames that have the same root but different spellings.

I would propose that some mechanism, be it a more robust definition of the SURN tag or an additional required tag for surname sorting, grouping, organizing, indexing be implemented in a near future GEDCOM specification.

[webtrees-pesz]

A possible solution for grouping names with the same root could be a new NAME-TYPE like UNIFIED.

[Norwegian-Sardines]

Are you saying a NAME.TYPE as defined by g7:enumset-NAME-TYPE?

[ungeahnt]

To group different spellings/name variations I would suggest a 'shared list' of names. For each group of names you can create a list with the different name variations. When you have an INDI with one of this name variations you can add the list to the INDIs name tag (similar to shared notes or _LOC).
I think this is helpful because you no longer have to commit to a single root name. This is sometimes not so easy.

[Norwegian-Sardines]

Ungeahnt:

So you would advocate for an additional tagged extension structure similar to the suggested _LOC extension as outlined in the 1.5 Extensions section!

This could be implemented in GEDCOM v7.1 and codified (as I would hope _LOC or a variation of it) as a new Record in v8.0 of GEDCOM. And, like the _LOC tag have history and notes associated with the instance.

[WGroleau]

If VARIANT were defined as I have suggested, it would not mean that it was ever that specific individuals are but rather that it might identify relatives. However, that has the problem that people might use it improperly (for some other meaning). I agree that SURN would be inappropriate since it already has a different purpose. I like the suggestion of Ungeahnt for something like

0 @xref@ INDI
1 NAME Stasz /Nędza/
2 VARIANTS @pointer1@ 
0 @pointer1@ VARIANTS
1 NAMES /Nędza/ /Nedza/ /Nendza/
0 @pointer2@ VARIANTS
1 NAMES /St. Germain/ /Saint Germain/ /Germain/
0 @pointer3@ VARIANTS
1 NAMES /见/ /見/
0 @pointer4@ VARIANTS
1 NAMES /van den Berg/ /Vandenburg/

[WGroleau]

The g7 spec describes NAME-TRAN as a translation, not a transliteration. ```
1 NAME Hans /Konigschreiber/
1 TRAN Henry /Kingswriter/
2 LANG en

[WGroleau]

Page 20 describes an "alternate age" example. Is there any value in something like

1 NAME Fred Doo
1 _NAME Doo Wah Diddy

```(would not fit my "variant" but maybe fits something