* Name variants

[gwilym'smum]

Hello, I have a family some of whom use Pickering and some use Pickerill. I enter them as they are recorded in the records (I do know they are the same family as sometimes the individuals use both forms). When I wish to find individuals from the records window is it possible to get all the individuals from both forms to appear together please. Thank you Ann

[johnmorrisoniom]

Hi Ann,
In the filter box at the top of the records window, just type in Pickeri and the record list will show only those records that match (including both variants)

[gwilym'smum]

Why didn't I think of that! don't think outside the box. Thank you very much.

[dbnut]

Name variants are a huge topic and cause all kinds of problems. There have been many postings about this (including some from me) and there are sure to be many more.

As a rider to John's reply, the FH filter box operates as an initial match so typing in "Pickeri" finds Ann's variants just fine.

In other cases it may be less than 100% effective. Take a family that has variants Dennes, Denness, Dennis. An initial match with "Denn" is OK, but will also find things like Dennison, Dennet[t] and so on.

Using clever stuff like "regular expressions" (too hard for me) may be the ideal solution, or even just wild-cards ("Denn*s" work for me on Ancestry, Family Search, etc.).

But there is another issue that becomes important if this is one of your "big names" in the family tree... the Records Window list has to sort on something and usually this is Surname (followed by Given name(s), etc.). Ann's list will separate Pickerill and Pickering as two separate blocks perhaps pages apart.

As Ann says some of them use both forms, we can't know in advance which form is the surname entered in FH. So it would be better to sort on a kind of generic (or standardised or normalised) surname if possible. That way, Anne Pickering could find its way between Ann Pickering and Anne Pickerill in the list.

Different people come up with different solutions. For the "Dennis" problem mine is to replace all such surnames with a fictional "DNS", and all lists keep everyone in one block. This works fine even if their surnames change over time or in different sources.

As for knowing what they were called at any particular point in time, well our source records spell it out. And just to summarise the range of surname usage for any one person I have an extra Surname added to the main Name field, containing some text like "Dennis, Denness" which can be shown on diagrams or in reports.

I use a similar approach for given names. Too often "Ann" and "Anne" are used indiscriminately, but "Ann" for all keeps them all together in the lists and it is very clear that "Anne Dennis (b.1835)" may be a duplicate of "Ann Dennes (b.c.1834)".

What's a name, anyway?

[LornaCraig]

And just to summarise the range of surname usage for any one person I have an extra Surname added to the main Name field, containing some text like "Dennis, Denness" which can be shown on diagrams or in reports.

Rather than adding an extra surname to the main name field you can use the Alternate Name field(s) to add all the variations you find. These can be added to your diagram text scheme or included in reports.

[tatewise]

Another possibility to consider is the SOUNDEX qualifier, which will tend to group like sounding Surnames together.

[dbnut]

you can use the Alternate Name field(s)

Thanks, Lorna, that's definitely an option.

In my case, though, I already use extra Name instances to document "significant" changes that dramatically impact dictionary order - mostly deliberate adoption of different forms like "Alice Brown Smith" to "Alice Brown-Smith" or other stark changes, including sometimes recording married names (don't usually bother). Agreed these can be displayed/printed.

A slight objection here is that it creates (or permits) a full name structure.

Now you get me thinking, something I ought to consider is adding one new Surname instance to the (normalised) Main Name for each recorded variant. But to save space I'd prefer to keep the whole variant surname list when displayed/printed to a single line and I simply have no idea how to do that.

Perhaps some clever so-and-so can show me how to do that (with scripting or really smart use of functions???).

[dbnut]

the SOUNDEX qualifier

Hey, Mike, more food for thought...

Searching online sources with that technique has given me very mixed success. And anyway there seems to be no way to incorporate SOUNDEX in query Row criteria or functions?

[tatewise]

%INDI.NAME:SOUNDEX% can be used wherever any other Data Ref can be used in Columns tab, Rows tab, functions, etc.

[dbnut]

%INDI.NAME:SOUNDEX%

Hehe, thanks, I learn something new every time!

[tatewise]

To display multiple variant Surnames on one line would use something like:

%INDI.NAME[1]% %INDI.NAME[2]:SURNAME% %INDI.NAME[3]:SURNAME% and so on...

If any variant does not exist then nothing is displayed.
The only small caveat is that the intervening spaces are all displayed.

[dbnut]

%INDI.NAME[1]% %INDI.NAME[2]:SURNAME% %INDI.NAME[3]:SURNAME% and so on

Huh, never thought to try that out! Reckon 5 should be enough for me.

If any variant does not exist then nothing is displayed.

Huh, should have expected that from other experiments!

The only small caveat is that the intervening spaces are all displayed.

Wouldn't be much of a problem as redundant ones would be limited in number and come at the end. Nice!

Better still if we had a Trim function???

[tatewise]

There is in effect a trim function, that is even more flexible:

=CombineText(" ",%INDI.NAME[2]:SURNAME%,,)

That combines the first 3 parameters only if the the 2nd parameter produces text, otherwise it uses the 4th parameter.
So in the above case it only produces a space before the Surname if the Surname exists.

Therefore, to produce a trimmed list of full-name followed by alternative surnames try using:

=Text( %INDI.NAME% . CombineText(" ",%INDI.NAME[2]:SURNAME%,,) . CombineText(" ",%INDI.NAME[3]:SURNAME%,,) . CombineText(" ",%INDI.NAME[4]:SURNAME%,,) )

If you prefer, you can replace each " " with ", " so the Surnames are comma separated, but only where they exist.

[AdrianBruce]

Another possibility to consider is the SOUNDEX qualifier ...

For anyone not familiar with the Soundex system (see https://en.wikipedia.org/wiki/Soundex), it comes with a considerable number of caveats. The most important point is that it (sort of) only encodes the first letter and the next 3 consonants. Thus anyone with long names will probably find the latter part of those names being ignored - e.g. my Pickstocks get equated in Soundex with all sorts of Eastern European names. If your scope is your own database for Soundex analysis, then you probably won't have that problem but others may arise - Pickstock keeps getting equated to Pickstone - which is a correct equivalence in Soundex but I have seen zero evidence of any equivalence in real life!

By all means try it - you may find it useful. Or you may want to stick it where....

[tatewise]

Adrian, your description of the Soundex encoding is an oversimplification, because some consonants are ignored or combined, so often more than the next 3 after the first are encoded. See rules 1 and 3.

Also Pickstock Soundex is P232 whereas Pickstone Soundex is P235 so they are similar but not equivalent.

The Pickering Soundex is P265 and the Pickerill Soundex is P264.
Interestingly, variants such as Peckerring and Peckerell or Packarrill have similar Soundex codes, but cannot use the FH Filter to bring them together.

[AdrianBruce]

An oversimplification indeed - hence my inserting "sort of" in italics. Interesting that you calculated Pickstock and Pickstone slightly differently - those two are the bane of my life (or, at least, my research) in being shown as equivalents on various sites with zero justification in real life (unless anyone knows different!). It is often hard to discern the logic used to identify equivalents on various sites. I have seen lots of people reject such logic in favour of wild cards - regrettably, "my" names seem not to suit wild cards and phonetic matching in whatever form seems somewhat better, even if Soundex itself is poor for the names that I have an interest in.

[tatewise]

The Pickstock and Pickstone Soundex calculations are not mine but FH using %INDI.NAME:SOUNDEX% as mentioned earlier, which appears to use the Wikipedia rules.
i.e.
Using the Wikipedia rules for Pickstock:

1. Retain first letter P and remaining consonants are ckstck
2. Replacement digits are 222322
3. Remove duplicate digits 232
4. Thus the Soundex is P232

Using the Wikipedia rules for Pickstone:

1. Retain first letter P and remaining consonants are ckstn
2. Replacement digits are 22235
3. Remove duplicate digits 235
4. Thus the Soundex is P235

So I do not see how any standard Soundex calculation could produce the same code for both surnames, primarily because the trailing ck and n yield different digits 2 and 5 respectively.

[AdrianBruce]

I would agree Mike - no proper Soundex calculation should come up with Pickstock and Pickstone being identical. I have to presume, therefore, that the site(s) that do equate the two are not actually using Soundex per se but some other algorithm. Next time that I see the equivalence of the two, I shall examine what (if anything) they call their matching process.

I think that my overall position is still that Soundex can produce odd equalities because of the truncation, but anyone's FH file might well not include any of the oddities.