On Thu, Sep 4, 2014 at 11:24 PM, Don Ferguson via <tmg-refugees@rootsweb.com > wrote: > I wouldn’t mind the RM approach if I could delete the ones I will never > use (like LDS and many purely US ones) and hide the ones I don’t want to > see, as I think I will probably never use them. Even a pure ‘hide’ > function would be OK, but I don’t see that in RM either. > There is really no need to delete or hide the built-in source templates but it can be done. Using SQLite, one could delete unused Source Templates from a database but that could prove counter-productive. These uneditable, built-in source templates are constant from database to database so that transfers of persons with sources between databases does not require a corresponding transfer of the source template specification. Thus a transfer to a database without the standard template for a source that used one would result in that source becoming phantomed. Custom source templates do require transfer of their specifications between databases and, as I think Jerry described, can result in duplicate sources failing to merge, e.g., a person with citations copied by drag'n'drop to another database and then back again may have such unmerged duplicate sources even though they are built from the seemingly identical custom source template. If built from a common built-in source template, they do merge. This is an unexpected and unwanted complication that I hope will someday be resolved. Users who exploit custom source templates have other alternatives to hiding or deleting the built-in ones. They prefix the name of the source template with a * or _ or some other character that sorts them to the top of the alphabetically sorted list of source template names and they use the Favorites and Recent lists when selecting a Source Type for a new Source. > > But your last comment about ‘the source is stuck with that Source Template > forever’ frightens me – that is also way too inflexible, methinks… > That is not absolutely true. Within RootsMagic, one can, for example, create a new Master Source based on a custom source template and merge a Source based on another template into it. As long as the two source templates have matching field names for non-empty fields in the original source and these field names are at the same levels (Master or Citation), nothing is lost. Again, for the daring, much more powerful and faster things can be done using SQLite queries. And there is promise of a source conversion facility someday... Tom

Hi Barbara, This looks like a very usable site! Thanks for making the text black -- that does help readability. And thanks for your leadership! Barbara On 9/6/2014 11:26 PM, Barbara Zanzig via wrote: > I've updated the website layout. Here's the announcement: > https://sites.google.com/site/tmgrefugees/news-announcements/blog . > > You can now subscribe to the activity on the site. Be aware that this is a > prototype and as the site design evolves, I may have to reinitialize > subscription lists--be prepared for a little disruption while we work out > the basics. > > I'm trying to learn enough to make some basic guidelines for site > editors--such things as "remember to share each new page". I should be > ready to share in 2 or 3 days. > > -- > Barbara Zanzig > TMG-REFUGEES list admin > admin email: *TMG-REFUGEES-admin@rootsweb.com > <TMG-REFUGEES-admin@rootsweb.com>* > list address: *http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html > <http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html>* > list website: *https://sites.google.com/site/tmgrefugees > <https://sites.google.com/site/tmgrefugees>* > *** > To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the message subject and body. > ------------------------------- > To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message > -- Barbara Levergood levergood@att.net

Changes look great! She's rolling along now, Barbara. :) -----Original Message----- From: Barbara Zanzig via Sent: Saturday, September 6, 2014 11:26 PM To: tmg-refugees@rootsweb.com Subject: [TMG-REFUGEES] Administrivia: website update I've updated the website layout. Here's the announcement: https://sites.google.com/site/tmgrefugees/news-announcements/blog . You can now subscribe to the activity on the site. Be aware that this is a prototype and as the site design evolves, I may have to reinitialize subscription lists--be prepared for a little disruption while we work out the basics. I'm trying to learn enough to make some basic guidelines for site editors--such things as "remember to share each new page". I should be ready to share in 2 or 3 days. -- Barbara Zanzig TMG-REFUGEES list admin admin email: *TMG-REFUGEES-admin@rootsweb.com <TMG-REFUGEES-admin@rootsweb.com>* list address: *http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html <http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html>* list website: *https://sites.google.com/site/tmgrefugees <https://sites.google.com/site/tmgrefugees>* *** To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the message subject and body. ------------------------------- To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Oh, I'd love to see someone do that and do a report! Barbara On Sat, Sep 6, 2014 at 7:40 PM, Tom Holden via <tmg-refugees@rootsweb.com> wrote: > Jim Byram offers to run anyone's project through the pre-release version of > TMG 9.04 export to produce the most comprehensive TMG GEDCOM yet. See his > message at > > http://www.whollygenes.com/forums201/index.php?/topic/15842-v9040000-gedcom-export-new-option/#entry65534 > > Tom > > > -- Barbara Zanzig TMG-REFUGEES list admin *http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html <http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html>* admin email: *TMG-REFUGEES-admin@rootsweb.com <TMG-REFUGEES-admin@rootsweb.com>*

Jim Byram offers to run anyone's project through the pre-release version of TMG 9.04 export to produce the most comprehensive TMG GEDCOM yet. See his message at http://www.whollygenes.com/forums201/index.php?/topic/15842-v9040000-gedcom-export-new-option/#entry65534 Tom On Fri, Sep 5, 2014 at 9:36 AM, Tom Holden <ve3meo@gmail.com> wrote: > On Fri, Sep 5, 2014 at 12:16 AM, Don Ferguson via < > tmg-refugees@rootsweb.com> wrote: > >> I’m not going to waste any more time playing with it until their promised >> Witness/Role function comes out, but I don’t have high hopes for it. Nor >> for RM’s direct import feature, given that that has been promised for years >> without delivery. But without those 2 major changes, neither program is >> worth thinking about – just my opinion. >> > > If you have little faith in either of those outcomes, TMG GEDCOM Export > will be significantly improved in v9.04, mainly in exporting Witness tags > and roles to custom GEDCOM extensions for shared events recognised by > RootsMagic, GedView and maybe Legacy. That still may not be good enough for > some but you can and should stick your oar into the discussion " > v9.04.0000-GEDCOM export / Enhanced option / Discussion" at: > http://www.whollygenes.com/forums201/index.php?/topic/15843-v9040000-gedcom-export-enhanced-option-discussion/ > > > Tom >

I've updated the website layout. Here's the announcement: https://sites.google.com/site/tmgrefugees/news-announcements/blog . You can now subscribe to the activity on the site. Be aware that this is a prototype and as the site design evolves, I may have to reinitialize subscription lists--be prepared for a little disruption while we work out the basics. I'm trying to learn enough to make some basic guidelines for site editors--such things as "remember to share each new page". I should be ready to share in 2 or 3 days. -- Barbara Zanzig TMG-REFUGEES list admin admin email: *TMG-REFUGEES-admin@rootsweb.com <TMG-REFUGEES-admin@rootsweb.com>* list address: *http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html <http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html>* list website: *https://sites.google.com/site/tmgrefugees <https://sites.google.com/site/tmgrefugees>*

Looks nice to me! Constance On Sat, Sep 6, 2014 at 8:36 AM, Tom via <tmg-refugees@rootsweb.com> wrote: > Good morning, Barbara > > So far, so good! A most excellent job. :) > > The only thing I have for comment so far is about the left column. Where it > shows "Genealogy Software News", "Announcement/blog Sample Page" and > "Software Comparison" is there a way to indent "...Software News", > "...Sample Page" and ...Comparison" so they don't appear as if they were > separate items? Also, can the width of this column be expanded just a tad > so > that the word "...blog..." in "Announcement/blog" appears in entirety? > Right > now the word "...blog..." is concatenated on my screen. > > Hm-m-m-m, a lot of words there for something very minor. Tom D > > -----Original Message----- > From: Barbara Zanzig via > Sent: Saturday, September 6, 2014 7:44 AM > To: TMG-REFUGEES@rootsweb.com > Subject: [TMG-REFUGEES] Administrivia re. group web site > > I've mocked up a group Google site. I've set it currently allow access by > giving you the address, to get your feedback on the site structure. > > For some of you newer folks this was a discussion about a week ago about > how to preserve the information we're collecting. > > After we get past this initial site design stage, we will need to go to a > by-invitation system during the site construction. There seems to be either > world access, access by link, or individual named access, and it's only in > the last category that I can give others permissions to add information. > Otherwise as owner I'll be the one making all changes, and I don't want > that (nor do you). > > What I'd like right now is a few people to look the site over and offer > design suggestions, particularly other pages and/or page hierarchies that > are needed. Also tell me if it's easy to read--the low-contrast theme I put > on it may need to be changed. > > If someone would like to take building the site as a project, I'd be happy > to give you edit access to it. Email me privately please. > > https://sites.google.com/site/tmgrefugees/ > > -- > Barbara Zanzig > TMG-REFUGEES list admin > > http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html > admin email: TMG-REFUGEES-admin@rootsweb.com > *** > To unsubscribe from the list, please send an email to > TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the > quotes in the message subject and body. > ------------------------------- > To unsubscribe from the list, please send an email to > TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the > quotes in the subject and the body of the message > > *** > To unsubscribe from the list, please send an email to > TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the > quotes in the message subject and body. > ------------------------------- > To unsubscribe from the list, please send an email to > TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the > quotes in the subject and the body of the message >

Good morning, Barbara So far, so good! A most excellent job. :) The only thing I have for comment so far is about the left column. Where it shows "Genealogy Software News", "Announcement/blog Sample Page" and "Software Comparison" is there a way to indent "...Software News", "...Sample Page" and ...Comparison" so they don't appear as if they were separate items? Also, can the width of this column be expanded just a tad so that the word "...blog..." in "Announcement/blog" appears in entirety? Right now the word "...blog..." is concatenated on my screen. Hm-m-m-m, a lot of words there for something very minor. Tom D -----Original Message----- From: Barbara Zanzig via Sent: Saturday, September 6, 2014 7:44 AM To: TMG-REFUGEES@rootsweb.com Subject: [TMG-REFUGEES] Administrivia re. group web site I've mocked up a group Google site. I've set it currently allow access by giving you the address, to get your feedback on the site structure. For some of you newer folks this was a discussion about a week ago about how to preserve the information we're collecting. After we get past this initial site design stage, we will need to go to a by-invitation system during the site construction. There seems to be either world access, access by link, or individual named access, and it's only in the last category that I can give others permissions to add information. Otherwise as owner I'll be the one making all changes, and I don't want that (nor do you). What I'd like right now is a few people to look the site over and offer design suggestions, particularly other pages and/or page hierarchies that are needed. Also tell me if it's easy to read--the low-contrast theme I put on it may need to be changed. If someone would like to take building the site as a project, I'd be happy to give you edit access to it. Email me privately please. https://sites.google.com/site/tmgrefugees/ -- Barbara Zanzig TMG-REFUGEES list admin http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html admin email: TMG-REFUGEES-admin@rootsweb.com *** To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the message subject and body. ------------------------------- To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

> > from: Michael J. Hannah <mjh@nm.net>to: Barbara Zanzig <bzanzig@gmail.com> > date: Sat, Sep 6, 2014 at 7:11 AM > > With the end of development of TMG, export of TMG data to GEDCOM has > become an active topic among users. I have collected notes from various > personal tests of GEDCOM export from TMG I have done over the years. Some > users have asked me to publish an article based on these personal notes. > Terry Reigel has kindly offered to host the article at: > http://tmg.reigelridge.com/GED-EXPT.HTML > This article is intentionally *very* detailed and advanced. It deals with > many GEDCOM export issues which are unlikely to be of any interest to most > users. However, if you want to learn some of the "gory" details, this > article may be of help. > As I disclaim at the beginning of the article, these are just my personal > notes and is not an official WhollyGenes publication. Any errors or > misunderstandings are undoubtedly mine. Use at your own risk. > > Michael Hannah > > We will be putting a link to this (and any other relevant items, feel free to submit ideas) on the new website. -- Barbara Zanzig TMG-REFUGEES list admin *http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html <http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html>* admin email: *TMG-REFUGEES-admin@rootsweb.com <TMG-REFUGEES-admin@rootsweb.com>*

I've mocked up a group Google site. I've set it currently allow access by giving you the address, to get your feedback on the site structure. For some of you newer folks this was a discussion about a week ago about how to preserve the information we're collecting. After we get past this initial site design stage, we will need to go to a by-invitation system during the site construction. There seems to be either world access, access by link, or individual named access, and it's only in the last category that I can give others permissions to add information. Otherwise as owner I'll be the one making all changes, and I don't want that (nor do you). What I'd like right now is a few people to look the site over and offer design suggestions, particularly other pages and/or page hierarchies that are needed. Also tell me if it's easy to read--the low-contrast theme I put on it may need to be changed. If someone would like to take building the site as a project, I'd be happy to give you edit access to it. Email me privately please. https://sites.google.com/site/tmgrefugees/ -- Barbara Zanzig TMG-REFUGEES list admin http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html admin email: TMG-REFUGEES-admin@rootsweb.com

Greetings, and welcome to our newest members. I've been working on a couple of things. I will describe the website in a separate message so it's its own thread with a correct subject line. The other item is getting the list published in the Rootsweb directory, and I could use some help. I'm a brand-new list admin and I have no idea why the list isn't published. If there is another list admin out there who can help me sort it out, I'd appreciate the help. Contact me privately please. -- Barbara Zanzig TMG-REFUGEES list admin http://lists.rootsweb.ancestry.com/index/other/Miscellaneous/TMG-REFUGEES.html admin email: TMG-REFUGEES-admin@rootsweb.com

> In the RM Help system there are articles explaining how spouses and > children can be re-ordered by hand ("Arranging the order of spouses", > "Arranging the order of children"). I did not find a way to order them > chronologically automatically throughout the database. Correct. Generally speaking, you order spouses and children in RM as you do data entry. However, ordering them after a big GEDCOM import can be problematic. Through the years, I have become pretty leery of big GEDCOM imports, anyway. There usually is just too much cleanup to do. So ordering spouses and children as I do data entry usually is only a minor annoyance. Jerry

Thanks for pointing out this problem in RootsMagic, Jerry. I did an experiment with marriages. In my TMG database, George married 3 times to: TMG ID 4, Anna, m. sortdate before 1815 TMG ID 5, Mary, m. 15 Jun 1823 TMG ID 6, Sarah, m. sortdate before 1 Jun 1850 After import from TMG into a previous trial version of RM, the three marriages sort in the correct order in RM's displays and in the narrative report. That is a good result. However, the sort date of the 2 marriages that lacked an event date in TMG incorrectly appears in RM as both the sort date and the event date. I then added 3 new marriages in RM (v. 6.3.1.4). The marriages appear in the correct order in the edit person display. However, in the narrative descendant report, the new marriages incorrectly all appear before the TMG-vintage marriages and they appear in the order in which I entered the people (Nellie, Millie, Emma), not in chronological order of the year of marriage: Nellie, m. 1843 Millie, m. 1844 Emma, m. 1842 TMG ID 4, Anna, m. sortdate before 1815 TMG ID 5, Mary, m. 15 Jun 1823 TMG ID 6, Sarah, m. sortdate before 1 Jun 1850 In the RM Help system there are articles explaining how spouses and children can be re-ordered by hand ("Arranging the order of spouses", "Arranging the order of children"). I did not find a way to order them chronologically automatically throughout the database. Barbara On 9/5/2014 5:17 PM, Jerry Bryan via wrote: >> Now, to more interesting stuff – I noticed in playing with some charts, >> that multiple marriages often weren’t displaying in >> date order, and children weren’t showing in birthdate order. FH Support >> eventually owned up to the problem: FH displays >> stuff in the order they were CREATED in the original sending program >> (guess in the order they are in the GEDCOM file, i.e. >> in individual’s record-ID order) – even though it shows the events (Facts) >> in its Facts list for an individual in date order. > This is also a problem in RootsMagic, and RootsMagic users have been > complaining about it for years to no avail. I wonder if RootsMagic will be > any more responsive to émigrés from TMG than they have been to native RM > users. > > Jerry -- Barbara Levergood levergood@att.net

> Now, to more interesting stuff – I noticed in playing with some charts, > that multiple marriages often weren’t displaying in > date order, and children weren’t showing in birthdate order. FH Support > eventually owned up to the problem: FH displays > stuff in the order they were CREATED in the original sending program > (guess in the order they are in the GEDCOM file, i.e. > in individual’s record-ID order) – even though it shows the events (Facts) > in its Facts list for an individual in date order. This is also a problem in RootsMagic, and RootsMagic users have been complaining about it for years to no avail. I wonder if RootsMagic will be any more responsive to émigrés from TMG than they have been to native RM users. Jerry

Thanks Tom. If I can just add a bit more to expand on what we’ve both said(!) And I’ve been arguing with FH Support on a number of bugs for the last few days, so I’ll add that in too. FH swear by GEDCOM in their advertising, and as Tom found, FH Help says: "Family Historian was designed from the ground up, to be 100% GEDCOM-compatible, and 100% GEDCOM-complete. You do not have to convert Family Historian files to the GEDCOM format. They already are in the GEDCOM format." That is exactly what I found – my TMG data (6100 people), after using the ‘direct import’ feature of FH (which they recommend over a GEDCOM transfer from TMG) ended up in FH in a 4.6MB GEDCOM file. FH has an Autosave feature you can set to save every X minutes (defaults to 5) – I haven’t noticed any issues while I have been playing with it. Guess there might be delays for those with 100,000 people in their TMG files though. The FH Preferences also include loading options to “Exclude other applications extensions to GEDCOM”, “Exclude fields that are not valid for GEDCOM 5.5” and “Convert known Family Tree Maker/Ancestry extension tags” – those, of course would only apply to pure GEDCOM imports. Just as RM folks apply edits to the SQLite database directly, you can, obviously, edit the FH GEDCOM file yourself – at the risk of creating something it will spit out of course. Now, to more interesting stuff – I noticed in playing with some charts, that multiple marriages often weren’t displaying in date order, and children weren’t showing in birthdate order. FH Support eventually owned up to the problem: FH displays stuff in the order they were CREATED in the original sending program (guess in the order they are in the GEDCOM file, i.e. in individual’s record-ID order) – even though it shows the events (Facts) in its Facts list for an individual in date order. You need to apply FH’s ‘Re-order’ function to sort it out, and they said ‘OK, we’ll do an auto-re-order when we do a TMG import’. I said ’No, that means any Tags in TMG that have a Sort-date only will end up out of sequence, as you don’t have any concept of Sort-date in FH’ (they do get flushed to the END of the FH Facts list). They came back with a dumb response on that one, which says to me that they don’t have any idea of what Sort-date is or does. I’m not going to waste any more time playing with it until their promised Witness/Role function comes out, but I don’t have high hopes for it. Nor for RM’s direct import feature, given that that has been promised for years without delivery. But without those 2 major changes, neither program is worth thinking about – just my opinion. Don Ferguson From: Tom Holden [mailto:ve3meo@gmail.com] Sent: Thursday, 4 September 2014 11:52 PM To: Don Ferguson; tmg-refugees@rootsweb.com Subject: Re: [TMG-REFUGEES] Family Historian (update) I have added some comments interspersed in your message below, confined to GEDCOM and RootsMagic, with which I am familiar. I have not tried FH. Tom

Jerry, I’m with you 100% on all you’ve said. My original comment (which I think is still valid) noted RMs Sources were ‘rigid and unchangeable’, from which I had decided that the only way would be to do as you suggest and use them as templates, or build your own from scratch. Since you ask, TMG’s templates are similarly based on Lackey or Mills (your choice), but you can do 2 important things (a) change them, and (b) ‘hide’ the ones you don’t want – and of course, build your own. I wouldn’t mind the RM approach if I could delete the ones I will never use (like LDS and many purely US ones) and hide the ones I don’t want to see, as I think I will probably never use them. Even a pure ‘hide’ function would be OK, but I don’t see that in RM either. But your last comment about ‘the source is stuck with that Source Template forever’ frightens me – that is also way too inflexible, methinks… Don Ferguson From: Jerry Bryan [mailto:c24m48@hotmail.com] Sent: Friday, 5 September 2014 1:03 PM To: Tom Holden; Don Ferguson; tmg-refugees@rootsweb.com Subject: Re: [TMG-REFUGEES] Family Historian (update) > 3. there are no canned Source formats etc, due to Item 1. Source > definitions are essentially free-form - nothing like the unchangeable rigid > formats forced on you by RootsMagic! > > RootsMagic's 413 built-in Source Templates based on Mills and Lackey are > uneditable but you are not obligated to use any of them. You can copy any > one to a custom template and edit that to suit your purpose. It also has > free-form, and that is the format I advocate storing a source in for a > variety of reasons while, optionally, using a template to help craft the > words and the order they are in to copy and paste into the free-form > fields. If I may add some additional comments to Tom’s with respect to RM’s Source Template feature: I think it’s a feature with great potential but numerous problems. There are certainly a lot of very savvy RM users who are very good genealogists who swear by RM’s Source Templates. So I don’t want to denigrate the feature more than it deserves. Nevertheless, I take a much more cautious approach to them than some users. Most of the built-in templates are based on Evidence Explained by Mills, and a smaller number are based either on Lackey or on Evidence by Mills. Despite being by the same author, Evidence Explained and Evidence seem very different to me. I actually like Evidence a lot better. Being against Evidence Explained is sort of like being against Apple Pie and Motherhood. Nonetheless, it often seems far too complicated to me. And worse than that, it frequently just doesn’t make sense to me. My favorite example of problems with Evidence Explained is obituaries as sources. It’s easy to search the 885 pages of EE in vain for how to cite obituaries correctly. That’s because Evidence Explained doesn’t tell you how to cite obituaries. It tells you how to cite newspaper articles, with the concept being that obituaries are just special cases of newspaper articles. I just don’t buy it. There’s the obvious fact that many modern obituaries don’t appear in newspapers at all, not even online. Rather, they appear online at the web sites of funeral homes. But more subtle and more important to me is that I think it’s the “obituariness” of an obituary that’s most significant, not it’s “newspaper articleness”. The net effect in RM is that if you are an adherent of Evidence Explained and try to use a built-in source template for an obituary, you will find yourself using a template based on Evidence instead of on Evidence Explained because Evidence Explained doesn’t believe in obituaries. So I always develop my own source templates. I only have about 15 or 20 of them, not the 413 that are built-in. Mine are simpler and easier to use than the built-in ones, I understand them better, and if I find a glitch of some kind in one of my templates I can fix the problem. The built-in ones are not editable. The conventional wisdom among savvy RM users is never to use the built-in source templates directly. If you like the built-in ones, you should always make a copy and use the copy, even if you are not going to make any changes to the template. That way, if you do find a glitch then you can fix it. If you use one of the built-in templates directly and find glitch in the template, then the only way to fix the problem is to delete the source entirely including all it’s citations and to re-enter everything about the source and all it’s citations by hand. Having said all that, I keep my copy of Evidence Explained by my computer at all times and I refer to it regularly. And I even cheat occasionally and peak at RM’s built-in source templates. But I don’t use the built-in templates, not even to make a copy. Each of my own source templates is developed from scratch by hand using EE for ideas. It’s really quite easy to do. Prior to developing my own source templates, I used only RM’s built-in Free Form source template as Tom suggests. It’s really a good solution. It’s only in the last year or so that I became persuaded of the value of developing my own source templates as compared to using the Free Form one. One of the reasons I waited so long is the sources built with RM’s built-in Free Form source template generally export to GEDCOM in a much better manner than do sources built with RM’s built-in templates that are based on Mills or Lackey (some of the Mills or Lackey templates produce sources that export better than others). Sources with my templates export just fine. Finally, if you create a source with one Source Template, built-in or not and even including the Free Form one, the source is stuck with that Source Template forever. If you want to switch to a different template for that source, your only alternative from with RM is to delete the source and all its citations and start all over again with that source. I will sometimes cheat and change a source to use a different source template using SQLite, but doing so exceeds the capabilities of most RM users. TMG is about the only genealogy program I’ve never played with, so I don’t know first hand how TMG’s handling of sources compares to RM’s. As Tom already reported, RM’s facility can be pretty flexible and you are not forced to use the built-in templates. But it’s very easy to use the templates in such a way that they are very inflexible unless you are very careful. Just to repeat, even if you like RM’s source templates, NEVER USE THEM DIRECTLY – ALWAYS USE A COPY INSTEAD. It’s trivial to make a copy. Jerry

On Fri, Sep 5, 2014 at 12:16 AM, Don Ferguson via <tmg-refugees@rootsweb.com > wrote: > I’m not going to waste any more time playing with it until their promised > Witness/Role function comes out, but I don’t have high hopes for it. Nor > for RM’s direct import feature, given that that has been promised for years > without delivery. But without those 2 major changes, neither program is > worth thinking about – just my opinion. > If you have little faith in either of those outcomes, TMG GEDCOM Export will be significantly improved in v9.04, mainly in exporting Witness tags and roles to custom GEDCOM extensions for shared events recognised by RootsMagic, GedView and maybe Legacy. That still may not be good enough for some but you can and should stick your oar into the discussion " v9.04.0000-GEDCOM export / Enhanced option / Discussion" at: http://www.whollygenes.com/forums201/index.php?/topic/15843-v9040000-gedcom-export-enhanced-option-discussion/ Tom

> 3. there are no canned Source formats etc, due to Item 1. Source > definitions are essentially free-form - nothing like the unchangeable rigid > formats forced on you by RootsMagic! > > RootsMagic's 413 built-in Source Templates based on Mills and Lackey are > uneditable but you are not obligated to use any of them. You can copy any > one to a custom template and edit that to suit your purpose. It also has > free-form, and that is the format I advocate storing a source in for a > variety of reasons while, optionally, using a template to help craft the > words and the order they are in to copy and paste into the free-form > fields. If I may add some additional comments to Tom’s with respect to RM’s Source Template feature: I think it’s a feature with great potential but numerous problems. There are certainly a lot of very savvy RM users who are very good genealogists who swear by RM’s Source Templates. So I don’t want to denigrate the feature more than it deserves. Nevertheless, I take a much more cautious approach to them than some users. Most of the built-in templates are based on Evidence Explained by Mills, and a smaller number are based either on Lackey or on Evidence by Mills. Despite being by the same author, Evidence Explained and Evidence seem very different to me. I actually like Evidence a lot better. Being against Evidence Explained is sort of like being against Apple Pie and Motherhood. Nonetheless, it often seems far too complicated to me. And worse than that, it frequently just doesn’t make sense to me. My favorite example of problems with Evidence Explained is obituaries as sources. It’s easy to search the 885 pages of EE in vain for how to cite obituaries correctly. That’s because Evidence Explained doesn’t tell you how to cite obituaries. It tells you how to cite newspaper articles, with the concept being that obituaries are just special cases of newspaper articles. I just don’t buy it. There’s the obvious fact that many modern obituaries don’t appear in newspapers at all, not even online. Rather, they appear online at the web sites of funeral homes. But more subtle and more important to me is that I think it’s the “obituariness” of an obituary that’s most significant, not it’s “newspaper articleness”. The net effect in RM is that if you are an adherent of Evidence Explained and try to use a built-in source template for an obituary, you will find yourself using a template based on Evidence instead of on Evidence Explained because Evidence Explained doesn’t believe in obituaries. So I always develop my own source templates. I only have about 15 or 20 of them, not the 413 that are built-in. Mine are simpler and easier to use than the built-in ones, I understand them better, and if I find a glitch of some kind in one of my templates I can fix the problem. The built-in ones are not editable. The conventional wisdom among savvy RM users is never to use the built-in source templates directly. If you like the built-in ones, you should always make a copy and use the copy, even if you are not going to make any changes to the template. That way, if you do find a glitch then you can fix it. If you use one of the built-in templates directly and find glitch in the template, then the only way to fix the problem is to delete the source entirely including all it’s citations and to re-enter everything about the source and all it’s citations by hand. Having said all that, I keep my copy of Evidence Explained by my computer at all times and I refer to it regularly. And I even cheat occasionally and peak at RM’s built-in source templates. But I don’t use the built-in templates, not even to make a copy. Each of my own source templates is developed from scratch by hand using EE for ideas. It’s really quite easy to do. Prior to developing my own source templates, I used only RM’s built-in Free Form source template as Tom suggests. It’s really a good solution. It’s only in the last year or so that I became persuaded of the value of developing my own source templates as compared to using the Free Form one. One of the reasons I waited so long is the sources built with RM’s built-in Free Form source template generally export to GEDCOM in a much better manner than do sources built with RM’s built-in templates that are based on Mills or Lackey (some of the Mills or Lackey templates produce sources that export better than others). Sources with my templates export just fine. Finally, if you create a source with one Source Template, built-in or not and even including the Free Form one, the source is stuck with that Source Template forever. If you want to switch to a different template for that source, your only alternative from with RM is to delete the source and all its citations and start all over again with that source. I will sometimes cheat and change a source to use a different source template using SQLite, but doing so exceeds the capabilities of most RM users. TMG is about the only genealogy program I’ve never played with, so I don’t know first hand how TMG’s handling of sources compares to RM’s. As Tom already reported, RM’s facility can be pretty flexible and you are not forced to use the built-in templates. But it’s very easy to use the templates in such a way that they are very inflexible unless you are very careful. Just to repeat, even if you like RM’s source templates, NEVER USE THEM DIRECTLY – ALWAYS USE A COPY INSTEAD. It’s trivial to make a copy. Jerry

Family Historian appears to be developing its TMG import facility with a view to including TMG's Witness data. There is a post from the developer at http://www.gouldgenealogy.com/2014/09/family-historian-an-alternative-to-the -master-genealogist-tmg/ which makes interesting reading. Regards Mike James

John, your observations of the relationship between TMG 9.03 and RootsMagic 6.3 are very good, insofar as I know little about TMG and am considered by some to have expertise in RootsMagic, but by no means everything - I am repeatedly amazed at the ways that other users come up with to do unusual things. I will comment inline with your quoted message below. Tom On Thu, Sep 4, 2014 at 11:44 AM, John Nunnally via < tmg-refugees@rootsweb.com> wrote: > .... > - As has been well documented, absolutely no witness information is > exported > by TMG currently. Thus it is not imported. > Tom Giammo's WitnessTMG utility is so far the only way to get rudimentary witness info into GEDCOM. TMG 9.04 will do a better job but may not make everyone happy; it exports to GEDCOM extensions that RootsMagic uses for shared facts. RootsMagic's promised Direct Import should transform witness info to shared events, too. > -If you use any kind of data subdivisions like [M1], [M2] or [CD1], [CD2], > etc. your data comes across without interpretation, complete with > imbedded > "||"'s. It would be incumbent on TMG to interpret this kind of information > during the export process if its meaning is going to be preserved. > I would expect that you will be faced with much editing no matter which system you move to, whether by direct import or by GEDCOM, simply because there may not be a very good correspondence between these TMG features and other systems. At least the [..] characters should be easy to search for. > -- RM has two fields that represent all "Places". The labels from RM for > these two fields are: "Place (City, County, State, etc.)" and "Place > details (address, hospital, cemetery, etc.)". All TMG place fields get > concatenated together, separated by commas and exported as a GEDCOM > "place". > On import, this data is put in the "Place" field. "Place details" is left > unpopulated. > That is correct. I tested a build of RMpi last night that processed a TMG 9.03 GEDCOM to RootsMagic format with the exported TMG place fields parsed into RootsMagic Place, Place Details and Note for Place Details. It worked well with the Sample project. I see no reason why the future direct import should not also be able to do that mapping, given TMG's admirable structure for place info. Does anyone use Addressee, Postal Code, Phone, LatLong, Temple? I just gathered them into Note. There is correspondence between fields in RootsMagic and LatLong and Temple so perhaps the direct import will map them correctly. For those who choose not to upgrade to TMG v9, direct import is in the offing but over what range of versions remains unannounced. Some versions may only have GEDCOM as a means of data transfer; whether my RMpi utility is of any help on older versions awaits reports from those who may try it. > -- RM has a family structure. So when you have two principals for an event > such as a census record, it will be imported as a family "fact" if > possible. > There appears to be a lot of debate even among RM users as to whether the > family facts are the best approach for anything other than marriages. > While there are the essential "couple" facts (Marriage, Divorce, .. about 10) for which there is no Individual equivalent, there are only two other "family" fact types for which there are Individual equivalents: CENSus and RESIdence. There is debate over whether to use one or the other but the bigger question is sharing either with others... -- RM has the ability to define roles in what is called "shared facts". > They are nice but not as robust as the TMG role concept. Likewise the > "shared facts" do not export well, just as roles do not in TMG. In fact > many RM users avoid shared facts just as TMG users avoid roles and > witnesses > because of the export limitations. > Not as robust? I don't understand. Yes, that discussion is driven by GEDCOM compatibility when exporting for use in other applications. I have gone to the extent of developing outboard SQLite queries, also included in my RMtrix utility, that convert shared events to singular events in the database or a copy of the master database, either because someone wishes to abandon shared events or because they need to export something more compatible. > -- RM has a very robust sentence construction mechanism that I see as > easier > to use than TMG in some ways. But TMG and RM sentences are not compatible > and thus are not imported. It would take some nifty programming to build a > TMG to RM sentence translator, but it might be possible within limits. RM > sentences are defined for each "fact" and also for each role in a "shared > fact". > I agree. If conversion of TMG sentence templates to RM is at all possible, it would have to be done within the direct import, I believe. > -- The Description field in a RM fact is of limited length (90 characters, > I > believe) and its use seems to be up to the discretion of the user most of > the time (see below). RM sentences may refer to the Description with the > variable [Desc] but that is the only option. I.e. you either include the > entire description in one place in your sentence or you don't. > 100 characters on import only. Unlimited afaik in data entry or export, which is crazy, other than by the limited view through the data entry field. Think of it as a summary phrase that is embedded in the sentence for a fact in the narrative or in the Description field for a fact in a tabular report. Maybe it would be how you would use M1 in a memo field. > -- The Note field appears to be of arbitrary length, much like the Memo > fields in TMG, but RM memos do not support the use of any sentence > variables > to allow for automated note generation and there is no facility to include > Notes in RM sentences. > Correct. > -- Although RM has a "Narrative Report", it does not include the same > things > TMG narratives include. There are not as many options in RM to influence > the > formatting of the narrative. RM's report is intended to be a paragraph > about each person created from sentences followed by the contents of the > Note for each fact. It does have the option of putting the output from > each > "fact" in a separate paragraph, but that is about it. RM does work > similarly to TMG with the substitution of pronouns for names and the > sentence definitions do give you the opportunity to override the defaults. > RM does not include marriages in its narrative. Neither TMG nor RM include > births of children. > Not familiar enough with TMG to comment on the comparison but RM does include marriages and other "family" (couple) facts in its narrative after the Individual facts are narrated. Births are indicated in the next generation after the couple facts but not as an event within the individual's or couple's narrative. It does have a powerful Timeline view of an individual for review and editing which has the option to display within his/her lifetime the events of the parents, spouses, siblings and children. > -- RM allows you to define "Custom facts", similar to TMG. My custom tag > types imported but the sentence was always "Sentence needs to be defined." > Again, I don't know if it is possible to map TMG syntax to RM or any other. You open the Fact Type List and define a default sentence template for each custom fact type and custom role in order to eliminate "Sentence needs to be defined" and to get the sentence to be output to a narrative report. > -- RM supplies standard source templates based on Evidence Explained as > well > as other standards and you can define your own custom source templates > similar to TMG custom source definitions. But none of the definitions, > standard or otherwise, in TMG are translated on import. All TMG sources are > exported as "free form". Thus no source is recognized as a census > citation, > for example, and the definitions of the individual source elements is > completely lost. > Syntax and structure mapping challengea, at the very least, that no other software may be able to handle. But, if both based on EE, maybe there is hope for direct import. > > I have not done much with RM data export. For census information, the RM > Description field is output as an "Event descriptor" portion of the > standard > CENS GEDCOM tag. For example, "1 CENS Contents of Description field would > appear here". According to the documentation I have, I'm not sure that is > a > standard GEDCOM construct. The generic EVEN GEDCOM event tag is documented > to support an "Event Descriptor" but I see no indication that this > construct > is valid for other events such CENS or MARR, etc. So importing the > contents > of the description field here may not be generally supported. > Very dependent on the receiving software. > > For a Death fact, the Description field is output as a GEDCOM "CAUS" tag, > indicating the cause of death. Thus in this case the meaning of the > Description field is restricted if you intend to do GEDCOM exports. > Which may be the only fact type that exports a CAUS tag, although GEDOM allowed it for other event/attribute types. > > The NOTE field is output as a standard GEDCOM NOTE tag with subsequent CONC > tags as necessary. NOTEs are generally accepted in GEDCOM, and they should > export in just about all cases, I would think. > Right. > > As is so often the case, your mileage may vary... > > John N. > >