Jump to content


Photo

First Experience with TMG Direct Import

TMG Direct Import Issues

  • Please log in to reply
69 replies to this topic

#1 Sherman Peabody

Sherman Peabody

    Member

  • Members
  • PipPip
  • 17 posts

Posted 22 September 2014 - 09:12 PM

Below are comments on what the import does and how it might be adjusted to be better.  I see direct import as providing a best possible import of TMG data into the existing RootsMagic infrastructure. I do not consider this to be the place for discussion of TMG features that do not transfer well into RM.

 

All in all, the TMG Direct import is good.  These are the things that jumped out at me. I'm sure I'll find others as a walk thru 21,000 persons...

  • When a fact is created from the appearance of a witness on a non-family fact, it should be attached to the witness’ person record, not the principal’s.  For example, a witness to a death event might be the widow or the informant on the death certificate.  These facts should be attached to the widow or the informant, not to the person who died.
  • I would think in almost every case that a TMG sentence refers to the [L] variable, the RootsMagic equivalent should be [PlaceDetails] [Place]. Or more specifically, <[L]> should be replaced with <[PlaceDetails]>< [Place]>.
  • A spouse as a witness does not imply that the event should be a family event.  For example, a spouse being a witness to a death most likely implies that it was intended to be an individual event attached to the spouse.  Another example, a spouse may be identified (as a witness) as the “closest relative” on a military registration.  That does not mean the spouse also registered for the military.
  • Birth date and death date are not populated in the Name Table.  Assuming TMG’ers will be importing to RM version 6, rebuilding indices should be recommended in the documentation as a "post-import" procedure.
  • With even a modestly large database, the first “Progress” screen that is displayed when an import is done can take quite a while before it displays anything.  A simple “working…” displayed in that popup window might be reassuring.
  • It sure would be nice if TMG split memos could be interpreted and imported as customized sentences and TMG split witness memos could be interpreted and imported as customized witness sentences, but I definitely understand why that is a "version 2" feature.
  • TMG surety values are not imported in any way.   I’m not sure how they should import, but does RM import QUAY values from GEDCOM?  I would think it would be similar.
  • When a TMG date variable ([D]) appears inside angle brackets (“<>”), if anything else appears inside the angle brackets other than the [D] variable itself, the RM variable [Date:Plain] should be used.  This allows the alterations of date prepositions in TMG to be realized in RM. It might not be the best use of RM [Date] constructs but more of the TMG sentences will come across without extra prepositions.


#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 23 September 2014 - 10:22 AM

Well reported, Sherman.


Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#3 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7256 posts

Posted 23 September 2014 - 04:17 PM

Confirming these observations and suggestions have been reported to development.


Renee
RootsMagic

#4 jjmick

jjmick

    Advanced Member

  • Members
  • PipPipPip
  • 81 posts

Posted 23 September 2014 - 07:34 PM

While the TMG direct import is not "perfect", my compliments to Bruce and all the RM folks for making this happen.  It is certainly much better than the GEDCOM import would have been.

 

I have used both TMG (beta tester) and RM for many years and this is much better than expected for the first try.  I am sure it will improve as time goes on.

 

Good Job!! Many thanks.

 

Mick Mickelson



#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 23 September 2014 - 08:40 PM

  • When a fact is created from the appearance of a witness on a non-family fact, it should be attached to the witness’ person record, not the principal’s.  For example, a witness to a death event might be the widow or the informant on the death certificate.  These facts should be attached to the widow or the informant, not to the person who died.

This does not make sense to me. What is the fact type supported by the death certificate? Is it that a person died or that a person reported a death?

 

If it is the Death fact, then surely it is the person who died who is the Principal and the person who reported the death can have a witness role such as Informant.

 

If, instead, the event you want to record is that a person reported a death, what fact type is that? It could be Miscellaneous or some custom fact type like Reported and the reporter could be the Principal and the person who was reported on could be in a witness role like "Subject". 

 

I think most people would follow the first convention on the basis that the evidence (the death certificate) supports the death fact for a person, a primary or vital fact type. Anything else is secondary.

 

However, I wonder if what you are raising is the flip side of the problem translating TMG dual principal tags for non-spousal principals to non-family fact type in RootsMagic. Is it possible that the primary subject is P2, not P1, and that the rote conversion of P2 to a witness is flipping roles in a way that you do not want. Maybe you have to flip the principals in TMG and then import. Does John Cardinal's TMG Utility do something like that?  


Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#6 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 23 September 2014 - 08:55 PM

  • Birth date and death date are not populated in the Name Table.  Assuming TMG’ers will be importing to RM version 6, rebuilding indices should be recommended in the documentation as a "post-import" procedure.
  • With even a modestly large database, the first “Progress” screen that is displayed when an import is done can take quite a while before it displays anything.  A simple “working…” displayed in that popup window might be reassuring.
  • TMG surety values are not imported in any way.   I’m not sure how they should import, but does RM import QUAY values from GEDCOM?  I would think it would be similar.

You should see these in the next update.


Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#7 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 23 September 2014 - 09:15 PM

  • I would think in almost every case that a TMG sentence refers to the [L] variable, the RootsMagic equivalent should be [PlaceDetails] [Place]. Or more specifically, <[L]> should be replaced with <[PlaceDetails]>< [Place]>.

... Good point. May not be covered in the next update. If not, I will look into a SQLite post-process...

  • A spouse as a witness does not imply that the event should be a family event.  For example, a spouse being a witness to a death most likely implies that it was intended to be an individual event attached to the spouse.  Another example, a spouse may be identified (as a witness) as the “closest relative” on a military registration.  That does not mean the spouse also registered for the military.

... I think this will be largely resolved in the next update, assuming what you are describing is, once again, the dual principal tag, this time for spousal principals but for an event that is not spousal, but I could be wrong on that. And if it does convert all such dual principal tags for spousal principals and which are not part of the marriage/divorce group to individual fact types with the second principal in a witness/shared role, there might be users who have a problem with that.  

 

  • It sure would be nice if TMG split memos could be interpreted and imported as customized sentences and TMG split witness memos could be interpreted and imported as customized witness sentences, but I definitely understand why that is a "version 2" feature.

 

... definitely

  • When a TMG date variable ([D]) appears inside angle brackets (“<>”), if anything else appears inside the angle brackets other than the [D] variable itself, the RM variable [Date:Plain] should be used.  This allows the alterations of date prepositions in TMG to be realized in RM. It might not be the best use of RM [Date] constructs but more of the TMG sentences will come across without extra prepositions.

... not expected in the next update; again, maybe a post-process in the interim...


Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#8 OleSeminole

OleSeminole

    New Member

  • Members
  • Pip
  • 2 posts

Posted 25 September 2014 - 04:28 PM

 

  • TMG surety values are not imported in any way.   I’m not sure how they should import, but does RM import QUAY values from GEDCOM?  I would think it would be similar.

 

I converted my TMG 8 data project to RM two years ago using GEDCOM and a LOT of editing.  This direct import is so much better! Especially the conversion of multi-role Tags to shared Facts.  The Quay values did not import in GEDCOM and they don't make any sense using the RM dialog. You can include comments in the citation notes about the surety values. I used TMG for almost 15 years. RM has worked well for me but I've had to change the way I record data that will be displayed in RM reports. Thanks to Bruce and the RM software group for this TMG import feature. 



#9 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 25 September 2014 - 05:38 PM

The new TMG update 9.04 exports GEDCOM with sureties for citations in what RootsMagic imports as Citation Comment and RM converts QUAY to one of its Citation quality parameters. TMG also exports witness tags in RootsMagic shared events compatible extended GEDCOM. And many types of outputs will be consistent with the TMG sentence templates which will result in something quite different from the results of the direct import. I am sure that prospective TMG émigrés will have much to contrast and comment on...

Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#10 torleifro

torleifro

    Member

  • Members
  • PipPip
  • 19 posts

Posted 28 September 2014 - 05:04 AM

As a TMG user I miss a file/report after the finished import with information abt all data that has not been imported or has been changed during import, and which persons are involved. Maybe it's already there/here?



#11 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3289 posts

Posted 28 September 2014 - 05:54 AM

As a TMG user I miss a file/report after the finished import with information abt all data that has not been imported or has been changed during import, and which persons are involved. Maybe it's already there/here?


Yes, there should be a plain-text file named <databasename>.LST (created in the same folder as the original GEDCOM) which will reflect some identifying info about the source .GED file imported and show tags and data that RootsMagic had difficulty interpreting.

---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#12 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 28 September 2014 - 05:59 AM

I think it is written to the same folder as the database .rmgc file...

Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#13 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3289 posts

Posted 28 September 2014 - 08:53 AM

Sorry, I'm sure Tom's right (I'm not at home). I think my assertion ignored the fact that I store RM databases and .GED files in the same folder. My bad !

---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#14 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 28 September 2014 - 09:32 AM

 

  • I would think in almost every case that a TMG sentence refers to the [L] variable, the RootsMagic equivalent should be [PlaceDetails] [Place]. Or more specifically, <[L]> should be replaced with <[PlaceDetails]>< [Place]>.
  • When a TMG date variable ([D]) appears inside angle brackets (“<>”), if anything else appears inside the angle brackets other than the [D] variable itself, the RM variable [Date:Plain] should be used.  This allows the alterations of date prepositions in TMG to be realized in RM. It might not be the best use of RM [Date] constructs but more of the TMG sentences will come across without extra prepositions.

Until the RootsMagician incorporates these changes, you might use the SQLite script TMG-RM Fact Sentence Tweaks which addresses these problems and a few others.


Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#15 Sherman Peabody

Sherman Peabody

    Member

  • Members
  • PipPip
  • 17 posts

Posted 28 September 2014 - 03:43 PM

This does not make sense to me. What is the fact type supported by the death certificate? Is it that a person died or that a person reported a death?

You are absolutely correct Tom, it did not make sense.  I misinterpreted what I was seeing in RootsMagic and bungled that one.



#16 Sherman Peabody

Sherman Peabody

    Member

  • Members
  • PipPip
  • 17 posts

Posted 28 September 2014 - 04:08 PM

Round 2: Using RootsMagic 6.3.3.1 this time:

 

  • The TMG [S] variable refers to the witness when it appears in a witness sentence.  Example TMG witness sentence:  “[S] was cited as the nearest relative of [P1] on his military registration <[D]><[L]><. [WM]>” translates in RM to: “[Person] was cited as the nearest relative of [Person] on his military registration <[Date]><[Place]><. [WM]>”

  • <[L]> should be translated to <[PlacesDetails]><[Place]>. This would fix several sentences in my import.  If [PlaceDetails] is blank, there is no harm done.  If it has something in it, the TMG [L] variable always includes those values.

  • My TMG birth tags have no witnesses cited.  It appears the import adds Parent witnesses whether they appeared in TMG or not:
    • An RM Parent witness was created for the mother with the sentence: “[Husband] was born a [PAR] on <[Date]><[Place]><. [Desc]>”.  This is almost a translation of the default TMG parent witness sentence, but it puts no spaces between the date and place as the TMG variables do and neither the parent, nor the child was a "husband".

    • An RM Parent witness was created for the father with exactly the same sentence generated for the mother.  In neither case (mother or father) does RM recognize [Husband] as a translatable variable.


  • A TMG Misc. tag has the customized witness sentence: “[W] was an attendee when [P1] was a presenter at the Mid-south Training for Service <[D]> <[L]>”.  This was imported to the RM witness sentence: [ThisPerson] was an attendee when [Husband] was a presenter at the Mid-south Training for Service <[Date]> <[Place]>.”  The witness was a female not even related to the principal who was also female and certainly not her “wife.”

  • People who have used two Principals in TMG for events other than family events (marriage, census, etc) are going to run into problems that are unavoidable.  Thus the translation of [P] or [P1] should be [Person] in almost every case.  [Spouse] might be used for [P2] or [PO] in family events, but I would think [Husband] would have very limited application for the purposes of this import.

  • It appears that as a rule, the TMG [M] variable is translated to [Desc] or [Desc:A] but then the TMG memo value is copied to the RM Notes field and the description field is left blank.  Since there is no RM memo variable, could the memo value also be copied to the description so the RM sentences would be closer to functional?

  • TMG graduation sentence: “[P] <was|and [PO] were> graduated <[D]> from < [L]> <[M]>”. This was translated in RM to “[Person] attended < [Place]><[Date]><. [Desc]>.” The import moved the TMG Addressee field to Place Details and then the sentence omits [PlaceDetails].  And again the TMG memo was moved to Notes and then the sentence refers to [Desc].

Unfortunately for me, it looks like almost all but the most straightforward TMG events will require a significant amount of reworking due to issues like the ones cited above.  These were found reviewing the events in just one family.  I certainly understand that this import is a complex problem.  I hope these comments are constructive.



#17 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5536 posts

Posted 28 September 2014 - 09:57 PM

Round 2: Using RootsMagic 6.3.3.1 this time:

  • The TMG [s] variable refers to the witness when it appears in a witness sentence.  Example TMG witness sentence:  “[s] was cited as the nearest relative of [P1] on his military registration <[D]><[L]><. [WM]>” translates in RM to: “[Person] was cited as the nearest relative of [Person] on his military registration <[Date]><[Place]><. [WM]>”

[s] should have been translated to [ThisPerson] if it was a witness sentence, [Person] if the principal's sentence and that is what I have observed. [WM] does not translate so it is left as a flag for you to fix.

  • <[L]> should be translated to <[PlacesDetails]><[Place]>. This would fix several sentences in my import.  If [PlaceDetails] is blank, there is no harm done.  If it has something in it, the TMG [L] variable always includes those values.

 

Agreed, except it should be < [PlacesDetails]>< [Place]>. RootsMagic does not auto-space variables so it is necessary to account for them in the sentence template. That's what is done by my interim patch TMG-RM Fact Sentence Tweaks.

 

  • My TMG birth tags have no witnesses cited.  It appears the import adds Parent witnesses whether they appeared in TMG or not:

 

Strange. I have not seen unintended shared Birth events in direct imports of the TMG Sample database nor of a 5000 person project.

 

  • An RM Parent witness was created for the mother with the sentence: “[Husband] was born a [PAR] on <[Date]><[Place]><. [Desc]>”.  This is almost a translation of the default TMG parent witness sentence, but it puts no spaces between the date and place as the TMG variables do and neither the parent, nor the child was a "husband".

 

Strange again. Is this an extension of the previous problem? Was this a custom Birth tag with two principals? Is P1 the mother? Again, no auto-spacing for variables - must be explicit - interim patch TMG-RM Fact Sentence Tweaks also spaces <[Date]>.

 

  • An RM Parent witness was created for the father with exactly the same sentence generated for the mother.  In neither case (mother or father) does RM recognize [Husband] as a translatable variable.

 

If it is a single-principal event, [Husband], [Wife], [Spouse], [Couple] have no meaning. But we're still back to why your Birth events have these supposedly auto-generated Father/Mother witnesses and what I have seen does not. 

 

  • A TMG Misc. tag has the customized witness sentence: “[W] was an attendee when [P1] was a presenter at the Mid-south Training for Service <[D]> <[L]>”.  This was imported to the RM witness sentence: [ThisPerson] was an attendee when [Husband] was a presenter at the Mid-south Training for Service <[Date]> <[Place]>.”  The witness was a female not even related to the principal who was also female and certainly not her “wife.”

 

This sounds like a 2-Principal tag in TMG being converted to an individaul fact type in RM. The nearest equivalent to [P1] is [Husband] and to [P2] is [Wife]. Consider those to be just names of variables and not indicative of gender. However, they do point to fields of the same name in FamilyTable. If detected as an individual fact type, then [P1] should translate to [Person]. If there is no immediate fix, I think a SQLite query could be devised to hunt these out and change them.

 

  • People who have used two Principals in TMG for events other than family events (marriage, census, etc) are going to run into problems that are unavoidable.  Thus the translation of [P] or [P1] should be [Person] in almost every case.  [Spouse] might be used for [P2] or [PO] in family events, but I would think [Husband] would have very limited application for the purposes of this import.

 

Witness role of Best Man: [This Person] was [Husband:casual:poss] best man... 
Witness role of Bridesmaid: [This Person] was [Wife:casual:poss] bridesmaid...
Otherwise, agreed. 

 

  • It appears that as a rule, the TMG [M] variable is translated to [Desc] or [Desc:A] but then the TMG memo value is copied to the RM Notes field and the description field is left blank.  Since there is no RM memo variable, could the memo value also be copied to the description so the RM sentences would be closer to functional?

 

Yes. TMG 9.04 GEDCOM does. And direct import does for a few fact types, e.g., Education, Occupation. For an interim fix, see Events - Move Short Note to Description
 

 

  • TMG graduation sentence: “[P] <was|and [PO] were> graduated <[D]> from < [L]> <[M]>”. This was translated in RM to “[Person] attended < [Place]><[Date]><. [Desc]>.” The import moved the TMG Addressee field to Place Details and then the sentence omits [PlaceDetails].  And again the TMG memo was moved to Notes and then the sentence refers to [Desc].

 

Presumably the standard TMG Graduation fact mapped to the standard RM Graduation fact so you get the standard RM sentence? And because it is an individual fact type, [PO] cannot be translated. That said, were it a family fact, <was|and [PO] were> are often carried over but does not function correctly under RM rules; it needs to be changed to <and [Spouse] were|was> as done in TMG-RM Fact Sentence Tweaks.

Unfortunately for me, it looks like almost all but the most straightforward TMG events will require a significant amount of reworking due to issues like the ones cited above.  These were found reviewing the events in just one family.  I certainly understand that this import is a complex problem.  I hope these comments are constructive.


Tom user of RM7230 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 growing bundle of RootsMagic utilities.


#18 torleifro

torleifro

    Member

  • Members
  • PipPip
  • 19 posts

Posted 29 September 2014 - 12:09 AM

I think it is written to the same folder as the database .rmgc file...

You are right, a LST file is written after GEDCOM import.

There is no file after direct import, Coming?



#19 CherylCh

CherylCh

    Advanced Member

  • Members
  • PipPipPip
  • 76 posts

Posted 30 September 2014 - 04:11 PM

After some cleanup on the TMG side, I did a fresh import into RM.  In TMG I have the following sentence template:  [D] he registered for the World War I draft [L]. <[M]>

 

Upon import, the resulting RootsMagic sentence template is:  [C=M,0  ,0  ][Date] he registered for the World War I draft [Place]. <[Desc]>.

And the resulting sentence in a narrative report: [C=M,0  ,0]on 11 Sep 1918 he registered for the World War I draft in Winder, Barrow County, Georgia.

 

This would be perfect if not for that odd little [C=M,0  ,0].  This isn't the only sentence template where I'm seeing this, but it's probably the simplest one where it's happening.



#20 CherylCh

CherylCh

    Advanced Member

  • Members
  • PipPipPip
  • 76 posts

Posted 30 September 2014 - 06:23 PM

Another problem I'm seeing is in sources.  A lot of my source citation templates use an optional citation memo (in TMGspeak, <[CM]>). 

 

In endnotes for narrative reports in RM, these are showing up as [Cm].

 

As far as I can see in the construction of RM sentence templates, <> means the same thing as in TMG - use only if present.  Maybe it's different for source templates???