Jump to content


Photo

TMG direct import; Name issues


  • Please log in to reply
19 replies to this topic

#1 torleifro

torleifro

    Member

  • Members
  • PipPip
  • 19 posts

Posted 26 October 2014 - 02:35 PM

Married Name is imported as Alt Name, not as Name Married which is a standard RM fact.

Same for Baptism.

 

 



#2 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1595 posts

Posted 26 October 2014 - 03:40 PM

There is NOT a standard RM or GEDCOM fact called "Name Married" - that would be a custom fact, user defined.

 

The RM Alt Name fact has a dropdown menu with 7 selections, including both Birth and Married. That selection, however, does NOT get used by any of the sentence templates for other RM facts, and I'm not aware of any way to revise the sentence templates to achieve that goal.  As it is, those selections are there as documentation for the database user, but not for any reports derived or extracted from the RM database.

 

I believe that they ARE properly transferred in a drag-n-drop from one RM database to another RM database.



#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6448 posts

Posted 26 October 2014 - 03:41 PM

Name Married is not a RM fact. Alt Name can have a parameter set that defines the type of name from among AKA, Birth, Immigrant, Maiden, Married, Nickname, Other spelling and import might be revised to set it but this parameter is unused everywhere outside the Edit Person window. Name Find in RootsMagic Explorer does include Married Names as a criterion but does not actually look for Names with the Married parameter; it simply matches on the husband's surname (i.e. an assumed married name).

 

There are only two standard Baptism fact types: Baptism and Baptism (adult).


Tom user of RM7630 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#4 torleifro

torleifro

    Member

  • Members
  • PipPip
  • 19 posts

Posted 27 October 2014 - 12:54 AM

My RM v6332 has these Name facts after my test import of a TMG project with 2 persons in it?

Just for fun or for no use at all?

 

Name-Baptism, Name-Change, Name-Married, Name-Nick, Name-Variation



#5 Jim Byram

Jim Byram

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 27 October 2014 - 06:16 PM

Many TMG tag types are imported that really serve no use in RM. The Name-something fact types fall into this category.

 

Primary TMG name tags are imported as the person's primary name. Non-primary TMG name tags are all imported using the RM standard Alternate Name fact type.



#6 koornalla

koornalla

    Advanced Member

  • Members
  • PipPipPip
  • 54 posts

Posted 27 October 2014 - 06:20 PM

Hi all,

 

I have issues with the Name-Marr import to RM as Alt Name as if adds unnecessary detail to the generated sentences in narrative reports. I would really prefer that the sentence for females that took on the married name after marriage not to generate a sentence "Name ABC was also known as Name XYZ". In most other situations where Alt Name would be used (if a person actually changed their name for example) it would be appropriate to generate a sentence.

 

I don't care how the import of Name-Marr occurs but the result has to be one that enables me to remove the option of this fact's (or subset of a fact's) generated sentence making its way on to a RM report..

 

I know you can edit any RM fact to achieve this but I would eliminate all sentences for the fact.

 

Within Alt Name I don't think fact types will help you nor will roles.

 

The TMG Name-Marr does get imported into RM as do all other TMG custom facts.

 

The obvious solution to my problem is to have all TMG Name-Marr facts being imported as  as RM Name-Marr facts.

 

Is this possible?

 

Any other clever ideas to achieve the same result?

 

 

Wayne Thurley



#7 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6448 posts

Posted 27 October 2014 - 07:24 PM

I don't think this is exactly what you want but it may add some insight: http://sqlitetoolsfo...s - Add Married

Tom user of RM7630 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#8 koornalla

koornalla

    Advanced Member

  • Members
  • PipPipPip
  • 54 posts

Posted 27 October 2014 - 09:29 PM

The sqlitetools idea looks promising. I might be able to delete the TMG married name fact using the TMG Utility then get RM to re-import the revised data. The only worry is I then lose the married name of an individual from the person list. Maybe I could live with that!!

 

The problem is the supression of the sentence for Alt Name. This tag is shared with people who have had other reasons for changing their names and the default sentence (or one generated by another role) really needs to appear in reports.

 

If the utility worked slightly differently by creating a role of married rather than creating a fact type of married then supressing the sentence for the Marriage role within the Alt Name fact that would be fantastic.

 

I am still to work out what use fact types are but I am sure they exist for a very good reason (almost certainly used for reporting purposes).

 

Keep the ideas coming. Great stuff!!

 

 

 

Wayne Thurley



#9 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 27 October 2014 - 10:35 PM

Wayne, you may want to rethink about changing Alternate name facts to another fact.

Alternate name facts are also treated as names in searches and on rhe Sidebar Index, People view, and RootsMagic Explorer if you choose to include them in the indexes.

This can be very helpful when you remember a woman's married surname and don't remember her maiden surname, or, help find her when you are doing research which gives her married name.

I enter Mrs. in the Prefix in the Alternate name fact for a married name.  On the index list, this tells me that Mary Smith is a woman's maiden name and Mrs. Mary Smith is the woman's married name.

I also put the woman's maiden surname in the Given name of the Alternate name fact for married names, i,e.  Mary (Doe).  That helps me tell the difference between Mrs. Mary (Doe) Smith and Mrs. Mary (Jones) Smith.

 

If a woman's name, is Elizabeth Ann Doe, married or maiden surname, and most of rhe research you find is Lizzie Doe, you might want to link an Alternate name fact with that Given name and the maiden or married surname.

At Lists, Fact type list, you can highlight the Alternate name fact and edit it.  Unchecking Narrative reports will globally surpress all Alternate name facts from being printed in a Narrative report.

Or, You can leave it checked and mark Facts you don't want to print for a person as Private on the Edit person screen.  When you create a Narrative report, choose not to print Private facts.
 



#10 koornalla

koornalla

    Advanced Member

  • Members
  • PipPipPip
  • 54 posts

Posted 28 October 2014 - 12:46 AM

Hi Laura,

 

You present a very compelling argument to keep to the one (Alt Name) fact. How I differ from you is I come with all this legacy TMG name data that I would prefer to migrate to RM as painlessly as possible. On one hand I see no reason to state the obvious by creating a sentence for a female that gets married and takes her husbands name (probably happened 99.5% of the time in the past) but I probably might want to create a sentence for other people that have a name change. I think roles will allow me to do what I want.

 

I like what you are doing but I also like what Tom is doing.

 

A variation of Tom's recommended SQLite utility does look very attractive for me but I in no hurry to migrate to RM yet.

 

 

 

Wayne Thurley



#11 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 28 October 2014 - 02:21 AM

I never had any married Alternate names until RM added the Alternate names to the indexes. In fact, I had no Alternate name facts at all.

As you say, most people can figure out that a married woman took her husband's surnwme especially in the past.

What made the difference for me was the usefulness of the Alternate name being in the indexes.

Otherwise, I don't see much point in either having married Alternate names or Name-Married if they really serve no purpose for the user.

Was Name-Married and the other Name-XXXXX's a required choice in TMG or did you have a choice about whether to use them or not use them?

#12 hlein

hlein

    Member

  • Members
  • PipPip
  • 24 posts

Posted 28 October 2014 - 03:05 AM

Laura,

 

I am sorry to say, but alternate names and married names (and other things you try to rationalise away or classify as useless) _do_ serve to the user. They can be used in sentences to match the docuemnts, make reports more talkative etzc.

Just because you did drive a compact car and never have driven a Mercedes, a Mercedes is not useless and does not serve anything.


Regards

Helmut


#13 Jim Byram

Jim Byram

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 28 October 2014 - 08:36 AM

Was Name-Married and the other Name-XXXXX's a required choice in TMG or did you have a choice about whether to use them or not use them?

Using any alternate name tag type and adding custom name tag types in TMG was up to the user. Name-Married tags could be added automatically when you added a Marriage tag or not. Your choice.



#14 Jim Byram

Jim Byram

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 28 October 2014 - 08:43 AM

The obvious solution to my problem is to have all TMG Name-Marr facts being imported as  as RM Name-Marr facts.

You can't create a custom alternate of the Alternate Name fact type as far as I can see. The only real alternative is to use TMG Utility to delete the Name-Married tags prior to import. Once in RM, there is no way to distinguish the married name Alternate Name facts from the other Alternate Name facts. Removing them would be a long process.

 

I have the same issue... choosing whether to keep the married names for navigation or to eliminate them since I prefer not to have them in reports or websites.



#15 koornalla

koornalla

    Advanced Member

  • Members
  • PipPipPip
  • 54 posts

Posted 28 October 2014 - 04:43 PM

You can't create a custom alternate of the Alternate Name fact type as far as I can see. The only real alternative is to use TMG Utility to delete the Name-Married tags prior to import. Once in RM, there is no way to distinguish the married name Alternate Name facts from the other Alternate Name facts. Removing them would be a long process.

 

I have the same issue... choosing whether to keep the married names for navigation or to eliminate them since I prefer not to have them in reports or websites.

Hi Jim,

 

I don't need to create a custom alternative to the Alt Name fact type as RM migrated my Name-Marr fact type for me. In saying that, after listening to what has been said thus far, I probably do not want to use it as the married name will not be automatically put into the RM indexes (which was why I used Name-Marr in TMG).

 

What I would like to do is to make better use of roles within the Alt Name fact type to customise sentences for the specific type of Alt Name person.

 

Two alternatives for me could be:

 

1. Convince RM to get the import utility to interpret my Name-Marr TMG tags as RM Alt Name tags with role of Married set.

 

2. Remove the TMG Name-Marr tags from TMG and convince the makers of Sqlite "Add Married" utility to modify the utility to assign a role of married to the Alt Name tag it creates rather than crating a Married Name Type. I think this wll make this utilty more useful.

 

 

Wayne Thurley



#16 Jim Byram

Jim Byram

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 28 October 2014 - 06:45 PM

Wayne,

 

The fly in the ointment for both of your suggestions is that the only role that can be used for the principal of the Alternate Name fact type is 'Principal'.

 

Jim



#17 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 29 October 2014 - 01:14 AM

You can change the default Principle sentene for the Alternate name fact at Lists, Fact type lists.

One of the switches that can be used in sentence templates is a gender switch.  The first sentence is for a male and the second sentence will print for a female.

Sentence example:
<% [Person:HeShe] was also known as [Desc]|[Person:HeShe] also used the name of [Desc]><[Date]>.

[Person:HeShe] prints He or She depending on the sex of the person.  {Person] would print the full name.
For the Alternate name fact, [Desc] is the entered alternate name.
< [Date]> at the end prints the date for either sentence if a date is entered.

The date for the fact could be entered with one of the date modifiers used by RM.
after, between date and date, from date to date, before date, etc.

The default fact sentence for any fact should be generic enough to work for any one with that fact.

The fact can be customized for each individual on the Edit person screen to better fit the circumstances for that person or to vary how the fact prints for each individual for better readability on a Narrative report.
 



#18 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6448 posts

Posted 29 October 2014 - 08:56 AM

2. Remove the TMG Name-Marr tags from TMG and convince the makers of Sqlite "Add Married" utility to modify the utility to assign a role of married to the Alt Name tag it creates rather than crating a Married Name Type. I think this wll make this utilty more useful.

I'm the maker. As Jim pointed out, there is no role for an Alt Name fact type other than "Principal" and even that is an inapplicable term for an unshareable fact. For Alt Names, RootsMagic does support in a very limited way Name Types (Undefined (default), AKA, Birth, Immigrant, Maiden, Married, Nickname, Other Spelling). Unfortunately,

  • There is but one common default sentence template with no variables available that are dependent on the Name Type. That seems like unfinished development and potential for improvement. It does not even have any effect on tabular outputs such as the Individual Summary.
  • The TMG direct import defaults to Undefined for Alternate Names that should be type Married.

Fortunately, each instance of an Alternate Name can have a "local" customized sentence. Currently, the script at Names - Add Married enters " " (the space character) to the local sentence for each added name to suppress its output to narrative reports.

  1. Aforesaid script could be revised to include a custom sentence appropriate to the Married type.
  2. A script could be developed to provide a Name type dependent local custom sentence to all defined type Alt Names, e.g.:
    • AKA:  <% [Person:HeShe] was also known as [Desc]|[Person:HeShe] also used the name of [Desc]><[Date]>.
    • Birth: [Person:HeShe:Poss] birth name was [Desc].
    • Immigrant: [Person:Casual:Poss] name when [Person:HeShe] immigrated< [Date:Year]> was [Desc].
    • Maiden: Until she married< [Date:Year]>, [Person:Casual] went by her maiden name, [Desc].
    • etc....

You won't get exactly what you had in TMG but you may get something you can live with, if you are willing to work with SQLite in its relationship to the RootsMagic database as you may have done with TMG Utilities et al on your TMG database. There are some things that application developers choose not to do or never get around to doing... 


Tom user of RM7630 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#19 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1595 posts

Posted 29 October 2014 - 09:49 AM

Laura and TomH:

 

You both describe using the Alternate Name's Description field - which doesn't exist in the Fact Type definition, but instead appears to be a dynamically-created concatenation of the Prefix+Given+Surname+Suffix. This does not provide a way to use the Name Type in the sentence, which is what a whole lot of us are hoping to see in an RM update.  Perhaps the field in the Names table which holds the Name Type can somehow be accessed?

 

I don't see anything in the RM Help - Sentence Template Language which addresses use of the Name Type.



#20 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 29 October 2014 - 10:44 AM

We use [ Desc] in the sentence because that is what prints the alternate name in the Narrative report.

No [Desc] in the sentence, no alternate name in the report.