Modified April 17, 2019 12:06 pm
Michael J. Hannah , Los Ranchos, NM.

TMG™ GEDCOM Export
Guide to Limitations and Issues ©MJH

NOTICE/DISCLAIMER: This document is not authorized or official TMG documentation. Instead see the embedded “ Help ” facility within your version of the program. I do not warrant in any way that the contents are accurate or useful, and any use of them is at the user’s own risk.

Any errors are undoubtedly mine. Corrections and suggestions can be addressed to me and posted on the TMG Mailing List hosted on Rootsweb where other TMG users may see them and comment.

Overview

These notes primarily cover advanced use of TMG and GEDCOM. I believe if TMG users only do the basic Birth, Death, Marriage, one set of parent/child relationships, and one-Principal events, with basic sources, their exports should be clean and simple. Further, whether they will care about these advanced issues will greatly depend upon the purpose of their export. If the user is providing the GEDCOM to some importing destination which will only accept basic information, then these notes are probably of little interest.

My following notes about TMG GEDCOM export issues are based on my testing through the final TMG Version 9.05. Most of my testing was done exporting to GEDCOM 5.5, which I recommend. Users are urged to test and verify any output from their own TMG projects. With the possible exception of some past bug fixes and the Enhanced Export Option, I believe most of these notes apply to GEDCOM exports from Version 7.04 to the present and probably before that.

Contents

This article is in two sections: basic GEDCOM export issues:

Limitations, ID Numbers, Names, Dates, Places/Locations, Two-Principal Tags, Relationship Tags, Citations, Sources, Repositories, Tag Names, Exhibits, My Export recommendations, Character Sets

and an Enhanced Export Option introduced in Version 9.04:

Address/Telephone, Note/Name dates, Sort dates, Witnesses, Surety, Repository detail, Lengthy descriptions

GEDCOM Versions

GEDCOM (an acronym standing for Genealogical Data Communication) is an open de facto specification for exchanging genealogical data between different genealogy software. GEDCOM was developed by The Church of Jesus Christ of Latter-day Saints (LDS Church) as an aid to genealogical research. Version 1.0 was originally specified in 1984. TMG export will only create GEDCOM files based on either Version 4.0 (specified in 1989) and Version 5.5 (specified in 1995). A Version 5.5.1 specification was released in late 1999 which enhanced Version 5.5 with nine new main GEDCOM tags, several new GEDCOM subtags, and other changes. Most current genealogical programs provide import and export based on this updated specification, but neither the standard TMG GEDCOM export nor the Enhanced Export added to TMG in 1994 are based on it. Since the GEDCOM export tag type for a custom TMG tag type can be set on the Other tab of the Tag Type Definition screen users may mistakenly believe they could specify a GEDCOM tag type for export new to Version 5.5.1. But since that name will be an undefined or unallowed GEDCOM tag type in either of the two GEDCOM Versions able to be specified for the TMG export, TMG will not export any tags of that TMG tag type. Thus all comments below are restricted to those two GEDCOM versions.

Basic GEDCOM Export Issues

Output Limitations

The TMG export wizard provides options for some types of information to select whether that data will be exported. If data begins with an exclusion mark ‘-’ it will not export unless that option is set, but the TMG tag will still generate a GEDCOM tag. For example a TMG Note tag which only has an excluded memo will generate a completely blank GEDCOM NOTE tag. However, if the export option “Show Excluded Data” is selected, the output will include the leading dash. Data that begins with double exclusions or data within text marked [HID:][:HID] is never exported. ¹ All parts of split memos ² are exported complete with their double bars, even if a particular part other than the first is marked with single or double exclusion marks. Sensitive data (text surrounded by sensitivity braces ‘{‘ and ‘}’) will only export if that option is selected, and the braces will be stripped unless requested to remain by selecting the export option “With Markers”.

All embedded text format codes (e.g. [ITAL:]text[:ITAL], [BOLD:]text[:BOLD], etc.) as well as the HTML format codes (e.g. [WEB:]url;text[:WEB], etc.) are removed and not exported, but the text within them is exported. See below concerning the embedded citations codes.

Beginning with TMG Version 5, options were introduced which permitted selecting a subset of individuals within a dataset by first selecting a dataset, then selecting a subset of individuals that is defined either in the Project Explorer or in a saved Focus Group.

Regardless of which Place fields are selected for export, the export uses only the following fields of a Repository: Name (Other); Place: Detail (not Addressee), City, State, Postal, Country, and Phone; and the Repository memo. A full GEDCOM repository record output from TMG will be:

0 @R1@ REPO

1 NAME Repository Name Other

1 ADDR Repository Place Detail

2 CITY Repository Place City

2 STAE Repository Place State

2 POST Repository Place Postal

2 CTRY Repository Place Country

1 PHON Repository Place Phone

1 NOTE Repository memo

The GEDCOM specifications identify maximum allowed text lengths for each of these fields as:

NAME - 90

ADDR - 60

CITY - 60

STAE - 60

POST - 10

CTRY - 60

PHON - 25

NOTE - essentially unlimited

The GEDCOM specifications generally expect an ADR1 tag subordinate to the ADDR tag similar to City, State, etc. data as the location of the address detail, but TMG places this data directly on the ADDR tag. (See also the Version 9.04 Enhanced Export Option below.) An ADR1 tag has the same maximum field length as the ADDR tag. TMG will export to the length it allows as input up to the maximum specified GEDCOM line length. Importing programs are within their rights to not allow longer text and/or to truncate any data in these fields to these maximum lengths.

While an ATTR tag existed in GEDCOM 4.0 which could be used for custom flag values, in GEDCOM 5.5 the ATTR tag no longer exists. The only other option is the GEDCOM ATTRIBUTE_TYPE, but that is now a fixed list. As such, TMG Flags are not exported.

Certain project/dataset information is not exported. The dataset file name could be under HEAD as the GEDCOM FILE tag. Also the full name of the TMG project could be in a NAME tag subordinate to SOUR in HEAD . The contents of the user’s dataset memo ( .DOC file) could be exported as a NOTE tag under HEAD . However, none of this is exported by TMG.

ID Numbers

TMG exports its ID number of the individual in the TMG dataset as their GEDCOM INDI number in the output file. That permits a direct correlation between the GEDCOM file and the original dataset. Some importing programs will use the GEDCOM INDI number as the ID number of the record created from the GEDCOM file. However, if there are gaps in the sequence of TMG ID numbers, some importing programs may have problems with the missing numbers or give errors. The GEDCOM specifications require the INDI number to be unique within this file, be surrounded by the at-sign character ‘@’, not begin with a number sign ‘#’, and not contain either a colon ‘:’ or exclamation ‘!’ character. If your project has multiple datasets the displayed TMG ID number usually is preceded by the dataset number and separated by a colon, e.g. (2:94). Since you can only export from one dataset at a time, and the INDI number cannot contain a colon, the dataset number is not exported as part of the GEDCOM INDI number, e.g. @I94@. For additional output of those TMG ID numbers see my GEDCOM recommendation number 5 below.

Names

The GEDCOM specifications define the construction of the entire name which is required to be on the GEDCOM NAME tag entry as:

1 NAME <TEXT1> /<TEXT2>/ <TEXT3>

These specifications state that TEXT2 is identified as the entire Surname since it is between slashes. Any of the three parts can be empty/missing but the slashes are expected. While TMG will infer empty name fields from the Primary Name tag for its reports, whether blank name fields in the GEDCOM output are inferred depends upon the “Name NPFX/NSFX” TMG Export option. If the GEDCOM Export option “Name NPFX/NSFX” is not checked, the subordinate namepart records for the NAME tag are not created, but if either TEXT1 or TEXT2 would be empty the NAME tag will include all inferred values for that otherwise empty field. ³ With the GEDCOM Export option “Name NPFX/NSFX” checked, no name fields are inferred even if TEXT1 and/or TEXT2 would be empty, and TMG will separately export up to six non-empty subfields from a TMG Name tag as:

1 TITL titlefield

1 NAME prefixfield givenfield /presurnamefield surnamefield/ suffixfield

2 NPFX prefixfield

2 GIVN givenfield

2 SPFX presurnamefield

2 SURN surnamefield

2 NSFX suffixfield

When constructing the complete name for the GEDCOM NAME tag the TMG Export combines the prefix and given in TEXT1 separated by a space, combines presurname and surname in TEXT2 separated by a space, and only puts the suffix in TEXT3 .

Although defined in GEDCOM, even if the TMG Name-Var tag is Name-Nick, TMG does not export anything into the NICK GEDCOM namepart. Neither the “OtherName” field, nor either of the sortname fields are exported. ⁴ If the TMG Name tag has a memo or citations these will export to GEDCOM. But the GEDCOM NAME structure does not define a DATE namepart, so the TMG Date field will not export. (See also the Version 9.04 Enhanced Export Option below.)

While the GEDCOM specifications allow multiple NAME tags for an individual, they include no mechanism to assign a specific NAME tag to be associated with a specific event. Thus this linkage feature in TMG is lost on export.

TMG “Title” Name Field

Regardless of the setting of the GEDCOM Export option “Name NPFX/NSFX”, the TMG “Title” Name field does not export as part of the GEDCOM NAME structure. Instead that TMG Name subfield always exports to a separate GEDCOM TITL tag. While GEDCOM does define a TITL tag type, that TITL event GEDCOM structure originally was designed to record the event upon which the title was granted. None of the TMG’s structures can produce a full GEDCOM TITL event structure, as the export of both TMG Name tags and Event tags have export limitations. A TMG Name type tag has no option to enter a Location so cannot export it, and the GEDCOM NAME tag has no option to include a DATE . (See also the Version 9.04 Enhanced Export Option below.) A TMG Event type tag can have both a Location and a Date, but it will export the entire memo even if split as the TITL value, so cannot export a separate memo.

A TMG custom Title-Event tag type in the Other group with a memo limited to the text of the title, and its TMG GEDCOM Export tag type set to TITL , would export closest to the defined intent of the GEDCOM TITL tag type. But such a custom event will have no recognition in TMG as being part of a name. As the Date (might be included by the Enhanced Export) and Location might be included as text in the memo, a Name-Title tag type in the Name group which only includes the Title text seems the best compromise for both TMG use and GEDCOM export.

If the GEDCOM Export option “Name NPFX/NSFX” is checked and there is data in more than the TMG Title field, both a GEDCOM TITL and a NAME tag will be exported. ⁵ The TMG Title field is exported as the GEDCOM tag TITL but that TITL tag will not include the memo and/or citations. The separate NAME tag will include the other name fields and any memo and/or citations. A TMG Name tag that only has data in the Title field will export only a TITL tag for the Title field text which will include the memo and/or citations.

If the GEDCOM Export option “Name NPFX/NSFX” is not checked and there is data in more than the TMG Title field, both a TITL tag and a second tag (either a NAME or another TITL tag) ⁶ will be created, both will contain the memo and/or citations, and the second tag will have inferred name values. Even when the option is not checked, a TMG Name tag that only has data in the Title field will export only a TITL tag for the Title field text which will include the memo and/or citations.

Dates

For both export and import there is a one-to-one relationship of the TMG standard date modifier codes and a GEDCOM date modifier as follows:

*The date format of EITHER OR is not defined as valid in the GEDCOM specifications. However, this GEDCOM format is what TMG’s final Version will produce on Export from its Or Date format, and TMG will convert that format upon Import to its Or format. Hopefully another program will either accept this format on Import or at least produce a message indicating an invalid format.

There are two additional legal GEDCOM date forms which are not exported by TMG's standard date codes: CAL and INT . However, TMG's irregular date format can accomodate the export of those two GEDCOM date forms, up to the maximum of 29 characters allowed in TMG's irregular dates. For example, a TMG irregular date of exactly:

CAL 1901

will export as the standard GEDCOM CAL (calculated mathematically) date form:

2 DATE CAL 1901

A GEDCOM INT date means “interpreted from knowledge about the associated date phrase included in following parentheses”. Since a TMG irregular date is limited to a maximum length of 29 characters, a meaningful phrase, complete with parentheses, can often be difficult. However, the TMG irregular date of:

INT 1901 (Fourth George R)

will export as the standard GEDCOM INT (interpreted) date form:

2 DATE INT 1901 (Fourth George R)

Places/Locations

Most TMG Master Place Records are exported the same way, duplicated as part of every tag to which that place record is linked. (But places linked to a TMG Repository Definition are exported very differently as described below.) The export creates a GEDCOM PLAC record subordinate to the GEDCOM record for that tag. On the TMG Export Wizard option screen for “Reference field, exclusion and place choices”, which fields to export from a linked Master Place Record can be specified. But this option applies to the export of all place records regardless of its TMG Place Style. All the selected fields will export in the TMG heirarchy order (L1 thru L10) as the comma separated text of that subordinate GEDCOM PLAC record. I highly recommend selecting the option “Commas When Missing”, otherwise it will be impossible to tell in a PLAC record what text originally came from which TMG place field.

Two-Principal Tags

The GEDCOM specifications only define two types of records associated with people: Individual records and Family records. There is no definition of a general “two-person” record. Family records are used to describe “marriages, common law marriages, and family unions caused by two people becoming the parents of a child”. A Family record is created for the two individuals being designated as explicitly married or share parenting a child, and the two individuals are identified by the HUSB and WIFE entries in the GEDCOM Family record. “The family record structure assumes that the HUSB /father is male and WIFE /mother is female.” Family events within the GEDCOM Family record thus are shared by these two individuals. Individual records are “a compilation of facts, known or discovered, about an individual”. Individual events within the GEDCOM Individual record apply only to this one individual. TMG tags can only be exported as an event within one or the other of these two types of records. Either the event must be within a Family record relating to both the “husband” and “wife” of the “family union” or within an Individual record associated with only one person. This is the explicit design of the GEDCOM 5.5 specs. Only family events are defined by the GEDCOM specifications as relating to two Principals, all other GEDCOM events have no mechanism defined for anything but one Principal. (See also the new Enhanced Export option below for a custom mechanism to link Witnesses to an event.)

If the two Principals assigned to a TMG tag are married or share parenting a child, and the export GEDCOM event type for that TMG tag type is defined as an expected or potential Family event (see the list of GEDCOM event types below), then the TMG tag will be exported as an event within the Family record of that family union. Such tags will not be exported as part of the Individual records of either of the two Principals.

If the two Principals are not married nor share parenting a child, and the export GEDCOM event type is defined as an expected or potential Family event, the tag is not exported in any way. TMG excludes the entire tag from the GEDCOM output. ⁷

TMG tag types with only one Principal set to export as an expected or potential Family GEDCOM tag type involve special conditions. Some GEDCOM tag types are expected to be GEDCOM Family events and have two Principals, such as the default export of standard tag types in the TMG Marriage and Divorce groups plus Annulment. Some GEDCOM tag types potentially can be either Family events or Individual events. TMG appears to deal with such one-Principal tags differently depending upon their group.

• Standard one-Principal TMG tag types which are set to export as GEDCOM tag types expected to be GEDCOM Family events will still export as a Family event in a GEDCOM Family record which identifies only that one spouse.

• Custom one-Principal TMG tag types which are set to export as GEDCOM tag types expected to be GEDCOM Family events will not export.

• A one-Principal TMG tag type which is set to export as a GEDCOM tag type which potentially can be either a Family event or an Individual event will export as an Individual event.

If the export GEDCOM event type for that TMG tag type is defined as a strictly Individual event (see the list of GEDCOM event types below), then the TMG tag will be exported regardless of the relationship of the two TMG tag Principals and regardless of the number of Principals. If there are two Principals, the single TMG tag will become two GEDCOM Individual events, a duplicate created within each Principal’s Individual GEDCOM record. However, any indication of a linkage of the two Principals to this identical event is lost in the GEDCOM output.

TMG tag types set to export to GEDCOM as 1 EVEN 2 TYPE deserve special mention. EVEN is a catch-all name for “event” and is the default GEDCOM export tag type for custom tag types in TMG. The TMG tag type Name is the fixed value to output in that GEDCOM event’s TYPE field. ⁸ Since 1 EVEN 2 TYPE events are among those which are potential Family events, the export actions for those types of events apply. Thus if there are two Principals who are married or share parenting a child, the tag will export as an event within a Family record. If the two Principals are neither, the tag will not export. If there is only one Principal, the tag will export as an Individual event.

Whatever the situation with the Principals, the GEDCOM export tag type for a custom TMG tag type must be set on the Other tab of the Tag Type Definition screen either to a existing allowed GEDCOM tag type, or to the generic 1 EVEN 2 TYPE event type. If the TMG export option is explicitly set to a named but undefined or unallowed GEDCOM tag type, that TMG tag type will not export.

With the ability to output Witness links using the new Enhanced Export option, users may wish to change the linkage of one of the two “non-family” Principals to be a Witness to the tag instead of a Principal using an appropriate role. With that change the linkage of both individuals to this one GEDCOM event will be retained within the enhanced GEDCOM output. A List of Events report can identify all TMG tags in a project which have two Principals with a filter like:

Principal1... // ID # // <> Does not equal // 0 // AND
Principal2... // ID # // <> Does not equal // 0 // END

I suggest including in the report’s output columns the Column Types of “Tag Type Group” and “Tag Type Label” as the first two sort fields, along with at least “Prin1 ID” to identify the specific tag. With this report sort, those tag types which are expected to be GEDCOM Family events and have two Principals (such as those in the Marriage and Divorce groups plus Annulment) can be quickly identified. The TMG tag types which potentially might be accepted as GEDCOM Family events (depending upon the two Principals being married or parenting a child) are any TMG tag types which output as 1 EVEN 2 TYPE plus those with a default GEDCOM tag type which is identified as both an Individual and Family event in the list of GEDCOM tag type names below. These standard TMG tag types include by default: Anecdote, Association, Census, Event-Misc, History, HTML, Illness, JournalConclusion, JournalIntro, Living, Military-Begin, Military-End, NarrativeChildren.

Relationship Tags

There are several export limitations concerning relationship tags. TMG will only export Primary relationship tags. Neither the memo nor the citations on the Primary relationship tags will be exported. While GEDCOM 5.5 has no structure for citations directly on its relationship tag types (i.e FAMC or FAMS ) so none are exported, it does have the capability to include a memo/note, but TMG does not export it. ⁹ Further all primary relationship tags will be exported as if they are birth/genetic relationships, regardless of the TMG relationship tag type. Although the GEDCOM 5.5 definition of the FAMC tag structure allows the nature of that entire family relationship (implying both father and mother) to be defined as one of four types using a PEDI qualifier tag (defined values: adopted, birth, foster, sealing), TMG does not use the PEDI qualifier on export. ¹⁰

No non-primary relationship tags will be exported ¹¹ even though the GEDCOM 5.5 standard does define a method to allow a child to be linked to multiple family structures using multiple GEDCOM FAMC tags. However GEDCOM considers all of those linkages to be (potential) biological relationships.

Citations

First, TMG will only include in the export those sources linked to some person or tag which is exported, and those repositories which are linked to exported sources. If the source is not cited, it is not exported. As specified in TMG HELP: “If the citation detail is split, only CD1 is exported.” Further CD1 is placed in the GEDCOM PAGE subtag under the SOUR tag reference. The GEDCOM specification limits PAGE text to a maximum of 248 characters. One Wholly Genes Forum post suggested choosing to restrict one’s memo data entry use to CD2 through CD9 for TMG output template purposes. Then with the Citation Preview option ¹² one could copy the created Full Footnote text and paste it into CD1. That way the TMG templates could be used, but the Full Footnote text (if it did not exceed 248 characters) would export to GEDCOM.

Since GEDCOM has no subtag for a Citation Reference, if the Export options specify to output the Citation Reference TMG will export it in the GEDCOM PAGE subtag following the Citation Detail text which is in that GEDCOM subtag separated by a semicolon. The combined export may still be limited to the maximum of 248 characters.

The entire citation memo will be exported to GEDCOM in a NOTE subtag, possibly with continuation lines, under the SOUR tag reference. If the citation memo is split, all parts including the separator bars will be exported. If the CM is not otherwise used in TMG source templates, the Full Footnote preview text could be copied and pasted to that TMG field for GEDCOM export.

Any embedded citation which is included in a TMG Tag Memo will not export. All the text between the embedded citation codes, including the codes, will not appear in the GEDCOM NOTE tag, nor will there be output a source citation to that source.

There is an option in the Export Wizard to export citation Surety values to GEDCOM. ¹³ I don’t use Surety so have not extensively tested this feature. However, the QUAY tag produced by this option can only accept one integer value, and the only values defined are 0, 1, 2, and 3. TMG will export only the P1 Surety as the QUAY value, and will not export a QUAY tag if the P1 value is either blank or a minus sign ‘-’. (See also the Enhanced Export option concerning Sureties.)

Sources

The GEDCOM citation points to a separate GEDCOM source record structure which is considerably more limited in capability than TMG Source records. There are only five main GEDCOM elements in the SOUR record to contain all the actual data about the source, plus a few elements in the REPO record. In contrast TMG has 31 different Source Element Groups which can contain variable data about the source and repository, although a single source can only include 23 of those elements.

In some cases the TMG Source Element name/alias used in this source definition can output, plus there can be additional fixed data entered as text output from the source templates. ¹⁴ TMG attempts to squeeze all these 31 elements and these names/aliases into the limited GEDCOM source elements. Numerous alternate names/aliases for a TMG Source Group can be defined, called Source Elements. But for all groups there is one standard Source Element name which is essentially identical to the name of the Source Element group. That name is used for clarity in the table below, but the Source Element alternate name/alias is in some cases output also as text in that GEDCOM field.

The TMG fields potentially exported into each GEDCOM SOUR record field are listed below. Multiple TMG fields output into a single GEDCOM field are output in the order shown , separated by commas unless otherwise specified. Fields marked with ^SE below are output preceded by the TMG Source Element name/alias used in that source definition ending in a colon. When multiple fields could output in a single GEDCOM field, any fields whose text contains commas and/or colons can make it difficult to tell when one field ends and another begins. Fields which are not marked with ^SE below and thus are not identified by their Source Element name make it especially unclear whether the text is from such an additional field, or was simply part of the text being output from the preceding TMG field. Since any field not marked with ^SE below does not output it’s alternative Source Element names/alias, such names will be lost in the GEDCOM export. If a GEDCOM field can contain multiple fields and the first or only field output is marked with ^SE below, the field will begin with that name/alias.

ABBR

Abbreviation (if no Short Title); otherwise Short Title, Short Subtitle (separated from a Short Title by a colon, not output if no Short Title)

TITL

Abbreviation (only if otherwise empty), Title, Subtitle (separated from a Title by a colon), Record Type ^SE , Subject ^SE , Second Person ^SE , Location ^SE , Second Location ^SE , Series ^SE , Edition ^SE , Volume ^SE , Version ^SE , Pages ^SE , File Reference ^SE , Film Number ^SE

AUTH

Author, Compiler ^SE , Editor ^SE

NOTE

Comments

PUBL

Publisher, Publisher Location, Date, Second Date (Source Element name is separated from the date by a comma)

CALN

Repository Reference

Repositories

If a TMG source definition has a repository linked on its Attachments tab, that GEDCOM SOUR record will in turn point to a separate GECOM REPO record which will export the details of the one TMG Repository linked as primary. If multiple repositories are linked to this source, only the link to the primary is exported. A Repository definition will only be exported if it is linked as primary to some source which is exported. If the TMG “Name-ID #” field in the repository definition has an ID number of an individual as the repository, the REPO subfield of the SOUR record will link directly to that individual's GEDCOM record. A separate GEDCOM REPO main record is not created for such a Repository Definition, so anything else entered in any field of that TMG Repository Definition is lost in the export. A Repository Abbreviation is never exported, even if the Name-Other is empty.

NAME

Repository Name-Other (if that field is empty, the word “unknown” is output as the name)

ADDR, CITY, STAE, POST, CTRY, PHON

Non-empty TMG address fields L2, L3, L5, L7, and L8 from the repository definition. If non-empty only these will be exported, and there is no option to export more or fewer place fields. (See also the enhancements to the Repository Detail place field when the V9.04 Enhanced GEDCOM Export option is used.)

NOTE

Repository Memo

GEDCOM Tag Names

Many standard TMG tag types are set to export as a specific GEDCOM tag name which is not included in the strict GEDCOM 5.5 specification. Even though they are the TMG export default, none of them (marked with the superscript ^NO in the table below) will export since the GEDCOM tag type is unrecognized. All of their event data will be lost on export if their GEDCOM export tag type is not changed to a recognized name, or to 1 EVEN 2 TYPE . Because I generally prefer to strictly adhere to the GEDCOM 5.5 definition as well as try to avoid loss of data, I usually modify such TMG Tag Types in the Other tab of the Tag Type Definition to avoid its unrecognized tag name and use the general purpose 1 EVEN 2 TYPE structure for GEDCOM export:

1 EVEN

2 TYPE TMG-tag-name

Any program accepting GEDCOM 5.5 should accept these generic definitions as custom events. This is also the only mechanism to retain a custom TMG tag type Name. If multiple TMG tag types are set to export to the same specific defined GEDCOM tag name, their different original tag type Names are lost.

Some standard TMG tag types export to a defined GEDCOM tag name, but do not or cannot export all the data which may be stored in the TMG tag type. A major example is the TMG Note tag type, which by default exports as the defined GEDCOM NOTE tag type. The entire memo will export as the text on the NOTE tag with possible CONC tags if necessary. But neither the Date nor the Location will export. (See also the Enhanced Export option below for custom output of the Date. That produces tag names with a leading underscore character, which is the naming method defined by the GEDCOM specification to identify a non-standard tag name.) I also recommend these GEDCOM export tag types specified in the table below be changed to 1 EVEN 2 TYPE so that all the TMG data will export. However, be aware of the affect this may have on such tags if assigned two Principals as described above.

Default GEDCOM export tag names

The following table lists the TMG Tag Types which are included in a “New” project ¹⁵ and the default GEDCOM tag type which they are set to output by default. Projects upgraded from earlier versions may have older and thus different defaults. The Notes in the table below indicate whether this GEDCOM tag type is a standard tag type defined in GEDCOM 5.5.

GEDCOM Family events generally assume/require two Principals who are either married or share parentage to a child. See the comments above about two Principal events.

Any TMG tag type, standard or custom, whose GEDCOM Export option is set to export as a TMG recognized Individual GEDCOM Attribute event can be affected by the TMG Export Option “Extract recognizable memos as tags”. If this option is not selected, the tag will export according to the GEDCOM tag type set in the TMG Tag Type Options. But if this option is selected and TMG recognizes the first word of the tag memo as one of TMG’s recognized Individual GEDCOM Attribute Event names followed by a colon, then TMG will export using that GEDCOM tag name instead of the GEDCOM tag type specified for this TMG tag type. (Unfortunately the two Individual GEDCOM Attribute event names which do not have defined TMG tag types, INDO and PROP , are not recognized in the memo by use of this export option.) ¹⁶ All the memo text following the colon will output, using GEDCOM CONC lines if necessary. Any blanks immediately following the colon are stripped. Historically this feature was introduced to deal with data imported from early PAF versions where "tags" were recorded in memo fields in the form: TAGNAME: data . Since both the GEDCOM export tag type specified for this TMG tag type and the tagname in any memo using this option must be recognized Individual GEDCOM Attribute event names, there now seems little value to this option. For example to create an Individual GEDCOM Attribute Event of NATI, a custom TMG “MyTag” tag type simply needs to be specified to export as the recognized Individual GEDCOM Attribute Event NATI. If the option is not set the GEDCOM tag will use the TMG tag’s memo as the data. However if this option is set, “MyTag” might be specified to export as the recognized Individual GEDCOM Attribute Event DSCR. But if the memo of a tag of that type begins with the text: NATI: text , a DSCR GEDCOM tag will not be output. Instead a NATI tag will be output as:

1 NATI text

The output of a different GEDCOM tag type than what is specified for that TMG tag type can be confusing. This option might be useful in conjunction with the TMG tag type “Attributes” since its default GEDCOM export tag type is unknown. One could specify some recognized GEDCOM Attribute Event such as DSCR for its GEDCOM export tag type. Then one could always enter TAGNAME: data in the memo of this TMG tag type, and setting this option would produce whatever GEDCOM Attribute Event tagname was desired. However, this seems unnecessarily indirect and does not seem to work in all cases.

The TMG tag types marked in the table below with a superscript ^LDS will be hidden if the “Show LDS tag types” option is unset on the Master Tag Type List. As mentioned above, the TMG tag types whose GEDCOM tag type is marked with a superscript ^NO should be changed to export as the generic GEDCOM 1 EVEN 2 TYPE tag type since TMG will not export the tag type as there is no defined GEDCOM tag type of that name. The TMG tag types marked with a superscript ^# should be used with caution as some of the TMG event information will be lost on export. They also may be good candidates to export as the generic GEDCOM 1 EVEN 2 TYPE tag type. The two standard GEDCOM event tag types CHRA and CREM which have no standard TMG tag type are good candidates for creating a TMG custom tag type with its export set to that name.

Exhibits

I have not done extensive testing of the GEDCOM export of exhibits, either internal or external, as I do not choose to export exhibits to GEDCOM. (If I get a chance to do such testing I may update this article in the future.) One type of exhibit I have tested are internal text exhibits, which are not exported by TMG either attached to events or to sources. Exhibits is one of several areas in the GEDCOM specifications which is open to interpretation in how they should be represented. The specification does provide for “multimedia objects” within a GEDCOM file which are to be “encoded” as a “Blob”, but also has a rather short maximum record length for them. Since the GEDCOM file is primarily intended to be a text file, due to the ambiguity of the specification, and because exhibit files are often very large, I have found this an area which programs commonly do not implement.

I suggest it would be safer and more reliable to transfer exhibits separately as their original file types, rather than rely upon an uncertain GEDCOM “encoding” and “decoding”. Users also might consider John Cardinal's TMG Utility to convert all their TMG internal image exhibits to external ones to make such a separate transfer easier. The only method I have used to export internal text exhibits from TMG uses the “Export” feature in the TMG Utility to export the Exhibit Log. Although that produces a single file of all the exhibits, it could be post processed. While I have not personally tried it, the documentation for Bryan Wetton’s program PathWiz! suggests it can create external text files from TMG’s internal text exhibits.

My GEDCOM export recommendations

Even with the Enhanced Export option mentioned below, I do not recommend using GEDCOM to transfer your TMG data to another program if it can be avoided. Whenever possible a program which will directly import the data from the TMG project files themselves is likely to do a better job. By exporting to GEDCOM, too much is likely to be lost or require considerable post import cleanup. However if GEDCOM is the only option, the following may improve the ability to later import the GEDCOM file:

1) Use the Enhanced Export option if you are using Version 9.04 or later.

2) Set the GEDCOM export option to 1 EVEN 2 TYPE for all the TMG tag types which you use and are described in the above listing of GEDCOM Tag Names as having export issues. That export setting will insure that all data for such TMG tag types including dates and citations are exported as custom events. However, be aware of the affect this may have on such tags if assigned two Principals as described above.

3) Use the Secondary Output on a List of People report to change all Ancestor Interest (ANCI) and Descendant Interest (DESI) TMG Flags to 0 before export. Use a copy of your project to do this if these flags are useful to you in TMG. As these Flags are generally not recognized by other importing programs, this will remove numerous messages concerning them from an import.

4) When you select Surety export, do not select the SOUR sub-option. For some importing programs these extra tags cause problems. If you select the Enhanced Export option, this SOUR sub-option will be disabled as it will interfere with the custom export of TMG surety information.

5) In Step 5 of the TMG Export Wizard you can select the TMG ID numbers (the number assigned to each person in a data set) to export. As mentioned above, the GEDCOM INDI number will already be the TMG ID number. If this option is selected, the TMG ID Number (without any dataset number) also will be exported in a separate standard GEDCOM REFN tag as the tag following the GEDCOM INDI tag for that individual.

This option may be of use if the importing program does not use the GEDCOM INDI number as that individual’s ID number in the constructed dataset. Most importing programs will retain the GEDCOM REFN data, so this option at least should allow you to see the TMG ID number in such importing programs. In Step 7 of the Export Wizard you could specify that the TMG Reference field be exported also in a standard GEDCOM REFN tag. That REFN tag will be output in addition to the one specified for the TMG ID number.

6) Also in Step 5 you can select the character set to be used. TMG only provides the options of (ANSI, ANSEL, IBMPC) and defaults to ANSI which is the character set used by TMG’s underlying software. ¹⁷ However, the GEDCOM 5.5 specification only allows three specific character sets (ANSEL, UNICODE, ASCII) and expects ANSEL. ¹⁸ These character sets all differ in how they represent upper range special characters (the characters from 128 to 255). I have not fully tested whether such special characters will output differently within the exported file by specifying either of the other two character sets in TMG’s export. Unfortunately if the TMG export specifies ANSI, some software packages will not import such a file. All GEDCOM files specify the character set used to generate the file on an internal GEDCOM tag near the beginning of the file, e.g.:

1 CHAR ANSI

Users have reported simply changing that name of the character set in that line in the file using a text editor to be one of the allowed GEDCOM values so that the file will import. It is not clear whether changing this character set name will affect how a specific importing software will deal with or change these upper range special characters. I recommend leaving the TMG export option as ANSI but changing the character set “name” in the resulting GEDCOM file to “ANSEL” if your importing software objects to ANSI. The user should review how the importing software now displays such upper range characters.

7) Set the GEDCOM line length to TMG’s maximum line length of 246. This will minimize data loss on created GEDCOM tags where the GEDCOM CONT/CONC continuation tags are not allowed or are limited to only one continuation line.

Version 9.04 Enhanced Export Option

As of Version 9.04 a new Option in Step 5 of the GEDCOM export wizard was added:

[ ] Enhanced GEDCOM tag export (see Help)

As described in Version 9.04 and the final Version TMG HELP, when this option is selected a number of additions are made to the GEDCOM export. Unless explicitly mentioned as part of this enhanced export option, all the conditions described above regarding what data is exported to a GEDCOM file are unchanged whether or not this option is selected. For example, for a TMG tag with two Principals to be exported as a GEDCOM family record, the two principals still must be married or must be the parents of one of more children (or both). And TMG Tag Types set to export as one of the above-listed non-existent GEDCOM tag names instead of as 1 EVEN 2 TYPE will still not export.

Address and Telephone tags

As described above, by default these two TMG tag types are set to export as the non-existent GEDCOM tag types of ADDR and PHON . If these tag types, or any custom tag types, are still set to export this way, this option will export the tags as the custom GEDCOM tag types of _ADDR and _PHON .

Dates in Note tags and Name tags

If the TMG Note tag type, or any custom tag type, is set to export as the GEDCOM tag type of NOTE , dates will be exported as a custom GEDCOM subtag under the NOTE tag:

2 _DATE date

TMG Name tag types should always have the GEDCOM export selection set to NAME , and with this enhanced option dates associated with these tags will be exported as the custom GEDCOM subtag:

2 _DATE date

For some import programs in order for this date data to be recognized as dates, these custom GEDCOM subtags for either the NOTE tags or NAME tags may need their tag names edited after export in the GEDCOM file to the standard GEDCOM tag name format by removing the leading underscore character in the custom tag name.

Sort dates

Sort dates are an advanced TMG feature. While they always exist within TMG, they can only be explictly entered/modified when in TMG’s Advanced (versus Beginner) edit mode. This enhanced export option will export these sort date values as a custom GEDCOM tag type following any tag’s standard DATE tag or any custom _DATE tag added by this enhanced export option.

2 DATE date

2 _SDATE sort date

or

2 _DATE date

2 _SDATE sort date

Witnesses (those individuals not linked to tags as Principals)

A linkage to another individual who is a witness to this Principal’s TMG event tag, the witness’ TMG rolename , and any entered Witness memo specific to that witness now can be exported. The output will be a custom GEDCOM subtag _SHAR within that event’s GEDCOM structure with two subtags: a non-standard use of the standard GEDCOM ROLE subtag plus a standard NOTE subtag. The _SHAR tag will point to that witness using their INDI, the ROLE tag will contain the TMG rolename assigned to that witness in this tag, and the NOTE tag will contain their TMG witness memo. Since both the ROLE tag and the NOTE tag are subordinate to the custom _SHAR tag type, a custom use of these two subtags is implied. As an example, partial export output from a TMG Census event tag might be:

1 CENS

2 DATE date

2 _SDATE sort date

2 _SHAR @I2@

3 ROLE rolename for I2

3 NOTE I2 witness memo

2 _SHAR @I13@

3 ROLE rolename for I13

3 NOTE I13 witness memo

In the above example the numbers @I2@ and @I13@ point to the individuals with those GEDCOM INDI numbers in this GEDCOM file. As mentioned concerning ID numbers, they also are the TMG ID numbers of these individuals. As mentioned concerning NAME tags, there is no GEDCOM mechanism to assign a specific NAME tag to be associated with a specific event. Thus linkage of a particular NAME for this witness to this tag is lost on export.

Surety

TMG surety has many more values and indications than defined in the standard GEDCOM QUAY feature. This enhanced export option will add a NOTE tag as part of the GEDCOM SOUR citation record following the GEDCOM QUAY tag. The NOTE data will contain all of the TMG surety data for the citation.

3 QUAY 3

3 NOTE {TMG Surety 3.12.}

The five values will reflect the TMG surety values currently assigned to this citation. Consistent with TMG’s display of surety, periods will be used as filler values for blank surety values.

Repository Detail Place Field

As described above, the Repository Place Detail is output by TMG on the GEDCOM ADDR tag. With this enhanced export option this data will be duplicated in an ADR1 tag as follows:

1 ADDR Repository Place Detail

2 ADR1 Repository Place Detail

2 CITY Repository Place City

2 STAE Repository Place State

2 POST Repository Place Postal

2 CTRY Repository Place Country

1 PHON Repository Place Phone

1 NOTE Repository memo

Lengthy Descriptions

The main TMG tag memo text for the standard Caste, Descriptn (or Description), Education, Occupation, and Religion TMG tag types is output on the exported GEDCOM CAST , DSCR , EDUC , OCCU and RELI tag lines respectively. The GEDCOM specifications identify maximum allowed field lengths for the text on these tag lines for each of these tag types as:

CAST - 90

DSCR - 248

EDUC - 248

OCCU - 90

RELI - 90

TMG will export the entire memo text up to the maximum specified GEDCOM line length. Importing programs are within their rights to not allow longer text and/or to truncate any data in these fields to these maximum lengths. To prevent the text loss when the memo length exceeds 90 characters, with this enhanced export option selected for each of these five GEDCOM tag types the entire memo text will be moved to a NOTE tag subordinate to that tag and will not be truncated. Most importing programs will place the NOTE text in the event note field and the event description field for these imported tags will be empty. While these event tags will require post-import cleanup, no text will be lost.

TMG doesn't have a standard Property tag type. However if a user has customized a tag type to try to export this information to be converted later to the standard GEDCOM PROP tag type, that GEDCOM tag type allows up to 248 characters, and this provision to deal with lengthy memos will be used for that custom GEDCOM tag type.

Disclaimer

I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke. I am simply a satisfied user of this software package and have constructed this document to aid me in its use.

If others find this content useful, so much the better. I do not warrant in any way that it is accurate or useful, and any use of its contents is at the user’s own risk.

This document was composed with Adobe^® Framemaker^® using its hyperlink and HTML conversion features.

©MJH Consulting, 1996-2019. All rights reserved.