TMG™ Custom Tags ©MJH

Modified August 1, 2020 5:42 pm
This site works better with Javascript enabled.
Michael J. Hannah, Los Ranchos, NM.

TMG defines the following ten tag groups which can have a tag type defined as a member of that group. An individual tag of a given tag type is then added to the record of a person. A tag group identifies the intended overall purpose of any tag which is added from any tag type defined within that group. The separate Tag Sentences chapter contains a list of all tag types within these tag groups, including my custom tag types.

A tag whose type is in this group has only one Principal and no Witnesses and defines one of many names (usually called Name-Var’s) that can be assigned to refer to this person in all other tags.

A tag whose type is in this group refers to only one Principal and describes the beginning of life of this person. A date in the Primary tag in this group defines the beginning date for life of this person, and is used to calculate an age associated with any other event.2

A tag whose type is in this group links one child to either one father or one mother and has no sentence, date, place, or witnesses, but does have citations and a memo. Only one father relationship tag and one mother relationship tag can be marked Primary. TMG enforces these two Primary parents having their SEX flags set to the opposite gender values. The Primary tags in this group are the only one used for all ancestor and descendant linkages for the child, and are the only relationships exported to GEDCOM.

A tag whose type is in this group links two people as spouses, usually for the purpose of defining a family by grouping children beget by the pair. The date3 of a tag in this group can control the grouping and order that those spouses and/or their children are displayed in some reports and charts. Only the data (e.g. date/location) from the one tag among all the tags in the defined tag types in the Marriage group for this couple which is marked Primary for a person will be used as this couple’s marriage data for that person.4 If there are multiple tags in this group for this couple it is possible for one tag to be Primary for one spouse and a different tag Primary for the other spouse, leading to differing marriage information in each spouse’s reports and charts. See the Primary attribute description and its footnote about this issue.5

A tag whose type is in this group also links two people as spouses in the absence of a tag linking the same two people in the marriage group. Thus a tag in this group without a spouse specified can produce “unknown spouse” in some reports, but it defines an end of a formal relationship and does not print as a marriage.

A tag whose type is in this group refers to only one Principal and defines an ending to the life of this person. TMG automatically sets the standard LIVING flag to ‘N’ when you add any tag in the Death group, and this flag is used by TMG to determine whether the person is living at the time of other events. The Primary tag in this group is used to calculate the lifespan of the person.

A tag whose type is in this group documents any events that may be associated with the disposition of the body of one or two6 Principals following death. TMG automatically sets the standard LIVING flag to ‘N’ when you add any tag in the Burial group,7 and this flag is used by TMG to determine whether the person is living at the time of other events. But adding a tag in the Burial group which has a date does not affect the calculation of the lifespan.

A tag whose type is in this group links multiple people to a common event but has no Principals, only Witnesses.

A tag whose type is in this group usually has a Place entered which is used to identify a mailing address or equivalent for a person. In Version 4 and earlier, tags of tag types in this group used to be the only tags that included three of the location subfields in their standard sentences. Now all tag groups allow entry in all of the location subfields. (See also the standard Residence tag type in the Other group which I have deactivated.)

A tag whose type is in this group links one or two Principals and multiple Witnesses to some general purpose other event.

A tag type is a master definition for similar tags in one of these ten tag groups. TMG documentation collectively refers to Event tags as a tag in only these six groups: Birth, Marriage, Divorce, Death, Burial, and Other. Tags in the remaining four groups are not considered “events” by TMG and are not included in the Master Event List: Name, Relationship, History, and Address. Each tag group can have multiple tag types defined within that group.

A tag type must have a unique name among all tag types within this dataset and must belong to only one of the ten tag groups. Tag type names have a maximum of 20 characters.8 As of Version 8 some of the previous standard tag names were changed/expanded to an unabbreviated name. These new names will exist in any New project created in Version 8 or later.9 Any tag type in the same group will have the same effect, e.g. any tag type defined in the Death group (e.g. Death, Murdered, Suicide, DiedAtWar, DiedAtSea, etc.) denotes the end of life of that person and when added will affect the LIVING flag. Each tag type defines its own template of default output sentences to be used for a tag of that type (e.g. Birth and Baptism are different standard tag types in the Birth tag group. Whichever is marked Primary defines a beginning date for the life of this person but each have different text in their output sentences). If you are using other languages in TMG, you must recognize that the tag type name in the tag type table is determined by the English (US) name.10 When you create a custom tag type (possibly by doing a copy of an existing tag) in any language other than English (US), you always need to edit the English (US) view to make sure that the label is consistent between all data sets where the custom tag type is used.

A tag is a specific instance of one of these tag types within a tag group used to document specific information associated with specific people in the dataset.

A reason for using tags in different tag groups is that some reports or charts (e.g. a box chart) only print the Primary events from a select set of tag groups, and most reports and charts allow an option to restrict output to only all Primary events for that report. A major reason for using different and custom tag types within the same tag group is that report options can select which tag types to be included, and you get one Primary tag from each tag type in the Other tag group when the report excludes all non-Primary tags.

Within TMG an existing tag can be easily changed to a different tag type but only to another type defined in the same group. However, changing an existing tag’s tag type does not change any associated default style set in that existing tag.11 Due to a remaining bug care must be taken when changing the tag type of an existing Relationship tag of a parent or the automatically presumed sex of the parent may be set wrong. TMG will not change existing tags to a tag type in a different group, and will not move the definition of an existing tag type to a new group. (Either of these actions may be possible using a separate special program like TMG Utility or TagWiz!.) Therefore it is important to consider in which tag group a custom tag type should belong when you first define it because of its treatment by TMG by being in that group. As of Version 8 you can define a unique font/background color setting for each tag type to distinquish different tag types in the Type column of the Details window.

Multiple tags of various tag types in the same tag group can be linked to the same Principal(s). Various reports are or can be restricted to tags designated as Primary, but they exclude non-Primary tags for all tag types in the report or none. Only one tag among similar tags can be marked Primary, but this designation depends on all three factors being identical: the tag group, both of the Principals, and possibly the tag type. For all tag groups except “Other” only one tag regardless of tag type within that group with the same Principal(s) may be marked Primary. For the tag group “Other” only one tag of the same tag type with the same Principal(s) may be marked Primary. Both the one tag in the Name tag group and the two (mother/father) tags in the Relationship tag group that are marked Primary are displayed in their special locations on the Person View and not among the chronological list of tags. Every new tag will be marked Primary when it is added if it will not conflict with an existing Primary tag. The new tag will be marked Primary if it is the first of that group with that set of Principals, or in the “Other” group the first of its type with that set of Principals.12

A leading ‘!’ as the first thing in a memo implies the following text is an external filename which contains the memo text. If the text immediately following the ‘!’ is not a filename this can produce a cryptic error message. Leading exclusion markers (‘-’ or ‘--’) are also honored. Memo text can be split into nine separately referencable parts. (See the discussion about empty split memo parts.) Reports have a variety of controls over how and when they print memos that depend upon whether or not a memo variable is included in the tag sentence template. If my custom tag treats the memo in a special way such as a split memo, or expects that it contains specific data, that is defined in the description of the tag type. Standard tag type sentences generally do not include the memo variable. I make extensive use of memos and split memos, and usually include their variables in all tag sentences.

In addition to the default tag type global sentences that can differ based on the SEX flag, individual tags can define a separate local sentence for each linked person, and specify a language. Constructing tag sentences, and the variables that can be used in these sentences, is a topic unto itself. See my separate Tag Sentences chapter which describes numerous custom sentences, even for standard tags.

Citing sources to tags is a separate topic unto itself. I have considerably customized source templates and regularly make use of both the Citation Detail and the Citation Memo.

Tags in the History group have no Principals, tags in the Birth and Death groups only define P1, tags in the Name group do not allow specifying a Principal and are fixed to this one person. If a sentence variable refers to a Principal which cannot exist for the tag (e.g. [P1] in a History group tag), it will output the “unknown person” text. Tags in any other group (including Burial) allow up to two Principals. Relationship tags label the two Principals as Parent and Child and automatically display the mother/father/son/daughter designation based on the SEX flag of the individual. The person’s name to be used for the sentence can be chosen in each tag from all the names defined by tags in the Name group for that linked person. A leading ‘-’ in the Principal’s ID number marks this name as excluded data to not display in the Person View on the tag when the “other” principal is the focus if “Preferences>Tag Box>Show excluded data” is not set, but does not exclude the name from still being output in some reports. Both Principals and Witnesses can be assigned roles, but if one Principal has a role, both Principals must have roles and neither can use the standard role “Principal”.

I prefer to enter the information in the date field as it is found in the documentation, then translate to a normal date, if necessary, in the sort date field. Sort Dates are only accessible in Advanced Mode. There is intentionally no way to output Sort Dates in TMG reports, as they are solely designed to force a tag order when the Date (or its absence) would produce an undesired order. See the discussion on dates in my data entry guide.

Tags in the Address group in Version 4 and before used to be the only ones that output the three Addressee, Zip/Postal Code, and Phone location fields in their tag sentences as part of the standard location variable. Now all location fields are available to all tags. The default output for sentence variable [L] can be modified by a Place style. See the discussion on places in my data entry guide.

In addition to the Principal(s), multiple people in the dataset can be linked as Witnesses to the same tag. They are assigned their own names from amongst their tags in their Name group, have their own memos, and can each have any role assigned (except Principal) with its separate sentence and language specified. Great flexibility is provided by these separable features for Witnesses and many of my custom tags define witness roles and sentences. As of Version 8 a number of new roles were defined as part of some standard tags.13

While the individual custom tag types mentioned below will demonstrate my own custom use of those tag types, I also have customization practices which apply to all tag types.

Custom tag types and custom modifications to standard tag types are unique to a given TMG dataset. Different datasets in the same project can have differing tag types and even differing definitions of the same tag types. Every custom tag type in a dataset must have a unique name within that dataset but can be anything up to the maximum 20 characters for a tag type name.14 As a general rule I choose not to (greatly) customize standard tag types, but to define my own tag types with my own unique names. (What constitutes “greatly” is a matter of personal taste but I try to keep such changes minor.) One motive for this choice is that when merging two datasets if the receiving dataset has a tag type of the same name, the customization to that tag type in the sending dataset is lost. While a standard tag type can have its name changed, thereby allowing a new custom tag type to be created with that original name in the same or even a different group, I choose not to do this to avoid conflicts with standard tag types in case I ever need to merge datasets (or use the feature introduced in Version 8 to Import tag types). If I am not going to use a standard tag type but define something similar to replace it, I (usually) both change its name to “NamOrig” where ‘Nam’ is an abbreviation of the original name, and deactivate15 that standard tag in the Master Tag Type List so I am not tempted to use it. That way if I merge in a dataset that does use any standard tag types I do not normally use, with perhaps non-standard definitions, these tag types with their original standard names and with their customizations will be retained when imported.

Some have suggested tag type naming conventions to indicate that a custom tag type should not be printed and thus not selected on the options of output reports, such as a leading ‘-’ or some characters such as ‘NP’ or ‘NotPrint’ as part of the custom name. I prefer to reserve the hyphen ‘-’ in a name only for Relationship and Name tag types16, since the standard names for those tag types already have that character. Some prefer to use prefixes, or even surround a tag type name with parentheses, for custom tag types. I prefer to use standardized custom qualifiers to tag type names as Suffixes and denote the base from the suffix by appropriate capitalization, e.g. BirthFind or BirthNotPrint. Using Suffixes allows all the basename variations to sort together in the master tag type list. To match the “standard” tag type naming variations, I separate a suffix from “Marr” with a space and from “Name” and Relationships with a dash. Suffixes allows all tags of the same base to still sort together. However, standardizing the meaning of Suffixes across different types of tags is also useful since the List of Events reports allows filtering by “Tag Label contains”. For example I use the filter “Tag Label contains FIND” to get reports of all my “*Find” tags. And I define “*Sens” tags for an equivalent tag type which contains sensitive data that I normally do not output in reports. Various examples of possible custom suffixes and their intended meaning as applied to multiple tag types are described below as “*suffix”. Any tag I actually use in my TMG projects (as opposed to being simply ideas I have collected) is identified below with the superscript MJH.

Beginning with Version 8 there is a Tag Label Color option to set a tag type to use specific font/background color settings. These colors for a given tag type are defined on the General Tab of its Tag Type Description. If you set a color TMG will prompt you to enable the option to display tag label colors in Preferences/Project/Colors. (See also the colors associated with People Accents and Filters.)

I reserve these tag types for when these major events are sufficiently documented, as opposed to the equivalent “*Assume” tag types. The color distingushes these major BMDB events from all others. I use the colors: font = Black, background = Light Yellow (just right of top left on the default color table)

I color all my “*Find” tag types (regardless of the default tag color for that type of tag) and the Note and Misc tag types the same. All these types are my “To Do” or research actions, and often are selectively not included in normal reports. I use the colors: font = Black, background = Light Pink (top right corner)

All *Assume and Relationship *-Can tag types (includes DeathAssumeBur & DeathAssumeCrem)

I color all my “*Assume” and possible relationship *-Can tag types to stand out as events which need further research and documentation. I use the colors: font = Black, background = Light Salmon (custom RGB = 240/170/200)

I set the Census* and Src Link tag types to the same color scheme I use to accent the Census Pseudo People. Those colors are: font = Light Yellow (one right from top left), background = Dark Green (third from left, four down). See also the default accent light green background color for all non-Census Source Pseudo People.

I set the Created tag type, used as a “birth” tag for pseudo people, to the Birth tag type background = Light Yellow (just right of top left on the default color table), but set the font to the Census tag type background color = Dark Green (third from left, four down).

Transcript tag types plus Relationship *-Step, the NarrativeChildren, Journal*, FamilySectionNote, Marr Dummy and Cem-list-head tag types

I often use the Transcript tags with Pseudo People and they are designed to produce narration. I set this color similar to the default color scheme I use to accent the Pseudo People, but slightly more grey background. I also use it for the NarrativeChildren, *-Step, FamilySectionNote, Marr Dummy, Journal* and Cem-list-head tags as they also primarily affect narration. I use: font = Purple (diagonally up one from bottom right), background = Grey (next but one to bottom right)

I set these tag types to the same color scheme I use as default for people’s names in Preferences // Project Options // Colors. I want the standard *-Bio relationships and the BirthPar tags to blend with a normal person’s name, but any other relationship be a clear highlighted difference. For my production project these colors (see also People Accents) are: font = Yellow (next to top left), background = Dark Blue (under the two very light blues)

I set all the tag types dealing with Adoption (such as *-Ado relationships, Adopt*, Name-Adopted and Name-Birth tag types) to the same color scheme I use to accent people based on the ADOPTED flag. Those colors are: font = White, background = Dark Blue (diagonally two up from bottom right)

I set all the tag types with the *Sens suffix to use Bright Red (one down from top left) as the text, but the normal background color of the base name tag type. This highlights the sensitive nature of these tags which should only be output for my private use. I use separate tag types instead of TMG sensitivity braces as Second Site will never output data marked with sensitivity braces as there is no option to do so. Thus I make the sentences of these tag types single excluded but without using the sensitivity braces so that I can choose to output this data in private sites.

My custom tag type TestTag is only used to test various TMG options and output. It should never be output in a normal report, and is normally deleted following the test. To make it annoyingly visible I use the colors: font = Black, background = Bright Red (one down from top left)

The name of a relationship tag type in the database is simply the text following the dash. Even though the tag name “appears” to differ depending upon whether viewed from the parent or child, it is really the same tag for either side of the relationship and for all types of linked people. For example, the tag type name internal to TMG for all *-Biological (*-Bio) tag types17 is really just “Biological” (or previously “Bio”), although a person’s Details will display “Son-Biological” or “Mother-Biological” based on the SEX flag of the linked child or parent. Automated sentences based on relationship tags will always use the words “parents”, “mother”, “father”, “son”, “daughter”, or “child” regardless of the suffix on the relationship, with no way in TMG to customize or modify those words/phrases other than postprocessing the output. (For example, a son linked by a standard Son-Adopted tag will output in TMG as “son” and not as “adopted son”.) Like most memos, the text will show upon roll-over for child relationship tags or non-Primary parent tags among the other tags in the Details view, but a Primary parent relationship tag must be opened to see its memo. Neither the memos nor the citations of the Primary relationship tags will be exported to GEDCOM, and all relationship tags are exported to GEDCOM as if they were “biological” regardless of the TMG tag type name.

The standard Relationship tag types which are pre-defined in TMG are: *-Adopted (*-Ado), *-Biological (*-Bio), *-Foster (*-Fst), *-God, *-Other (*-Oth), and *-Step (*-Ste). As noted above, within TMG all of these tag types are treated identically, are treated as genetic relationships regardless of name if set as Primary, and their different names are only noticable when viewing a person’s Details screen. While TMG generally does not output the “name” of the relationship tag type, by including the Parent Section in the Second Site configuration for Pages / Person Entry, and ensuring that Non-Primary parents are not omitted on the Data / Database configuration, all parents will be included in the child’s list of parents, with a label based on the relationship tag name.

If using the standard *-Adopted (*-Ado) relationship tag type see my separate discussion about adoption tag types. Also see the discussion about the standard ADOPTED flag.

If using the standard *-Step (*-Ste) relationship tag type see also the separate discussion about my custom usage of the NarrativeChildren tag types as a companion to this relationship tag type for non-Primary children.

I currently reserve the standard *-Other (*-Oth) relationship tag type for parent/child relationships between “pseudo” people. I typically do not include any of these special relationship tag types in normal reports.

Although these tag types have no sentences, the complete list of all variations of relationship tag type names are in the master tag type name table in the separate Tag Sentences chapter.

Since the names of the relationship tag types in the database are simply the name following the dash, you cannot create a custom tag type simply named “Biological” since that name is actually already in use as a standard relationship tag type even though it does not show as a tag type name in the Master Tag Type List. The name of a custom relationship tag type is simply the text which will follow the dash, so do not enter the dash when naming the custom tag type or text such as “Father” or “Son”. Relationship tags have no sentences but do have memos, thus their tag type names generally are the only visual clue in Person Views to describe what you intend and their memos what you found. Neither the memos nor the citations of the Primary relationship tags will be exported to GEDCOM, and all relationship tags are exported to GEDCOM as if they were “biological” regardless of the TMG relationship tag type name.

Since relationship tags have no sentences, a variety of custom tag types have been proposed for the “Other” group to narrate various relationship complications. One suggestion is to create a special Name-Var tag to be used for non-biological relationships (see Name-Adopted and Name-Step). Which one father and one mother is set to Primary will produce automatic sentences in multiple reports and be used by the Parent sentence variables and as the genetic/biological relationship for all ancestor and descendant linkages for these two people. However, you may choose to have no parents set Primary and would thus need some kind of tag with sentences to reflect those relationships. As one such example (which I do not currently use), a custom tag of FatherComm for a commonly recorded father (and an optional Witness role named father-poss for one or more possible fathers) might be added to sort immediately after a child’s Birth tag with a sentence something like:

It is commonly recorded that the father of [P1] is [P2]< but conflicting evidence also considers [R:father-poss] as possible><. [M]>

Although these tag types have no sentences, the complete list of all variations of relationship tag type names are in the master tag type name table in the separate Tag Sentences chapter.

*-Bio2, *-Bio3 are relationship tag types I defined for parent/child relationships when the parent had children with more than one spouse. This idea was raised on the ListServ to deal with polygamous marriages in an effort to be able to more clearly see in the parent’s Person View which child was begat by which spouse. However, it is also informative in the child’s Person View. I have created custom Relationship tag types named *-Bio2, *-Bio3, etc. for linking the children from spouse two, three, etc. By default the children with the first spouse would use the standard *-Bio tag type. As of Version 8, you could set each of these tag types to display a different color, but I have not yet chosen to do this. Using these custom tag types also works when both spouses have multiple spouses, since Relationship tags are separate for each parent/child pair. The child might be linked to the father as *-Bio3 to show they were begat by the father’s third wife, but linked to the mother as *-Bio2 to show they were begat with her second husband. Thus the tag type name indicates which spouse of that parent: (1), 2, 3, etc.

I define *-Can as a full set of relationship tag types18 for “candidate” or potential parent/child relationships. This is when I think a pair of people might be parent/child, but am very uncertain.19 It maintains the link and my thinking, but the tag type name reminds me that it is not a firm claim. As of Version 8 I also use a common color highlight for all *Assume and *-Can tag types as a clue the information is not complete.

The citations and memos of my custom *-Nil relationship tag types can be used to document that I have determined that a parent/child relationship for these two people does not exist even though it looks likely, to avoid having to redetermine this at a later date. This relationship tag allows citations to the sources that make this lack of a relationship clear, and a memo that documents the conclusion. Once appropriate citations are obtained is easy to change a *-Can tag type to a *-Nil type. However, I am more likely to delete the *-Can tag and use an appropriate memo in my custom Related tag type. (See also my custom *Nil tag type name suffix without the relationship dash.)

For all custom tag types in the Name group, I separate the tag name suffix from the base text of “Name” by a hyphen to match the standard tag type names like Name-Var in that group. Other suggestions for Name-Var custom tags beyond those explicitly mentioned below include Name-Full, Name-Legal, or Name-Official to define the full name for this person used in official records. Name-Usual or Name-Primary could identify the name usually or primarily used by this person, but I use my custom Name-Comm. (Do not confuse a tag type named Name-Primary with designating a tag in the Name group as Primary for the purposes of TMG reports.) Name-Stand could define the standard way “I” choose to spell or output this person’s name. Name-Occ could include titles only appropriate when associated with their work, e.g. Judge. (Note that the forms of the [S] people variable are not recognized in Name tag type sentence templates, as these tags can only have one Subject.)

As all event tags allow you to specify the name from a specific Name tag to be used in the sentence for that event, variations are of value. However, even if a different Name is specified for a specific event tag, the name of the “other” Principal shown for that tag in the Details of a Person View will be the Name tag marked Primary for that person regardless of the name variation chosen to be used for that “other” Principal in the output of that specific tag.

Tag types in the Name group can have a Name Style set as default for a tag type. Name Styles can be used to customize the sorting of name entries in various lists, both in TMG and Second Site. See the Data Entry chapter for the Effect of Name Styles on sorting. (In addition to the custom styles for people’s Primary names below, see also my special purpose custom Name Styles more fully described elsewhere: Census styles, Location styles, Married style, Repository style, Source style, and SurnamePreSort style.)

For names where I desire to enter data in fields which the “U.S. Standard Name” style does not output, I have defined a custom “AllFields” name style. This Style also can be useful for a non-US-standard style of foreign name for which one does not wish to set up a whole new Name Style for just a few people.

For surnames with a non-empty PreSurname field, see also the Name-Surname-Sort tag type below with its SurnamePreSort style which I created for dual sorting and index entries of such surnames. For a similar reason, for women whose married name has a non-empty PreSurname field I enter two Name-Marr-Title tags with its Married style to provide dual sorting and index entries of her married name. If her Primary Maiden name has a non-empty PreSurname field, I simply include it in the “Maiden” field with the surname.

AllFields Name Style Templates
Output	[Title] [Prefix] [GivenName] [PreSurname] [Surname] [Suffix]
Surname sort	[PreSurname] [SortSurname], [Prefix] [SortGiven] [Title] [Suffix]
Surname display	[PreSurname] [Surname], [Prefix] [GivenName] ([Title]) [Suffix]
Given sort	[Prefix] [SortGiven] [Title] [Suffix] [PreSurname] [SortSurname]
Given display	[Prefix] [GivenName] [Title] [Suffix] [PreSurname] [Surname]
Children/Siblings	[Title] [Prefix] [GivenName] [PreSurname] [Surname] [Suffix]

For mononym names, where a single name or phrase is used as if it is both the given name and the surname, I have defined both the custom tag type Name-One and the following custom Name Style “OneName”. (This style is also used by default for the custom tag type Name-Link-Only.) I then enter that mononym text in the Primary Name tag in both the GivenName and Surname fields (which the OneName custom style labels OneNameG and OneNameS are a reminder the text should be the same). Duplicating the name in both fields is required so that all TMG name sentence variables and indexes in both TMG and Second Site will handle the mononym name appropriately. (Note the trailing comma in the Surname display template which is required20 as described further in the Data Entry chapter concerning Name Styles.)

OneName Name Style Templates
GivenName [OneNameG]	The complete one name text (duplicate it in both fields)
Surname [OneNameS]	The complete one name text (duplicate it in both fields)
Output	[OneNameS]
Surname sort	[SortSurname]
Surname display	[OneNameS],
Given sort	[SortGiven]
Given display	[OneNameG]
Children/Siblings	[OneNameS]

The one tag in the Name Group which is marked Primary for a person is treated in a special manner. Any tag type in the Name group can be marked as the Primary for a person and does not have to be the default Name-Var tag type. That tag now will appear in the separate ‘Name’ area above the Primary parents rather than among the event tags below. Any custom label “name” of the tag type will not display in that position, but it will display that tag type’s label “color”. Even if this tag has a sentence defined, that sentence will not output in narrative reports, and TMG will not allow editing of the sentence while a Name tag is marked Primary. Thus even if a custom Name tag type has been assigned as Primary with a sentence explaining a non-standard nature of this name, that sentence will not output. There is an option on the Memos tab for some narrative reports which will direct Name tag memos to output. If selected the memo data in the Primary tag will output according to the output for memos not included in the sentence even if the Primary Name tag sentence includes a memo sentence variable. Finally, the name data entered in this tag will be used by TMG in many circumstances. Children and Parents are listed in most TMG reports under the name from whatever tag in the Name group is designated Primary for that child or parent. For an event tag in the Details area, the “other” Principal will display their Primary Name even if that other Principal has a different Name tag selected for use in the sentences of that event. The Primary Name tag also will be the basis of Inferred Name Parts in other Name tags as described below.

If you have defined different and special Name Styles, you may not have to define different tag types in the Name group unless you will want to exclude them from reports. Standard Name-Var tags assigned different Name Styles could produce very different output. Leave the surname field blank for any non-Primary Given name variations since the surname is inferred to be the same as in the Primary Name tag. Use an exclusion marker “-” or “--” as the complete Given text in the name tag if there is intended to be a blank Given name to avoid the missing name text, e.g. “(?)”. For more details concerning blank name parts, whether entered as blank or caused to be blank by exclusion, see the Blank Name Parts topic in the Data Entry chapter.

A blank given name with an alternate surname will automatically take on the Primary given name. Note that the variable [N] used in sentences21 for Name-Var tags does not infer empty values from the Primary name in narrative report output but will only output the data entered in that tag. However, when a specific Name variation is selected as the name associated with a tag, sentence name variables for name parts that are blank (e.g. [PF]) will infer their empty values from the Primary name.22 A Name-Var could also be used (such as the custom Name tag Name-Index) to record other (standardized?) spellings of this family name, even if never used by this person, to show linkage and produce an entry in indexes. See my data entry notes for names for additional examples and entry standards for cultures with different name structures and conventions, e.g. mononyms, patronymic, matronymic, farm, place, occupation, etc.

View of the Name in Picklist/PE from Name Group tags when non-Primary names are displayed

• given empty and surname empty but suffix non-empty, given and surname copied from Primary

• given a single minus and surname a single minus but suffix non empty, suffix only at top of picklist

• given double minus and surname double minus but suffix non empty, as if given and surname a minus.

The purposes of the People (Name) indexes in TMG reports and Name index in Second Site web pages are by their nature very different. (See also the topic TMG Indexes in the Style Guide chapter.) As mentioned in the Data Entry chapter, options associated with Name Style templates can affect whether only Display or also Sort entries will be included in an index. Further, whether either that Name Tag Type or the tag’s sentence is excluded in the report can affect the appearance of that Name variation in these indexes.

The sentence of a Primary name tag will not print in either TMG or Second Site. However both programs provide report options to output that tag’s memo. Both programs also have several non-narrative types of output which will output date from tags, but my discussions are generally focused on narrative output. Only non-Primary Name tag sentences have the potential to print their tag sentence in a report. However selecting a name variation defined in a particular Name tag for either a Principal or Witness to appear as output via a people variable in the sentence of some other tag is a separate issue from either the output of that Name tag’s sentence or the inclusion of that name variation in an index.

In TMG in all cases of exclusion options if a name from a Name tag is selected for the person associated with a people variable in either a Principal or Witness sentence in a tag, that tag’s narrative output will show the specified part of the selected name. Also that occurance of the name on that page of the report will be included in the TMG People (Name) index regardless of exclusion options for the Name tag itself or the Name tag’s sentence.

In Second Site in all cases of exclusion if a name from a Name tag is selected for the person associated with a people variable in either a Principal or Witness sentence in a tag, that name also will still output in that tag’s narrative sentence so long as that linked-to person is included in the site. Further that name in that sentence may still be a hyperlink to that person depending upon the Data/Names option chosen for Name Link. But if the linked-to person is not included in the SS site, the name in this tag’s sentence will simply output “an unknown person” with no hyperlink. However the inclusion of the name variation in the Second Site Name index is a separate issue and will depend upon the exclusion options for the Name tag itself and the Name tag’s sentence. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so.

Often there is the desire to define/document a name variation, but also a desire for various types of exclusion of output concerning that name. If there is simply a desire to record that a name variation was associated with a person, but there is no desire for it to appear in the index nor be selectable in tags, an Anecdote or similar tag should be used instead of a Name tag to mention this variation. If the name variation is needed to be available for selection in other tags, there still may be a desire for some forms of exclusion. Obtaining these variations in TMG versus Second Site are described in more detail below.

• output the Name tag’s sentence to explain the variation, but not include it in the index [TMG, Second Site]

• not output the Name tag’s sentence, but include the variation in the index [TMG, Second Site]

• neither output the sentence nor include it in the index, but still be able to select the name in other tag’s output [TMG, Second Site]

Because of the differences in the purpose of TMG and Second Site indexes each program behaves slightly differently with respect to these selective exclusions, and the consequences of specific exclusion methods differ. WARNING: the behavior of Second Site associated with various types of exclusion concerning Name tags has changed twice since TMG ceased to be developed, as described below.

In TMG the purpose of a People index is to identify all, probably multiple, places within the report where that name variation for a person appears. In the Report Options of those reports which can produce a People index, on the Indexes tab you must select either surname or given name to get a People index. If you choose both they will output separately, or you can choose “Combined index” and they will be combined together into one People index. There is even an option to combine the normally separate People and Places indexes into a single index. (See also the topic TMG Indexes in the Style Guide chapter.)

Unless the report option for Names appends some kind of identifier, there is no way to identify in the index (or the report) which person has this name variation. Inclusion of a name is based solely on some tag which outputs in the report having selected that name for a Principal or Witness and some part of that name was output by a people variable in a sentence for that tag. Therefore if a tag’s Principal or Witness sentence which has selected that name variation is output, the output from the people variable will cause that name variation to appear in the index. If that name variation’s Name tag sentence is not output due to some form of exclusion, and that name variation is only selected in tags not included in the report, such as in tags for other people who are not included in the report, then that variation will not appear in a TMG People (Name) index. The people variable must output an actual name part, not some form of pronoun (e.g. [OBJ] or [RP:rolename]). If only a pronoun is output the name will not be considered to have been output in that sentence to trigger inclusion in the TMG index. If the people variable for the selected name begins the sentence and is automatically replaced by a pronoun, the name is thus not considered to have been output in that sentence for inclusion in the index. If any portion of the name is output by the sentence (e.g. only the given name using the people variables [PF] or [RF:rolename], or the special [N] variable in a Name tag sentence), that entire Name tag’s name is considered output and will be included in the index. If the sentence which would output the name is single excluded, whether or not the name is output (and thus triggers inclusion in the index) will be affected by the option to show excluded data. So concerning how to obtain the three potentially desired exclusion options in TMG:

• output the Name tag’s sentence to explain the variation, but not include it in the index

If this person and their Name tag sentence is included in the report, that occurance will be identified in the index. Thus this exclusion combination is not directly possible in TMG. One could use an Anecdote or similar tag for the explanation instead of a Name tag to avoid that index occurance. However, so long as the Name tag exists and that name is selected in any tags which output a name part due to that person’s people variable, those occurances will appear in the TMG index.

• not output the Name tag’s sentence, but include the variation in the index

This is the most common desire, and the easiest option to accomplish in both programs. Simply define the Name tag sentence template to exclude the output of the sentence, or exclude that Name tag type from the report. Any method of exclusion of the sentence, including not selecting that Name tag type to be included in the report, will work for TMG. However, different exclusion methods will have different consequences in Second Site as described below. Before the changes and fixes made to Second Site Version 6.2 Build 11 the only reliable way to accomplish this in SS was with a double-excluded sentence template of “--<[M0]>” which also worked in TMG. But after those changes and fixes this template would not work in Second Site because the name will not be included in the index. If using Second Site Version 6.0 Build 00 or later, for excluding the sentence of a single Name tag of a tag type I now recommend using the (fixed) single-excluded sentence template of “-<[M0]>]:NP:]” which provides a non-empty sentence template even if output of excluded data is selected.23 Regardless of the method to exclude the Name tag sentence, if any tags select that name variation and output a part of that name via that person’s people variable, those occurances will appear in the TMG index.

• neither output the sentence nor include it in the index, but be able to select it for tag output

Not possible in TMG. If the name variation is ever selected for any tag, and a person variable is used in that tag’s sentence to refer to that person, and some part of that name is output, that occurance will appear in the TMG index. The only way to avoid an index entry is to enter the person’s name as text instead of using a person variable (or force a pronoun output), but then it does not matter what name variation is selected or even if the person is linked to the tag.

In Second Site a name in a Name index only identifies who has that name and provides a link to that person’s page. For this reason the name from the Primary Name tag of any person in the site is always included in the index regardless of any exclusion markers in that tag’s sentence (since that sentence is never output). Even if the tag type of the Primary Name tag is not selected in the list of tag types in Data/Database, the name in the Primary Name tag will be included in the index. Inclusion in the Second Site index of the name from a non-Primary Name tag is based solely on two factors:

• whether that Name tag type is selected to be included by two different SS options, and

Unlike TMG, index inclusion is not based on whether some part of that name is output via a people variable in any other tag output within the site. Any tags for people in the site which select a name variation and output that person’s people variable will output that variation as long as that person is also in the site regardless of any other exclusion choices. But that output has no bearing on the index.

The effect of the two options to select a Name tag type has not changed in several versions of Second Site. If a Name tag type is not selected in the list of tag types in Data/Database, then no Name tag of that tag type will produce a sentence in a person’s page or an index entry (except Primary names). If a Name tag type is selected in the list of tag types in Data/Database but not selected in the tag list of any Pages/Person Entry/Tag Group/Tag Filter (or selected in the list of a No Output tag group type but excluded from other groups in this group type’s options), then no Name tag of that tag type will produce a sentence in a person’s page. However the name variation is still eligible for including in the index, but will be dependent upon exclusion of the specific tag’s sentence.

If a Name tag is selected for output, or if name variations of that tag type are still eligible for including in the index, then both the output of the sentence and inclusion in the index will be dependent upon whether the sentence of the specific Name tag is excluded. WARNING: the effect of exclusion of some Name tag sentence templates on whether that tag’s name will be included in the Second Site Name index has significantly changed from Version 6.2 Build 06 to the Version 6.3 Build 00 and later.24

As specified25 by John Cardinal, the author of Second Site, a Name tag with a double-excluded sentence is intended to not appear in the site, neither its sentence nor an index entry. (While this specific statement is true, the issue of double exclusion is more complex and pervasive than this one example. See the Second Site HELP documentation for more details. This behaviour was not true prior to Version 6.2 Build 11. This is now true for its sentence and index entry, but the name variation of that tag still can be selected in other tags and will output the people variable so long as that person is in the site. Prior to Second Site Version 6.2 Build 11 there were some inconsistency issues and bugs26 associated with both single and double sentence exclusion of non-Primary Name tags. Version 6.2 Build 11 resolved27 some of these issues, but they were not completely resolved until Version 6.3 Build 00. So concerning how to obtain the three potentially desired exclusion options for single Name tags in 6.3 Build 00 and later:

• output the Name tag sentence to explain the variation, but not include it in the index

Like TMG this combination is not directly possible in Second Site. One could use an Anecdote or similar tag for the explanation instead of a Name tag to avoid that index occurance. However so long as a Name tag’s sentence will output, its name variation will appear in the index.

This is the most common desire, and the easiest option to accomplish in both programs. Several of my custom Name tag types typically exclude the sentence only but are desired in the indexes. As noted above, if this is desired for all Name tags of a given tag type, then select that type in the list of tag types in Data/Database but do not select it in the tag list of any Pages/Person Entry/Tag Group/Tag Filter (otherwise select it in the list of a No Output tag group type but exclude it from other groups in this group type’s options).

To accomplish this only for a single Name tag of a tag type, that tag’s sentence must be excluded, but in a way to still allow the name to be included in the index. Due to various bugs in single-excluded Name tag sentences, up to and including Second Site Version 6.2 Build 06 the only reliable and consistent way to guarantee inclusion in the SS index with no sentence output was with a double-excluded sentence template of “--<[M0]>” which also excluded the sentence in TMG. But this index behavior of a double-excluded sentence itself was a bug and violated the intent of the program. As of Second Site Version 6.2 Build 11 and later this double-excluded sentence would no longer accomplish this desired exclusion option because the name now also would not be included in the index. But some of the bugs concerning single-excluded Name tag sentences still existed, so there was (temporarily) no reliable and consistent way to accomplish this option. As of Version 6.3 Build 00 these remaining bugs were also fixed. Therefore, for including the name in the index but excluding the sentence of a single Name tag of a tag type in Version 6.3 Build 00 or later you can now use the (fixed) single-exclusion sentence template of “-<[M0]>[:NP:]” which accomplishes this exclusion option in both these later versions of Second Site and excludes the sentence in TMG.28 This now will ensure no sentence or memo will be output in narrative reports regardless of the setting of the Data/Database option of Show Excluded Data, and provides a non-empty sentence template regardless of that option.

• neither output the sentence nor include it in the index, but be able to select it for tag output

Because of the different purpose of its index, this can be done in Second Site where it is not possible in TMG. As mentioned above this exclusion is possible for an entire Name tag type if that type is not selected in the list of tag types in Data/Database. Due to the fix to double-excluded Name tags made in Second Site 6.2 Build 11 this is also now possible in that and later versions for any single Name tag. If the sentence template of a Name tag is double excluded, e.g. “--<[M0]>”, neither the sentence nor an index entry will output, but that name variation may still be selected in other tags, and will both output the name and provide a link to the person if the referenced person is in the site. An example is my custom Name-Link-Only tag type.

Its sentence presumes the Principal’s name was [N] and [M] is an optional comment, usually indicating my basis for assigning this name to this person. Since this custom tag is in the Name group I can select this name for other tags, and can change the tag to a standard Name-Var tag type or make it Primary if the name is confirmed. As of Version 8 I use a common color highlight for all *Assume and *-Can tag types.

Reflected by its sentence, this is the standard tag type for the event of being baptized which often involves assigning a name or an additional name to a child. Use the memo to explain.

See the discussion of all custom tag types I have defined for the events of Adoption in the separate chapter about non-Primary children. Assuming the typical name change as a result of an adoption, a child involved in an adoption could be assigned either or both of these two custom Name tag types: Name-Birth with its sentence and Name-Adopted with its sentence. The Name-Adopted should have a Sort Date after the adoption event tag. Having two separate Name tags allows either Name tag to be marked Primary, and either name to be used as appropriate in events for that person.

Reflected by its sentence, this is the standard tag type for the event of legally changing one’s name, either by external agents (e.g. immigration official) or by official means (e.g. deed poll).29 See also Sex Change below. Use the memo to explain.

Its sentence defines the common name used by the Principal and [M] is an optional comment. Since this custom tag type is in the Name group I can select this name for other tags instead of their formal or legal name, which for various reasons I may wish to retain the Primary name tag. A similar custom tag type for married women might be Name-Marr-Comm for a commonly used married name, but I do not currently use that.

I have considered this variation of my research *-Find tag types for the Other group when I have no name for the person, but do not currently use it. Another use could be for a person who was known to be adopted, or to have changed their name for some other purpose, and research is needed to find their other name.

Surnames (and given names) can often have a great many variations in spelling. Some users have suggested using a custom Name tag type to record your personal standard or common expectation for the spelling of that name part. A single individual can also have many possible name variations but you may expect to find them most commonly under a specific name or nickname. Adding such a “standard” Name tag to a person could help you locate them more quickly in TMG by insuring they will be found in TMG lists by this spelling or variation as well as by their Primary name. It would be typical to change the tag to exclude the sentence to prevent narrative text. This tag type could also be selected for inclusion in reports so that it would (also) produce an index entry of this “standard” variation. Various suggestions for the label of this tag type include Name-Std, Name-Standard, etc., but I prefer Name-Index to reflect its primary purpose of simply producing an alternate index entry. I make its sentence single excluded30, including the special memo variable <[M0]> which is not required but included to ensure the memo will not output and provide a non-empty sentence template if output of excluded data is selected. Because it will not output in narrative reports, text in the memo can be used to document why I am including this tag as that text will show in the Details section. (See also my similar custom Name-Surname-Sort tag type for its more focused purpose when there are PreSurname values, and custom sentences for the standard Name-Var tag type.) I generally use Name-Index for my own purposes of creating an alternate index entry when there is not documentation for that alternate name. If there is documentation of this alternate name, or I want to include this name in the person’s narrative. I generally use the standard Name-Var tag type, and explain this alternative using its general purpose sentence or a custom sentence.

An alternative or addition to this custom Name tag would be to customize either this tag type or the normal tag type to sort these names together in a single group in the name list based on the standard spelling while still displaying their alternative spellings within that group. This custom sorting can be accomplished either by entering the standard spelling in the desired “Sort” field of the name tag, or by creating a custom Names Style where the “Sort” template has replaced the “Sort” field variable with the hard-coded standard spelling.31 For more details about custom sorting of names based on Name Style information, see the discussion of the Effect of Name Styles on Sorting in the Data Entry chapter.

I am experimenting32 with this separate name tag type for names associated with my Location Pseudo people, but have currently only used it for alternate names for the same location. It currently defaults to the LocationCtryStCntCity Name Style so that all fields are available. Its sentence defines the name as an alternate for the Primary Location Name and includes an optional Date that reflects when this alternate name was in use, usually qualified as: From-To, Before, or After.33

Prior to Version 8 the name of the standard tag type for the married name of wives was Name-Marr, but is now expanded to Name-Married. These tags can be automatically created when a Marriage tag type is added (or globally added later using the TMG Utility) and will only have the surname entered. Selecting this name variation for the married P2 female allows sentence constructs using the Two Principals separator like “<[P]|[P1F]><|and [P2]>” that will give either “Jacob Sark” or “Elizabeth Sark” with only one Principal assigned, and “Jacob and Elizabeth Sark” when both are assigned. (See also the general discussion of sentence variables.) There is a Journal Report Option on the Miscellaneous tab to “Suppress married names from text”. That report will only suppress the narrative text from Name-Married tags whose Surname field data exactly matches the Surname field of the Primary name tag of a spouse.34

There are multiple suggestions to enter a maiden surname in the suffix field of a Name-Married tag, either with the exclusion character35 “-(née Maiden-surname)”, or using sensitivity brackets,36 to help in distinguishing between multiple similar married names. Others have also suggested putting the married surname in the suffix of the maiden name tag, e.g. “-(m. Spouse-name)”, for the same reason, with care if she had multiple marriages. The suffix field is used since the default Name Style does display this name part. As I expect to use the suffix field for its intended purposes I do not use either of these methods.

Others suggested defining a custom Name Style that includes fixed text37 (e.g. “Mrs.”, “née”, or “m.”) and assign that style to a name tag. I use that concept as part of the Name-Marr-Title tag with its custom Married Name Style which expects their married surname to be entered in the OtherName field. The OtherName is a field not intended to be displayed as part of any standard Name Style. An advantage of a separate custom Name tag type is that the tag sentence can be excluded from printing, but the tag type can still be selected to be included in reports so that this name variation is added to name indexes.38 Thus I generally select my custom Name-Marr-Title tag type to be included in reports and indexes. Selecting this name variation and using the Two Principal sentence variables mentioned above will produce “Mrs. Elizabeth Sark” if only the woman is assigned to the tag and “Jacob and Mrs. Elizabeth Sark” for a couple. I do not select the standard Name-Married tag type to be included in reports and indexes as I only use it in some cases for a “selected” name in other tags.

One problem with most of these alternatives occurs when the married surname has a surname prefix. For the husband, my custom tag type Name-Index provides the capability for index entries both with and without the prefix. One could use my “AllFields” name style with the standard Name-Married tag type to produce both index entries. With my custom Name-Marr-Title tag type in order to produce both entries, I have chosen to enter two of these tags with two “surnames” in the Married(OtherName) field: one with the PreSurname first, and one with the PreSurname last in parentheses (e.g. “van der Gaag” and “Gaag (van der)”. That will cause its two sort entries to match the two husband’s surname entries, one due to his Name-Surname-Sort tag.

I use my custom Name-Marr-Title tag type along with the standard Name-Married tag type to have a tag type with the married title and the maiden surname, but I also keep the standard Name-Married without the title or maiden surname as an option to select for that person for events. Since I prefer the name with its maiden surname instead of only the married surname from the standard Name-Married tag type in indexes, I created the Name-Marr-Title tag type using the (now fixed) single-excluded global sentence of “-<[M0]>[:NP:]” and my custom Name Style of “Married” (see below). I enter the Title appropriate to that language or region to indicate the married status (e.g. “Mrs.” or “Frau”). I usually leave all other name fields blank to inherit the values (including the birth/maiden surname) from the Primary name tag (which I normally leave as the birth/maiden name tag) with only the married surname entered in the OtherName field. Thus when this name variation is assigned to a tag the maiden surname is “available” using the sentence variable [PL], e.g. (née [PL]).39 Occasionally I will include her common given name if her Primary given name is seldom used. I then include Name-Marr-Title but not Name-Married in reports so that the name indexes include the title and maiden surname. Creating this custom Name-Marr-Title tag allows separate Male/Female sentence constructs so the Subject is always listed first. Using the Two Principals separator mentioned for the two templates: Male: “<[P]|[P1F]><|and [P2]>” and Female: “<[P]|[P2F]><|and [P1]>” they will produce for the male “Jacob and Mrs. Elizabeth Sark” and for the female: “Elizabeth and Jacob Sark”. Or alternatively to include the maiden surname but list the Subject first use the two templates: Male: “<[P]|[P1F]><|and [P2] (née [P2L])>” and Female: “<[P]|[P2F] (née [P2L])><|and [P1]>”.40 These templates would produce respectively for each Subject: “Jacob and Mrs. Elizabeth Sark (née Bowers)” and “Elizabeth (née Bowers) and Jacob Sark”.

One added “feature” of this custom Name Style for the Name-Marr-Title tag type is noted if you have set Preferences > Project Options > General > Display surname in CAPS. That causes the contents of the Surname field to be capitalized (in the case of this custom tag that field inherits the Primary Maiden surname) and the OtherName field, although displayed where you expect a Surname, is not capitalized. As an example the Name-Married will display in a surname sort as: “HANNAH, Mary Ann” but my Name-Marr-Title will display as: “Hannah, Mary Ann, Mrs. (née HOWES)”. Thus these married surname entries really stand out as variations in the Picklists and Project Explorer. As this is a separate custom tag I can continue to explore other options for this tag type. Some prefer to set the Name-Married tag as Primary and thus create a Name-Maiden (or Name-Birth) tag type to make its contents obvious for use with event tags prior to marriage. I generally keep the Primary name variation as their full name at birth and set each event tag to select an appropriate Name tag.

Married Name Style Templates
Title [Mrs.]	Appropriate female married title (e.g. in U.S. is usually “Mrs.”)
Prefix, PreSurname, Suffix [Blank2, Blank4, Blank6]	(empty) As I encounter more name variations I may use one or more of these three fields (e.g. a Maiden surname with a PreSurname), but by default I choose to label them “Blank”.
GivenName	(empty) Automatically propagates from the Primary name. If a common Given name is desired it can be entered.
Surname [Maiden]	(empty) Automatically propagates from maiden surname in the Primary name tag. If Primary name is not maiden, must enter maiden Surname to be available as a sentence variable from this Name tag. If maiden name has a PreSurname may need multiple tags. (See also the Name tag type Name-Surname-Sort.)
OtherName [Married]	The husband’s surname (possibly with a PreSurname)41
Output	[Mrs.] [GivenName] [Married]
Surname sort	[Married], [SortGiven] [Maiden]
Surname display	[Married], [GivenName], [Mrs.] (née [Maiden])
Given sort	[SortGiven]•••42[Married] [Maiden]
Given display	[Mrs.] [GivenName] [Married] (née [Maiden])
Children/Siblings	[Mrs.] [GivenName] [Married] (née [Maiden])

As mentioned above I usually exclude Name-Married tags from printing, and define its global sentence as “-<[M0]>[:NP:]” (where <[M0]> is not required but included to make it clear the memo will not output). Since event tags can specify which tag in the Name group to use for Principals and Witnesses in that event tag’s sentences, and it is often desired to output the married name in the narrative for various tags, sometimes with and sometimes without their title, the existence of these different Name-Var tags is usually of value.

To get a list of all females that have a marriage but do not have a Name-Married tag requires two steps. First, set a flag on all individuals (which should? only be females) with a Name-Married tag and either given or surname not empty. Then set a flag for all females where the above flag is not set and a Marriage Group Tag exists. You may need to adjust your filter to check for the appropriate number of such tags for people with more than one marriage. Similar actions can identify those married females who do not have matching Name-Marr-Title tags. See also John Cardinal’s TMG Utility program for creating Name-Married tags.

Include at least the married title in the Title field, and the married surname in the Married(OtherName) field.

If the husband’s married surname includes a non-empty PreSurname field, enter two Name-Marr-Title tags: one with the PreSurname first, and one with the PreSurname last in parentheses (e.g. “van der Gaag” and “Gaag (van der)”

The sentence for this standard tag type was: “[P] was known as [N]< [D]><, [M]>” but I chose to change it to reflect that this is a nickname, and usually select this tag to print. Typically the nickname (e.g. “Bob”) is entered in the GivenName field and the rest of the fields are left blank so that when this name variation is chosen in some other event tag the rest of the fields come from the Primary name (e.g. “Bob Richards”). Some choose to use the Name-Nick tag with a custom Name Style with fixed text of quotes in the Templates around the nickname and enter the nickname in the OtherName field to result in Robert “Bongo” Richards. Both tag type variations could be defined so that either were available for use in tags.

For mononym names, where a single name or phrase is used as if it is both the given name and the surname, I have defined both of these custom tag types and a companion custom Name Style “OneName”. I then enter that mononym text in the Primary Name tag in both the GivenName and Surname fields (which the Name Style labels OneNameG and OneNameS as a reminder the text should be the same). Since these tag types have this Name Style as default, if a new tag is added from the list of tag types it will initialize with that style, otherwise the style should be changed to OneName. Entering the name in this manner with this style will define it so that name variables and indexes in both TMG and Second Site will handle it appropriately. The Name-One tag type is usually set as the Primary name so its sentence is usually irrelevant, but is defined the same as the standard Name-Var tag type. Even though the name is entered twice, because of the Name Style the [N] variable in that sentence will only output the surname field.

The Name-Link-Only tag type is intended for defining an abbreviated name which is used only for linkage within a sentence (for examples see the Cemetery Pseudo People). Therefore its sentence is double excluded as to never output or be included in indexes.43 While the double exclusion does this anyways, I also exclude this tag type from the list of tag types in Second Site to ensure it does not appear in those name indexes, but I can still select it as the name to use in tag sentences. Due to their custom Name Styles defining this tag is especially useful for pseudo people since the name part desired as the abbreviated name is often a name part which does not have a separate sentence variable (e.g. only the prefix or only the presurname). The sentence can choose to use either the given name or the surname depending upon whether or not the typical alternate font selected in reports for surnames is desired. For such pseudo people’s names often a custom local sentence will need to be defined to use this abbreviated name, or an alternative role defined which expects this abbreviated name to have been assigned to this person.

Some have suggested adding information about a non-biological relationship by adding text such as “step” or “stepson of John” in the child’s Suffix field in parentheses to an appropriately named Name-Var tag type. You could then use that name variation with a tag (or make it the Primary name tag) whenever it is desired to reflect that relationship. One might even select whether the relationship text in the Suffix field would print by marking it either excluded or sensitive44 data. I do not currently use this method.

I created this Name tag variation solely for use with all surnames whose PreSurname fields are non-empty due to a a surname article or prefix, e.g. “van der Gaag”. (Do not use this tag type to simply record an alternative surname for a person. Instead use the standard Name-Var tag type as the base of this surname and explain this alternate name.) I choose to have such surnames sort and appear in indexes both with and without the PreSurname value, e.g. both under ‘V’ and under ‘G’. If using the Standard Name Style, a name with a PreSurname will not fully output since those templates do not include the PreSurname field. All such names, with its separate PreSurname, are first entered as a standard Name-Var tag type, but with the “AllFields” Name Style described with that tag type unless a special Name Style has been defined for this naming convention which includes the PreSurname field. Now, I also enter this non-primary Name-Surname-Sort tag to produce the sort without the PreSurname. This tag type defaults to use my special “SurnamePreSort” name style for appropriate display and sort fields for the indexes. Because I generally do not want a separate sentence for this Name tag but do want the name to appear in indexes, I define its sentence as single excluded45, including the memo variable <[M0]> which is not required but included to ensure the memo will not output and provide a non-empty sentence template if output of excluded data is selected. Because it will not output in reports, text in the memo can be used to document why I am including this tag as that text will show in the Details section. Since only the GivenName and Surname will repeat from the Primary Name-Var tag, at least the PreSurname must be entered in its separate field in this tag. If there are any non-empty fields other than GivenName or Surname they must also be entered. But neither GivenName nor Surname need to be entered as those two fields will be inferred. In most of my cases I only need to enter the PreSurname in its field in these Name-Surname-Sort tags. And if I have just first entered it in the AllFields Name-Var tag, the F3 key will repeat it.

I do not use this Name tag variation when I simply want to cause an alternate variation of the surname, such as a standardized or variation in the spelling, to occur in lists and indexes. Instead see the separate Name-Index tag type. For more details about custom sorting of names based on Name Style information, see the discussion of the Effect of Name Styles on Sorting in the Data Entry chapter.

SurnamePreSort Name Style Templates
Output	[Title] [Prefix] [GivenName] [Surname] ([PreSurname]) [Suffix]
Surname sort	[SortSurname] [Prefix], [SortGiven] [Title] [Suffix]
Surname display	[Surname] ([PreSurname]), [Prefix] [GivenName] ([Title]) [Suffix]
Given sort	[Prefix] [SortGiven] [Title] [Suffix] [SortSurname] [PreSurname]
Given display	[Prefix] [GivenName] [Title] [Suffix] [Surname] ([PreSurname])
Children/Siblings	[Title] [Prefix] [GivenName] [Surname] ([PreSurname]) [Suffix]

Similar to my custom Name-Marr-Title tag type, one could have a custom Name-Title tag type in the Name group for other kinds of titles. As noted in my Import/Export chapter, TMG handles import of GEDCOM titles and export of the Title field in TMG Name tags to GEDCOM in a way that data could be lost or confused. This custom tag could be created to help with this GEDCOM import/export issue. This separate tag can also have data entered to allow the exported GEDCOM to more closely resemble an event tag describing the acquisition of the title, with separate source citations, which is the intent of the TITL GEDCOM tag type. The TMG default for GEDCOM import of TITL tag types will be as a Name-Variation tag type,46 and export can be explicitly set for this tag type to the GEDCOM TITL tag type. If there is only one TITL GEDCOM tag, it will be merged on import with the primary Name-Var tag. One advantage of this custom tag type is that due to TMG’s automatic fill of Given and Surname, this custom tag type will produce a separate non-Primary Name variation which would show in name indexes.

If the acquisition of a title is desired to be recorded as an event, a custom Title-Event tag type could be created in the Other group. The export could be explicitly set for this tag type to the GEDCOM TITL tag type. Such a tag type will not have TMG’s automatic fill of Given and Surname, and will not show in name indexes. And as noted in my Import/Export chapter, GEDCOM export of such an event tag type has its own limitations.

I would only create such tags if I had special documentation of the acquisition of a title, or was doing a lot of GEDCOM transfers of such information. I do not currently use either of these tag types for titles. Instead I generally use a standard Name-Var non-Primary tag and have its sentence explain the acquisition of this title.

The sentence of a Name tag marked Primary will not output in most reports, and this tag type is the default used for a person. However, I also use this tag type when I want to assign a selectable alternative name and output a sentence explaining that name variation. Therefore, I changed the sentence of this generic standard tag type in the Name group to allow the split memo to describe the nature of this specific name variation. In general I do not enter a memo in a Name-Var tag which is Primary, only in non-Primary tags whose sentence will output. I also use custom local sentences, along with Sort Dates to ensure their consecutive output order and memos to explain the name variation, when I mention several variations of a name. Each name variation needs a separate tag if each name is desired in the index, which I typically prefer. An example pair of tags for two surname spelling variations might have their pair of custom local sentences as:

I use name suffixes to identify a common purpose for a custom tag type which relates to another tag type. The same suffix can be used to name a custom tag type for a common purpose related to any standard or custom tag type. Thus a custom tag type for the purpose “*Suf” can relate to any tag type, e.g. “Xyz”, by being named “XyzSuf”. Because it is a suffix, the tag type “XyzSuf” will sort next to the tag type “Xyz” in the Master Tag Type List as a variation of that main tag type.

This suffix has been proposed to record alternate data for any tag, e.g. BirthAlt, DeathAlt. Others have suggested a name made by surrounding the standard tag type name with parentheses, but I prefer suffixes. For example, you might have conflicting information about a birth or a death, and alternative theories can each have their own tag with their own cited sources. By giving it a separate tag type name instead of using multiples of the same named tag for the alternates, you can selectively exclude this tag type from reports but leave the main. As you conclude that one alternative is more likely, make it the Primary in the group along with some note why. The order of the alternatives can be controlled by sort dates even if the “Primary” is interspersed with the alternates.

A tag type with the *Assume suffix is used when I want to create a BMDB tag type (or any other tag type for that matter) for a person, have some degree of uncertainty concerning the documentation for that event, but can make some statement about it based on either probabilities (e.g. probable age at marriage) or other secondary but possibly unreliable data (e.g. census data). I create these *Assume tag types in the appropriate BMDB group with special sentences that reflect uncertainty associated with this event, e.g. BirthAssume, Marr Assume, etc. I cite any documentation that may have led me to make this statement and usually put a comment about the basis for my statement in the memo. Later when I have primary documentation or evidence I think is likely acceptable by most anyone, I can just change the tag type to its “standard” type in that group whose sentence simply states that the event did take place. In the meantime the people and events sort into what are probably appropriate time spans since they now have a tag in the BMDB groups. Since these tags indicate I need further research and data, as of Version 8 I use a common color highlight for all *Assume and *-Can tag types.

These tag sentences use the term “presume” but also have a split memo to allow an appropriate term for each data part whose accepted definition in the language accurately reflects my degree of uncertainty. The words/terms I use vary on my scale from no evidence to full evidence. The following terms are expressed as verbs, but I also use equivalent adjectives or adverbs as appropriate.

• Assume—No evidence but based on my analysis of the (lack of) data - synonyms: accept, ascertain, assert, believe, conjecture, deem, estimate, expect, guess, hypothesize, imagine, posit, postulate, presuppose, speculate, suppose, suspect, theorize, think. I seldom use this term as I usually have at least some evidence or probability on which to base my statement.

• Presume—Limited or incomplete evidence, or simply based on probability - synonyms: consider probable, infer, believe likely, maintain, predicate, surmise, understand. This is the default term in the sentence for these tag types for my overall statement of the event.

• Deduce—At least some related evidence - synonyms: adjudge, appraise, assess, derive. I am likely to use this term associated only with a specific part of the statement, such as the date or location.

• Conclude—Significant to me though possibly incomplete or unreliable evidence - synonyms: attest, decide, determine, discern, establish, judge, reason I am likely to use this term associated only with a specific part of the statement, such as the date or location.

One suggestion47 concerning such statements of uncertainty (which I do not currently use) was to enter notes in the memo listing multiple sources chronologically according to the date on which the data was given. The first line of the notes would indicate your current statement and level of uncertainty. If you did not want these notes to print in your narratives, you could use a split memo, and have these notes in a trailing memo segment that was not in your sentences. Can also include a code of the source type, e.g. marriage (m), death (d), and births of children (b). To keep each source’s note short it was suggested to use the “less than” designator to indicate the implied date for this tag based on the data in the source and the source’s own date (e.g. “34 = <1 June 1829” means that the source recorded the age as 34 and the date of the source is 1 June, so this implies the date for this birth tag would be during the year before 1 June 1929). For example, a single BirthAssume tag where all the sources only had ages might have its memo summarizing multiple sources by:

presuming b. c. 20 Sep 1827
1850 census = 22 = <1 June 1828
1860 census = 34 = <1 June 1826
1860 vitals (m) = 22 = (maybe should be 32?)
1861 vitals (b) = 34 = <28 Sep 1827
1862 enlistment (CSR) = 30 = <6 Aug 1832
1866 vitals (b) = 28 = <7 Aug 1838 = (maybe should be 38?)
1870 census = 46 = <1 June 1824
1880 census = 52 = <2 June 1828
1886 vitals (m) = 54 = <22 Sept 1832 = (maybe should be 58?)
1888 pension + app = 58 = <31 Oct 1830
1891 vitals (d) = 63 = <14 Sept 1828

These suffixes have been proposed for tag types (such as Birth, Marriage, Death, etc.) which only cite data about this one aspect of the event, and thus can have appropriate default sentences reflecting this one piece of data. Set the sort date to print after the standard tag, if there is one. By having separate tags you can use the sort date to order the sentences or select whether they print and thus improve report output. Alternatively you could just enter additional non-Primary tags of the standard tag type without a suffix, plus set the appropriate witnesses, sort date, surety and non-standard sentence. But the separate names allows for selectively including or excluding these tag types.

A tag type with this suffix is used to hold data and citations associated with the base name of the tag type whose output can be controlled by the overall exclusion option. Thus the sentence templates begin with a single exclusion marker. The name provides a clear reminder that this is special information which may or may not output. The separate tag type makes it easy to change to a different base name tag type if the sensitivity of the data changes. While such tags could be excluded from most output by not selecting these tag types, I prefer all these tags to be controlled by the report or site exclusion option. My current examples are the general purpose AnecdoteExcl tag type, the TranscriptExcl tag type and the Num ChildExcl tag type, but this suffix could be used with any tag type name. If I had several tag types with this suffix I would probably use a Version 8 color highlight to further identify such types, but currently use the color highlight of the base name tag type. (See also the *Sens suffix.)

I typically create these tag types in the appropriate group for research about the event so it can be simply changed to the “normal” tag without the suffix when the desired information is found. However sometimes a tag group automatically implies something to TMG (like Birth/Marriage/Death groups), so I choose to create them in the Other group for those cases. This is one method for identifying the need for research about a given event (e.g. BirthFind). Some prefer using a custom “Research” or “ToDo” role in the standard tag, but I prefer the separation available by using separate tags. For recording source information that the event did not take occur in a particular manner see the suffix *Nil. As of Version 8 I use a common color highlight for all such tag types since these Find tags need further research and data, and to distinguish them from their normal tag types. While each of these custom tag types is unique, I generally use [M1] to indicate what type of source should be checked, [M2] to record the details (such as age or name used at that time) that will help in searching that source, and [M3] for an optional comment usually describing why I am looking for this information at this location and time.

If there are one or more likely sources (possibly attached to repositories), I will cite them to the tag, and can include in the Citation Detail where I expect to look within that source. (See also other ideas about unknown sources.) If they exist for a likely source, I usually choose to link my source and/or repository pseudo people describing where I intend to look using custom Witness roles source and repository. (As a repository code is included in the attached Task, that is usually sufficient for my purposes to filter for research as a specific repository.) These custom role sentences generally include all the above Memo parts as well as their own [WM]. However, such a Witness role cannot/should not be used when the tag is defined to have “real” witnesses and its sentences include [WO] which would then also include the pseudo person. In addition to avoiding [WO] in sentences for these tags, one could have sentences that use specific roles and use [R:Rolename]. Another alternative to allow the use of [WO] is if the pseudo person is Principal2 and not a Witness, like my CensusFind tags. Could define a custom role for the linked people (e.g. ToDo, Research) so this is shown on the PV of that person, but I find the tag name sufficient reminder. Other possible suffix names for these tags are *ToDo or *Research. See also the use of these tags with the Research Log and my custom FIND flag.

This suffix is proposed for a separate tag type for attaching an image exhibit associated with a particular event so you can selectively choose whether and in what order these tags print. Such tags are similar to my custom Transcript tag, providing a way to attach a scanned image from a given source. Individuals that are in the image can be linked as witnesses. Need to decide how to record “meta” data about the image itself such as: title, place and date taken, where stored, condition, format, etc. One suggestion from the ListServ has Principal Sentence: “[:CR:][:CR:]<Reference no: [BOLD:][D][:BOLD]><[:CR:]Title: [L2]><[:CR:]Format: [L9]><[:CR:]Where Taken: [L3]><[:CR:] Date Taken: [L4]><[:CR:]Stored: [L5]><[:CR:]Condition: [L6]> [:CR:][M] [:CR:]” and Witness Sentences: “[W] was in the photograph <[D]>”. This suggestion uses place fields for certain data, and that is different than usual and might cause problems or suggest a custom Place Style. I would probably use a split memo instead of using the place fields in this non-standard manner.

There are two reasons for such a suffix on a tag type name. The first is to document negative research, e.g. BirthNil to document that no birth records exist for this person at this time or place. A custom tag type is created, usually in the Other group, to show likely records do exist and were checked to confirm the absence of documentation about this event, with an appropriate sentence. The date of this type of *Nil tag should be associated with the event date attempted to be located. The other is to record actual negative data, e.g. Marr Nil to show this person was known to never have been married or not be/been married as of that date. A custom tag type is created in the appropriate group to document that an individual is known to not have this event, with an appropriate sentence. I have not had to define a tag type of ChildrenNil as suggested by some users since my customization of the NumChild tag can be used for that purpose. The date of this type of *Nil tag should be as of the source that specified the negative data, e.g. “As of [D] [P] was known not to ever have been married.”48 (See also my custom *-Nil relationship tags.) The sentence might be better with [P]first for pronoun substitution as “[P] had no known spouse and was probably unmarried <[D]> <[L]>” and use a date form of before or between. Could be used whether the person had children or not.

A tag type with this suffix is used to hold sensitive data and citations associated with the base name of the tag type. The name provides a clear reminder that this is special information, and such tags can easily be excluded from most output by not selecting these tag types. The separate tag type makes it easy to change to a different base name tag type if the sensitivity of the data changes. My only current examples are the general purpose AnecdoteSens tag type, the TranscriptSens tag type and the Num ChildSens tag type, but this suffix could be used with any tag type name. The sentence templates include embedded codes for both Second Site and TMG to color all the tag’s sentence output to make the sensitivity of the data clear should the tag be selected for output. I use a color highlight of red text on the background color of the base name tag type to make these tag types stand out on the screen. Since Second Site never outputs any data marked with TMG sensitivity braces, using such custom tags instead of sensitivity markers allows control over the output of such tags while allowing them to output in either TMG or Second Site. As I use Second Site as my primary output, such custom tag types now provide an option to include such data in a private site as well as in private TMG reports. Thus I seldom use sensitivity markers. (See also the *Excl suffix.)

A tag with one of these suffixes could summarize a set of similar tag types with a custom single narrative, and then define this tag type to print and the other tag types non-printing. Alternative ideas are to have a tag type simply named Summary, Narrative, or Text, to be used for a single custom narrative for this person using information from multiple tag types to avoid the repetition of autogenerated sentences. All other tag types could then be selected to not print.

I retained but customized this standard tag type in the Address Group along with defining a custom ResidedAddress tag type also in that group. My Address custom sentences expect to indicate where the linked people are now or were associated with a single particular date, and the ResidedAddress sentences where they once lived for a defined period of time with a beginning and end, or with a prefix like “before” or “after” associated with a known beginning or ending. (To describe a move from one address to another see my Moved tags, and my customized Immigratn and Emigration tag are used for a change in country.) Having these two tag types in the same Address group can allow a “now” to very simply be changed to “then”, with a date range, by changing the tag type. I could (but don’t currently) use the date I last identified the information as the [range end] date in Address and record the known date range in ResidedAddress. Notes were once given on the ListServ to provide a method to use the Version 4 and earlier Address tags to generate a mailing list. Now it is simply a matter of generating a List of Events report to a Comma Separated Value (.csv) file type, set the Options to output the appropriate Output Columns, and import that file into a program designed to generate mailing lists from such a file. Due to my usage, Location and Date are required entries for these two tag types in the Address group, and my sentences reflect that.

For both of these tag types, [M1] provides details of the location. The various custom Principal and Witness roles are intentionally similar to the Moved and Emmigration/Immigratn tag types. If there is only one head of the residence they are entered as the role Principal but if they are a couple with the same surname the role Couple is used for both. [M2] is a single optional comment for the Principal(s) and [M2] is for the P1 Couple male with [M3] for the P2 Couple female. The Witness role child is defined separately so that the sentence can use their Given names only. The Witness role resident is defined for others also resident at the location. Both of these Witness sentences include [M1], but provide their own optional [WM].

Both of these tag types in the Address group have a custom role of EMail which is used to identify the address of only one Principal. The entire sentence is surrounded by sensitivity braces49 since I currently consider this information sensitive due to the likelihood of e-mail spam. I prefer this as a role in these tag types although others may prefer a separate custom tag type.

I use these tag types for general purpose data about the person when there is no specific tag type for that purpose. Their sentences all consist of just the Memo fields [M] and [WM] for output for complete flexibility. The standard Anecdote tag type sentences have no additional formatting. The custom AnecdoteExcl tag type sentences also consist simply of the Memo fields, but this tag type exists for tags and information which I wish to be controlled by the general exclusion option in both reports and sites. As such its sentence templates begin with a single exclusion marker. The custom AnecdoteSens tag type has its tag name colored and its sentences not only begin with a single exclusion maker but also have formatting to color the text in both TMG reports and Second Site pages as for all *Sens types. Further its sentences are designed the same as the Note tag type, as I choose to output it in Second Site in the tag group with Notes rather than with the narrative. This special tag type exists for truly sensitive information.50 I seldom select this tag type for anything other than private TMG reports and Second Site sites. But even if selected it will not output if the excluded output option is not set.

I could use this standard tag type to associate “real” people with “pseudo” person such as with a pseudo index person of a surname, or a link to a pseudo person that groups people for some reason such as an unproven but potential family. I have changed its sentences to allow more flexibility with the use of a split memo. [M1] provides details about the association and [M2] provides details about the location in both the Principal and Witness sentences. [M3] is an optional trailing comment for the Principal(s), [WM] for each Witness. For any projects created before Version 8 the GEDCOM option of this tag type should be changed from exporting as an ASSO GEDCOM tag to the more general EVEN GEDCOM tag, or much data may be lost.51

When you come to a conclusion concerning some information about a person based on bits and pieces of other data, but no one piece of data directly provides the information, you could enter it using a custom Author tag type (as author of the genealogy data/report). It could have no Witnesses, and the main sentence could mostly point to the memo. The memo could indicate whether this data is based on my knowledge, conclusion, assumption, or guess. Since one must have a source to specify surety, one could cite a generalized source named “my conclusions”. An actual source document could exist such as an essay written by me describing how the conclusions were reached. This Author tag provides a place for a single overall narrative describing my assumptions or conclusions about the person. See also my *Assume tags.

I chose to define a slightly more complicated sentence using a multipart memo. As a “lumper” the ability to split a memo into multiple parts allows me to use each part for a separate purpose to provide the variable information for the sentence of this single tag type, optionally also including conclusions of relationships of the Principal to Witnesses. [M1] is my conclusion about the Principal, [M2] generically about the relation to [WO], [M3] about the date and location, and [M4] a final optional comment. [WM1] is the conclusion about the Principal from this witness’ perspective, [WM2] relates the Principal to this Witness, [WM3] is about the date and location, and [WM4] a final optional comment for this Witness.

The standard Baptism tag type is in the Birth group. Create a custom tag type of BaptAdult with an appropriate sentence for this event in the Other group so that this tag’s date will not be used as birth in the absence of a birth tag for computing ages. The sentence works for either one or two Principals. [M1] provides details about the baptism in both the Principal(s) and Witness sentences. [M2] is an optional comment for the Principal(s), [WM] for each Witness. I have set this tag type to export using the standard GEDCOM tag type CHRA rather than either BAPM for baptisms or CHR for christenings.

Added as a custom tag type to the Other group, its sentences require a Location and Date and use [M1] to indicate what should be checked for a baptismal record, [M2] to record the details such as name or parents, and [M3] for an optional comment. The Witness roles source and repository are also defined to link to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

I changed the sentences of this standard tag to a more general purpose tag with the potential for expanded text. [M1] provides for optional information in front of the date (“two years after birth”), [M2] optionally precedes the location in the sentence since I prefer the flexibility of sometimes putting the name of the church here rather than as part of a location in the MPL, and [M3] has optional comments. The Witness sentence now has the optional [WM] memo. Similar to the Birth tag type, I added [PAR] to the standard Principal sentence, deleted the role Child, added the Principal role ChildOnly for a sentence without the parents and moved that role to be first and default. I only use the Principal sentence with the parents whenever I do not have a companion Birth tag and the Baptism tag is the Primary tag in the Birth group. I also modified the sentences to reflect that only one person may be assigned as a Principal to a tag in the Birth group. I have not (yet) chosen to create multiple roles for witnesses, e.g. godparents, pastor, etc. If I find the need, rather than multiple specific roles I would likely modify the general Witness sentence to have a split Witness memo part identify the role similar to my general CensusEnum tag type.

Added as a custom tag type to the Other group, its sentences require a Location and use [M1] to indicate where I looked, [M2] to record the details I used for the search, and [M3] for an optional comment. The Witness role source is also defined to link to the appropriate source pseudo person.

While this tag name is for a standard tag type, in my projects this is actually a custom tag type in the Birth Group. As described below I renamed the standard tag type to BirthAssume so that custom-named tag type with its custom sentences would be created when using the TMG Hotkey (Ctrl-B). I then created this (custom) type based on a copy of the standard Birth tag type with the standard name and more standard sentences to be used when the birth data was known.

Non-standard features proposed concerning this standard tag type include custom witness roles such as midwife. Some also choose to add the parents as Witnesses to their children so that some text about the birth appears in the parents’s narratives. (See also the BirthPar tag type.) For this (custom) tag type I added the [PAR] variable to the Principal sentence as they are usually known if the birth information is known, deleted the role Child, and added the Principal role ChildOnly for those cases where I want a sentence without the parents. I also use the split memo to allow separate text before the date and location. Note that the [M3] text is expected to start a new sentence due to the automatic punctuation following either the [L] or [PAR] text. For an explanation of my use of the custom Witness role multiple see the discussion about Twins and Multiple Births. As of Version 8 I color highlight this tag type.

If there are no printable fields (Memo, Date, Location) entered in the Primary tag in the Birth Group, that tag will not appear in TMG narratives, even though the sentence preview would make you think it should. You can force such a sentence to appear as long as the sentence at least contains a conditional memo variable. The trick is to enter text in the memo, but use the text that will cause TMG to treat that memo as empty. (For details see the topic Empty Split Memo Parts in the Tag Sentence Details chapter.) If the sentence contains the <[M]> (or <[M1]>) conditional memo variable, this tag with no (other) printable fields entered now will still output.

The feature of a tag in the Birth Group not being output due to no printable fields entered can be of use for the creation of such tags with Sort Dates the only field entered, in order to sort the children of a couple correctly when no dates are known and you don’t wish to estimate one or wish to output any birth narrative. (While TMG will always omit such birth sentences, in Second Site omitting these otherwise empty tags in its narrative is an option on Data/Database.) The BIRTH ORDER flag was a feature introduced before the Sort Date in the development of TMG and could be used instead for this sorting effect. However, the use of the BIRTH ORDER flag can give some unexpected visual outcomes (screen versus reports), whereas use of the Sort Date (making sure no Birth Order flag is set for any child in the family) gives consistent Detail View, Reports and Chart output.

Since I usually do not select my custom Census tags for output in many formal reports, I try to make a point of citing these sources at least once to a tag which will be selected. Most typically I cite this source on whatever tag I am using in the Birth group, since Census data usually includes some indentification of the person’s age which is an indicator of the birth date.

I have made this custom tag type name the default for the TMG Hotkey (Ctrl-B) by renaming the standard Birth tag type. When I am adding a new person I am usually “presuming” a birth date or location before I have reliable citations to prove this data, so this tag type is used by default. I also created a custom tag with the standard name Birth and appropriate standard-like sentences. In that way the default tag type can be this named type with its custom sentences, but I can change the tag type to the custom Birth tag type to use its sentences when I cite appropriate information. If there are no printable fields (Memo, Date, Location) entered in the Primary tag in the Birth Group, which is likely this tag type, that tag will not appear in TMG narratives even though the sentence preview would make you think it should. For more details see the discussion in the Birth tag above.

Depending upon what optional information is included, the sentences for this custom named tag type reflect a presumption about the date, location and/or parents. I use the split memo to allow separate text before the date and location, often to indicate my basis for the statement about this data. If the [M2] text following the date contains some explanation of the date (e.g. “based on the birthdate of his son”) then end the text with an escaped comma (i.e. “\,”) to separate it from the following location (so it doesn’t read like the son was born in that location). Note that the [M3] text is expected to start a new sentence due to the automatic punctuation following either [L] or [PAR] text. Like the Birth tag type, I added [PAR] to the default Principal sentence as for information even though this couple may be “presumed”, added the custom Witness role multiple, and added the Principal role ChildOnly for a sentence without the parents. If birth data is confirmed I can easily change to the (custom) Birth tag type with its more standard sentences since it is also in the Birth group. As of Version 8 I use a common color highlight for all *Assume and *-Can tag types.

Added as a custom tag type to the Other group to avoid it defining a birth. Thus when found a tag in the Birth group will need to be created rather than changing this tag’s type. Its sentences require a Location and Date and use [M1] to indicate what should be checked for a birth record, [M2] to record the details such as name or parents, and [M3] for an optional comment. The Witness roles source and repository are also defined to link to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

I added [PAR] to the Principal sentence of this standard tag type, deleted the role Child, and added the Principal role ChildOnly for a sentence without the parents.

The standard MULTIPLE BIRTH flag can be used to indicate a person was one of multiple children born together. I do not choose to use this flag and have deactivated it. If you want sentences saying that the individual is a twin (or triplet, etc.), one could define a separate custom tag type such as Twin identifying P1 and P2, either in the Birth group or more likely in the Other group. One could extend this separate tag idea to define a Triplet (and Quad, etc.) tag type using [W] (and [WO]) or use roles.

Rather than a separate custom tag type, I prefer including a comment identifying the sibling(s) in each multiple birth person’s Birth tag split memo, and have defined the role multiple in the Birth tag (and BirthAssume tag) for same date birth siblings as witnesses to each others birth tag. For example, for twins I include the text “along with [PP] twin [RF:multiple]” in split memo part [M1]. The Witness sentence for role multiple is double excluded since each child’s own Birth tag will have the equivalent multiple birth sibling reference in its split memo part [M1].

If I am careful to ensure that all Birth group tags have reciprocal multiple witness set, then I don’t need the flag as I can find all multiple birth people with a filter of:

This custom tag type (not flag), in the Birth group, can be used where the only information known is that “he was born the second child” or “third son” and can have an appropriate sort date to have the individual list in the appropriate order in parental lists of children. Some have proposed separate tag types (e.g. BornFirst, BornSecond, etc.), or separate roles in a BirthOrder tag type to define the order. I use a sentence on this single tag type where [M1] (and [WM1]) is required and provides the order information, and [M2] (and [WM2]) provides an optional comment.

I find using this tag type more complete than just setting the BIRTH ORDER flag as it provides this birth sort date, and allows citations to document how I know this order information. A tag in the Birth group, like this one, with a sort date will accomplish proper sequencing of offspring in the display and reports. Like the Birth tag type, I added [PAR] to the Principal sentence, and added the Principal role ChildOnly for a sentence without the parents.

One concern about the standard Birth tag type is that the birth event of a child is not included in the narrative of the parent in most TMG narrative report formats. Some have proposed defining custom roles with custom sentences in that tag for the parents and then assigning them as Witnesses to their children’s birth. Depending upon your reports and report options this may cause more problems than it solves. I recommend a separate custom tag type in the Other group, such as this BirthPar tag type, as providing more user control even though it requires entering and coordinating two tags. A separate tag type can be selectively included or excluded from reports, and added or not for a given child. Its sentences expect the child to be the P1 Principal, and the parents are both assigned the custom Witness role parents if both are known, or either mother or father if only one is known, with appropriate sentences.52 [M1] occurs before the required Date field to optionally describe the birth in all sentences, and [M2] occurs before the optional Location. Each [WM] is an optional sentence unique to each parent. As of Version 8 I use a common color highlight for the BirthPar and all *-Bio tag types.

A birth record can often be filed much after the actual birth for a variety of reasons, including creating a new birth record with an adopted name. By placing this custom tag type in the Other group, it does not confuse BMDB and age computation issues, allowing a tag date for the actual filing rather than the birth date, with an appropriate sentence describing this unusual and out of normal time sequence event. [M1] provides the details of the filing and [M2] is an optional comment. Like the Birth tag type, I added [PAR] to the Principal sentence, and added the Principal role ChildOnly for a sentence without the parents.

I added [PAR] to the Principal sentence of this standard tag type, deleted the role Child, and added the Principal role ChildOnly for a sentence without the parents. Because this tag is in the Birth group, a companion tag in the Death group is required to provide a lifespan and clearly show the individual is not living. Since the sentence for the BirthStill tag makes the situation clear there is no need for additional text. Thus the custom role of Stillborn should be used in a Death tag to exclude output from that tag. As of Version 8 I color highlight this tag type.

Remember to also include a Death tag type with the role of Stillborn so that there are tags in both the Birth and Death groups

If you do not expect to have multiple tags about burial, with the need to designate one as Primary, or do not want to have both Death and Burial data output to those reports that only output Primary tags, or do not need to define two principals on the same Burial tag, then you may not want this standard tag type to be in its separate group, where it is by default. However, if I have separate burial data I generally want the separate Burial tag in its separate group apart from a death tag.

A gravestone or memorial photo is a common image exhibit on any tag type which documents Burial. Some gravestones include multiple people, such as commonly having both husband and wife. While I enter a separate tag (with likely different dates) to document the burial of each person, I prefer to have any Second Site exhibit page of the gravestone to show back-links to all people mentioned on the memorial. For this reason I have created the custom witness role of jointstone for any person also mentioned in the exhibit but not otherwise already linked to this tag. (See also the description of the information to be entered in the exhibit fields.) If there are other witnesses to this tag, such as a Cemetery pseudo person, be sure to order the jointstone witnesses first in the list so they will group with the Principal of this tag in the Second Site back-links. For the DeathAssumeBur tag type, if the spouse is already a widow(er) Witness, there is no need to add that person again as a Witness with the jointstone role (and TMG will prevent the duplication) since the spouse will already be a back-link on any exhibit attached to this tag whether or not they are also on the stone.

Instead of only using some custom burial tag within the Death group, as an additional alternative to the standard Burial tag in the Burial group, I have defined a custom DeathAssumeBur tag in the Death group.53 This tag combines into one tag my custom DeathAssume tag and the standard Burial tag. (See also my DeathAssumeCrem tag below for combined death and cremation. I may need to generalize these tag types, or create new tag types or roles for other dispositions of a body.) I use this custom tag type when the only documentation I have is from a burial but do not (yet) have any explicit documentation about the death. However, the burial can “presume” the death of the buried single Principal. For me this is often faster/easier than entering the two equivalent tags: DeathAssume and Burial especially for people not in a lineage of primary interest. Since it is in the Death group, the tag name DeathAssumeBur sorts among Death tag types. It should be read as “an assumed death and a known burial” since the default sentences are designed that way. As of Version 8 I color highlight the Burial tag type as known data but the DeathAssumeBur as a *Assume tag type since I still am looking for more documentation about the death.

Whenever any tag is added in the Death group, TMG will automatically set the LIVING flag to ‘N’. This “non-living” implication exists only for tags in the Death group. When a chart is to print a death date, the date from the Primary tag in the Death group will be used. A tag with a date in the Death group also permits using an age sentence variable to identify the age at death. To take advantage of all these automatic features is the reason I created DeathAssumeBur in the Death group. One disadvantage of using this custom tag type is if I later find death documentation, moving this burial information from the DeathAssumeBur tag to the separate Burial tag is more difficult since they are in different groups. Thus for individuals whom I expect to search for that additional documentation I am likely to do the extra work up-front to create the two separate tags.

For most married females I try to make a point to set their selected name on all tag types involving burial to the name used in the records or on the memorial, usually selecting the name variation provided by my custom Name-Marr-Title tag. Using this name variation is especially useful for reports of all interments at a specific site as these women are invariably recorded using their married names, but it also provides access as a variable to their maiden surname. These reports are either made as an Individual Narrative of a pseudo Cemetery person, or as a filtered List of Events filtered for both types of burial tags and possibly also filtered for a specific cemetery by an MPL location or a name in the Memo. Thus in these columnar LOE reports I choose “Prin1 Last, Given (Selected)”54 to show their married names, e.g. “Mrs. Mary Jones”.

The Burial tag only documents the burial itself so in its custom sentences [D] is the date of the burial, [L] is the burial location, and [M1] provides the details of the burial (e.g. “following services in the village church”). Note that if later memo parts have text and [M1] is empty it must contain the special Tab character placeholder so it will be treated as empty.55 If I do not have documentation for the burial date I leave the Date blank. I always set the Sort Date to ensure the tag comes after any Death date, even if an actual known burial date is the same day. I always have at least a Sort Date in my Death tags. Thus, if the Burial date is the same date or unknown I use the same Sort Date from the Death tag (even if it is a ‘circa’ approximation) but append a question mark ‘?’ to cause the Burial tag to sort after Death. It looks odd to have a narrative relate burial before death (unless that is known to occur!).

Since I would normally only have a standard Burial tag when I also have a death tag, the Burial tag default role for the Principal is my custom JoinDeath with a sentence that will concatenate with the death tag sentence that it expects to immediately follow.56 If the burial sentence should be separate, I use the standard role Principal. The roles JoinDeath and Principal will insert the automatic preposition for the location, but the roles JoinDeathL and PrincipalL do not.

The memo parts [M2] and [M3] are optional extra burial comments for the Principal, where [M2] is often the name of the funeral home performing the burial (e.g. “by the Neekamp funeral home”), and [M3] often some separate informative sentence about the grave (e.g. “The infant’s grave is next to her father’s, Samuel K. Jones”).

If this cemetery is entered as a pseudo person, then it should be linked as a Witness with a Cemetery Witness role selecting its Name-Link-Only name, both so that this person’s burial will be listed in that pseudo person’s narrative, and so that this burial sentence will produce a Second Site link to that pseudo person. [M4] is semi-optional qualifying text. It either qualifies the preceding burial date (e.g. “following 9 a.m. services in the church”) and/or qualifies the following linked cemetery or burial location. The cemetery should either be linked to its pseudo person or named last in [M4] but not both.57 If not linked the cemetery name should be entered last in [M4] (e.g. [M4] “in lot K-4 in Paradise Cemetery” versus simply “in lot K-4” when linked). If the cemetery will be linked it should never be included as part of the MPL location record so that Second Site will provide separate hyperlinks to the cemetery person itself and the place record. While many cemeteries may be “in” (my standard report preposition for locations) a location such as a city or village, many burial grounds are often neither “in” nor “at” an MPL location. Thus [M5] can provide an appropriate preposition or phrase (e.g. “12 miles southeast of”) in front of the MPL location when used with an ‘*L’ role. However, if not within an MPL location, I usually try to use the larger surrounding MPL entry in which the cemetery actually resides.

The DeathAssumeBur tag sentences combine the typical roles and sentences of a presumed death tag and a known burial tag, with [D] as the death date, [L] as the burial location, and [M1] providing details of the presumed death (if any known, e.g. “probably while fighting during the Civil War”). (If I have separate details of the burial such as its date, or of the death such as its location, then I use separate Death(Assume) and Burial tags.) Note that if later memo parts have text and [M1] is empty it must contain the special Tab character placeholder so it will be treated as empty.58 If either the Birth or Death Dates are imprecise or have a modifier, it is also better to use the two separate tag types as this avoids the potential issue of the [AE] variable.

Although the sentence of this custom tag for the standard role Principal includes the age variable [AE]59 and widow(er) role variable, like the DeathAssume tag type the default Deceased role does not. Since the role Deceased presumes less known data (e.g. probably an approximate date), that role is the default. The tag will usually have some kind of Date, but like all tags in the Death group should always at least have a Sort Date, and if it is a conditional date use a role (such as the default Deceased) which does not output an age at death. The roles Deceased and Principal will insert the automatic preposition for the burial location, but the roles DeceasedL and PrincipalL do not.

Like the standard Burial tag type, the memo parts [M2] and [M3] are also optional extra burial comments for the Principal as described above.

If this cemetery is entered as a pseudo person, then it should be linked as a Witness with a Cemetery Witness role selecting its Name-Link-Only name, both so that this person’s burial will be listed in that pseudo person’s narrative, and so that this burial sentence will produce a Second Site link to that pseudo person. [M4] is semi-optional qualifying text. It either qualifies the preceding burial date (e.g. “following 9 a.m. services in the adjacent church”) and/or qualifies the following linked cemetery or burial location. The cemetery should either be linked to its pseudo person or named last in [M4] but not both.60 If not linked the cemetery name should be entered last in [M4] (e.g. [M4] “in lot K-4 in Paradise Cemetery” versus simply “in lot K-4” when linked). If the cemetery will be linked it should never be included as part of the MPL location record so that Second Site will provide separate hyperlinks to the cemetery person itself and the place record. While many cemeteries may be “in” (my standard report preposition for locations) a location such as a city or village, many burial grounds are often neither “in” nor “at” an MPL location. Thus [M5] can provide an appropriate preposition or phrase (e.g. “12 miles southeast of”) in front of the MPL location when used with an ‘*L’ role. However, if not within an MPL location, I usually try to use the larger surrounding MPL entry in which the cemetery actually resides.

Similar to the Death and DeathAssume tag types, because of possible options with [M4] and the two types of Principal roles to deal with a location preposition, I do not include the [L] variable in either the widow(er) or Witness roles. In addition to including the main [M1] for the death details there is an optional [WM] for comments. The widow(er) witness role is only used on the tag if there is a surviving spouse. It provides text in the surviving spouse narrative concerning the presumed death of the spouse so that a subsequent marriage sentence makes sense.

In addition to the potential problem with the [AE] variable, a disadvantage to DeathAssumeBur in the Death group is that the keyboard shortcut (Ctrl-U) cannot be used to add this custom tag type, the shortcut will always try to add the original Burial tag type in the Burial group even if it were inactivated. Another disadvantage is that some reports and charts (e.g. the box chart) only print the Primary event from a select set of tag groups, so you would not have a tag in the separate Burial group, and only get this one tag from the Death group. The main advantage to me for this custom tag is quicker data entry and you do get a death date as you would with a Death(Assume) tag.

For all four tag types that refer to a Burial or a Cremation, I have added61 the Witness roles cemetery and cemeteryMrs so that these tags may be linked to pseudo Location people that are cemeteries/crematoria. I only create such pseudo people for those few locations where I have found many of my ancestors, I wish to record further notations (via custom tags) about that site, and I wish to be able to easily make a report of all interments at that site. Otherwise I simply generate an LOE report as mentioned above as that report will include all interments. If this Witness is linked, the link should always select the Name-Link-Only name for that pseudo person as the global sentences are designed to only output the Given name to avoid the use of the special font most reports output for surnames.

In contrast to their companion DeathAssume* tags in the Death group, the standard Burial or Cremation tags in the Burial group often do not have any value in the Date field (as opposed to the Sort Date). And if these burial/cremation tags do have a date it records the date of that separate event, not the death. Thus the death date cannot be output by using a date variable in an Individual Narrative of the pseudo Cemetery person, and the age at death cannot be output by using the [AE] sentence variable, two common values which are often included on memorial stones. Yet linking a Cemetery witness to a DeathAssume* tag type can usually give appropriate date and age information since the tag date will be some kind of (presumed) death date. But note the sentence may need to be locally modified if the dates are incompete or have modifiers since Second Site will either compute the age differently or not output it.62 However, there is a reverse problem concerning location when linking a Cemetery witness to a Death group tag. That tag’s location is the (presumed) Death location, which is often different than the Burial/Cremation location and can cause problems with Place indices.

For better accuracy, and to avoid potential issues with the [AE] variable, two separate tags in the respective Death and Burial groups should be used. When I have both a Burial/Cremation tag and a separate tag in the Death group, I link a Cemetery witness only to the Burial group tag and not the Death group tag, even though the Death group tag will almost always have some kind of death date.

To improve the data in the Individual Narrative of the pseudo Cemetery person, the witness sentence template for a Cemetery witness contains conditional witness memo split parts to record this “expected” memorial data. The sentences of the DeathAssume* tags can access the death date and compute the age, so any separate burial information should be entered in this memo. However there may be issues with the [AE] variable. Conversely the tags in the Burial group can only access the burial/cremation date, so the death date and age data should be entered in their memo. Any known birth date is not accessible to either tag type and should be entered in the memo as that is often recorded in burial/cremation records. The sentences for a Cemetery witness necessarily differ between the tag types in the Death group and the Burial group to reflect the differences in what data is accessible from that tag and what needs to be entered in their memo.

First, if the Principal to the tag which assigns a pseudo person Witness to a Cemetery role is a married female, and I have added and assigned my custom Name-Marr-Title to this tag for her, both her married and maiden surnames are available as variables. [P+] (which is the default variable in these sentence templates) will output her title, given name and married surname, but [PL] will output her (Primary) maiden surname.63 Thus for such women I select the custom role of cemeteryMrs for this Cemetery pseudo person which uses a sentence template with the text “ (née [PL])” after [P+] at the beginning of the template to output both surnames.

If any witness memo parts to the Cemetery Witness sentence are added and there is no burial/cremation Date on this tag, [WM1] should not be empty so it can trigger appropriate punctuation of the output, and may often require leading punctuation to follow the name(s) (e.g. “; plot 3A”).64 My data entry convention is to use a semicolon for data associated with the burial or memorial. Normally [WM1] should include any known plot location or other similar data, a transcription of the memorial if available, and anything else desired to be recorded. If this memo part does not contain any text, it will still probably require (only) escaped punctuation to follow the name. If there are trailing witness memo parts, [WM1] should include a period to end the burial information and begin a sentence describing the following data (e.g. “. Reported” or “. Recorded”) indicating whether presumed or documented data. Any other witness memo part prior to the last memo part should end in an appropriate escaped puncuation if necessary (e.g. “30 Apr 1798\;”).65 [WM2] is for birth date, [WM3] death date in the Burial group tags and burial/cremation date in the Death group tags, and [WM4] age at death often entered “xxy xxm xxd” for brevity. NOTE: If a death Date is entered (and not just a Sort Date) and either it or the Birth Date is either incomplete or has a modifier, Second Site will either compute the [AE] age differently than TMG or not output the clause, and [WM4] must be used to record the age. In this case one of the Dates may need a modifier like circa and the sentence template be locally modified to hide [WM4] from TMG to avoid duplication of age data in those reports, e.g. “<died at age [WM4]>” becomes “<[HID:][SS:]; died at age [WM4][:SS][:HID]>”. In most cases it is easier to use the two separate tag types than dealing with this [AE] issue. This data, to whatever precision is known, should be entered if not otherwise included as part of the data in [WM1] or in other output of the Cemetery Witness sentence. Any of these memo parts can include comments on how that data was computed.

Since I have been able to obtain memorial photos for “most” interments (usually from FindAGrave.com) the icon indicating an attached image is usually present for each entry in the narrative list of interments for a Cemetery pseudo person. While the absence of that icon does indicate no image, I have designed [WM5] to append a custom icon to explicitly indicate there is no image. In this way the case of a missing icon suggests I have not (yet) searched for an image. The text for[WM5] is displayed on rolling over the icon and explains the absence of the image, such as “No posted memorial image”, “Image is unreadable”, etc. I only include this for Second Site, so the [WM5] text is hidden from TMG. Note: because it is a pop-up, if multi-line pop-up text is desired each line of the text in [WM5] before the last must end in the ISO Latin 1 Character HTML five character Entity Name for a carriage return to break the lines: ‘’. You cannot just use either the carriage return character or the [:CR:] code. A maximum total of 60 characters can be used in this special HTML image title pop-up field.

Using the witness memo seems the most flexible and useful method to produce the list of meaningful information for the cemetery person’s narrative, but is certainly the most data entry work. While only needed for those tags linked to a pseudo cemetery person, it is still a lot of work, and also requires updating that memo whenever better information about this event is obtained.

If multi-line [WM5] pop-up text is desired, use the ISO carriage return:  to break the lines. Max 60 characters for that field.

I have considered this research variation in the Other group when I have no burial, but have not created it yet as I focus on finding documentation of the death itself. If I create such a custom tag, I expect that I would have a person as the Principal, with other people possible as some Witness role for other expected burials there, and I should remember to define the two Cemetery Witness roles so that the tag can be linked to one or more such pseudo Location people. As of Version 8 I use a common color highlight for all Find tag types. If I simply want to research all interments at a cemetery, I would probably use my custom MiscFind tag linked to that cemetery pseudo person.

This is a custom tag type which is only used in the details of Cemetery Pseudo People. The tag is to provide a separation between the tags providing a description and other information about the cemetery or crematorium (which all should have Sort Dates to occur first), and the following tags of burials or cremations which occured at this site. No data is intended to be entered into this tag other than a Sort Date. The three Principal roles (Cemetery, Crematorium, and CemAndCrem) provide special fixed sentences to produce a header above the burial/cremation tags sorted to follow in both TMG narrative reports and in the Second Site page for this pseudo person. I added this tag type after Version 8 and thus use a color highlight (the same as a Transcript tag type) to make the separation between tag types clear in the TMG Details.

See my separate chapter which discusses how to deal with census data, and its separate list of all my custom tag types to record various forms of census documents.

Added as a custom tag type to the Other group, its sentences require a Location and use [M1] to indicate what should be checked for documenting a child of the Principal(s), [M2] to record the details such as name, and [M3] for an optional comment. The Witness roles source and repository are also defined to link to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

Like the Birth tag type, I added [PAR] to the Principal sentence of this standard tag type, deleted the role Child, and added the Principal role ChildOnly for a sentence without the parents.

These proposed tag types and suffix for tag types provide many alternatives to record conflicting data. By defining a separate tag type, generation of reports and web sites can choose whether to include this information. Many users want to be clear both to themselves and to any readers of their output to what extent the information about a person is incomplete, uncertain, or has conflicting data from differing sources. I use my custom tag suffixes *Alt, *Find and *Nil to define such separate tag types.

While correspondence is usually documented as a source associated with the author/writer, the contents is often desirable in narratives, and not just in tags appropriate to the topics, e.g. occupation, marriage, etc. Further it is often desirable to highlight relationships between people associated with a correspondence. One recommendation is to create this custom tag type and make author P1 and addressee P2 with people mentioned as witnesses, and a citation to the actual correspondence. This lets everything be done as a single tag entry. Tag date is date of the correspondence. Possibly have one of these tags with a P2 but no P1 for correspondence received from an unknown source (that unsigned letter in Aunt Maude’s effects). But there are problems. What should go in location for this tag: sender or recipient address? With author P1 it would seem to make sense that it be the sender’s address, but this may not be known, where the recipient address probably is, if you have the envelope. What do you do with multiple addressees, or senders? (e.g. “Dear Aunt Mary and Uncle Jack”, “love, Ann and Tom”.) This might be accomodated with appropriately defined roles for multiple people.

Alternatively could have multiple correspondence tag types, either generic, or as suffix-type tags: e.g.: Contacted - with date of contact and name/address of person/institution in the location field with the person(s) in the dataset affected by the correspondence linked as witness(es). Change tag type of the tag later to Replied. Discuss can be used for on-going discussions with the memo recording the pertinent data. Use a tag type Sent to record whether data has been sent to someone, and Received for the reverse. Could have a tag type Mentioned for all the topics or people mentioned. These multiple tag types requires more data entry, but could be cleaner with respect to locations and sentences. Your own correspondence, such as requests for information, could link to a pseudo year person as a filing mechanism.

I choose to use my custom Transcript tag to include source text in a narrative. In addition to the “Subject” of the transcription as P1, this tag type can include a “pseudo” source person as P2. Appropriate witness roles link all other “real” people associated with the source to this tag, e.g. the role mentioned. Since correspondence is a source, I also use such source people and this custom tag type for documenting correspondence. My method allows multiple Transcript tags which could link to a single source pseudo person, each focusing on a particular Subject, topic or portion of the source with its set of linked people, and the citation detail for each tag referencing the specific location in the source (e.g. correspondence) of this topic or portion. My pseudo source person could also refer to a “real” person, and have Transcript tags for all correspondence from that person. I generally prefer creating a duplicate separate “pseudo” person for such correspondance rather than linking directly to the “real” person entry in the database for two reasons: a) I may not chose to have that person in my database, and/or b) I like the consistency of my Transcript linkages and sentences being collected under “pseudo” source people.

This tag type, in the Birth group, is used to describe a Pseudo entity, and/or provide “begin” dates for pseudo persons in my dataset, and its custom roles and sentences reflect its special purpose.66 As of Version 8 I color highlight the Created tag type with a normal Birth background, but a custom green text to reflect its pseudo person use. Due how I construct narratives for such people, all Pseudo people should have a Created tag using the appropriate role. The sentences generally do not include the Primary name of the person due to the special Name Styles I use for pseudo people. Census people and their Sort Dates and Roles for the Created tag are described in their separate chapter. Source people are created as of the publication date, etc. For some pseudo people a “creation” date is not needed or desired, so this tag may simply not be used. In other cases a “bogus” Sort Date may be desired simply for sorting (e.g. the year “3000” to sort last, or part of a location name as an irregular date for Interments to sort by location, or a constructed “between” date to sort portions within a Book person). Depending upon the Role there may be only <[M]> or both <[M1]> and <[M2]> to make the sentence more meaningful. The sentence for this Pseudo entity may wish to refer to one or more “real” people (e.g. the person(s) covered by this biography Source person). The role linkWitness which produces no Witness sentence can be used for this purpose.

The narrative “Create” sentence may only need to indicate this “person” is being used to group (i.e. be the parent of) other such people. In those cases I use the role Group so that the sentence will simply indicate that grouping, generally with no date output but often with a special Sort Date for custom sorting as described above. The Group role sentence has an optional first split memo part <[M1]> in the sentence which follows “subordinate” and precedes “entities” and should indicate the nature of the subordinate entities (e.g. Interment group, Interment site, Book, etc.) The optional second split memo part <[M2]> for this role sentence describes the common nature of those subordinate entities, such as the text “in [L]” when grouping by location or “in [D]” when grouping by date.

Pseudo Person	Role	Date	Place	M (or M1)	M2
USA	Location	1776	USA		All USA Location entities are descendants
Indiana, USA	Location	11 Dec 1816	Indiana	when it was admitted to the Union
Wells County, Indiana, USA	Location	2 Feb 1838	Wells County, Indiana	when formed by the state legislature from Adams New Purchase	No changes to its geographic area have occured since its formation
*All, Interments	Group	(Sort Date: 3000)		country Interment
USA, Interments	Group	(Sort Date: USA)	USA	Interment	within [L]
USA, Indiana, Interments	Group	(Sort Date: Indiana)	Indiana	Interment	within [L]
USA, Indiana, Wells, Interments	Group	(Sort Date: Wells)	Wells County, Indiana	Interment	within [L]
Fairview Cemetery, Bluffton, Wells County, Indiana	Cemetery	1874	Bluffton, Wells County, Indiana	as a community burial place
USA, Indiana, Wells, Harrison, Interments	Group	(Sort Date: Harrison)	Harrison Township, Wells County, Indiana	Interment site	within [L]
Grove Cemetery, Harrison Township, Wells County, Indiana	Cemetery	1834	Harrison Township, Wells County, Indiana	prior to the formation of Wells County and Harrison Township, on land owned by the Grove family
LIB Abq Public Genealogy	Repository		Albuquerque, Bernalillo County, New Mexico	is the genealogy section of the Albuquerque & Bernalillo County Public Library System
*All, Books	Group			Source	which are books
Hist IN Adam & Wells 0928360, Books	Group	1918	Indiana	biography Source	from Volume II for the two separate counties covered by this book.
Hist IN Adam & Wells 0928360 (Wells), Books	Group	1918 (Sort Date: Wells)	Wells County, Indiana	biography Source	of some of the significant individuals from [MOTH]
Biog IN Wells 977.2J39h, Markley Mrs J, Books	Source	1903 (Sort Date: bt 1903-2517)	Wells County, Indiana	about [R:linkWitness] (née [RL:linkWitness])	They are extracts from [RS:linkWitness] biography

Like any tag in the Birth Group, if there are no printable fields entered (i.e. the entire memo, date, and location is left blank) that tag will not appear in TMG narratives, even though the sentence preview would make you think it should. You can force this blank-memo “Group” sentence to appear by entering the ASCII Tab character followed by the split memo separator codes (‘||’) in the memo. This special tab character can only be entered within TMG by using Alt + 0009 on the numeric keypad. (See also the topic Empty Split Memo Parts in the Tag Sentence Details chapter.)

This tag type’s Principal roles and sentences reflect the kinds of pseudo persons that might be assigned this tag, include appropriate sentence variables and are restricted to their appropriate sex: Source, Location, Repository, Date, Cemetery.67 Most role sentences expect a memo which begins with a verb and provides an overall description of the entity, e.g “films a government index of the marriages in this location” or how created “was formed from Chester county” or details “used only for burials of the Smith family”. Because of the types of tags associated with pseudo people, and the way their reports expect to print, while there may be a date entered depending upon the type of pseudo person, this tag often has a blank sort date or a “before” sort data so that the tag will sort first, with the exception of my Interments and Census people which have special sort date values designed for groupings. For multiple pseudo children under a pseudo parent, the order can always be assigned by the BIRTH ORDER flag68 or by setting a non-blank sort date if that won’t cause problems. While very useful in Second Site for grouping, this tag type typically is only output on special TMG reports which include pseudo people.

If no [M1] text is desired but there is [M2], [M1] must contain the Tab character followed by the split memo separator code ‘||’. The Tab must be entered by using Alt + 0009 on the numeric keypad.

If a married name variation is selected, use “[R:linkWitness] (née [RL:linkWitness])”

I added the custom tag type Cremation to the Burial group. Like the DeathAssumeBur tag type described in more detail below, a DeathAssumeCrem was added69 for similar reasons to the Death group. As of Version 8 I color highlight the Cremation tag type as known data but the DeathAssumeCrem as a *Assume tag type since I still am looking for more documentation about the death. Like the similar burial tag type, entering only a single DeathAssumeCrem tag is sometimes easier than entering two separate but equivalent DeathAssume and Cremation tags. I have set these tag types to export using the standard GEDCOM tag type CREM rather than the default of BURI for tag types in the Burial group.

Since ashes are usually spread as a separate action in some other location than the place of cremation, I either enter that in a separate Anecdote tag or in a comment in the memo of these tags. Like burial tag types, for most married females I try to make a point to set their selected name on all tag types involving cremation to the name used in the records, usually selecting the name variation provided by my custom Name-Marr-Title tag.

While ashes are seldom scattered in the same location for multiple people, a photo of some kind of memorial stone with multiple names, similar to a gravestone, could be an exhibit on any tag type which documents cremation. While I enter a separate tag (with likely different dates) to document the cremation of each person, I prefer to have any Second Site exhibit page of such a memorial to show back-links to all people mentioned on the memorial. For this reason I have created the custom witness role of jointstone for any person also mentioned in the exhibit but not otherwise already linked to this tag. (See also the description of the information to be entered in the exhibit fields.) If there are other witnesses to this tag, such as a Cemetery pseudo person, be sure to order the jointstone witnesses first in the list so they will group with the Principal of this tag in the Second Site back-links. For the CremAssumeBur tag type, if the spouse is already a widow(er) Witness, there is no need to add that person again as a Witness with the jointstone role (and TMG will prevent the duplication) since the spouse will already be a back-link on any exhibit attached to this tag whether or not they are also on the memorial.

Similar to the Burial tag type, the Cremation tag type sentences only document the cremation itself so [D] is the date of the cremation, [L] is the cremation location, and [M1] provides the details of the cremation. If I do not have documentation for the cremation date I leave the Date blank. I always set the Sort Date to ensure the tag comes after any Death date, even if an actual known burial date is the same day.

The Cremation tag default role for the Principal is my custom JoinDeath with a sentence that will concatenate with the death tag sentence that it expects to immediately follow.70 If the cremation sentence should be separate, I use the standard role Principal. The roles JoinDeath and Principal will insert the automatic preposition for the location, but the roles JoinDeathL and PrincipalL do not.

The memo parts [M2] and [M3] are optional extra cremation comments for the Principal, where [M2] is often the name of the facility performing the cremation (e.g. “in the Perpetual Light crematoria”), and [M3] often some separate informative sentence about the ceremony or ashes (e.g. “The ashes were presented to his brother, Fred Smith”).

If this crematorium is entered as a pseudo person, then it should be linked as a Witness with a Cemetery Witness role selecting its Name-Link-Only name, both so that this person’s cremation will be listed in that pseudo person’s narrative, and so that this cremation sentence will produce a Second Site link to that pseudo person. [M4] is semi-optional qualifying text. It either qualifies the preceding cremation date (e.g. [M4] “following 9 a.m. services in the adjacent church”) and/or qualifies the following linked crematorium or cremation location. The crematorium should either be linked to its pseudo person or named last in [M4] but not both.71 If not linked the crematorium name should be entered last in [M4] (e.g. [M4] “in the memorial chapel at Paradise Crematorium” versus simply “in the memorial chapel”). If the crematorium will be linked it should never be included as part of the MPL location record so that Second Site will provide separate hyperlinks to the crematorium person itself and the place record. While most cremations are “at” rather than “in” (my standard report preposition for locations) a location such as a city or village, many crematoriums are often neither “in” nor “at” an MPL location. Thus [M5] can provide an appropriate preposition or phrase (e.g. “12 miles southeast of”) in front of the MPL location when used with an ‘*L’ role.

The DeathAssumeCrem tag sentences combine the typical roles and sentences of a presumed death tag and a known cremation tag, with [D] as the death date, [L] as the cremation location, and [M1] providing details of the presumed death.

Although the sentence of this custom tag for the standard role Principal includes the age variable [AE]72 and widow(er) role variable, like the DeathAssume tag type the default Deceased role does not. Since the role Deceased presumes less known data (e.g. probably an approximate date), that role is the default. The tag will usually have some kind of Date, but like all tags in the Death group should always at least have a Sort Date, and if it is a conditional date use a role (such as the default Deceased) which does not output an age at death. The roles Deceased and Principal will insert the automatic preposition for the burial location, but the roles DeceasedL and PrincipalL do not.

Like the custom Cremation tag type, the memo parts [M2] and [M3] are also optional extra cremation comments for the Principal as described above.

If this crematorium is entered as a pseudo person, then it should be linked as a Witness with a Cemetery Witness role selecting its Name-Link-Only name, both so that this person’s cremation will be listed in that pseudo person’s narrative, and so that this cremation sentence will produce a Second Site link to that pseudo person. [M4] is semi-optional qualifying text. It either qualifies the preceding cremation date (e.g. [M4] “following 9 a.m. services in the adjacent church”) and/or qualifies the following linked crematorium or cremation location. The crematorium should either be linked to its pseudo person or named last in [M4] but not both.73 If not linked the crematorium name should be entered last in [M4] (e.g. [M4] “in the memorial chapel at Paradise Crematorium” versus simply “in the memorial chapel”). If the crematorium will be linked it should never be included as part of the MPL location record so that Second Site will provide separate hyperlinks to the crematorium person itself and the place record. While most cremations are “at” rather than “in” (my standard report preposition for locations) a location such as a city or village, many crematoriums are often neither “in” nor “at” an MPL location. Thus [M5] can provide an appropriate preposition or phrase (e.g. “12 miles southeast of”) in front of the MPL location when used with an ‘*L’ role.

For all tag types that refer to a cremation, I have added74 the Cemetery Witness roles so that these tags may be linked to pseudo Location people that are cemeteries/crematoria. Note that due to potential issue with the [AE] variable it is usually better to have separate DeathAssume and Cremation tags. For more details on the use of these roles, see my notes about this special witness and its Name-Link-Only name in the Burial tag type description.

If multi-line [WM5] pop-up text is desired, use the ISO carriage return:  to break the lines. Max 60 characters for that field.

The sentence in this standard tag type for the standard role Principal now includes the age variable [AE]75 and the widow(er), where the standard role Deceased does not. Like all tags in the Death group, if the Death tag has a conditional date, use a role which does not output an age at death. I have [M1] provide the details or cause of the death in all the sentences. Note that if later memo parts have text and [M1] is empty it must contain the special Tab character placeholder so it will be treated as empty.76 [M2] and [M3] are optional trailing comments for the Principal. [M4] is optional qualifying text for the location. [M4] also can provide an approparite preposition for the following location depending upon the role. The standard roles Principal and Deceased will insert the automatic preposition for the location, but the roles PrincipalL and DeceasedL do not. Some suggestions for comments for this tag have been: unmarried, having never married, without issue, young, in infancy, etc. I added the Witness role widow(er) with the witness sentence gender specific. This also allows the Principal’s sentence to optionally reference the spouse whenever they are this witness. My sentences use the phrase “[W] became a widower when his wife [PF] died” or “[W] became a widow when her husband [PF] died” in the appropriate gender sentence. Others have suggested simpler sentences like: “His wife [PF] died” or “Her husband [PF] died”, finding the phrase “became a widow(er)” redundant. Because of possible options with [M4] and the two types of Principal roles to deal with a location preposition, I do not include the [L] variable in either the widow(er) or Witness roles. In addition to [M1] for the details there is an optional [WM] for comments. Whether the witness role is used on the tag is based on whether there is a surviving spouse. It provides text in the surviving spouse narrative concerning the death of the spouse so that a subsequent marriage sentence would make sense. I changed the default witness role to allow a split witness memo to characterize the nature of the witness. For orphaned children [WM1] could specify their age, or could identify the attending doctor, etc. I choose to not include the location in witness sentences. As of Version 8 I color highlight this tag type. If I have burial information but no death information, I use my custom DeathAssumeBur tag instead of including a Death tag with a guessed date. If I have both death and burial data my Burial tag can concatenate its text to the Death tag sentence.

For the purposes of a stillborn child, in addition to the BirthStill tag a Death tag is required to produce a lifespan and set the LIVING flag to N. Since the BirthStill tag makes the situation clear, the custom role Stillborn excludes all output from the Death tag and the tag memo should remain blank.

I have made this custom tag the default for the TMG Hotkey (Ctrl-D) since when I am adding a new person I am usually presuming a death date or location before I have reliable citations to prove this data. Causing this tag type to be assigned to the hotkey can only be done by renaming the standard tag to this custom name and then creating a custom tag with the standard name and sentences. (See also my custom tag types DeathAssumeBur and DeathAssumeCrem described separately.) Although the sentence of this custom tag for the standard role Principal includes the age variable [AE]77 and widow(er) role variable, the default Deceased role does not. Since the role Deceased presumes less known data (e.g. probably an approximate date), that role is the default. Depending upon what optional information is included, its sentences reflect an presumption about the death date, location and/or cause. The date is often entered with a qualifier, e.g. “before 1900”. I have [M1] provide the details or cause of the death in all the sentences. Note that if later memo parts have text and [M1] is empty it must contain the special Tab character placeholder so it will be treated as empty.78 [M2] and [M3] are optional trailing comments about the death for the Principal, usually indicating the basis for the [M1] statement. [M4] optionally precedes the death location in the sentence since I prefer the flexibility of sometimes putting details or comments about my level of confidence in the sentence here rather than as part of a location in the MPL. If the [M4] text following the date contains some explanation of the death date (e.g. “since his wife is listed as a widow in the 1900 census”) then end the text with an escaped comma (i.e. “\,”) to separate it from the following location (so it doesn’t read like the census was in that location). [M4] also can provide an appropriate preposition for the following death location depending upon the role. The Principal roles Principal and Deceased will insert the automatic preposition for the location, but the roles PrincipalL and DeceasedL do not. I added the Witness role widow(er) with the witness sentence gender specific. Similar to the Death tag type, because of possible options with [M4] and the two types of Principal roles to deal with a location preposition, I do not include the [L] variable in either the widow(er) or Witness roles. In addition to including the main [M1] for the death details there is an optional [WM] for comments. The widow(er) witness role is only used on the tag if there is a surviving spouse. It provides text in the surviving spouse narrative concerning the presumed death of the spouse so that a subsequent marriage sentence makes sense. Since this tag type is in the Death group I can change the tag to a standard Death tag type if death documentation is discovered. If I have burial information but no death information, for convenience I often use my custom DeathAssumeBur tag instead of including a DeathAssume tag with a presumed date plus a separate Burial tag. As of Version 8 I use a common color highlight for all *Assume and *-Can tag types.

Added as a custom tag type to the Other group to avoid it defining a death. Thus when the facts are found a tag in the Death group will need to be created rather than changing this tag’s type. Its sentences require a Location and use [M1] to indicate what should be checked for a death record, [M2] to record the details such as name and probable age, and [M3] for an optional comment. The Witness roles source and repository are also defined to link to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

Different custom tag types could exist for different types of deeds: DeedChattel, Deeds, DeedWarranty, or even have a Name-Deed tag in the Name group to record a name as shown on a deed. Like many sources which document an event, a deed could be considered only a source or indicating some ownership event. A number of ideas concerning deeds have been mentioned on the TMG ListServ, but I have not yet explored such sources and custom tags. However, I believe that my more general custom Transcript tag type to record source information may accomplish much of what these custom tag types are designed to do.

I modified the sentences of this standard tag type to split the memo to allow for more creative output.

This tag type79, in the Death group, is used to provide ending dates when needed for pseudo persons in my dataset, and its custom roles and sentences reflect its special purpose. Its Principal roles and sentences reflect the kinds of pseudo persons that might be assigned this tag, include appropriate sentence variables and are restricted to their appropriate sex: Source, Location, Repository, Cemetery.80 Its general purpose split memo primarily provides for a type of ending and a reason for the ending of the entity, e.g “ceased to exist as a county name in this state [D] when this area formed the new state of [L]” or “ceased to be used as a burial ground [D] when the church associated with this cemetery was decommissioned and all graves were moved to [L]”. This tag type should have a date and the Sort Date should be the same. This tag type is only output on special reports associated with pseudo people.

I modified the sentences of this standard tag type to add memo text, and to provide roles if it is known who divorced whom. I have [M1] provide the reasons for the divorce if known, e.g. “after years of bitter disagreements over religion”, with [M2] and [M3] optional separate trailing comments for the roles Divorcer and Divorced respectively. Alternatively the sentence template for the Principal role does not indicate who initiated the divorce, which could either be unknown or “no-fault”. The fact of the divorce may be known, but often not who initiated the action.

I modified the sentences of this standard tag type to add memo text, and to provide roles if it is known who filed for divorce from whom. I have [M1] provide the reasons for the filing if known, e.g. “due to disagreements over religion”, with [M2] and [M3] optional separate trailing comments for the roles Divorcer and Divorced respectively. Alternatively the sentence template for the Principal role does not indicate who filed for the divorce, which could either be unknown or jointly as “no-fault”.

The sentences of this custom tag in the Divorce group reflect a presumption about occurance, date, location and/or cause of the divorce. The date is often entered with a qualifier, e.g. “before 1900”. I have [M1] provide the basis for making the statement about the divorce, e.g. “since Ellen is listed as divorced in the 1910 census”, with [M2] and [M3] optional separate trailing comments for each Principal. If the [M2] text following the date contains some explanation of the date (e.g. “based on his subsequent remarriage”) then end the text with an escaped comma (i.e. “\,”) to separate it from the following location (so it doesn’t read like the subsequent remarriage was in that location). [M4] optionally precedes the location in the sentence since I prefer the flexibility of sometimes putting details or comments about my level of confidence in this location here rather than as part of a location in the MPL. The sentence templates do not indicate who initiated the divorce, which could be included in the memos. The fact of the divorce may be known, but often not who initiated the action. Since this tag is in the Divorce group I can change the tag to a standard Divorce tag type if documentation of the divorce is confirmed. Divorce tags need to be in the separate Divorce group so that Divorce and Marriage data may both be output to those reports that only output Primary tags. Each tag in the Divorce group for an individual can be marked Primary as long as the other Principal is different in every tag. This can be an issue if a person marries and divorces the same person multiple times. See also my *Assume tags. As of Version 8 I use a common color highlight for all *Assume and *-Can tag types.

The sentences of this custom tag in the Other group reflect assumptions about what I expect to find concerning the occurance, date, location and/or cause of the divorce. The date is required and usually entered as a range, e.g. “between 1900 and 1910”. As with all *Find tag types [M1] suggests what records to search and may also include information about likely location. [M2] provides details to aid in the search, with [M3] and [M4] optional trailing comments for each Principal. As of Version 8 I use a common color highlight for all Find tag types. Since this tag is in the Other group a new Divorce tag type in the Divorce group will need to be created (or convert an existing DivorceAssume tag) if documentation of the divorce is confirmed. See also my general discussion about *Find tags.

I define a custom tag type that links two (and only two82) person entries in my dataset whenever I suspect they may actually be the same person, but have not yet chosen to merge their records. Its sentences expect the person whose record I am likely to merge with the other will be assigned P1 with the role Duplicate. The person whose record I expect to retain and merge into is assigned P2 with the role Target or Source. For “real” people I use the P2 role Target. However I also use this tag to link possibly duplicate source pseudo people, and those P2 people use the role Source. P1 and P2 should both be “real” people or both be “source” people.

[M1] records why I suspect these two people entities are likely to be the same person and why I am doing the comparison. The P1 Duplicate role has [M2] for separate comments only in that person’s narrative. The P2 roles Target or Source have [M3] for separate comments in their narrative. Having this separate tag allows linking Research Tasks that might resolve the question.

The DupNil tag type (see also the suffix “*Nil”) has the same roles in similar sentences to document my conclusions why the P1 Duplicate cannot be the same as the P2 Target or Source, to avoid having to discover this all over again. And each person similarly has separate memo parts for their own separate narrative comments. Thus a Duplicate tag type can easily be changed to a DupNil tag type when the issue is resolved. These two tag types are considered Research Notes and are usually not selected to be printed for normal narratives.

I changed the sentences of the standard Education tag type to be a more general purpose type, and use it for all education events. I choose not to use the separate standard Graduation tag type with its sentences which I disabled, but also use this custom generalized Education tag type for this event. [M1] defines what happened (“graduated from high school”), [M2] optionally precedes the location in the sentence since I prefer the flexibility of sometimes putting the name of the school here rather than as part of a location in the MPL, and [M3] has optional comments. Two custom roles for the Principal and Witnesses allow multiple education tags to concatenate to form a single sentence about education, but each tag can have its own printing date, location and citations. They are made to be consecutive by Sort Dates.

Added as a custom tag type to the Other group, its sentences are intentionally similar to my Emigration tag type, and defines the same Principal and Witness roles. However, in this tag type the location is optional and the split memo part [M1] indicates what should be checked for an emigration record. The rest of the split memo is the same as the Emigration tag type, e.g. [M2] the probable destination, [M3] for Principal comments, etc. [WM1] is required and has the probable name and possibly relationship of any Witness expected to emigrate with the Principal(s). This matching structure of the split memos allows the tag type of this tag to be changed to Emigration when the record is found, simply replacing [M1] with the listed name of the Principal(s). The Witness roles source and repository are also defined to link the Find tag to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

I changed the sentences of this standard tag which identifies a permanent change of country to require the Date and the Location from which the emigration is taking place. (See also the Immigratn tag.) If not included this will intentionally create the “unknown location” or “unknown date” text. I use the Principal role Head for either a single individual or head of a miscellaneous group, and the Witness role emigree for all others emigrating with the Head. The Principal role Parent is specifically for a family group, the Witness role child for family members so that only their given names are listed, and the Witness role emigree for all others emigrating with the family. Even if only one parent leads the group, I can put a Male as P1 and a Female as P2 but must use the appropriate [M3] or [M6]. [M1] optionally provides the name(s) of the Principal(s) as listed in the emigration documentation in case it is different than defined in any Name tags, [M2] optionally specifies the claimed destination. [M3] has optional comments included only in the narrative of the Head or the male Parent and [M6] is only used in the female narrative, e.g. “She reported being from Prussia with her final destination as Detroit”. [M4] can provide further details about their departure location, and [M5] about the date. [WM1] optionally provides the listed name of the Witness, and possibly includes the listed relationship to the Principal (e.g. “son Johan”), and [WM2] has optional comments only for the narrative of this Witness. The listed departure location, date, and destination (plus [M2], [M4], and [M5]) is included in each Witness sentence. If you create ship pseudo people, such a person could be added as a Witness with a custom role of ship. I have not currently customized this tag type for this purpose and instead add the ship name somewhere in the memo parts, e.g. [M2] as “Baltimore on board the ship Koeln”. (To describe a move from one address to another that does not involve a change in country or citizenship see my Moved tags.)

I chose to change the sentences of this standard tag type for both the Principals and Witnesses to have [M1] specify the employer. [M2] is a comment for the Principals, and [WM] for the Witnesses that were also employed by this employer. See also the Occupation tag type.

All generic GEDCOM tag types ( 1 EVEN 2 TYPE ) will automatically be assigned to this standard Event-Misc tag type upon import unless specifically reassigned in the Import wizard. For this reason I also use this tag type for a simple generic event tag with my custom generic sentence. [M1] defines what [P] and [PO] “were” at some date and location, and [M2] has optional comments. The Witness sentence includes [M1] but has [WM] for optional Witness comments. This split memo structure is a good example of my “lumper” preference, allowing one tag to be used for multiple purposes which are detailed by the memo. I use this tag type for generic events instead of the Misc tag type since I have reserved the latter for temporary information purposes. See also the tag type MiscFind for finding generic information.

Added as a custom tag type to the Other group, the Guardian tag type sentences are similar to the Adopting tag and record when an adult becomes guardian of a child. The child is a Witness but using the role ward, with up to two adults as the two Principals using their role Guardian. This tag uses my standard split memo structure for any details about the guardianship, and allows linking any citations such as court records. [M1] provides general guardianship details for output for the Principals. [M2] is an optional comment that will preceed the date, and [M3] an optional comment that will preceed the location. Each child’s sentence uses the [M2] and [M3] guardianship details and its own optional [WM]. This also allows a single Guardian tag to be used when multiple children are assigned a guardian at the same time, each with their own unique [WM], regardless of whether they share birth parents, and even allows for linking others using the standard Witness role with their separate witness memos to the guardianship event.

A companion research tag type of GuardianFind has also been defined when you only know someone became a Guardian but no further details. [M1] allows a comment about where to look and the subsequent memo parts are in the same order as the Guardian tag so that [M1] can simply be deleted when the research tag type is changed to the main tag. The Witness roles source and repository are also defined to link to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

I changed the sentences of this standard tag. [M1] defines what [P] and [PO] were “ill with” at some date and location, and [M2] has optional comments. The Witness sentence includes [M1] but has [WM] for optional Witness comments.

Added as a custom tag type to the Other group, its sentences are intentionally similar to my Immigratn tag type, and defines the same Principal and Witness roles. However, in this tag type the location is optional and the split memo part [M1] indicates what should be checked for an immigration record. The rest of the split memo is the same as the Immigratn tag type, e.g. [M2] the probable origination, [M3] for Principal comments, etc. [WM1] is required and has the probable name and possibly relationship of any Witness expected to immigrate with the Principal(s). This matching structure of the split memos allows the tag type of this tag to be changed to Immigratn when the record is found, simply replacing [M1] with the listed name of the Principal(s). The Witness roles source and repository are also defined to link the Find tag to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

I changed the sentences of this standard tag which identifies a permanent change of country to require the Date and the Location to which the immigration is taking place. (See also the Emigration tag.) If not included this will intentionally create the “unknown location” or “unknown date” text. I use the Principal role Head for either a single individual or head of a miscellaneous group, and the Witness role immigree for all others immigrating with the Head. The Principal role Parent is specifically for a family group, the Witness role child for family members so that only their given names are listed, and the Witness role immigree for all others immigrating with the family. Even if only one parent leads the group, I can put a Male as P1 and a Female as P2 but must use the appropriate [M3] or [M6]. [M1] optionally provides the name(s) of the Principal(s) as listed in the immigration documentation in case it is different than defined any Name tags, [M2] optionally specifies the claimed departure location. [M3] has optional comments included only in the narrative of the Head or the male Parent and [M6] is only used in the female narrative, e.g. “She reported being from Prussia with her final destination as Detroit”. [M4] can provide further details about their arrival location, and [M5] about the date. [WM1] optionally provides the listed name of the Witness, and possibly includes the listed relationship to the Principal (e.g. “son Johan”), and [WM2] has optional comments only for the narrative of this Witness. The listed arrival location, date, and origination (plus [M2], [M4], and [M5]) is included in each Witness sentence. If you create ship pseudo people, such a person could be added as a Witness with a custom role of ship. I have not currently customized this tag type for this purpose and instead add the ship name somewhere in the memo parts, e.g. [M2] as “Bremen on board the ship Koeln”. (To describe a move from one address to another that does not involve a change in country or citizenship see my Moved tags.)

These types were introduced as standard TMG tag types in Version 7. JournalIntro and JournalConclusion are only used when a Principal of the tag is the subject in a Journal report. If a person does not have one of these tags linked to them as a Principal, their TMG Journal output will not be affected. I have not fully tested these Journal* tag types behaviour in either TMG (or Second Site) as I have not included them in my projects, and do not usually generate TMG Journal reports for any but my own use.

To highlight that these tag types only affect narration, I accent them with the same colors as my Transcript tag type.

Since government records of land transactions are common, a separate custom tag type can be used for this data. This idea is similar to the one proposed for Deeds above. Possible roles include: Buyer, Seller, other, mentioned. Could also have a LandHeld tag to describe land found on a plat map, with roles such as Principal, Witness, and adjacent. I have not yet explored this. However, I believe that my more general custom Transcript tag type to record source information may accomplish much of what these custom tag types are designed to do.

The on-line database83 of land patents from the Bureau of Land Management suggests to me a possible custom tag type of LandPatent. One suggested sentence is:

[P] <was|and [PO] were> issued a land patent <[D]> for <[M1]> of land located <[L]>. <[M2]>

where [D] is the date the patent was issued, [M1] the quantity of land (usually in acres), [L] where the land is located, and [M2] other comments such as price per acre, total cost, legal land description, etc.

I tested a LocationLink tag type in the Address group, but decided to abandon its use. Its sentences were designed to have the pseudo location as the Principal with the role “Location” and every person with events that occur in this location linked as a “Witness”. This was only useful for links to a pseudo person from real people. However, as I use SecondSite and its Place Index to commonly view my data, that Index does everything I would desire to link people with locations, plus eliminating the need to create the tag and make the links.

Some have proposed various custom tag types for information about a location. For Location pseudo people, one may want to link together multiple location pseudo people of what is actually the same location with some kind of Location tag type. I think my ResidedAddress tag type with associated dates and the name as used within that time range as the location that links to the MPL place might serve these functions, but have not yet done that for my Location people and need to test this more. This custom tag type in the Address group might require special roles to deal with pseudo location people. Since it would be used in this manner only with Location pseudo people, its dual use would not cause selection-by-tag-type problems in reports since I also generally select by the PSEUDO flag as well. May possibly need to create new tag types in the Address group, or new roles in my ResidedAddress tag type, something like ObsoleteLocationName and CurrentLocationName with the pseudo person Surname being “Location” and Given being “most commonly used” place name. Currently I am using my Name-Loc-Var tags for alternate names over time for the pseudo person, which seem to be sufficient for my purposes.

I have made this custom tag the default for the TMG Hotkey (Ctrl-M) since when I am adding a new person I am usually presuming a marriage before I have actual data to prove a marriage took place. Causing this tag type to be assigned to the hotkey can only be done by renaming the standard tag to this custom name and then creating a custom tag with the standard name and sentences. Depending upon what optional information is included, the sentences of this custom tag type reflect a presumption about the date, location and/or spouse. The date is often entered with a qualifier, e.g. “before 1900”. [M1] is an optional comment for the Principal, usually indicating my basis for making this statement, e.g. “based on their recorded relationship in the 1900 census”. [M2] optionally precedes the location in the sentence since I prefer the flexibility of sometimes putting details or comments about my level of confidence in this location here rather than as part of a location in the MPL. If the [M2] text following the date contains some explanation of the date (e.g. “based on the birthdates of their children”) then end the text with an escaped comma (i.e. “\,”) to separate it from the following location (so it doesn’t read like the children were born in that location). Since it is in the Marriage group I can change the tag to a standard Marriage tag type if the marriage is confirmed. In the reverse of what I have done with the Birth group tag types, I removed [PARO] from the default Principal sentence but keep it in the Bride and Groom role sentences. While I could have a conditional [PARO] variable, since the assigned spouse’s parents may be a wild guess as to candidate parents, I prefer to manually set whether the spouse’s parents are shown. By changing the role to Bride or Groom I can easily show the parents of either spouse once I know them. I can even change the role to have one Principal’s sentence to Bride or Groom to show parents, and have the other not show by leaving their role as Principal.84 The Groom role for P1 enforces male, and Bride for P2 enforces female, but the default warnings can be ignored. I choose always to put a male as P1 and a female as P2 leaving blank whichever may be unknown. As of Version 8 I use a common color highlight for all *Assume and *-Can tag types.

Marr Bann/Marriage bannMJH, Marr Cont/Marriage contract, Marr Lic/Marriage licenseMJH

Modified the standard sentences of Marr Bann to allow for optional comments. Since the banns usually occur on successive dates, I enter the last date as the tag date, and put the earlier dates in [M1]. The sentences prevent the automatic preposition for the date, so I will need to enter something in [M1]. I use [M2] to record the details of the location, such as the church, and [M3] for an optional comment. I removed [PARO] from the default Principal sentence but keep it in the Bride and Groom role sentences. I can even change the role to have one Principal’s sentence show parents, and have the other not show by leaving their role as Principal.85

I don’t currently use the Marr Cont tag type, but modified its sentences similar to Marr Bann for when I find such a source and wish to use a separate tag. I seldom use a separate Marr Lic tag type, but also modified its sentences similar to Marr Bann for when I find such a source and wish to use a separate tag. I usually simply cite these two sources to the Marriage tag especially when both are on the same date. I decided not to show the parents in either of these two tag types’ sentences as they will usually show as part of the Marriage tag.

This custom tag type is used to force the existence of a one-Principal Family Section in TMG Journal reports. TMG will output a Family Section based on this Marriage Group tag even if there is no one-Principal NarrativeChildren tag nor any children with this Principal as the sole Primary parent. This allows my custom use of the NarrativeChildren tag type (as described in the separate chapter on non-Primary children) to replace that one-parent Family Section heading with a list of non-Primary children. As such this tag type must be selected for TMG Journal Reports, but is normally not selected for any other TMG narrative report. If there is no one-Principal NarrativeChildren tag nor any children with this Principal as the sole Primary parent, all recent versions of Second Site will produce no Family Section for this Marriage Group tag since it has no spouse or narrative output. The presence of a one-Principal NarrativeChildren tag is sufficient to cause a Family Section in Second Site Version 7 and later, thus this tag type does not need to be selected in that program but does no harm if it is. As my special custom use of the NarrativeChildren tag type describes, my use of a Marr Dummy tag should only ever have one Principal. Further, its sentences are intentionally defined to produce no output. Even if this person has another one-Principal Marriage Group tag (which is usually unlikely), so long as that other tag is Primary also adding this tag will cause no problems in either program since it produces no output. Thus I always enter it as a companion to any of my custom uses of a one-Principal NarrativeChildren tag. To keep the order of this Family Section the same in TMG and Second Site, I enter nothing but a SortDate in this Marr Dummy tag which is the same as the SortDate in the companion NarrativeChildren tag. This also ensures they appear together in this non-Primary parent’s Details. To highlight that this tag type is only entered as a companion to the NarrativeChildren tag, as of Version 8 I accent it with the same colors as the NarrativeChildren tag type.

Added as a custom tag type to the Other group to avoid it defining a marriage. Thus when found a tag in the Marriage group will need to be created rather than changing this tag’s type. Its sentences require a Location and Date and use [M1] to indicate what should be checked for a marriage record, [M2] to record the details such as name or parents, and [M3] for an optional comment. If you are looking for a marriage between two specific people, they should be the two Principals in this one tag. If it is not known who the spouse may be, only one Principal can be used. The Witness roles source and repository are also defined to link to the appropriate pseudo people. I choose always to put the male as P1 and the female as P2 but have not defined the Bride and Groom roles to enforce this as so much is likely unknown for this tag type. As of Version 8 I use a common color highlight for all Find tag types.

Added as a custom tag type to the Other group, its sentences require a Location and use [M1] to indicate where I looked and did not find a source for a marriage record, [M2] to record the details I used for the search, and [M3] for an optional comment. The Witness role source is also defined to link to an appropriate source pseudo person. I choose always to put the male as P1 and the female as P2 but have not defined the Bride and Groom roles to enforce this.

I made a custom Marr Not tag type within the Marriage group for people who are known to have mated (especially if they had identified offspring and I want to show that shared parental relationship) but are not considered married in the typical sense, and defined its sentences accordingly. TMG requires “marriage” events to exist to print reports with correct birth order sorting of the offspring of the mating. If the relationship is simple and reciprocal I use the standard Principal roles for both parties and the sentence just has their names followed by a required [M] and no Date or Location. The Male role as the default for P1 enforces male, and Female as default for P2 enforces female, but the default warnings can be ignored. I choose not to include [PARO] in any of the Principal sentences but it can be added in a local sentence template if desired.86 If I want to say something different from each point of view, [M1] specifies the relationship in the default Female (and in the Bride) role sentence with optional Date and Location and [M2] as her comment, and [M3] specifies the relationship in the default Male (and the Groom) role sentence with optional Date and Location and [M4] as his comment. [WM1] states the relationship from the Witness’ point of view, with [WM2] for added comments.

Could have other separate custom tag types in the Marriage group, e.g. Marr Coh for known to have cohabited (lived together), Marr Rel for known to have relations (sex) but not to have lived together. My “lumper” preference seems served with my one Marr Not tag type and using the split memo to describe the relationship. As its sentences contain no fixed text, only split memo parts, this tag type also can be used for any non-typical marriage-like events, such as same-sex marriages or partnerships. However, having separate custom tag types may be of value for selecting which will print. Alternatively could have appropriate roles for various specific relationships and associated different predefined sentences with either the standard Marriage tag type or a single non-typical tag type.

The Marr Never is a custom tag type in the Other group for this one person known to have never married. This information could be recorded by an Anecdote tag, but I prefer having an explicitly named tag that sorts with other marriage tag types. Its sentences can either imply “prior to this date” or a true “never” married throughout their entire life. One could either have a special role that did not include [PO] in a lumped tag type, or link the spouse to a pseudo person with a name like “Never Married” or “No one” for reports. Currently I prefer this in the Other group to avoid any automated effects that come with a tag in the Marriage group, but may rethink this after using it more.

The tag type Src Link is a marriage that links a type of pseudo source person to a type of pseudo location person. It is separately described in my Source guide.

If a person has more than one partner, or has children with more than one partner, whether there is any marriage or other partnership relationship, you must create a tag type in the Marriage Group with a Sort Date for each relationship if you want to control the order that those partners and/or their children are displayed in some reports and all Descendant-related Box Charts. If a person has multiple marriages, you can pick which marriage will show in screens as the main marriage by selecting the appropriate spouse for that person from the Family view. That “last viewed spouse” will temporarily identify to TMG that marriage as “Primary” and display it when only one marriage would show. All my custom marriage tag types separate the suffix from the base “Marr” by a space to match the standard tag type names in the Marriage group. In the reverse of what I have done with the Birth group tag types, I removed [PARO] from the default Principal sentence but keep it in the Bride and Groom role sentences. By changing the role to Bride or Groom I can easily show the parents of either spouse once I know them. I can even change the role to have one Principal’s sentence show parents, and have the other not show by leaving their role as Principal.87 The Groom role for P1 enforces male, and Bride for P2 enforces female, but the default warnings can be ignored. I choose always to put the male as P1 and the female as P2 leaving blank whichever may be unknown. I also use the split memo to allow separate text before the date and location. I have not (yet) chosen to create multiple roles for witnesses, e.g. Bride’s Maid, Pastor, etc. As of Version 8 I color highlight this tag type. If I find the need, rather than multiple roles I would likely modify the general Witness sentence to have a split Witness memo part identify the role similar to my general CensusEnum tag type. Currently I simply use the general purpose Anecdote tag type to describe these other aspects of the marriage event and restrict the Marriage tag to recording the fact of a union.

I added a memo to the sentences of both standard Milit-Beg and Milit-End tag types, as well as creating the sentences of a more general purpose custom MilService tag type.

Due to some tag import from PAF or GEDCOM often automatically being assigned to the Misc tag type, I changed the Principal sentence to “[:CR:][M]” but I can ignore the witness sentence since the imports do not set any. I often use this tag type to temporarily record some information which needs further research, similar to the Note tag. I usually exclude this tag type from printing, or by using exclusion marks in the memo. As of Version 8 I color highlight this tag type. Any of these imported tag types should ultimately be deleted as I convert them to standard features such as Research Log entries or *Find tag types, etc. Instead of using this tag type for miscellaneous events see my Event-Misc tag type for a general purpose tag.

Added as a custom tag type to the Other group, its default sentences require a Location and use [M1] to indicate what should be checked for some data, [M2] to identify what data is being sought, [M3] to record the details that may help locate the data, and [M4] for an optional comment.88 While I prefer to narrow the search to a location, and may put a repository MPL entry as the location, I do have a NoLoc Principal role with an optional Date variable (usually entered as a range) for special situations.89 The Witness roles source and repository are also defined to link to any appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types. When the data is found it is likely this tag will be changed either to a specific appropriate event tag type or the Event-Misc tag type. While most *Find tag types will (should?) have a task, I often add this more general purpose tag type as a quick place to hold incomplete research information without fully drafting a more complete tag or task.

There are occasions when I encounter some facts which on the surface appear to relate to this person, but which I have concluded actually refer to some other person. To save rediscovering this conclusion multiple times, I use this general purpose tag and cite the source(s) which are appropriate. Its sentences simply contain the memo. I usually exclude this tag type from printing.

These custom tag types created in the Address group are a cross between my customized Immigratn / Emigration tag types and my customized Address and ResidedAddress tag types. They document a move of a group or family from a specific address/location or to a specific address/location, but where that move does not involve a change in country and/or citizenship. The MovedTo sentences require a destination but not a source, and the MovedFrom sentences the reverse, but the Date is optional.

For both of these tags, [M1] provides details of either the destination or departure location as appropriate. [M2] is the optional comment about the “other” location. [M3] is an optional trailing comment for the Principal(s). If the comment should be different for two Principals, the role Couple is used for both and [M3] is for the male and [M4] for the female. Even if only one person leads the group, I can use the role Couple and put a Male as P1 and a Female as P2 but must use the appropriate [M3] or [M4]. The Witness role child is defined separately so that the sentence can use their Given names only. The Witness role resident is defined for others also participating in the move and both of these witness sentences include both [M1] and [M2] but provide their own optional [WM] for each resident or child.

Added as a custom tag type also in the Address group, its sentences require a Date and the Location where records are likely to be found which should be either the expected origination or destination. Intentionally similar to my Moved tags, [M1] indicates what should be checked for an emigration record and whether the Location is “from” or “to”, [M2] the probable “other” location, and [M3] is an optional trailing comment for the Principal(s). If the comment should be different for two Principals, the role Couple is used for both and [M3] is for the male and [M4] for the female. The Witness role child is defined separately so that the sentence can use their Given names only. The Witness role resident is defined for others also participating in the move. All Witness sentences include both [M1] and [M2] but provide their own optional [WM] for each Witness. The Witness roles source and repository are also defined to link to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

I chose to change the sentences of this standard tag type for both the Principals and Witnesses to have [M1] specify the country of naturalization. [M2] is a comment for the Principals, and [WM] for the Witnesses.

Due to automatic usage of the standard Note tag type in import from PAF or GEDCOM, I changed the Principal sentence to “[:CR:][M][:NP:]”.90 Normal Imports do not have witnesses, but I also use this tag for quick entry of research notes, especially the identification of websites which might have relevant data. Such notes may apply to multiple people, who are simply linked as Witnesses. The standard sentence for Witness will only output the Witness memo, where my sentence for the default witness custom role of mainDup will (only) output a duplicate of the Principal sentence including the Main Memo. I generally do not include Note tags in formal reports, reserving these tags for incomplete research comments. As of Version 8 I color highlight this tag type.

There are some suggestions to create a separate custom tag type, possibly called NoteSensitive, for sensitive notes to be able to be explicitly excluded from output.91 For such sensitive data I use my custom AnecdoteSens tag type instead.

I chose to change the sentences of this standard tag type for both the Principals and Witnesses to have [M1] specify the number of children as of the Date. This tag can also be used with [M1] having “no children” if a person is known not to have had any offspring. [M2] is a common comment for the Principals, and [WM] for the Witnesses. I choose to have this split memo structure instead of separate custom tags or role sentences for each number. I added the role of Couple to make the printing of a married couple more compact and which adds the [M3] memo only for the male and [M4] only for the female.

The custom NumChildExcl and NumChildSens tag types are used when the data is actually sensitive92 at some level. Except for their sentence template exclusion (see *Excl) and output coloring (see *Sens) they are identical to the standard NumChild tag type. If different text for a standard NumChild tag is also desired, the text for the Excl sentences or Sens sentences should be structured so that the narrative makes sense when both the standard and custom tag types output.

I chose to change the sentences of this standard tag type for both the Principals and Witnesses to have [M1] specify the number of marriages as of the Date. [M2] is a comment for the Principals, and [WM] for the Witnesses. I choose to have this split memo structure instead of separate custom tags or role sentences for each number. Typically there would be only one Principal, but the sentences work with two assuming the count is identical for both parties.

Several suggestions exist for some kind of custom tag type to document the relationships shown in this common source record. One recommendation also uses a custom Place Style called Newspaper with output template: “<[Addressee], ><in the [Newspaper], >printed in< [City], ><[County], ><[State], ><[Country]>” A complex version of a sentence for such a tag type has several roles to cover people mentioned in the obituary. However, I believe that my more general custom Transcript tag type associated with a pseudo source person that is the newspaper to record source information may accomplish much of what this custom tag type is designed to do. Alternatively I may wish to do something as complex as how I record Census data.

I chose to change the sentences of this standard tag type for both the Principals and Witnesses to have [M1] specify the occupation, [M2] provides some detail for the location, [M2] is a comment for the Principals, and [WM] is for the Witnesses.

There has been discussion of the difference between using the standard Occupation tag type with its standard sentence stating the person “was” something specified by its memo versus using the standard Employment tag type with its sentence saying “was employed” with its memo specifying the employer. Having different tag types recognizes that people often have a series of events concerning being employed by someone or somewhere, but seldom an event explicitly describing being an occupation. However, based upon a person’s employment one may also wish to have this tag to describe their occupation.

I chose to disable the standard Ordination tag type with its sentences and replace it with a custom tag type called Ordained due to my choice for the text in the sentences of this tag type.

I chose to change the sentences of this standard tag type for both the Principals and Witnesses to have [M1] specify the details of the list, such as the conveyance (e.g. the name of the ship). [M2] is a comment for the Principals, and [WM] for the Witnesses. While I have customized this tag type, I usually use my customized Immigratn or Emigration tags instead, and simply cite the passenger list as a source.

Added to the Other group, the extremely generic sentences of this custom tag type provides a way to describe either a reciprocal relationship between the two Principals or a non-reciprocal relationship using roles. If the relationship is reciprocal, both [P1] and [P2] use the role Principal and[M1] is required to specify the relationship (e.g. “is a first cousin of”), with [M2] optionally providing details associated with the Date and Location, and [M3] for optional comments. The three parts of the memo allow the template sentence to be used for a variety of reciprocal relationship circumstances. If the relationship is non-reciprocal, the Principal(s) use the role Target and the other people are Witnesses using the role related. Since the main memo parts and the witness memo parts can be different this allows for non-reciprocal wording, e.g. [M1]being “were godparents of” and [WM1]being “was a godchild of”.93 A given person might have multiple tags of this tag type to define relationships to different people.

Because the sentences are so generic, this tag can also be used to specify that two Principals are not related in any close way based on evidence and conclusions. Thus I have not defined a RelatedNil tag type.

This tag type could also be used to identify the relationship of everyone in the dataset to a specific person, such as to the compiler of the dataset (you). However, to avoid hundreds of this tag displaying in that specific person’s (your) Details view, the tag type could define a limited number of roles named for each target person of special interest in that dataset, and set the role for the Principal to that rolename for that copy of this tag type. For example the sentence for rolename Michael might be something like: “[P] is Michael’s [M1]< and also his [M2]>< and his [M3]>”. A tag to document a person’s relationship to Michael would only link the current person as the Principal using this role, and thus avoid having to link Michael to this and every similar tag. The split memo is required since a person could have multiple relationships to the same given target person through different lines. I have not currently populated any of my datasets with such tags, but using the TMG Automatic “Relation” tag (see Preferences / Current Project Options / Other) or the TMG Tools / Relationship Calculator or a Relationship Chart report would help in identifying the relationship(s) and setting up such tags.

In a similar vein, some have proposed adding custom Generation tag(s) that specified the number of generations from a limited number of specific persons in that dataset using whatever algorithm you find appropriate, e.g. yourself and all cousins not removed are 1, parents and their siblings are 2, children are -1, etc. Again, this proposal avoids linking the target person to the tag, but only links the related person as the Principal using the appropriate rolename. A possible sentence for the role of Michael might be: “[P] is in generation [M1]< and in generation [M2]>< and in generation [M3]> based upon [PP] relationship to Michael”. Again the split memo is required since a person could have multiple relationships to the same given target person through different lines. I choose to only keep track of the generation level relative to one person per dataset, and instead use my custom MAIN Flag for this purpose.

Added as a custom tag type to the Other group, its sentences and roles are similar to the Related tag above. Use [M1] to indicate what should be checked for some data, [M2] and [M3] as optional comments about the Principal(s). The Principal role is used for a suspected reciprocal relationship, or one or two Principals on one side of a non-reciprocal relationship are set to the role Target with one or more Witnesses with role(s) related. [WM1] can optionally specify the suspected specific relationship for this Witness, [WM2] and [WM3] are optional comments. The Witness roles source and repository are also defined to link to the appropriate pseudo people. As of Version 8 I use a common color highlight for all Find tag types.

See also my separate write-up on the Research Log and my preferred custom *Find tag types as well as the Research pseudo person. Discussions have proposed defining a set of custom tag types to record the kind of data needed and linked to all people that would be affected by finding that data, as well as possibly linked to pseudo source people and pseudo repository people where it might be found. When the research is completed, could link to a research completed pseudo Year person. As a “lumper” if I were to use such generic custom tag types I think I would prefer a single tag linked to multiple repositories and sources rather than one for each separate combination. Examples of custom tag types (needs lots of work) include:

• ResItem - for tidbits of data that might belong to an as yet unidentified person or surname

• ResCSent / ResCRecd - to document correspondence sent/received, possibly linked to the addressee if they are entered in the dataset

• ResInt - interest notes like “possible father to Mary Ann Leach, 4th-great-grandmother” or “called ‘cousin’ to so-and-so in X’s will -- could be cousin or in-law?”

• ResToDo - can use roles such as Birth, Death, Marriage, Will, Deed, CivilWar, Copied-Birth, Copied-Death, etc. to identify what information is needed

• ResSource - name of book and author in detail field with repository and call number in place fields, linked to location and surname pseudo people. Use roles such as Not in Index, Not Mentioned, Poss Mentioned, Mentioned, and all comments and abstracts in the memo field. Link people with a role of Look for. Alternatively see my Transcript tag.

• ResNote - note about research done to date but usually not intended to print, e.g. “Sources are so far silent on her second marriage, but family history indicates …” or “Frank is known only from the barely-legible headstone that marks his plot next to his presumed mother, …”

Rather than use these custom tag types, another proposal is to pre-insert the tags for the actual event being researched (e.g. Birth, Death, etc.) and use a ToDo role to link the source and repository. I have chosen the method of a tag type in the same group as the normal tag with a name suffix that reflects the need to do research (i.e. my *Find tags) and just changing it to the normal tag type when the research is done.

I renamed as “ResideOrig” and inactivated the standard Residence tag type with its sentences in the “Other” group and made a custom tag type named ResidedAddress to be in the Address group along with the standard Address tag. (While I could have named this custom tag type in the Address group “Residence” once the original tag was renamed, I have adopted a naming practice to not do this.) My Address custom sentences expect to indicate where they are now or associated with a single particular date, and the ResidedAddress sentences where they once lived for a defined period of time with a beginning and end, or with a prefix like “before” or “after” associated with a known beginning or ending. (To describe a move from one address to another see my Moved tags, and my customized Immigratn and Emigration tag are used for a change in country.) Having these two tag types in the same Address group can allow a “now” to very simply be changed to “then”, with a date range, by changing the tag type. It also causes this custom ResidedAddress tag to output the Addressee, Zip/Postal Code, and Phone fields in its tag sentence as part of the standard location variable. I could (but don’t currently) use the date I last identified the information as the [range end] date in Address and record the known date range in ResidedAddress. Due to my usage, Location and Date are required entries for these two tag types, and my sentences reflect that.

Both tag types in the Address group have a custom role of EMail which is used to identify the address of only one Principal. The entire sentence is surrounded by sensitivity braces94 since I currently consider this information sensitive due to the likelihood of e-mail spam. I prefer this as a role in these tag types although others may prefer a separate custom tag type.

Added as a custom tag type to the Other group, its sentences require a Date which is likely a range, and use [M1] to indicate what should be checked for the residence and [M2] the details to help find the residence. The various custom Principal and Witness roles are intentionally similar to the ResidedAddress and Address tag types. [M3] is an optional comment for the narrative of the Principal(s) or the male of the Couple, [M4] for the female. When the data is found it is likely this tag will be changed to the Event-Misc tag type or one of the residence tag types. The Witness roles require [WM1] giving their expected name and possibly relationship to the Principal and provide [WM2] for an optional comment. The Witness roles source and repository are also defined to link to the appropriate pseudo people. Due to my defining both the ResidedAddress and Address tag types in the Address group, I have not yet seen the need for an equivalent AddressFind tag type. I just use this one tag type to indicated needing to find either a residence or an address. As of Version 8 I use a common color highlight for all Find tag types.

This special medical event in a person’s life raises special documentation issues. While you could simply put both names in the given name of the Primary Name-Var tag (e.g. “John/Mary)” or have a Name-Chg tag, TMG only provides one gender flag for a person and does not allow adding custom values. A more complete option may be to have two completely separate “persons’ in the dataset, one of each gender. (For issues concerning a one person method versus a two person method, see also my discussion on Adoption.) A custom SexChgOld tag type could be added possibly in the Death group for the prior person (or possibly also a true Death tag). A custom SexChgNew tag type could be in the Birth group for the new along with the physical DOB in a separate Birth tag with the source being the legal name change. For either “person” you can simply toggle the Primary indicator between the two tags in the Birth or Death groups to have reports with dates as desired. And you could link each “person” to the other either with a custom tag (similar to my custom AdoptLink tag) or as witnesses to appropriate tags. The decision of whether to define one or two “persons” in the dataset for this sex changed individual is similar to the adoption event, and can depend upon how sensitive the event may be. I have not yet had to record such an event, so these are just ideas.

I retain the name of this custom tag type in the Other group to enable me to deal with it separately, but constantly change its sentences, roles, and other characteristics as needed to test various features of TMG. As of Version 8 I set an intentionally very annoying color highlight for this tag type.

These custom tag types are used to link an exhibit (either internal or external) of a transcription extract of some portion of a source to one or more people mentioned in that extract. The Transcript tag type with all its custom sentences is generally always selected for output. The TranscriptExcl tag type with all its sentences having a leading single exclusion marker is also always selected for inclusion but its output is controlled by the exclusion option. The TranscriptSens tag type has its tag name colored and all its sentences not only have a leading single exclusion marker but also have formatting to color the text output in both TMG reports and Second Site pages as for all *Sens types.95 This special tag type exists for truly sensitive information, and I seldom select this tag type for anything other than private TMG reports and Second Site sites. But even if selected it will not output if the excluded output option is not set. Having three tag types with identical roles but different formatting makes it easy to control the output by simply changing the tag type should the sensitivity of the data change.

These tag types are designed to use one each or just one of two Principal roles: Subject and Extract. As of Version 8 I color highlight these tag types. The role Subject is used to link the primary person in the database that is the main subject of the transcript of this portion of the source. If the substance of the transcript is directly focused on more than one main subject, I use the Witness role subjects for all others after the Subject Principal role. If there are subjects there must be a Subject. The role Extract is used to link to a pseudo source person if one has been created for this source, and if used is set to P2. (If there are only two Subjects, and no Extract person, I can put the second person in P2 with the role subjects.) Since a given source could have multiple transcript tags each recording different portions of the source, viewing all the transcript tags in the details of the pseudo source person can identify all portions that have been transcribed. All other people who are not the main focus of this transcript portion but who are mentioned in this extract are linked as witnesses using the role mentioned. As the list of those mentioned could be quite large they are only listed in the Extract and repository sentences.

This somewhat complex sentence structure allows not having to define a source pseudo Extract Principal for a transcript tag since I will always have at least the single Subject Principal. However, I generally use a source pseudo Principal whenever there are multiple tags from the same source. I have also defined the Witness role of repository to link to that pseudo person where the original of the source is located. While the source citation will likely have the Attachment link to the repository of my photocopy, if used this pseudo person link should be to the original source, and its [WM] should indicate where it is found in that repository. This Witness role is usually used when I have not constructed a pseudo Source person for the extract and/or I only have one transcript of that source. With the three different tag types I can select which transcript tags print in most reports or use them just to record the raw information. But I also use the appropriate “normal” tags to record the source information for those narrative sentences. Since these tags are optionally selected to print, I tend to use a special Version 8 tag type color highlight for such tag types. I can have separate custom Individual Narrative reports for excluding some or all transcript tags, or for printing transcript tags for all real people that are Principals and all pseudo people that are Principals or Witnesses to a transcript tag.

Tag Field	Description
P1	Primary subject of the Transcript, assigned the role “Subject”. Additional subject persons all use the Witness role “subjects”
P2	Role “Extract” if there is a pseudo source person. Can be role “subjects” if no source person. If there is no “Subject” person there must be an “Extract” person.
Date	Date or date range covering the events of the extract, or publication date of the source
Sort Date	As above. If multiple Transcript tags are used for a single pseudo source person, use a date range to cause the tags/extracts to sort in their order in the source. One method (see the Book “family”) is to base the second date in the range on the page number of the extract.
Location	Of the events in the extract
Main memo	identifies this particular portion of the source, perhaps using the CD\|\|topic of this extract portion\|\|phrase to follow “transcribed”\|\|identification of the source if there is no linked pseudo source person\|\|how the primary Subject is “referred to”\|\|quoted text about this primary Subject\|\|comment about this primary Subject
subjects Wit. memo	how this additional witness subject is “referred to”\|\|quoted text about this witness subject\|\|comment about this witness subject
mentioned Wit. memo	how the person is “mentioned”\|\|quoted text about this person\|\|comment about this person
repository Wit. memo	Description of the original source in this repository
Citation	to this extract portion as required by source template
Exhibit (internal or external)	The text of this extract of the source, usually as a transcription in a text exhibit structured as [:CR:][LIND:]exhibit text[:LIND]

The tag date and location should refer to the events covered by this transcription extract of the source (not the entire date range covered by the source nor the date of the transcription). The three-part split main tag memo describes this extract. [M1] identifies this particular portion of the source, perhaps using the CD from the source citation. [M2] describes the topic covered by this extract portion (e.g. “details of the wedding ceremony”, or “memories of her youth”) and precedes the optional date (or date range) and location. [M3] is a phrase to follow the word “transcribed” to document the transcriber and/or transcription (e.g. “by Michael Hannah, 9 October 1998”) and is only included in the sentences for the pseudo source person and subjects.

If there is no Principal with the role Extract, then [M4] contains the identification of the source. (While I choose to use my actual TMG source abbreviations since I make them unique, this could be any text identifying the source.) If a source person is assigned the role Extract, then [M4] must be left empty as the source identification will come from the source person’s name. The three split memo fields for the Subject person follow: [M5] is how the Subject is mentioned, [M6] is quoted text about this person from the extract, and [M7] a comment unique to this Subject related to this extract. If there are any Subjects identified there must always be assigned a Principal with the role Subject and with [M5], [M6], and [M7] data. If there are additional multiple main subjects, each is described with their unique split Witness memo. All other people mentioned in the extract are witnesses using the role mentioned with each having their unique three-part split Witness memo. [WM1] is how the person is mentioned, [WM2] is the quoted text about this person in the extract, and [WM3] is a comment unique to this witness. There could be only an Extract Principal person and all other people linked as mentioned.

While a tag type could be designed to have the transcription entered in the memo, the Transcript sentences are designed to have an exhibit (usually a text exhibit) that is the transcription attached to the tag. This method allows multiple Transcript tags linked to one or more subjects and/or a source person, each tag focusing on a particular topic or portion of the source with its set of people as witnesses, and the citation detail of each tag referencing the specific location of this portion of the source for this extract. It also allows separating out any sensitive information from a private source into separate tags with full control over what does and does not output while still recording the information.

If you want the tags sorted in the order their extracts appear in the source, you might use appropriate variations of the Date for the Sort Date (see entering dates). However since I usually have the tag Date refer to the date (or date range) associated with the information in this specific extract, this may not be appropriate or possible as the original source information may not have been arranged in chronological order. Thus an Individual Narrative report including exhibits of the Transcript tags of the source pseudo person might print all the transcribed text for that source in the chronological order of the Sort Dates, but would not necessarily be in publication or page order. If page order is desired and possible, I use the Sort Date “between” scheme also used for the Created tag of multiple Source son’s of a grouping Book Source Person.

The purpose of such a custom tag type is to generate text in the surviving spouse narrative concerning the death of the spouse so that a subsequent marriage sentence makes sense. One suggestion is to add such a custom tag type in the Other group with the widow/er the Principal with a sentence of “[P] was widowed when [PP] spouse died< [D]>”. Another suggestion is to also add this custom Widow(er) tag type to the Divorce group as this is simply expressing the end of a marriage. I link both parties as Principals so the tag shows in both person’s Details, and my sentences for tag types in this group use separate memo parts for each Principal. I have not yet discovered any special reasons associated with a Divorce group tag type to motivate placing another separate tag type in that group.

Instead of using such a custom tag type, I prefer to define a custom optional witness role of widow(er) in the Death or equivalent tags in the Death group for a surviving spouse with the witness sentence gender specific. Whether this witness role is used on the tag is based on whether there is (believed to be) a surviving spouse.

For recording most of these documents I prefer my more generic custom Transcript tag in the Other group. Its Principal role of Subject can be used for the deceased, and its generic Witness role of mentioned can be used to link and identify the relationship of all people mentioned in these documents. TMG provides sentences for the separate standard tag types Will and Codicil (in the Other group) and Probate. (For probably some legacy reason that I do not understand, possibly to sort after Death, Probate is in the Burial group!) However, the will itself can simply be spoken (nuncupative) near the time of death or can consist of many documents and legal actions beyond adding a codicil some time before death. Further, there can be many actions and events involved in the disposition of an estate in addition to a simple probate which may occur long after death. A variety of custom tag types96 have been proposed to deal with these different events, and I include them as possible ideas. If I were to use them, my conventions would have them all start with the characters Will or Estate so they sort together in the Master Tag Type List. These also could be “lumped” into fewer but more generic tag types where the nature of the event is described in a split memo.

• Will - The standard tag type is usually used when a will is written, and may have an exhibit attached of the details of the will. (I have modified these sentences to make use of split memoes, as I have found a few instances where the presence of a will is documented, but I have no transcript.)

• Codicil - The standard tag type when a codicil is added to a will without totally rewriting a will.

• WillAdmin - No will was written and letters of administration are given for someone to probate the estate.

• WillProb - A legal decision (probate) concerning a will or estate, which can happen multiple times if there are clauses that redistribute the will after some future event, such as the later death of a beneficiary.

• Probate - The standard tag type in the Burial group. Some prefer a separate tag in the Other group like WillProb so that it will print in reports that only print Primary tags when there is already a Primary Burial tag.

• EstateSale - When part of the estate is sold to pay debts, usually producing a Bill of Sale or a listing of what in the estate was sold.

• EstateSettle - For the final settlement given to the executor or administrator of an estate.

• EstateDivs - Tells how the estate was divided, sometimes described in a Division of Estate document. If the property has to be sold to pay debts, the final division may be very different than what the will stated, or how the estate was legally settled.

Endnotes
1. This list only includes tag types I have customized, and uses the pre-Version 8 abbreviated Tag Type names, as those are what I still use in my projects. 2. If there is no date, or location, or memo, most blank tags in the Birth group may not print even though the sentence may have meaning. Usually I have at least a date or a location so this is not an issue. As a workaround to ensure the tag prints, add double exclusion marks ‘--’ as the sole content of an otherwise empty memo, and include the memo as a conditional variable in the sentence. 3. An example of the date of the tag in the Marriage group being used to sort families is found in the Descendant Indented Chart. Since blank dates sort before non-blank dates, I recommend at least entering an estimated date for the beginning of the relationship in the Sort Date for any tag in the Marriage group. 4. Need to test what the consequences to a person (reports, charts, etc.) of having Marriage group tag(s) but not having any tag marked Primary. One can force this condition by manually removing the Primary designation. Consequences of doing that have not yet been adequately tested in any version. One can also take obscure actions which will cause more than one tag in the Marriage group to be marked Primary. Consequences of doing that also have not yet been adequately tested in any version. 5. There were ways to easily cause one spouse to have the tag Primary and the other not, but as of Version 8.05 this has been fixed for most common methods for entering these tags. Non-symmetric Primary designations can usually be avoided if both Principals are linked to the new Marriage group tag before doing an OK out of the initial creation of that tag. Since Marriage group tags are designed to link two people, this is an appropriate data entry practice. For more details and ways to detect non-symmetric Primary designations of Marriage group tags see the footnote in the Primary attribute topic below. One can force this condition by manually changing the Primary designation for a tag for only one spouse. 6. A Burial group tag can have two Principals for historical reasons since it was often common for a mother and child who both died during childbirth to be buried together. 7. My old (possibly incorrect) notes suggest that the LIVING flag was not set by adding a Burial group tag in some previous versions, but it is set at least in Version 7.04 and later. 8. Version 4 limit on a Tag Type Label was 10 characters, and Version 5 expanded this to 21. As of Version 6 names were truncated at 20. Since Version 8.05 the maximum is 20 characters for the Label and 23 for a role. Previous versions had side-effects if you entered too many characters, but since Version 6 your entry is truncated to the maximum. 9. My description of each standard tag type indicates whether its name was changed in Version 8. Care should be taken importing an older version project into a Version 8 or later project in case you have created a custom tag type name in the earlier version which happens to be the same as the new expanded Version 8 name. 10. I do not use other languages, and the handling of languages changed in Version 8 with the change in roles, so this comment may be obsolete. Need to test languages in the final Version. 11. See the remaining bug report which describes this behavior. 12. As of Version 7.04 and through Version 8.04, the check for Primary was only done when the tag itself was created. For example, if you later added a spouse as a Principal to an existing Marriage tag, the tag was not marked Primary for that newly linked spouse, even if they had no other tags in the Marriage group. While a couple could have more than one tag in the Marriage group and only one tag among them could be Primary, for a given couple the Primary marker should be symmetric on the same tag. One can force this non-symmetric condition by manually removing the Primary designation, which will be removed only for the focus person and not the spouse. VFI will not correct the non-symmetric condition. As of Version 8.05 whether or not the marriage tag is Primary for the focus person, the Primary designation now is automatically set for the other spouse in either of the two standard conditions: when an existing person is linked as the other spouse to a marriage tag, or when a new spouse person is created and linked from within a marriage tag. An example filter for a List of Events report to find people with any Marriage group tag with non-symmetric Primary designations is as follows (carefully note the parentheses). Identified tags should be carefully reviewed as there are rare cases where non-symmetric Primary designations may be appropriate, especially with multiple tags for the same Principals which are all in the Marriage Group. ( Field \| Subfield \| Operator \| Value \| ) Connect Tag Type Group is \| \| Marriage \| \| AND Principal1… \| ID # \| <> Does not equal \| 0 \| AND Principal2… \| ID # \| <> Does not equal \| 0 \| AND ( Principal1… \| Primary marker \| Off \| \| OR Principal2… \| Primary marker \| Off \| \| ) AND ( Principal1… \| Primary marker \| On \| \| OR Principal2… \| Primary marker \| On \| \| ) END 13. Care should be taken upgrading an earlier project with custom tag role names to Version 8 or later in case you have created a custom tag role name in an earlier version which happens to be the same as the new added Version 8 name. 14. Version 4 limit on a tag type name was 10 characters, and Version 5 expanded this to 21. As of Version 6 names are truncated at 20. The Tag Type “Past tense” field is also a maximum 20 characters, and the Abbreviation (including a trailing ‘.’ if desired) is 4 characters. 15. Marking a tag type as not “Active” only affects whether or not it is listed in the Master Tag Type list, and only based on the option on that list to “Show deactivated tag types”. It may still be used, and may exist in “Add Person” templates. 16. At least one earlier version of the program had a problem with custom tag type names which were not in the Relationship group and had an internal ‘-’ character in the name. While this appears fixed, I choose to only use this special character for tag type names in the Relationship and Name groups for the sake of visual consistency. 17. The names of most Standard relationship tag types were expanded to unabbreviated names in Version 8, and “-Bio” was changed to “-Biological”. 18. I have not (yet) expanded my custom relationship tags to full names, e.g. -Candidate, to match the expanded standard Relationship tag type names introduced in Version 8. 19. Tag types that define such custom relationships are good examples of tag types appropriate to use the new Version 8 tag type color highlight feature to distinguish these custom tag types from “normal” relationships. 20. If you include a Surname Index in Second Site, a mononym name using this custom OneName Name Style with a trailing comma in the Surname Display template will sort correctly among all surnames. Without the comma Second Site will assume there is no surname and sort this person under “(no surname)”. When whatever mononym “surname” entry is clicked in the Surname Index, Second Site opens the full Name Index which lists all people with this surname by their given names. If there is no comma in the template Second Site will now list the (no surname) person’s given name. If there is a comma in the template, since there is no separate given name for this mononym surname Second Site will indicate this absence of a given name by repeating the surname followed by a comma. 21. If the sentence for a tag in the Name group contains an unconditional split memo variable (e.g. [M2] not in conditional brackets) it does not output “an unknown value”. Instead due to a remaining bug it outputs the variable as text (e.g. “[M2]”). 22. Due to a remaining bug, for sentences in tags in the Name group the [P] variable used at the beginning of a new paragraph in a narrative will always output the appropriate pronoun. To output (only) the name part(s) entered in the Name tag use the special [N] variable. 23. Changing to this single-exclusion template works equally well in both programs. Even when Show Excluded Data is selected in either program there is no sentence to output so nothing appears, but inclusion in the index works as expected. 24. The behavior mentioned here was observed by testing versions 6.2 Build 06, 6.2 Build 11 and 6.3 Build 00. 25. See his post on this issue on the Second Site Google group where he indicates that all double-excluded data is intended not to appear in the site. While this specific statement about a Name tag sentence is true, the issue of double exclusion is more complex and pervasive than this one case. See the Second Site HELP documentation for more details. 26. In earlier SS versions, the criteria for inclusion of a name in the index as described in its HELP documentation, and as intended by the author, was not how the program behaved. The name from any tag of the standard types “Name-Variation” or “Name-Married” (“Name-Var” and “Name-Marr” in versions of TMG prior to Version 8) would be included in the index. It did not matter whether or not their global or local sentence was excluded in any way, or whether the SS Data/Database option “Show Excluded Data” was selected or not. They were always included regardless of the Name Style used on such tags. Next, the name from any custom Name tag, or any of the other three standard tag types (Baptism, Change, and Nick), whose global sentence was double excluded and did not have a local sentence defined would always be included in the index whether the SS Data/Database option “Show Excluded Data” was selected or not. This guaranteed inclusion in the index of a double excluded tag was the reason for earlier double-excluded templates in several of my custom Name tags (Name-Index, Name-Marr/Name-Married, Name-Marr-Title, Name-One, Name-Link-Only, and Name-Surname-Sort). Other users also chose this template format when an index entry was desired but no output from the Name tag sentence was wanted. For names from tags of the other three standard Name tag types (Baptism, Change, and Nick) and any custom Name tag types, where the sentence was changed to a different and single excluded local sentence the name was included in the index exactly opposite to what the SS Data/Database option “Show Excluded Data” is intended to cause. The name with this single excluded sentence would not be included if “Show Excluded Data” was checked, but would be included if “Show Excluded Data” was not checked. Finally, names from tags of the other three standard Name tag types (Baptism, Change, and Nick) and any custom Name tag types where the sentence was changed from a non-double excluded global sentence (i.e. non-excluded or single-excluded) to become a double excluded local sentence would never be included in the index, which is the program’s intent. 27. One sentence output bug continued to exist in Second Site, even in this version. For some single excluded local sentences in some Name tag types the SS Data/Database option “Show Excluded Data” was still not honored in this version. In Name tags whose type was neither of the two standard types “Name-Variation” or “Name-Married” (“Name-Var” and “Name-Marr” in versions of TMG prior to Version 8), if the sentence was changed from any form of a global sentence to a different local sentence of a single conditional excluded memo variable “-<[M]>” and the memo was not empty, the memo/sentence would not output when the SS Data/Database option “Show Excluded Data” was selected. “Name-Variation” or “Name-Married” tags with this local sentence were output as expected according to this option setting. This lack of excluded output applied to such local sentences of the other three standard Name tag types of Baptism, Change, and Nick, as well as any custom Name tag type. Otherwise the sentence output of non-Primary Name tag excluded sentences behaved as expected, including honoring this option setting when the global sentence is single excluded with a conditional memo variable and no local sentence is entered. Need to text this again in the latest version 7 of Second Site. 28. Changing to this single-exclusion template works equally well in both programs. Even when Show Excluded Data is selected for narrative output in either program there is no sentence to output so nothing appears, but inclusion in the index works as expected. However, non-narrative output (e.g. Second Site grid-type output) may show the label and date, but the sentence output column is usually empty save for exhibit links or citation references. 29. Originally at www.box.net.au/~johnr/rrlnames.htm but site no longer responds. 30. See the separate topic describing Name Tags-Indexes and Exclusion. 31. The presence of hard-coded text in a template will produce a warning message: “The XXX template includes text that is not within square brackets [like this] to designate it as a field label. Are you sure that you want to save this template?” Just select Yes for those templates where you desire such hard-coded text. 32. Need more testing to decide whether to go back and change all my Location pseudo people’s Primary name tags from my current use of the standard Name-Var tag type with an appropriate Location Name Style to some separate Name tag type, such as this one, only used by Locations. Since I don’t usually include Name-Var tags for printing I have not yet seen a need, but I may wish to have a separate selectable tag type. If so, I might either create a Name-Location tag type for the Primary name to make it separate from the alternate, or add separate roles on this Name-Loc-Var tag type to be used when assigned as the Primary or alternate names to provide appropriately different sentences. 33. Note to self: Need to test and research all my Location pseudo people to see if they have had alternate names and I need to add Name-Loc-Var tags. 34. See also a more complete discussion in the description of the remaining bug concerning narratives of Name-Married tags which are still output even with this option set. 35. Some old notes say not to use the exclusion marker as it doesn’t show in a PE list, but testing shows that an excluded name part shows in the PE even if the option Preferences / Tag Box / Show excluded data is not selected. Some prefer the exclusion marker as it allows selecting whether it shows based on report options in both TMG and Second Site. 36. Note the remaining bug where sensitive data in a Name is always included in an Individual Narrative Index. Also note that Second Site never outputs data marked with sensitivity braces. 37. The presence of hard-coded text in a template will produce a warning message: “The XXX template includes text that is not within square brackets [like this] to designate it as a field label. Are you sure that you want to save this template?” Just select Yes for those templates where you desire such hard-coded text. 38. See the separate topic describing Name Tags-Indexes and Exclusion. 39. For an example, see the custom cemeteryMrs role described in the Burial tag. Note that if the maiden surname has been entered with a separate surname prefix (see Name-Surname-Sort), the [PL] variable will not output that prefix. It must be added manually. 40. The TMG HELP explicitly states that “Conditional brackets and variables cannot be nested” and implies that only one variable may be included within a single set of conditional brackets. However it can be shown as an undocumented feature that if multiple variables are included within a single set of conditional brackets, the text within the brackets is only output if all variables within those brackets have value. These constructs work in both TMG and Second Site. 41. If the husband’s married surname includes a non-empty PreSurname field, then for the spouse I enter two Name-Marr-Title tags with separate entries in [Married]: one with the PreSurname first, and one with the PreSurname last in parentheses (e.g. “van der Gaag” and “Gaag (van der)” 42. Three spaces are required between [SortGiven] and [Married] to match the spaces that surround [Suffix] and [Title] between [SortGiven] and [SortSurname] in the U.S. Standard Name Style. Otherwise these married names will sort last when using a given name sort. 43. For example, see the cemeteryMrs role described in the Burial tag. 44. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. 45. See the separate topic describing Name Tags-Indexes and Exclusion. 46. Once imported it may be necessary to individually change such tag to this custom tag type. If they can somehow be uniquely identified, the TMG Utility may be able to change the tag type in bulk. 47. from Carol Simpson on the TMG ListServ 48. If you want the lack of marriage and lack of children to be clear on reports and/or charts, could create a pseudo unmarried person. 49. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. I accept this for email addresses as I prefer never to include them in on-line sites. 50. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. By having a separate tag type I can still set options to include and output this data in private sites I create for my own use. 51. See the more detailed description of GEDCOM Tag Names in the Import/Export chapter. 52. As of Version 9.02 the variable [R:parents] in the sentence will output both (all) names of people assigned that role. 53. Like the DeathAssumeCrem tag type, my definitions and use of this tag type have evolved over time. 54. The “(Selected)” option did not work in Version 7.04 for either a List of Events or a List of Witnesses. As of Version 8.00, for both reports “Last, Given (Selected)” now outputs the selected Surname and Given Name but also outputs the Suffix name field separated by a comma with no space. “Given Last (Selected)” reflects a remaining bug since it always outputs the Primary Given Name and Surname, not the Selected name. 55. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter. 56. This sentence starts with the concatenation sentence code ‘[+]’ which was introduced in Version 7. 57. Having the cemetery name either linked or in [M4] but not both makes it easy to search for the name of a cemetery in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both. 58. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter. 59. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I generally choose to use a role which does not include an age variable if the Date has a modifier or is incomplete since Second Site will compute the years differerently from TMG or not output such an age value when TMG will. Otherwise I must include the age in the memo. 60. Having the cemetery name either linked or in [M4] but not both makes it easy to search for the name of a cemetery in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both. 61. Note to self: The cemetery and cemeteryMrs roles has so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects. Need to test its use in my other projects. 62. If either the birth or death date for this person is an estimate or incomplete Second Site will either compute the age differently than TMG or not output an age value when TMG will. In these cases if I choose to use only one tag, I manually enter the age for Second Site in [WM4] and add the modifier circa to either the Birth or Death Date since then the [AE] phrase will not output in Second Site. I then locally modify the conditional [WM4] phrase in this tag’s templates to be hidden from TMG to avoid duplication in those reports, e.g. “<died at age [WM4]>” becomes “<[HID:][SS:]; died at age [WM4][:SS][:HID]>”. In most cases splitting into two tags is easier. 63. Note that if the maiden surname has been entered with a separate surname prefix (see Name-Surname-Sort), the [PL] variable will not output that prefix. It must be added manually. 64. While a TMG report will put a space between the name and this [WM1] leading punctuation (e.g. the semicolon), Second Site will not. Since my primary output is Second Site this space in the TMG reports does not bother me. Note also that this leading punctuation does not need to be escaped, although it will have no effect on either program if it is escaped. 65. While the [WM1] leading punctuation does not need to be escaped (altough it doesn’t hurt to do so), any punctuation which is last in a memo part will need to be escaped or TMG reports will remove it. While Second Site does not remove this trailing punctuation the escape causes no harm. (Tested with Second Site Version 6.2 Build 6. Need to test with Build 11 or later.) 66. Note to self: Need to review and test the need for MOTH and FATH in these sentences since my primary output is Second Site which will include links to these “parents”. I have decided I do not want or need them in the Cemetery role or Group role, but need to review other roles and how the Place should be output. 67. Note to self: The cemetery and cemeteryMrs roles and the linkWitness role have so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects, or carefully crafted Created tag sentences. Need to test these uses in my other projects. 68. See the BIRTH ORDER flag discussion in the Style chapter for further details concerning its use with blank dates. 69. Like the DeathAssumeBur tag type, my definitions and use of this tag type have evolved over time. 70. This sentence starts with the concatenation sentence code ‘[+]’ which was introduced in Version 7. 71. Having the crematorium name either linked or in [M4] but not both makes it easy to search for the name of a crematorium in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both. 72. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I generally choose to use a role which does not include an age variable if the Date has a modifier since Second Site will not output such an age value but TMG will. Otherwise I must include the age in the memo. 73. Having the crematorium name either linked or in [M4] but not both makes it easy to search for the name of a crematorium in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both. 74. Note to self: The cemetery and cemeteryMrs roles have so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects. Need to test its use in my other projects. 75. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I need to use a role which does not include an age variable if the Date has a modifier since Second Site will not output such an age value but TMG will. Otherwise I must include the age in the memo. 76. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter. 77. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I need to use a role which does not include an age variable if the Date has a modifier since Second Site will not output such an age value but TMG will. Otherwise I must include the age in the memo. 78. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter. 79. Note to self: I have this tag type only in my main Maternal project. Need to include and test it in my other projects. 80. Note to self: The cemetery and cemeteryMrs roles have so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects. Need to test its use in my other projects. 81. I need to test and identify on which reports the presence of having only some tag type in the Divorce group but none from the Marriage group still implies a marriage/spouse. Also need to test whether this divorce-only spouse shows in the children and siblings view, and whether TMG remembers this last viewed spouse. I believe it will operate as if there is a tag in the Marriage group, but I have not yet tested in any version. 82. Earlier I defined these tag types to allow any number of Witnesses that identified possible people to which this person could be merged. Usage has taught me that I prefer to restrict these tag types to only two people. One reason is that it is easier to simply toggle between two Principals when comparing. If there is more than one other person entity to which this person might be merged, I find it cleaner to add multiple tags. 83. The Bureau of Land Management land patent database <https://www.glorecords.blm.gov/> 84. If a person either has no parents (yet) identified or has some conflict and/or uncertainty among multiple possible candidate parents, then I prefer to ensure that I do not imply that I know these are the parents by listing them in any Marriage group tag’s sentence. I can look for and examine any Principals who still have the default role Principal by running two reports, and decide whether they still should have this role. A List of People report first sets a WORK Flag to ‘Y’ as Secondary Output for all real people with at least one known parent and at most one of each type of parent using the filter conditions: ( Field \| Operator \| Value \| ) Connect ( Father \| Is Known \| \| OR Mother* \| Is Known \| \| ) AND PSEUDO \| = Equals \| N \| AND # of Fathers \| < Is less than \| 2 \| AND # of Mothers \| < Is less than \| 2 \| END Then I run a List of Events report filtered for any one of my four tag types which include both sets of Principal roles, and where one Principal has known parents (WORK = ‘Y’) but the other Principal (still) has the role Principal so is not listing the parent(s). ( Field \| Subfield \| Operator \| Value \| ) Connect ( Tag Type… \| Label \| = Equals \| MARRIAGE \| OR Tag Type… \| Label \| = Equals \| MARR ASSUME \| OR Tag Type… \| Label \| = Equals \| MARR BANN \| OR Tag Type… \| Label \| = Equals \| MARR SETT \| ) AND Principal1… \| WORK#1 \| = Equals \| Y \| AND Principal2… \| Role \| = Equals \| PRINCIPAL \| END It is necessary to run this second report separately for each Principal, reversing which Principal in the last two conditions. I choose as output columns the Principals’ IDs, Flags, and Roles, plus the Tag Type Label and Date to find the desired person and tag. To check if either of the roles Bride or Groom have been inappropriately set, first reset the WORK#1 Flag using the filter: # of Parents \| = Equals \| 0 \| AND PSEUDO \| = Equals \| N \| END then change the last two filter conditions above to: Principal1… \| WORK#1 \| = Equals \| Y \| AND Principal2… \| Role \| = Equals \| BRIDE \| END Run again with the conditions reversed to check if the role Groom has been inappropriately set. 85. If a person either has no parents (yet) identified or has some conflict and/or uncertainty among multiple possible candidate parents, then I prefer to ensure that I do not imply that I know these are the parents by listing them in the spouse’s Marriage group tag’s sentence. I can look for and examine any Principals who still have the role Principal by running two reports. For more details see the footnote to the Marr Assume tag description above. 86. I need to test and review whether I want to see parents in these tag types. If so, it would be consistent to include [PARO] in Bride and Groom roles. 87. If a person either has no parents (yet) identified or has some conflict and/or uncertainty among multiple possible candidate parents, then I prefer to ensure that I do not imply that I know these are the parents by listing them in any Marriage group tag’s sentence. I can look for and examine any Principals who still have the role Principal by running two reports. For more details see the footnote to the Marr Assume tag description above. 88. For identifying multiple census records to find (if only one record use a CensusFind tag) the Location could be a county with [M1] = “1820, 1830, and 1840 census records”, and [M2] = “various household enmerations” or “head of household enumerations”. The FamilySearch repository entry can be a Location with [M1] = “Pedigree Resource”, “Ancestral File”, or “SSDI”; and [M2] = “submitted data” or “a SSAN record”. The FindAGrave repository can be a Location with [M1] = “submitted grave record” and [M2] = “personal and family data”. An actual web site where this information might be found can be referenced in [M4] using the TMG formatting codes. 89. My most common non-Location situation is an identified source rather than a location or repository, such as a book of biographies or a separate web site of a families’ genealogy. The source is cited to this tag, with [M1] mentioning the source (e.g. “Heskett family records”), [M2] describes what kind of data the source contains about this person (e.g. “family data”) and [M4] what specific information you wish to find and record (e.g. “Enter his children’s record from the cited source”). If the data in the source is organized by either Locations or Date, those optional values can be entered to focus the search. 90. There is an issue with the Second Site end-of-sentence processing which requires my use of the special [:NP:] sentence code. Often I have explanatory Memo text ending in a colon, followed by a weblink which begins with “\<”. Without the [:NP:] code the colon is replaced with a period. Also with these Note tags it is not important to me whether the text ends with a period. Because of my use of a separate Second Site “Research Notes” Tag Group for Note tags if the either the main memo for the Principal role or the Witness memo for the Witness role are empty, those people will get an empty bullet in their Research Notes list. 91. For special issues concerning exporting Note tags to GEDCOM, especially with sensitive text, see my Import/Export chapter. 92. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. 93. This tag type’s sentences did not use [R:Target] since prior to Version 9.02 the treatment of R role variables assigned to Principals was inconsistent. [Note to self: Need to reconsider and test these sentences in light of the new more consistent treatment of R role variables assigned to multiple people, as well as possibly using the new S subject variables.] See the discussion of linked people variables. 94. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. 95. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. 96. Many were proposed by Teresa Ghee Elliott on the TMG ListServ.

Endnotes

1. This list only includes tag types I have customized, and uses the pre-Version 8 abbreviated Tag Type names, as those are what I still use in my projects.

2. If there is no date, or location, or memo, most blank tags in the Birth group may not print even though the sentence may have meaning. Usually I have at least a date or a location so this is not an issue. As a workaround to ensure the tag prints, add double exclusion marks ‘--’ as the sole content of an otherwise empty memo, and include the memo as a conditional variable in the sentence.

3. An example of the date of the tag in the Marriage group being used to sort families is found in the Descendant Indented Chart. Since blank dates sort before non-blank dates, I recommend at least entering an estimated date for the beginning of the relationship in the Sort Date for any tag in the Marriage group.

4. Need to test what the consequences to a person (reports, charts, etc.) of having Marriage group tag(s) but not having any tag marked Primary. One can force this condition by manually removing the Primary designation. Consequences of doing that have not yet been adequately tested in any version. One can also take obscure actions which will cause more than one tag in the Marriage group to be marked Primary. Consequences of doing that also have not yet been adequately tested in any version.

5. There were ways to easily cause one spouse to have the tag Primary and the other not, but as of Version 8.05 this has been fixed for most common methods for entering these tags. Non-symmetric Primary designations can usually be avoided if both Principals are linked to the new Marriage group tag before doing an OK out of the initial creation of that tag. Since Marriage group tags are designed to link two people, this is an appropriate data entry practice. For more details and ways to detect non-symmetric Primary designations of Marriage group tags see the footnote in the Primary attribute topic below. One can force this condition by manually changing the Primary designation for a tag for only one spouse.

6. A Burial group tag can have two Principals for historical reasons since it was often common for a mother and child who both died during childbirth to be buried together.

7. My old (possibly incorrect) notes suggest that the LIVING flag was not set by adding a Burial group tag in some previous versions, but it is set at least in Version 7.04 and later.

8. Version 4 limit on a Tag Type Label was 10 characters, and Version 5 expanded this to 21. As of Version 6 names were truncated at 20. Since Version 8.05 the maximum is 20 characters for the Label and 23 for a role. Previous versions had side-effects if you entered too many characters, but since Version 6 your entry is truncated to the maximum.

9. My description of each standard tag type indicates whether its name was changed in Version 8. Care should be taken importing an older version project into a Version 8 or later project in case you have created a custom tag type name in the earlier version which happens to be the same as the new expanded Version 8 name.

10. I do not use other languages, and the handling of languages changed in Version 8 with the change in roles, so this comment may be obsolete. Need to test languages in the final Version.

11. See the remaining bug report which describes this behavior.

12. As of Version 7.04 and through Version 8.04, the check for Primary was only done when the tag itself was created. For example, if you later added a spouse as a Principal to an existing Marriage tag, the tag was not marked Primary for that newly linked spouse, even if they had no other tags in the Marriage group. While a couple could have more than one tag in the Marriage group and only one tag among them could be Primary, for a given couple the Primary marker should be symmetric on the same tag. One can force this non-symmetric condition by manually removing the Primary designation, which will be removed only for the focus person and not the spouse. VFI will not correct the non-symmetric condition.

As of Version 8.05 whether or not the marriage tag is Primary for the focus person, the Primary designation now is automatically set for the other spouse in either of the two standard conditions: when an existing person is linked as the other spouse to a marriage tag, or when a new spouse person is created and linked from within a marriage tag.

An example filter for a List of Events report to find people with any Marriage group tag with non-symmetric Primary designations is as follows (carefully note the parentheses). Identified tags should be carefully reviewed as there are rare cases where non-symmetric Primary designations may be appropriate, especially with multiple tags for the same Principals which are all in the Marriage Group.

( Field | Subfield | Operator | Value | ) Connect

Tag Type Group is | | Marriage | | AND

Principal1… | ID # | <> Does not equal | 0 | AND

Principal2… | ID # | <> Does not equal | 0 | AND

( Principal1… | Primary marker | Off | | OR

Principal2… | Primary marker | Off | | ) AND

( Principal1… | Primary marker | On | | OR

Principal2… | Primary marker | On | | ) END

13. Care should be taken upgrading an earlier project with custom tag role names to Version 8 or later in case you have created a custom tag role name in an earlier version which happens to be the same as the new added Version 8 name.

14. Version 4 limit on a tag type name was 10 characters, and Version 5 expanded this to 21. As of Version 6 names are truncated at 20. The Tag Type “Past tense” field is also a maximum 20 characters, and the Abbreviation (including a trailing ‘.’ if desired) is 4 characters.

15. Marking a tag type as not “Active” only affects whether or not it is listed in the Master Tag Type list, and only based on the option on that list to “Show deactivated tag types”. It may still be used, and may exist in “Add Person” templates.

16. At least one earlier version of the program had a problem with custom tag type names which were not in the Relationship group and had an internal ‘-’ character in the name. While this appears fixed, I choose to only use this special character for tag type names in the Relationship and Name groups for the sake of visual consistency.

17. The names of most Standard relationship tag types were expanded to unabbreviated names in Version 8, and “-Bio” was changed to “-Biological”.

18. I have not (yet) expanded my custom relationship tags to full names, e.g. *-Candidate, to match the expanded standard Relationship tag type names introduced in Version 8.

19. Tag types that define such custom relationships are good examples of tag types appropriate to use the new Version 8 tag type color highlight feature to distinguish these custom tag types from “normal” relationships.

20. If you include a Surname Index in Second Site, a mononym name using this custom OneName Name Style with a trailing comma in the Surname Display template will sort correctly among all surnames. Without the comma Second Site will assume there is no surname and sort this person under “(no surname)”. When whatever mononym “surname” entry is clicked in the Surname Index, Second Site opens the full Name Index which lists all people with this surname by their given names. If there is no comma in the template Second Site will now list the (no surname) person’s given name. If there is a comma in the template, since there is no separate given name for this mononym surname Second Site will indicate this absence of a given name by repeating the surname followed by a comma.

21. If the sentence for a tag in the Name group contains an unconditional split memo variable (e.g. [M2] not in conditional brackets) it does not output “an unknown value”. Instead due to a remaining bug it outputs the variable as text (e.g. “[M2]”).

22. Due to a remaining bug, for sentences in tags in the Name group the [P] variable used at the beginning of a new paragraph in a narrative will always output the appropriate pronoun. To output (only) the name part(s) entered in the Name tag use the special [N] variable.

23. Changing to this single-exclusion template works equally well in both programs. Even when Show Excluded Data is selected in either program there is no sentence to output so nothing appears, but inclusion in the index works as expected.

24. The behavior mentioned here was observed by testing versions 6.2 Build 06, 6.2 Build 11 and 6.3 Build 00.

25. See his post on this issue on the Second Site Google group where he indicates that all double-excluded data is intended not to appear in the site. While this specific statement about a Name tag sentence is true, the issue of double exclusion is more complex and pervasive than this one case. See the Second Site HELP documentation for more details.

26. In earlier SS versions, the criteria for inclusion of a name in the index as described in its HELP documentation, and as intended by the author, was not how the program behaved. The name from any tag of the standard types “Name-Variation” or “Name-Married” (“Name-Var” and “Name-Marr” in versions of TMG prior to Version 8) would be included in the index. It did not matter whether or not their global or local sentence was excluded in any way, or whether the SS Data/Database option “Show Excluded Data” was selected or not. They were always included regardless of the Name Style used on such tags. Next, the name from any custom Name tag, or any of the other three standard tag types (Baptism, Change, and Nick), whose global sentence was double excluded and did not have a local sentence defined would always be included in the index whether the SS Data/Database option “Show Excluded Data” was selected or not. This guaranteed inclusion in the index of a double excluded tag was the reason for earlier double-excluded templates in several of my custom Name tags (Name-Index, Name-Marr/Name-Married, Name-Marr-Title, Name-One, Name-Link-Only, and Name-Surname-Sort). Other users also chose this template format when an index entry was desired but no output from the Name tag sentence was wanted.

For names from tags of the other three standard Name tag types (Baptism, Change, and Nick) and any custom Name tag types, where the sentence was changed to a different and single excluded local sentence the name was included in the index exactly opposite to what the SS Data/Database option “Show Excluded Data” is intended to cause. The name with this single excluded sentence would not be included if “Show Excluded Data” was checked, but would be included if “Show Excluded Data” was not checked. Finally, names from tags of the other three standard Name tag types (Baptism, Change, and Nick) and any custom Name tag types where the sentence was changed from a non-double excluded global sentence (i.e. non-excluded or single-excluded) to become a double excluded local sentence would never be included in the index, which is the program’s intent.

27. One sentence output bug continued to exist in Second Site, even in this version. For some single excluded local sentences in some Name tag types the SS Data/Database option “Show Excluded Data” was still not honored in this version. In Name tags whose type was neither of the two standard types “Name-Variation” or “Name-Married” (“Name-Var” and “Name-Marr” in versions of TMG prior to Version 8), if the sentence was changed from any form of a global sentence to a different local sentence of a single conditional excluded memo variable “-<[M]>” and the memo was not empty, the memo/sentence would not output when the SS Data/Database option “Show Excluded Data” was selected. “Name-Variation” or “Name-Married” tags with this local sentence were output as expected according to this option setting. This lack of excluded output applied to such local sentences of the other three standard Name tag types of Baptism, Change, and Nick, as well as any custom Name tag type. Otherwise the sentence output of non-Primary Name tag excluded sentences behaved as expected, including honoring this option setting when the global sentence is single excluded with a conditional memo variable and no local sentence is entered. Need to text this again in the latest version 7 of Second Site.

28. Changing to this single-exclusion template works equally well in both programs. Even when Show Excluded Data is selected for narrative output in either program there is no sentence to output so nothing appears, but inclusion in the index works as expected. However, non-narrative output (e.g. Second Site grid-type output) may show the label and date, but the sentence output column is usually empty save for exhibit links or citation references.

29. Originally at www.box.net.au/~johnr/rrlnames.htm but site no longer responds.

30. See the separate topic describing Name Tags-Indexes and Exclusion.

31. The presence of hard-coded text in a template will produce a warning message: “The XXX template includes text that is not within square brackets [like this] to designate it as a field label. Are you sure that you want to save this template?” Just select Yes for those templates where you desire such hard-coded text.

32. Need more testing to decide whether to go back and change all my Location pseudo people’s Primary name tags from my current use of the standard Name-Var tag type with an appropriate Location Name Style to some separate Name tag type, such as this one, only used by Locations. Since I don’t usually include Name-Var tags for printing I have not yet seen a need, but I may wish to have a separate selectable tag type. If so, I might either create a Name-Location tag type for the Primary name to make it separate from the alternate, or add separate roles on this Name-Loc-Var tag type to be used when assigned as the Primary or alternate names to provide appropriately different sentences.

33. Note to self: Need to test and research all my Location pseudo people to see if they have had alternate names and I need to add Name-Loc-Var tags.

34. See also a more complete discussion in the description of the remaining bug concerning narratives of Name-Married tags which are still output even with this option set.

35. Some old notes say not to use the exclusion marker as it doesn’t show in a PE list, but testing shows that an excluded name part shows in the PE even if the option Preferences / Tag Box / Show excluded data is not selected. Some prefer the exclusion marker as it allows selecting whether it shows based on report options in both TMG and Second Site.

36. Note the remaining bug where sensitive data in a Name is always included in an Individual Narrative Index. Also note that Second Site never outputs data marked with sensitivity braces.

37. The presence of hard-coded text in a template will produce a warning message: “The XXX template includes text that is not within square brackets [like this] to designate it as a field label. Are you sure that you want to save this template?” Just select Yes for those templates where you desire such hard-coded text.

38. See the separate topic describing Name Tags-Indexes and Exclusion.

39. For an example, see the custom cemeteryMrs role described in the Burial tag. Note that if the maiden surname has been entered with a separate surname prefix (see Name-Surname-Sort), the [PL] variable will not output that prefix. It must be added manually.

40. The TMG HELP explicitly states that “Conditional brackets and variables cannot be nested” and implies that only one variable may be included within a single set of conditional brackets. However it can be shown as an undocumented feature that if multiple variables are included within a single set of conditional brackets, the text within the brackets is only output if all variables within those brackets have value. These constructs work in both TMG and Second Site.

41. If the husband’s married surname includes a non-empty PreSurname field, then for the spouse I enter two Name-Marr-Title tags with separate entries in [Married]: one with the PreSurname first, and one with the PreSurname last in parentheses (e.g. “van der Gaag” and “Gaag (van der)”

42. Three spaces are required between [SortGiven] and [Married] to match the spaces that surround [Suffix] and [Title] between [SortGiven] and [SortSurname] in the U.S. Standard Name Style. Otherwise these married names will sort last when using a given name sort.

43. For example, see the cemeteryMrs role described in the Burial tag.

44. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so.

45. See the separate topic describing Name Tags-Indexes and Exclusion.

46. Once imported it may be necessary to individually change such tag to this custom tag type. If they can somehow be uniquely identified, the TMG Utility may be able to change the tag type in bulk.

47. from Carol Simpson on the TMG ListServ

48. If you want the lack of marriage and lack of children to be clear on reports and/or charts, could create a pseudo unmarried person.

49. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. I accept this for email addresses as I prefer never to include them in on-line sites.

50. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so. By having a separate tag type I can still set options to include and output this data in private sites I create for my own use.

51. See the more detailed description of GEDCOM Tag Names in the Import/Export chapter.

52. As of Version 9.02 the variable [R:parents] in the sentence will output both (all) names of people assigned that role.

53. Like the DeathAssumeCrem tag type, my definitions and use of this tag type have evolved over time.

54. The “(Selected)” option did not work in Version 7.04 for either a List of Events or a List of Witnesses. As of Version 8.00, for both reports “Last, Given (Selected)” now outputs the selected Surname and Given Name but also outputs the Suffix name field separated by a comma with no space. “Given Last (Selected)” reflects a remaining bug since it always outputs the Primary Given Name and Surname, not the Selected name.

55. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter.

56. This sentence starts with the concatenation sentence code ‘[+]’ which was introduced in Version 7.

57. Having the cemetery name either linked or in [M4] but not both makes it easy to search for the name of a cemetery in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both.

58. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter.

59. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I generally choose to use a role which does not include an age variable if the Date has a modifier or is incomplete since Second Site will compute the years differerently from TMG or not output such an age value when TMG will. Otherwise I must include the age in the memo.

60. Having the cemetery name either linked or in [M4] but not both makes it easy to search for the name of a cemetery in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both.

61. Note to self: The cemetery and cemeteryMrs roles has so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects. Need to test its use in my other projects.

62. If either the birth or death date for this person is an estimate or incomplete Second Site will either compute the age differently than TMG or not output an age value when TMG will. In these cases if I choose to use only one tag, I manually enter the age for Second Site in [WM4] and add the modifier circa to either the Birth or Death Date since then the [AE] phrase will not output in Second Site. I then locally modify the conditional [WM4] phrase in this tag’s templates to be hidden from TMG to avoid duplication in those reports, e.g. “<died at age [WM4]>” becomes “<[HID:][SS:]; died at age [WM4][:SS][:HID]>”. In most cases splitting into two tags is easier.

63. Note that if the maiden surname has been entered with a separate surname prefix (see Name-Surname-Sort), the [PL] variable will not output that prefix. It must be added manually.

64. While a TMG report will put a space between the name and this [WM1] leading punctuation (e.g. the semicolon), Second Site will not. Since my primary output is Second Site this space in the TMG reports does not bother me. Note also that this leading punctuation does not need to be escaped, although it will have no effect on either program if it is escaped.

65. While the [WM1] leading punctuation does not need to be escaped (altough it doesn’t hurt to do so), any punctuation which is last in a memo part will need to be escaped or TMG reports will remove it. While Second Site does not remove this trailing punctuation the escape causes no harm. (Tested with Second Site Version 6.2 Build 6. Need to test with Build 11 or later.)

66. Note to self: Need to review and test the need for MOTH and FATH in these sentences since my primary output is Second Site which will include links to these “parents”. I have decided I do not want or need them in the Cemetery role or Group role, but need to review other roles and how the Place should be output.

67. Note to self: The cemetery and cemeteryMrs roles and the linkWitness role have so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects, or carefully crafted Created tag sentences. Need to test these uses in my other projects.

68. See the BIRTH ORDER flag discussion in the Style chapter for further details concerning its use with blank dates.

69. Like the DeathAssumeBur tag type, my definitions and use of this tag type have evolved over time.

70. This sentence starts with the concatenation sentence code ‘[+]’ which was introduced in Version 7.

71. Having the crematorium name either linked or in [M4] but not both makes it easy to search for the name of a crematorium in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both.

72. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I generally choose to use a role which does not include an age variable if the Date has a modifier since Second Site will not output such an age value but TMG will. Otherwise I must include the age in the memo.

73. Having the crematorium name either linked or in [M4] but not both makes it easy to search for the name of a crematorium in [M4]which has been made a pseudo person to identify any tags where I might have failed to link that pseudo person, or incorrectly done both.

74. Note to self: The cemetery and cemeteryMrs roles have so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects. Need to test its use in my other projects.

75. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I need to use a role which does not include an age variable if the Date has a modifier since Second Site will not output such an age value but TMG will. Otherwise I must include the age in the memo.

76. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter.

77. Originally I used the variable [A] but changed this variable to [AE] due to the behavior of [A] when the dates are incomplete. But I need to use a role which does not include an age variable if the Date has a modifier since Second Site will not output such an age value but TMG will. Otherwise I must include the age in the memo.

78. This is true of any memo, but since I output these memo parts in charts I will encounter the remaining bug invoked by a truly empty [M1]. For further details see the Empty Split Memo Parts topic in my Tag Sentence Details chapter.

79. Note to self: I have this tag type only in my main Maternal project. Need to include and test it in my other projects.

80. Note to self: The cemetery and cemeteryMrs roles have so far only been added to my primary Maternal project as I have not yet added Cemetery people to my other projects. Need to test its use in my other projects.

81. I need to test and identify on which reports the presence of having only some tag type in the Divorce group but none from the Marriage group still implies a marriage/spouse. Also need to test whether this divorce-only spouse shows in the children and siblings view, and whether TMG remembers this last viewed spouse. I believe it will operate as if there is a tag in the Marriage group, but I have not yet tested in any version.

82. Earlier I defined these tag types to allow any number of Witnesses that identified possible people to which this person could be merged. Usage has taught me that I prefer to restrict these tag types to only two people. One reason is that it is easier to simply toggle between two Principals when comparing. If there is more than one other person entity to which this person might be merged, I find it cleaner to add multiple tags.

83. The Bureau of Land Management land patent database <https://www.glorecords.blm.gov/>

84. If a person either has no parents (yet) identified or has some conflict and/or uncertainty among multiple possible candidate parents, then I prefer to ensure that I do not imply that I know these are the parents by listing them in any Marriage group tag’s sentence. I can look for and examine any Principals who still have the default role Principal by running two reports, and decide whether they still should have this role. A List of People report first sets a WORK Flag to ‘Y’ as Secondary Output for all real people with at least one known parent and at most one of each type of parent using the filter conditions:

( Field | Operator | Value | ) Connect

Then I run a List of Events report filtered for any one of my four tag types which include both sets of Principal roles, and where one Principal has known parents (WORK = ‘Y’) but the other Principal (still) has the role Principal so is not listing the parent(s).

( Field | Subfield | Operator | Value | ) Connect

It is necessary to run this second report separately for each Principal, reversing which Principal in the last two conditions. I choose as output columns the Principals’ IDs, Flags, and Roles, plus the Tag Type Label and Date to find the desired person and tag.

To check if either of the roles Bride or Groom have been inappropriately set, first reset the WORK#1 Flag using the filter:

# of Parents | = Equals | 0 | AND
PSEUDO | = Equals | N | END

then change the last two filter conditions above to:

Run again with the conditions reversed to check if the role Groom has been inappropriately set.

85. If a person either has no parents (yet) identified or has some conflict and/or uncertainty among multiple possible candidate parents, then I prefer to ensure that I do not imply that I know these are the parents by listing them in the spouse’s Marriage group tag’s sentence. I can look for and examine any Principals who still have the role Principal by running two reports. For more details see the footnote to the Marr Assume tag description above.

86. I need to test and review whether I want to see parents in these tag types. If so, it would be consistent to include [PARO] in Bride and Groom roles.

87. If a person either has no parents (yet) identified or has some conflict and/or uncertainty among multiple possible candidate parents, then I prefer to ensure that I do not imply that I know these are the parents by listing them in any Marriage group tag’s sentence. I can look for and examine any Principals who still have the role Principal by running two reports. For more details see the footnote to the Marr Assume tag description above.

88. For identifying multiple census records to find (if only one record use a CensusFind tag) the Location could be a county with [M1] = “1820, 1830, and 1840 census records”, and [M2] = “various household enmerations” or “head of household enumerations”. The FamilySearch repository entry can be a Location with [M1] = “Pedigree Resource”, “Ancestral File”, or “SSDI”; and [M2] = “submitted data” or “a SSAN record”. The FindAGrave repository can be a Location with [M1] = “submitted grave record” and [M2] = “personal and family data”. An actual web site where this information might be found can be referenced in [M4] using the TMG formatting codes.

89. My most common non-Location situation is an identified source rather than a location or repository, such as a book of biographies or a separate web site of a families’ genealogy. The source is cited to this tag, with [M1] mentioning the source (e.g. “Heskett family records”), [M2] describes what kind of data the source contains about this person (e.g. “family data”) and [M4] what specific information you wish to find and record (e.g. “Enter his children’s record from the cited source”). If the data in the source is organized by either Locations or Date, those optional values can be entered to focus the search.

90. There is an issue with the Second Site end-of-sentence processing which requires my use of the special [:NP:] sentence code. Often I have explanatory Memo text ending in a colon, followed by a weblink which begins with “\<”. Without the [:NP:] code the colon is replaced with a period. Also with these Note tags it is not important to me whether the text ends with a period. Because of my use of a separate Second Site “Research Notes” Tag Group for Note tags if the either the main memo for the Principal role or the Witness memo for the Witness role are empty, those people will get an empty bullet in their Research Notes list.

91. For special issues concerning exporting Note tags to GEDCOM, especially with sensitive text, see my Import/Export chapter.

92. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so.

93. This tag type’s sentences did not use [R:Target] since prior to Version 9.02 the treatment of R role variables assigned to Principals was inconsistent. [Note to self: Need to reconsider and test these sentences in light of the new more consistent treatment of R role variables assigned to multiple people, as well as possibly using the new S subject variables.] See the discussion of linked people variables.

94. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so.

95. Note that Second Site never outputs any data marked with sensitivity braces, there is no option to do so.

96. Many were proposed by Teresa Ghee Elliott on the TMG ListServ.

I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke, nor with John Cardinal, author of several TMG after-market programs. I am simply a satisfied user of these software packages and have constructed these documents to aid me in their use.

If others find these documents useful, so much the better. I do not warrant in any way that they are accurate or useful, and any use of them is at the user’s own risk.

These documents were composed with Adobe^® Framemaker 2019^® using its hyperlink and "Save as HTML" conversion features.

FF:	[NAME OF PERSON] [RECORD TYPE]<; certificate #[FILE NUMBER],><[ITAL:][TITLE][:ITAL].> [AGENCY]; [REPOSITORY], [REPOSITORY ADDRESS].
SF:	[NAME OF PERSON], [RECORD TYPE]<; certificate #[FILE NUMBER];> [REPOSITORY], [REPOSITORY ADDRESS].
B:	[REPOSITORY ADDRESS]. [REPOSITORY]<. [ITAL:][TITLE][:ITAL].>