Family Historian User Group

I'm trying to narrow down the fact types I use to those that are most translatable to other GEDCOM applications, not necessarily for a particular software program, but rather seeking general stability and transferability. Thus I'm favoring FH Standard facts. I've been following viewtopic.php?f=43&t=19623, which has been helpful.

I've encountered an issue with facts for individual's who have AKA or Known As names (of which I have many). I used the Export Gedcom File plugin to create a GEDCOM file using only the Basic Options and exporting to Standard GEDCOM Release 5.5.1. Here is an example copied from my exported GEDCOM file.

1 FACT C. Albin Jacobson
2 TYPE Known As

The issue is that when I use this export in the Gedshow WordPress plugin (built for FH users) on my website, the heading for Known As shows for the individual, but no content displays, i.e. "C. Albin Jacobson" does not appear.

I believe that Known As is standard GEDCOM, as shown in the attached screenshot from the GEDCOM 5.5.1 Specification. Can anyone provide any guidance? Is there an error in my GEDCOM export or might it be an issue with the Gedshow WP plugin?

P.S. I just added my GEDCOM file, if some may find it useful in addressing the issue.

I have moved this to the Importing and Exporting Forum.

The GEDCOM 5.5.1 details you refer to are associated with the INDI.NAME field and not facts.
The NAME_TYPE is held in the INDI.NAME.TYPE field.
In the GEDCOM that looks like:
0 @I321@ INDI
1 NAME C. Albin /Jacobson/
2 TYPE aka

Your code is using a custom Attribute fact that in GEDCOM 5.5.1 involves the INDI.FACT field.
The INDI.FACT.TYPE field defines the type of custom Attribute ('Known As' in this case).
In the GEDCOM that looks like:
0 @I321@ INDI
1 FACT C. Albin Jacobson
2 TYPE Known As

If C. Albin Jacobson is not appearing then I suspect the Gedshow WordPress plugin is at fault or only handles GEDCOM 5.5.
Is the heading for 'Known As' shown as part of the Individual Names section?
Or is it shown amongst your other facts that come before and after your 'Known As' Attribute?
A screenshot of your website page showing the Names and Facts might help.

As an experiment, what happens if you use:
1 EVEN
2 TYPE Known As
2 NOTE C. Albin Jacobson

Thanks, Mike. On a hunch I exported to GEDCOM 5.5 and the "Known As" Attribute fact now displays as a note when imported into Gedview; see screenshot. So that solves that issue. Your response triggers two questions.
1) Are you telling me that I created the custom "Known As" Attribute fact and that it is not commonly use in FH? (If I did it was long ago, and I have forgotten.)

tatewise wrote: ↑ Your code is using a custom Attribute fact that in GEDCOM 5.5.1 involves the INDI.FACT field.
The INDI.FACT.TYPE field defines the type of custom Attribute ('Known As' in this case).
In the GEDCOM that looks like:
0 @I321@ INDI
1 FACT C. Albin Jacobson
2 TYPE Known As

2) If GEDCOM has a AKA Name field, why use a fact at all? How would I access the AKA Name field in FH if it does in fact exist?

tatewise wrote: ↑

28 Jul 2022 14:30

The GEDCOM 5.5.1 details you refer to are associated with the INDI.NAME field and not facts.
The NAME_TYPE is held in the INDI.NAME.TYPE field.
In the GEDCOM that looks like:
0 @I321@ INDI
1 NAME C. Albin /Jacobson/
2 TYPE aka

As always, thanks for your thorough and speedy response. I've been away from my desk most of the day, so mine was delayed.

P.S. I have not yet tried the experiment you suggested.

@BEJ

Nice to see someone using my Gedshow plugin on their website

Colin, perhaps you can explain why the custom Attribute using a FACT tag does not display its value.
Is it that your plugin does not handle GEDCOM 5.5.1 or some other reason?

BEJ:

1) You probably used the FH installed Extended Set definition of the Known As custom Attribute or imported it from another product as explained in 2) below.

2) The Extended Set is intended to handle GEDCOM 5.5 imported custom facts from Ancestry and FTM.
GEDCOM 5.5 does not specify the NAME_TYPE field introduced in GEDCOM 5.5.1.
So FH V7 supports both the Known As custom Attribute and the NAME_TYPE field.
See the All tab, and right-click on Name to Add Type that can be set to aka.
However, FH does not include that Type detail in its reports by default. and other products may not handle it either.

3) As an experiment, what happens if you use:
1 EVEN C. Albin Jacobson
2 TYPE Known As
which is produced by Export Gedcom File, Extra Options tab, Custom Attribute: Custom Event & Value

tatewise wrote: ↑

28 Jul 2022 22:13

Colin, perhaps you can explain why the custom Attribute using a FACT tag does not display its value.
Is it that your plugin does not handle GEDCOM 5.5.1 or some other reason?

Mike
It does handle 5.5.1 and extracts data from standard Gedcom tags. Bruce has sent me the two gedcoms and I am going to do some investigation. A few of the problems users have had with the plugin is webserver configuration so that may be the cause here. I will check it out in the next couple of days and see what I find.

Working on my Swedish heritage I find that ancestors might have had several surnames during their lifetime depending on changing locations, professions, or simple preference. Spellings differ from record to record for an individual’s given names and surname where, in a couple of instances, the variant spellings indicate entirely different names. A further complication is the patronymic naming custom which means surnames changed with each generation and siblings could have different surnames. To help keep track of it all I created a Names tab in the Individual Property Box.

I tried to collect all the entry fields related to an individual’s name in my Names tab; see screenshot. It includes the custom attribute Known As. I had copied the Known As attribute from the FH Extended Set so I could place it in a fact set I created called, Name Variants. (To distinguish items that I have edited I always add a preceding underscore, so the label for my edited attribute is “_Known As.”)

Unfortunately, I could not figure out how to add Alternate Names to my Names tab, so I must click More(+)… in the upper right of the Property Box to add alternative names. BUT, what is an Alternate Names entry anyway?? It clearly is not a fact.
• Is Alternate Names simply a FH7 note?
• Are they useful?
• If so, how do I add the entry field to my Names tab?

tatewise wrote: ↑

28 Jul 2022 22:13

So FH V7 supports both the Known As custom Attribute and the NAME_TYPE field.
See the All tab, and right-click on Name to Add Type that can be set to aka.
However, FH does not include that Type detail in its reports by default. and other products may not handle it either.

As suggested, I added a name type and set it to aka. However, as I understand it, only one type can be applied and it is assigned to an individual’s primary name. I use the birth name as the primary name and all the others are variants. I’m looking for a solution that allows entering an individual’s birth, AND married, AND aka names. Maybe I’m back to using attribute or event facts.

Speaking of events, I attempted to follow the suggestion to experiment with a Known As event fact. I created a new AKA event fact, but there was no good place to enter a person’s name. Now that the Known As attribute exports Okay, I think I’ll stick with that.

Any help with the above appreciated.

I think the key piece of information you are missing is that the Primary Name is INDI.NAME[1] instance 1.
Each Alternate Name uses subsequent instance numbers INDI.NAME[2], INDI.NAME[3], et seq...
Then each Name_Type is INDI.NAME[2].TYPE, INDI.NAME[3].TYPE, et seq...
All those Names and Types are shown on the All tab.

So in your custom tab, you must use those instance indexed Data References.

i.e. It is similar to multiple instance facts like Census INDI.CENS[1], INDI.CENS[2], INDI.CENS[3], et seq...

Got it. Thank you. I’ve successfully altered my Names tab to include Alternate Names with Type for each. Are the five types offered created by FH or are they part of GEDCOM? Can I create types?

Now I need to decide if the Known As attribute has any value or if, for example “C. Albin Jacobson,” is best recorded as an Alternate Names, aka Type. After I ponder a bit I may create a new post to explore that question.

The types offered in the drop-list are those specified in GEDCOM 5.5.1 but you can enter any value you like directly into the box.
However, the ones you create do not get added to the drop-list, so you must take care to spell them the same way each time.

An advantage of a Known As Attribute is that you can record where (Place) and when (Date) that name came into use.
An Alternative Name does not allow Place and Date, but the associated Note &/or Citation can include those details.

Yup. I was just trying to add Place and Date to the Alternate Names and discovered it is not possible. Lots of choices!

I was not aware that FH could hold "type" for different alternative names. That is something I have missed for years! For me it looks like I can add and edit name types in the "All" tab. Type is also shown in the "Names and titles" with a column Type, but the value is always "Name". Error? And the field is not in the edit pop-up for the name…

But most important for me is how I can use the name type in sentences with data reference. I understand that I can use the instance number, but that will not help me very much. It should be a solution where I can put the name type (f.ex. maiden) as parameter for the data reference. Is that possible? (Or in a plan?).

The Names & Titles column Type is nothing to do with the Name > Type (INDI.NAME.TYPE) field.
It differentiates between an Alternate Name entry (INDI.NAME) and a Title Attribute fact entry (INDI.TITL).

No, you cannot simply use a Type value as a parameter to select a particular Name field.
It would need a =TextIf(...) function that tests INDI.NAME[2].TYPE = parameter to display INDI.NAME[2] but otherwise tests INDI.NAME[3].TYPE = parameter to display INDI.NAME[3] and so on for as many Alternate Names may exist.

Thank you very much for quick reply!