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. > >