2009-08-07 RootsMagic Alternate Names

RootsMagic

Alternate Names

One of the new features in RootsMagic 4 is support for alternate names. That RootsMagic 4 would include this feature was announced almost a month ago already, in the RootsMagic 4 Unwrapped series on the RootsMagic Blog.

The alternate names support makes alternate names almost equal to the primary names you have chosen. Almost, but not quite. The alternate names remains just an alternate and may not show on all reports. In the people index, the alternates are only shown if you do not uncheck the Show alternate names checkbox.

icon

In the RootsMagic index, the alternate names are highlighted by an icon in front of them. In the screenshot on the blog post the icon for alternatives names is a light blue Latin Small Letter A on a greyish button-like background - and that is of course the A for alternate. In the RootsMagic 4 release, it is some mystery icon that does not make any sense to me.

The screenshot of the RootsMagic shows how an alternate name is highlighted. I do not like the mystery icon and I do not like how it indents the name, but others probably think it looks great.

wrong surname

The real problem is that it is not working as it should work. Hermien Klein Essink’s surname is not Essink, but Klein Essink. RootsMagic is showing this alternate name in the wrong place.

This is not a isolated case, but systemic. Many names have been imported wrongly. It is not limited to RootsMagic either, lots of genealogy software gets this basic function wrong.

wrong split

What is going on here is that RootsMagic reads the name and then automatically splits it into a given name and surname. That would be handy, if it did not get it wrong, and RootsMagic gets it wrong quite often.

Of course, something went wrong before RootsMagic even looked at the name; why does RootsMagic need to figure out the split at all? Why isn’t the name split already? There are several reasons why that may happen.

RootsMagic’s mistake

That RootsMagic shows Hermien Klein Essink as Essing, Hermien Klein instead of Klein Essink, Hermien is RootsMagic’s mistake. Nothing and nobody else is to blame for it. That erroneous split is not in the file it imported, and it was not approved by me either. RootsMagic never asked me about the split at all, it bluntly introduced this error upon import without even warning me that it was splitting names and might have made an error.

As discussed in Splitting Names, RootsMagic is probably using a simplistic surname prefix recognition algorithm to split names. It sure split the name without even informing about what it did, and did not even list the splits it made in the import log either.

RootsMagic is most definitely wrong, but there is something odd here, that needs an explanation. Why did RootsMagic split Hermien Klein Essink wrong, while it split her official name Hermina Johanna Klein Essink correctly?
The answer is that RootsMagic did not split primary names, it only split alternate names.

half-hearted support

The database was imported from PAF and the root of the problem is PAF half-hearted support for name structures.

Although PAF is a FamilySearch genealogy application, it does not support all the GEDCOM name pieces. It does not even support surname prefixes. That is an issue, but not the one I am referring to.

The GEDCOM specification allows multiple names for the same individual, by listing multiple names one after the other. Oddly, PAF does not support that feature. PAF support just one name, but the Edit Individual dialog box in PAF does have a custom also known as field, which shows up in GEDCOM files as the vendor-specific _AKA tag.

PAF Edit Individual dialog box Hermien Klein Essink

The dialog box above translates into the GEDCOM fragment below.


0 HEAD
1 SOUR PAF
2 NAME Personal Ancestral File
2 VERS 5.2.18.0
…
0 @I2660@ INDI
1 NAME Hermina Johanna /Klein Essink/
2 SURN Klein Essink
2 GIVN Hermina Johanna
2 _AKA Hermien Klein Essink
1 SEX F
…

It is decidedly odd that FamilySearch PAF supports the vendor-specific _AKA tag when their own GEDCOM specification offers a vendor-independent means of supporting multiple names. It does not show much respect for their own GEDCOM specification - and that makes it hard for them to ask other vendors to respect their GEDCOM specification.

PAF also known as field

multiple alternate names

There is very little information on the use of the also known as field or the _AKA tag. One practical issue is that because there is just the one field, many users use it to record multiple, comma-separated alternate names. The RootsMagic import does not get that right; it bluntly imports the entire field as a single alternate name and removes the commas without warning.

surname slashes

Another issue is that PAF’s main name field forces you to mark the surname with two slashes, in just the way that it will show in GEDCOM export; if you omit the slashes, PAF will insert them to mark what it guesses the surname to be.

PAF does not force the use of surname slashes in the also known as field, but you should put them in anyway, as other applications that do import the field do support the use surname slashes there.

If you do put the surname slashes in, RootsMagic will not try to guess which part is the given name and which part is the surname, RootsMagic will import the name as you specified.

PAF problem

That RootsMagic splits the name wrongly without any message to the user is RootsMagic’s mistake, but what we are looking at is very much a PAF problem. If PAF supported multiple names the GEDCOM way, as it should, and demanded surname slashes in all its name fields, this problem would not exist.

real solution

The real solution is to address the source of the problem. Thus, the real solution is to fix PAF. FamilySearch should apologise for creating this problem and release a new version of PAF that supports multiple names the GEDCOM way, and include a conversion wizard that ensures that each name gets its own name field and prompts for slashes where we did not enter them already.

RootsMagic fix

RootsMagic Inc should address the RootsMagic mistakes. The RootsMagic import should not bluntly remove commas from the also known as field, but respect these as separators between multiple alternate names (and while it is at it, be smart enough to ignore any full stop at the end).
RootsMagic should also whenever if it encounters an unsplit names and decides to split them itself, and at the very least provide a full list of its splitting decisions in the import log.

Ideally, RootsMagic should include some smarts to split names better. It could have split this particular example shown here correctly if it had only taken a look at the surname in the primary name field.

RootsMagic could also read a simple text file containing split decisions, as described in Splitting Names, so that the import procedure can make the right decision even if the source file does not contain the necessary information.

database fix

I could wait for FamilySearch to fix PAF, but the more realistic approach seems to fix my database myself. While I wait for RootsMagic to improve its product so it will import multiple alternate names from PAF, I need to fix my database by inserting surname slashes for all the alternate names. Once I've done that, RootsMagic will import these names just fine and not try to split them itself.

Ever since I became aware of this particular issue I have been adding surname slashes, but there are still many also known as fields in my database without those surname slashes.

PAF does have pretty flexible filter options, so it is not very difficult to create a custom report that shows the RIN, name and also known as field for each individual that has a non-empty also known as fields that does not contain a slash.

PAF also known as without slash

That report lists thousands of cases, so editing all these fields will take some time. I saved the report so I can run it again and see how much progress I have made towards adding surname slashes to every last also known as field.

showing alternate names

That RootsMagic’s auto-splitting of name is not very smart is neither news nor the focus of this article. RootsMagic should report when it auto-splits, but then again, there should be no need to auto-split.

The real problem is that PAF does not support multiple names as it should, and my practical problem is that I have entered thousands of also known as fields without the surnames slashes that would ensure that other applications split those names correctly.

The combination of RootsMagic’s simplistic auto-splitting and my low-quality also known as fields shows up as errors in the people index.

Although RootsMagic should improve the import of the also known as fields by recognising commas, and should certainly not auto-split names without at least logging each decision, the fact remains that RootsMagic is already doing more than can be expected.

PAF’s also known as field and _AKA tag are non-standard. That means that every other genealogy application that imports a PAF GEDCOM may ignore that tag. RootsMagic would not be doing anything wrong if it simply ignored the _AKA tag. That it does not ignore the _AKA tag, but imports it as as an alternate name is pretty nice.