* Rootsmagic Names vs FH7 names

[BakerJL75]

Rootsmagic has Alternate names such as married and other types. When exported to a Gedcom with Mike Tate's plugin, they are in the Gedcom. But unless I'm missing something, FH7 only makes use of them to view on the "more" dropdown on the main person screen. Would it be possible to write a plugin that would pull that data out of the Gedcom and convert it to a ALT Name fact or something? Not sure I'm far enough along at this point to write it. but if it wouldn't be too complicated, maybe it would be something for me to aim for. Eventually I do want to learn to write plugins.

[tatewise]

If I understand correctly, an RM GEDCOM imported to FH puts those types of Name in the more (+)... Alternate Names list.
Those Alternate Names can be customised to appear on the Main tab under the Primary Name.
They also get included in Diagrams and Reports as AKA names.

Where would you want them to be more visible than that?

I think RM allows Dates & Sort Dates to be added to Names, which is very non-standard GEDCOM.
They will be treated as UDF by FH.

It is probably possible to use the Change Any Fact Tag to convert those Alternate Names to custom Facts but would need manual selection to prevent the Primary Names being converted.
However, those custom Facts would not migrate back to RM as Name types.

[LeslieP]

Oh boy, the names thing has just become my biggest issue, I hadn't really looked at it yet. I'm certain that I'm far from alone in having multiple names for people, and those Alt Name Facts (RM terminology) are a hybrid of name and fact - the data is name parts, and the names show up in people lists for searching, but there are also notes, sources, media attachments, dates, and sort dates. I have used them for birth names and adoptive names, married names, alternate spellings and plain old inaccuracies from census records, etc.

Lots of folks have likely put effort into creating sentences for these different types of names as well. Sentence structures are lost, but the ability to rebuild would be important.

As it stands now, everything other than the name itself is discarded on import into FH. Conversion of these names into a regular fact type will have to happen prior to or during import.

If somehow they can all get converted into an Attribute Fact (similar to Title) that FH will recognize, at least we'd have all of the information we need.

I'm not sure how in the heck to proceed, this is a pretty big deal to me, and probably others. Ideas anyone?

[LeslieP]

Update: small freakout was unnecessary, all of the data from the gedcom created by RM does exist in FH, it's not been thrown out. The task is now how to make it usable, how to convert all but the primary name into a name attribute with all of the data moving over.

I should have known to trust FH not to blow away my information. Apologize for my crisis of faith.

Now that I know all the info will still BE in FH, this becomes a challenge rather than a problem.

[tatewise]

Yes, I imagine all the data is present and correct and shown on the All tab as UDF.

So the next step is to establish a comprehensive definition of all possible NAME structures and how to convert them.
Hopefully, they will be consistent with the standard Fact structures for Dates, Sort Dates, Notes, Media, etc.
I presume there is a TYPE definition that identifies the various types of NAME.

Does the Primary Name (i.e. INDI.NAME[1]) ever have any of those subsidiary fields?
If so, should they also yield a custom Attribute Fact as well as keeping the Primary Name?

Regarding conversion, should each TYPE of NAME yield a different custom Attribute?
Or should there be just one custom Attribute with the TYPE value held in a labelled Note, etc.

The format of the Name itself needs consideration because the usual Forename /Surname/ structure does not apply.
So should it be Forename SURNAME or SURNAME, Forename or what?

There is a lot to clarify before a Plugin can be written.

[BakerJL75]

Where would you want them to be more visible than that?

I'm a little late replying, had some other stuff to do.
I would like the ability to craft my own sentences, possibly with a date or sort date.
Her married name was Doe
He was called Joe between 1950-1957
etc.

[tatewise]

OK, so Leslie and Jackie you need to agree on the custom Attribute details you want to be derived from the RM Name details.

I think the trickiest aspects will be the Name itself and the Type.
Where will they appear in the custom Attribute fact?
Bear in mind that qualifiers such as :SURNAME will not work with Attributes because they only apply to Names, so it will get awkward to extract just the Surname or just the Given name from a full Name.
One possibility is to have labelled Note text for each Name part.
e.g.
Forenames: John
Surname: Smith

[LeslieP]

I am of the "keep it simple" school of thought. AltName Fact Type should be as similar to existing fact structure and usage as possible.

Make it like the Title Fact. The name goes in the attribute field, whatever parts of the name we want to display. We can add date, age, location, note, source, media.

We have a standard sentence, "He was also known as ___" and if we want to specify some other kind of thing like adopted name, married name, alternate spelling, etc, those are witness roles that can be defined at the fact level, with custom sentences.

Since the principal can be a witness (very cool!) that really does seem to take care of the ability to have special treatment / custom sentences based on the type of name.

In the import/conversion, I would think all names other than the first one (which is primary) would need to be converted over to AltName facts, concatenate all of the name pieces together into the value field, and the name type becomes the witness role.

Oh, and yes, even the primary name can have notes and sources, so I guess ALL names would need to be copied to the AltName fact? And then we have names in both altname facts as well as the simple names window? Ugh. Duplication.

[BakerJL75]

So the next step is to establish a comprehensive definition of all possible NAME structures and how to convert them.

There are 7 options to what you call the Alternate Name in Rootsmagic, but all the sentences it generates are the same. The RM sentence template is [person] was also known as [Desc]< [Date]>.

The data does come over in the gedcom. It looks the same in the exported gedcom as it does in the FH gedcom after you import it. The first name is the one RM considers the primary name. The dates do come over.
0 @I3720@ INDI
1 NAME Edwin Alfred /Glenn/
2 GIVN Edwin Alfred
2 SURN Glenn
2 NICK Eddie
1 NAME Edwin Alfred /O'Glenn/
2 GIVN Edwin Alfred
2 SURN O'Glenn
2 TYPE immigrant
2 DATE 1 JAN 1893
1 NAME Edward Alfred /Glenn/
2 GIVN Edward Alfred
2 SURN Glenn
2 TYPE aka
2 DATE 1 JAN 1893
1 NAME Edwina /Glenn/
2 GIVN Edwina
2 SURN Glenn
2 TYPE married
2 DATE 1 JAN 1893
1 NAME Edwinn /Glenn/
2 GIVN Edwinn
2 SURN Glenn
2 TYPE other spelling
2 DATE 1 JAN 1893
1 NAME Edwina /Smith/
2 GIVN Edwina
2 SURN Smith
2 TYPE maiden
2 DATE 1 JAN 1893
1 NAME Eddie /Glenn/
2 GIVN Eddie
2 SURN Glenn
2 TYPE nickname
2 DATE 1 JAN 1893
1 NAME Edwin Alfred /Glenn/
2 GIVN Edwin Alfred
2 SURN Glenn
2 TYPE birth
2 DATE 1 JAN 1893

[BakerJL75]

I am of the "keep it simple" school of thought. AltName Fact Type should be as similar to existing fact structure and usage as possible.

I like your thought here, and the rest of the post. I am a little confused by your last statement:

Oh, and yes, even the primary name can have notes and sources, so I guess ALL names would need to be copied to the AltName fact? And then we have names in both altname facts as well as the simple names window? Ugh. Duplication.

I was thinking one AltName fact for each AltName fact in RM, to which notes and sources could be attached. When you say ALL names would need to be copied to the AltName fact do you mean one AltName fact for all names combined? I'm probably just interpreting what you are saying incorrectly, but wanted to check. And I love the idea of using Witness Roles to customize sentences.

[tatewise]

That is a useful start.
Taking the sample GEDCOM posted by Jackie, what would its converted FH form look like?

BTW: Primary Names in GEDCOM/FH are allowed Notes and Sources without needing to become Facts.
It is only if they can have Dates, Sort Dates, Places, Ages, do they need to have a Fact.

[BakerJL75]

Taking the sample GEDCOM posted by Jackie, what would its converted FH form look like

I'm not quite sure what you are asking. This portion of the gedcom in the FH project directory looks exactly the same as what I posted if that's your meaning.

BTW: Primary Names in GEDCOM/FH are allowed Notes and Sources without needing to become Facts.

And this would be in the ALL Tab for the sources, and the Notes Tab for the notes?

[tatewise]

It would useful to see the GEDCOM you would like to see after a Plugin converted each RM Name to an Attribute.
e.g. Custom Attribute AltName with value Edwina Smith
1 FACT Edwina Smith
2 TYPE AltName
2 DATE 1 JAN 1893

But what do the following get converted into?
2 GIVN Edwina
2 SURN Smith
2 TYPE maiden

It was I think suggested to do something like this:
2 _SHAR @I3720@
3 ROLE maiden

Do the GIVN and SURN values just get discarded?

If you want a sentence like "Her maiden name was Smith" the Sentence Template would be such as:
{his/her} {%FACT._SHAR.ROLE%} name was {????}
How would {????} extract Smith from the value Edwina Smith?

An alternative method is to use labelled Note text:
2 NOTE [[
3 CONT Type: maiden
3 CONT Givn: Edwina
3 CONT Surn: Smith
3 CONT ]]

Then the Sentence Template would be:
{his/her} {=GetLabelledText(%FACT.NOTE2%,"Type: ")} name was {=GetLabelledText(%FACT.NOTE2%,"Surn: ")}

[LeslieP]

This is how I imagine it could work, to convert the names info from RM into an Alt Names fact in FH.


The GEDCOM export from RM, an individual with 3 name records, notes, sources, dates, sort dates and media.

Code: Select all

0 @I2@ INDI
1 NAME James Malcolm /Price/
2 GIVN James Malcolm
2 SURN Price
2 NICK Mack
2 NOTE It is possible, though not certain, that he was named "in honor of" his p
3 CONC aternal grandfather James Mordecai Price (I446), albeit with a moderniz
3 CONC ed version of the name Mordecai. That modernization led to his lifelong n
3 CONC ickname of Mack.
1 NAME Mackie //
2 GIVN Mackie
2 TYPE nickname
2 DATE UNTIL 1951
2 NOTE He was called Mackie through most of school, shortening it to Mack once h
3 CONC e got to college.
1 NAME James Robert /Lakey/
2 GIVN James Robert
2 SURN Lakey
2 TYPE birth
2 DATE FROM 14 SEP 1933 TO 7 DEC 1933
2 _SDATE 15 SEP 1933
2 NOTE His name at birth was James Robert Lakey, and this wasn't changed legal
3 CONC ly until he was 4 years old, but he was never known by this name. He wa
3 CONC s never aware of this name until his adoption records were unsealed in 2
3 CONC 004.
2 SOUR @S528@
3 _TMPLT
4 FIELD
5 NAME Page
2 SOUR @S534@
3 _TMPLT
4 FIELD
5 NAME Page
2 SOUR @S535@
3 _TMPLT
4 FIELD
5 NAME Page
2 SOUR @S536@
3 _TMPLT
4 FIELD
5 NAME Page
2 OBJE
3 FILE P:\Genealogy\exhibits\birth_records\price_james_malcolm_as_lakey_james_robert-birthcert-oklahoma_1.jpg
3 FORM jpg
3 _TYPE PHOTO
3 _SCBK Y
3 _PRIM Y
1 SEX M

As shown in FH immediately after creating new project using the above gedcom. Main screen and name/title popup just shows the additional names, no indication of type, dates, notes, etc.

screenshot_20210209_006.png (40.7 KiB) Viewed 4687 times

The data still exists, and is visible on the records view.

screenshot_20210209_007.png (71.01 KiB) Viewed 4687 times

Create a new fact type Alt Names, witness roles correspond to name types

screenshot_20210209_008.png (27.53 KiB) Viewed 4687 times

Then a miracle happens (or a plugin, same thing really though)
This is what the plugin does:

• Skip the first name, because that needs to remain as the actual name of the individual
• Concatenate Given and Surname, place in attribute field
• Type, if used, becomes witness role and the individual is a witness to their own fact
• Date, sort date, media, sources, notes, all get put in the right places

Here's how it looks once the miracle has happened:





Issues

• The note on the first name doesn't show up anywhere that I can find.
• Ideally, a modified version of "change fact type" can automatically do this, leaving the first name unchanged. As it is now, using the change fact type plugin requires manual accept/reject for every name. Thousands!
• Alternative, make it do a COPY of name fact type to alt name fact type rather than a CHANGE - so that we get AltName facts for all existing names, and all of the existing names still exist in the names/titles popup as well as the records view.
• Someday...FH could be enhanced to treat an AltNames fact type the same as it treats the Title Fact Type.

[BakerJL75]

I agree. That sounds good.

[tatewise]

Jackie, earlier you said you wanted sentences such as:
Her married name was Doe
He was called Joe between 1950-1957

I'm not sure how you would achieve that with what Leslie has proposed.

Leslie, I'm not sure why it needs to be as complex as introducing Fact Witness Roles.
Why not just keep the TYPE field on the AltName attribute? It is a GEDCOM standard tag for all facts.
Although it is not shown on the Facts tab by default, it is shown on the All tab, and can be customised to appear on the Facts tab, etc. See FHUG Knowledge Base Recording a Civil Partnership and scroll down to Fact Type Descriptor which illustrates the technique for Marriage events that could similarly be applied to AltName attributes.

The idea of adapting the Change Any Fact Tag plugin would then be so much simpler and consistent, with just the special case of skipping the Primary Name.

[LeslieP]

Had no idea that there was a GEDCOM standard way of adding a TYPE to any kind of fact. That is indeed a much better solution than the witness role.

I have tried changing some things on my test project in the AltName fact that I created and can't find a way to get the TYPE to be a field in the middle section of the facts tab so that new alt names could use it. I really don't want to be going far down the road of non-standard and customization because it will just create problems down the road with exports to websites (I use TNG) and whatnot.

Perhaps to keep things simple, the idea of using witness roles should be scrapped and the name types should just be pasted into the note field and folks can figure out how to write their sentences to handle it.

[tatewise]

Sorry, I've just realised we can't add TYPE to a custom Attribute like AltName as it already uses TYPE to specify AltName.

So to explore that avenue would require the use of the standard Title attribute.
On the All tab right-click and choose Add Description to add a TYPE value such as Nickname.
To get that to appear in the Facts tab use Tools > Fact Types..., select Title, click Edit... button, click Advanced... button, tick Summary Template and set Template to {=CombineText( "", %FACT.TYPE%, "", "Title" )}
The Sentence Template can similarly use the same code to customise the Narrative Sentence.

If you want to export to other products then non-standard extensions like Fact Witnesses should be avoided.
Even certain standard GEDCOM fields are not well supported in some other products.

As I suggested on Tuesday, "an alternative method is to use labelled Note text" which will work for custom Attributes.
2 NOTE [[
3 CONT Type: maiden
3 CONT Givn: Edwina
3 CONT Surn: Smith
3 CONT ]]

In the Note that looks like:
[[
Type: maiden
Givn: Edwina
Surn: Smith
]]

They can be referenced using {=GetLabelledText(%FACT.NOTE2%,"Type: ")} etc.

Both the above alternatives are explained in Recording a Civil Partnership under Fact Note or Cause and Fact Type Descriptor.

I'm glad we are having this discussion before rushing off writing Plugins.

[LeslieP]

Bless you for your patience in helping us RM folks try to figure out how to maximize data transfer and utility, while also learning about the capabilities of FH. I think I'm starting to get a handle on this - FH is much more like TMG than RM, which is a major advantage, but it's taking me a minute to adjust my thinking.

The ability to use the note field in FH is similar (but even more advanced) than TMG was so I'm having to open my mind back up to thinking about it that way. I'm liking the labelled text, inside of privacy brackets, idea.

Ultimately Calico Pie enhances FH to include Alt Name facts that are the same as Title facts, with the descriptor field included as a part of the data entry interface.

Until then...

The alternate name as created in RootsMagic (I dummied up the npfx, nsfx, nick fields for demo purposes)

screenshot_20210211_003.png (41.86 KiB) Viewed 4555 times

As exported from RM to GEDCOM

Code: Select all

1 NAME James Robert //
2 NPFX pre
2 GIVN James Robert
2 SURN Lakey
2 NSFX post
2 NICK nick
2 TYPE birth
2 DATE FROM 14 SEP 1933 TO 7 DEC 1933
2 _SDATE 15 SEP 1933
2 NOTE His name at birth was James Robert Lakey, and this wasn't changed legal
3 CONC ly until he was 4 years old, but he was never known by this name. He wa
3 CONC s never aware of this name until his adoption records were unsealed in 2
3 CONC 004.
2 SOUR @S528@

Plugin converts all 2nd and later NAME entries into AltName attributes with name parts and type placed at the end of the note field in privacy brackets.

Voila! How it looks for the user in FH

screenshot_20210211_004.png (55.98 KiB) Viewed 4555 times

Nothing funky for the user to have to do, sentences can be written to use the name type as desired. All is right with the world!

[LeslieP]

Oh! Something else - notes that exist on the primary name.

Could your plugin move any primary name notes that it might find into the person note field? (Local note? I'm not sure what it's called, the note field on the Main tab.)

RM doesn't allow notes on the primary name, but TMG did, and they got imported from TMG to RM years and years ago. In my file there are name notes on primary names that are not visible in the RM program anywhere but they do get exported to GEDCOM and show up on my TNG website. It's a weird bit of cruft that I've never gone through and fixed, I'm sure there are other users like me who have notes on that first name.

[tatewise]

Notes local to the Primary Name are perfectly valid standard GEDCOM.
They can appear on the Main tab with a little customization without moving them to the record local Note.
i.e. Use the Menu > Customize Property Box... and untick Show most commonly-used items only.
Add <Custom Item> to Main area for Indiviudal with Item Name: and Label: Name Note: and data Reference: %INDI.NAME.NOTE2% then click OK and move it up to just below Name.

Ultimately Calico Pie CANNOT enhance FH to include Alt Name facts that are the same as Title facts.
Title facts are standard GEDCOM facts that are allowed to have a subsidiary TYPE field.
CP cannot invent standard facts. It is against the GEDCOM rules. So any Alt Name fact must always be a custom fact.
That is the kind of problem that other products sometimes create and then cannot export as valid GEDCOM.