The ALIA Tag of GEDCOM - Thu, 8 Mar 2012

Some tags in GEDCOM are misused, and the ALIA tag is one of the worst. Very often in a GEDCOM file you’ll find the following:

0 @I1@ INDI
1 NAME Thomas Jacob /Black/
1 ALIA Jack /Black/

This is definitely wrong. GEDCOM states: “Alias Names: One or two systems used the ALIAs tag for representing multiple names. This form is not supported in the GEDCOM Standard version 5.5.”

When Behold encounters an ALIA tag used the wrong way, it will log the following message:

** Missing Link (#1): “ALIA” is missing its link to a record (enclosed in ‘@’) and should not have a data value.

Among my collection of 690 GEDCOM that I use for testing, 36 of them do it this incorrect way. The vast majority of these are GEDCOMs produced by various versions of Family Tree Maker.

GEDCOM defines the ALIA tag as: “ALIA {ALIAS}:= An indicator to link different record descriptions of a person who may be the same person.” GEDCOM specifies it’s structure be: “+1 ALIA @<XREF:INDI>@” which has a pointer to an INDI record, but does not have a line value. So it should be used this way:

0 @I1@ INDI
1 NAME Thomas Jacob /Black/
1 ALIA @I2@
1 … (other information for this INDI)

0 @I2@ INDI
1 NAME Jack /Black/
1 … (other information for this INDI)

GEDCOM doesn’t state that the links need be both ways, so one way is good enough. And there is nothing preventing links from being chained, so that three or more INDI records can be treated as the same person.

With Behold, once virtual merging is added, I was hoping to use this ALIA tag to signify the individuals to merge. This would happen behind the scenes so the user of Behold wouldn’t have to worry about it. This ALIA tag that would be in the GEDCOM file correctly indicating the linkage.

However, among my 690 test GEDCOM files I have, only 9 use the ALIA tag in this manner, and 7 of them were files created by people simply for testing GEDCOM files and the other 2 were hand-edited files. So I didn’t find a single program that was using the ALIA tag for the powerful purpose for which it was intended. That is not good news. I’m worried in this case that if I export correct GEDCOM, there might not be another program that would be able to correctly interpret it.

Isn’t that ironic? Correct GEDCOM that might not transfer to another program, because no other program will know what to do with it. (p.s., if you know of a program that does handle the ALIA tag correctly AND makes use of it AND exports it again, please let me know.)

If all that is wanted is to add a known alternative name to an individual, then the proper way to do this in GEDCOM is to include the alternative name as a second NAME tag, and to give it a NAME_TYPE of “aka” (which stands for: also known as), as follows:

1 NAME Thomas Jacob /Black/
1 NAME Jack /Black/
2 TYPE aka

Some programs did not use this construct, but instead use custom tags. They are valid in GEDCOM, but because they are custom, few other programs would understand their meaning.

PAF, for example produces:

1 NAME Thomas Jacob /Black/
2 _AKA Jack /Black/

and Brother’s Keeper does the same but with a different custom tag:

1 NAME Thomas Jacob /Black/
2 _AKAN Jack /Black/

Quite a few programs use the NAME tag with the subordinate TYPE tag and the “aka” descriptor correctly.

When Behold produces valid GEDCOM 5.5.1 output which I’ll soon start working on, I’ll get it to convert the incorrect ALIA tags into the valid “NAME/TYPE aka” structure., That will allow this data to be correctly interpreted by programs that read valid GEDCOM 5.5.1.

I’ll also get Behold to convert the _AKA and _AKAN tags to the valid format.

It will be quite a job to fix the GEDCOM mess produced by other programs, and this analysis of this one tag gives you an example of the problem. I’ll try to get Behold to do the best I can.